Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!ll-xn!cit-vax!elroy!smeagol!usc-oberon!sdcrdcf!ism780c!darryl
From: darryl@ism780c.UUCP
Newsgroups: comp.lang.modula2
Subject: Ambiguity?
Message-ID: <4839@ism780c.UUCP>
Date: Tue, 9-Dec-86 20:05:30 EST
Article-I.D.: ism780c.4839
Posted: Tue Dec  9 20:05:30 1986
Date-Received: Sun, 14-Dec-86 02:09:00 EST
Reply-To: darryl@ism780c.UUCP (Darryl Richman)
Distribution: net
Organization: Interactive Systems Corp., Santa Monica, CA
Lines: 28


Does VAL introduce an abiguity into Modula-2?  Consider:
    :
    :
PROCEDURE Foo: INTEGER;  BEGIN RETURN 0; END;
    :
...VAL(POINTER TO ..., Foo)...;

How does the compiler decide whether "Foo" in this position denotes a
PROCEDURE or the INTEGER returned from an invocation of Foo?  I realize that
VAL is particularly machine dependent, and that my example above may only have
meaning for a particular, known, implementation;  even so, this appears to be
allowed and ambiguous.  In particular, I wonder why Wirth allows invocation to
be specified with or without the empty argument list;  this redundancy seems
particularly strange when contrasted with the spareness of the rest of the
language.

	    --Darryl Richman, INTERACTIVE Systems Corp.
	    ...!cca!ima\
			>-!ism780c!darryl
	    ...!sdcrdcf/
	    The views expressed above are my opinions only.

P.S.  The implementation I use, from Wirth's group, has an "implementation
restriction" and requires that I include the empty argument list when I want
an invocation.  In ambiguous circumstances such as this, I must code
"VAL(POINTER TO..., ADR(Foo))", if I want the PROCEDURE and "VAL(POINTER
TO..., Foo())" if I want the invocation.