🚀 go-pugleaf

From hutch%citron.cs.clemson.edu@hubcap.clemson.edu (David Hutchens):
>>> 	z := x ** 3;
>>>   which, of course (:-) generates the message "Ambiguous Expression".
>>>     [...] there are 2 distinct ** operators, so the compiler doesn't
>>>     know which to pick!"
>>  Actually, the compiler does know...
>
> (By the way, I tried this example on several of the early "validated"
> compilers and they ALL worked the way I stated.  I don't happen to
> know if the compilers were broken at the time or they changed the spec
> of the language ... but I think the latter.)

    This would imply that validation certificates were being given
    to compilers built to the 1980 Preliminary LRM rather than to
    the 1983 ANSI/ISO-approved "Final" LRM, which I tend to doubt
    rather seriously.  The early compilers did have quite a few
    problems, due in part to the fact that the early validation
    suites were not very extensive at the time, but now that the
    "second generation" highly optimizing Ada compilers are hitting 
    the market, compiler maturity is not so much of an issue any more. 

> So I was wrong in the specifics, but even more right in the intent
> because the designers had to gum up the language specification to get
> it to work the way people would feel most comfortable.

    Actually, even with the situation you described, there would
    still be a means of resolving the situation: assuming that the
    exponentiation functions followed the general rule (both parameters
    of the same type), the type of x would determine the exponentiation 
    function to use.  Since the 3 is a constant of type universal_integer,
    it would be capable of matching whatever integer type was required, 
    be it short, regular, long, or whatever.  In order to get a problem,
    it would therefore be necessary for the _user_ to define a new "**"
    function with parameters of different types.

    Therefore, I am again led to the conclusion that the error was
    the result of immature compilers and immature validation suites. 

> I don't think keywords are the only source of inexperienced user
> frustration with large languages.

    Certainly not; there are some very irritating problems with Ada 83
    such as the inability to define an ADT's Destroy routine such that
    the routine is automatically invoked upon block exit, but this is
    being addressed right now via the Ada 9X scheduled revision process.

    Of course, Ada 83 can almost always provide a good workaround 
    (in the above example, by having the user invoke Destroy at
    the end of the block), and this is absolutely nothing compared 
    to the total frustration of using smaller languages like Modula-2 
    which do not permit generic ADTs at all.  


    Bill Wolfe, wtwolfe@hubcap.clemson.edu