Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: Simple Pascal question
Date: Mon, 5 Aug 2024 00:09:48 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <v8p58c$gmo$1@reader1.panix.com>
References: <v8goeh$2b5op$1@dont-email.me> <v8lpj0$ems$1@panix2.panix.com> <v8nrp9$3tp$1@reader1.panix.com> <v8o4h8$2ut3$1@dont-email.me>
Injection-Date: Mon, 5 Aug 2024 00:09:48 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="17112"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4150
Lines: 94

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.