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: References: 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 , Arne Vajhøj wrote: >On 8/4/2024 8:22 AM, Dan Cross wrote: >> In article , >> Scott Dorsey wrote: >>> In article , >>> Uli Bellgardt 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.