Xref: utzoo comp.lang.misc:7357 comp.arch:21960
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!mtxinu!taniwha!paul
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Algol68
Message-ID: <811@taniwha.UUCP>
Date: 9 Apr 91 18:47:52 GMT
References: <9168@castle.ed.ac.uk> <4202@zaphod.UUCP> <801@taniwha.UUCP> <4217@zaphod.UUCP> <809@taniwha.UUCP> <1991Apr08.235109.11628@ZYX.SE>
Reply-To: paul@taniwha.UUCP (Paul Campbell)
Followup-To: comp.lang.misc
Organization: Taniwha Systems Design, Oakland
Lines: 52

In article <1991Apr08.235109.11628@ZYX.SE> bd@ZYX.SE (Bjorn Danielsson) writes:
>In article <809@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:
>> [text deleted]
>>
>>	union([]int , struct (int a, b, c)) fred = (1,2,3);
>That example isn't a legal Algol-68 declaration: the source (right-hand part)
>must be the coercee of a "united to" coercion in order to be acceptable as a
>union value for the identity-declaration. But the syntactic "sort" of a
>"united to" coercend is "meek" according to section 6.4.1.a, and a collateral
>clause like "(1,2,3)" is only allowed in a "strong" position according to
>section 3.3.1.

But STRONG is defined to be (amoung other things) FIRM (6.1.1A)
which is defined to be (amoung others) MEEK (6.1.1B).

An easier way to understand it is on page 93 where it states (in the
explanation): 'In a strong position all 6 coercions can occur'.

Basicly the idea is that the coercions have to be unambiguous, the strong
meek etc positions desrcibe places where a coercion might be ambiguous
and therefore the compiler wouldn't know what to do. The reason the above
problem occurs is because there are two forms of the collateral clause
(3.3.1d and 3.3.1e) which can in some circumstances be ambiguous.

Gee it's a long time since I delved into the Report (urgh - 10 years so
I'm probably a bit rusty)

In a strong position the compiler always knows which type it's coercing to,
in a firm position it has a list to choose from (eg the parameters from a
list of overloaded operators), meek ones are limited mainly because the
required type is known to be very simple because of it's syntactic position
(ie an array subscript or the selection expression in an if statement),
soft positions are the place where ambiguity is most to be avoided since
the resulting types are used to create a strong position for another
expression (ie a in a := b).

All in all I hate coercions, they are a real pain in the butt, give me
the C 'a = *b' any day, not only is it easier to compile, typecheck etc
but the programmer can see what's going on easily. Note that most languages
[except a few like Bliss] still have dereference coercions in assignments,
but just one (so the C 'a = b' is really the Bliss 'a = .b'). Other places
where coercions pop up are in float<->int changes and Pascal calls
of functions without parameters (C requires an explicit call - hooray!).

	Paul

(Followups to comp.lang.misc)
-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P

"But don't we all deserve.
 More than a kinder and gentler fuck" - Two Nice Girls, "For the Inauguration"