Re: Language design question

flisakow@ricotta.cs.wisc.edu (Shaun Flisakowski) asked:
> It seems that with strong typing, there is no need for a dereferencing
> operator, as the compiler could add these automatically. (I'd still
> have an address-of operator)


To which our esteemed moderator wisely replied:
> [This sounds a lot like Algol 68 coercion. -John]


I once read a wonderful commentary on this. Something to the
following effect:


        PL/I made conversions automatic. Reading a PL/I program is like
        trying to insert the necessary casts without any hints.


        Algol 68 make pointer coercions automatic. Reading an Algol 68
        program is like trying to insert the necessary dereferences without
        any hints.


        Some third language made something else automatic. . . .


The point of the commentary is not that the compiler can't do it.
It's that the reader (maintainer) of the program also has to do it.
It is much easier for a reader to see what is going on if the writer
has to be explicit.


Now, this is not a universal truth. There are some programs that are
easier to read because by omitting some transformation allows the
reader to see more clearly what the author intended. For example,
sometimes the conversions that a PL/I compiler supplies are exactly
the right ones, and the user is left with a less cluttered program.


However, if the program is doing the wrong thing, which is generally
the case if a maintainer is looking at it, one of the things the
maintainer has to determine is whether the wrong thing is happening as
the result of an unintended conversion (coercion, etc.). Thus, the
reader has to mentally insert the same things the compiler does.
Sometimes, that is tricky. Worse, sometimes our reasoning processes
fail us and we infer something different than the compiler does
causing us to see problems where they aren't or miss problems that
occur.


Therefore, if I were in your shoes and designing a language where
something could be left out because the compiler can infer it. I
would specify the language at two levels, a user level and a reference
level. The user makes the thing that can be inferred optional, but
allows the users to specify it if they want. The reference level
requires the thing to be specified. The language is specified in
terms of the reference level and explicitly explains the rules the
compiler must use to infer the reference level from the user level.
In addition, the language should require the compiler to provide an
option the produces a reference level copy of the source code from a
user level copy.


The users can then program in the user level code and take advantage
of its terseness. However, the users also have access to the
reference level source code when they want to understand exactly what
the code is doing.


When porting the code, the reference level version is the one to use,
since it eliminates the ambiguities of the user level version and that
should better enable the new compiler to match the semantics of the
previous compiler. I can't count the number of times I've seen C bugs
reported because the user was unaware that they were depending on the
order that their previous compiler (or optimization level) ordered the
side-effects in a statement. One of those places that C lets
compilers infer what the user intended.


Now, if you'll excuse this person who find himself becoming a crotchety
old man (before what he believes to be his time), . . .
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------
Web Site in Progress: Web Site : http://world.std.com/~compres
[Doesn't sound crochety to me. My favorite PL/I type conversion example:
Declare A, B, and C as three-character strings. B='123';C='456';A=B+C;
What does A contain? PL/I automatically coerces strings to decimal numbers
in arithmetic context, so it correctly converts B and C and adds them to
get 579. Then it converts it back to a string of a default length,
which is ' 579'. Then it truncates the string from the right, so the
result is ' '. Oops. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.