Re: Simple Pascal question

In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

On 8/4/2024 8:22 AM, Dan Cross wrote:

In article <v8lpj0$ems$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt  <UliBellgardtsSpamSink@online.de> wrote:

The value 1.5 should be an f_float value as well:
>
$ type zzz.pas
program z(input,output);
>
var
    x : f_float;

>
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it?  I don't remember ever having to manually coerce
anything.  Or is f_float sufficiently different from a normal float?

 
Just to touch on the Pascal point itself, one of that language's
hallmarks is almost excessive rigidity in how it treats types.

>
Ada is even more strict.

Rust even more so.

While integer->float conversions are implicit, the opposite is
not.  I think that the general rule is that when a type "widens"
conversion is implicitly ok (so in mathematics, when the
integers are a proper subset of the reals, so every integer is
already a real, and implicit conversion from int to real is
intuitive, even though representations on physical computers
aren't quite so neat for implementation reasons), but when types
narrow, as in when going from real to int, one must exercise
more caution.

>
Such a restriction is rather common today.

Yup.  Because it turns out that it's usually a good idea.  Even
among integers implicit conversions can be surprisingly lossy,
if one is converting to a narrower type.

An old annoyance about Pascal was that the size of an array is
part of it's type, which makes writing functions and procedures
that work across differently sized arrays challenging.

>
In original Wirth Pascal. Most implementations has solutions.

Note I said "an old annoyance".  Emphasis on old.
https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html

Of course, to do practical work, people extended the language.
E.g., TurboPascal.

[snip]

Interesting, this has become du jour again in modern languages,
but those tend to provide access to a `slice` type that provides
a window onto the underly array, and implicitly encodes a
length (and usually a "capacity").  This makes working with
arrays in such languages very convenient.

>
Different people may have different opinions on what is a modern
language.

Designed in this century.

But a lot of the widely used static typed languages does not
have any problems with arrays of different lengths as they
are treated as objects.

Like I said, modern languages make this a solved problem.

Like:
>
public class FlexArray {
    private static void dump(int[] a) {
        for(int v : a) {
            System.out.printf(" %d", v);
        }
        System.out.println();
    }
    public static void main(String[] args) throws Exception {
        int[] a1 = { 1 };
        int[] a2 = { 1, 2 };
        int[] a3 = { 1, 2, 3 };
        dump(a1);
        dump(a2);
        dump(a3);
    }
}

Java arrays are more like the aforementioned slices.

- Dan C.