Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!unisoft!dual!ptsfa!vixie!paul
From: paul@vixie.UUCP (Paul Vixie Esq)
Newsgroups: net.lang.mod2
Subject: Re: Significant Changes to M2
Message-ID: <191@vixie.UUCP>
Date: Fri, 7-Nov-86 04:27:47 EST
Article-I.D.: vixie.191
Posted: Fri Nov  7 04:27:47 1986
Date-Received: Sun, 9-Nov-86 02:59:32 EST
References: <8610201143.1439@ur-cayuga.arpa> <163@unc.unc.UUCP>
Reply-To: paul@vixie.UUCP (Paul Vixie Esq)
Organization: Vixie Enterprises, San Mateo, CA
Lines: 69

In article <163@unc.unc.UUCP> hinrichs@unc.UUCP (Klaus Hinrichs) writes:
>
>	[...] Proposal WG106, case (i) we agree with. A shorter name should be
>found for StringTerminator. EOS, end of string, is one possibility.

	Yes!

>WG073:    What's  the  use  of  returning  pointers,  when they  cannot be de-
>referenced?  If there is no way they can be used, returning them should not be
>allowed.

	Pointers can be dereferenced, but the pointer value returned from
	the function must be put into some variable somewhere first.  Thus

		x := foo()^.bar;

	is not a valid expression, but

		z := foo();
		x = z^.bar;

	is quite acceptable.

>WG113:  Does that mean,  the language  should not  allow one-pass compilation?
>   [...] The standard should enhance portability of  Modula-2 programs, not
>prevent it!

	Agreed.  Put FORWARD into the language.  Wirth likes it.  I like it.

>WG119:  SIZE should accept type parameters as well as variable parameters.
>There should be no TSIZE.

	Oops, what about times when you have a variable and a type of the
	same name?  They are in different namespaces, and are allowed to
	duplicate without collision.  You need different syntax to refer
	to the different namespaces.

>WG085:    The NEW  and DISPOSE  procedures do  have the  undesirable effect of
>producing side effects.   However, they  have one  great advantage:   they are
>safe.    It is  a bad  idea to  make the  user responsible  for something, the
>compiler can (and should) do.

	Safe from what?  NEW causes an implicit ALLOCATE call, and DISPOSE
	causes an implicit DEALLOCATE.  If you don't import these two functions
	from somewhere, your code won't compile.

	Leave the magic out!  If there were a standard macro preprocessor for
	M2, people could do NEW and DISPOSE as implicit ALLOCATE and DEALLOC
	calls themselves... if you must have magic, make it more generally
	available and usable.

>WG084: We prefer to have both possibilities. If an export list is given only
>the identifiers listed in the export list are exported. If the export list is
>omitted all identifiers defined in the definition module are automatically
>exported.

	This could have surprising side effects.  Defining part of a language
	as "if you don't mention this subject, I'm going to do all kinds of
	things without telling you" is very dangerous.  If you want a way to 
	"export all identifiers", find an EXplicit syntax for it...

>Ed Biagioni		seismo!mcnc!unc!biagioni	biagioni@cs.unc.edu
>Gernot Heiser		mcvax!cernvax!ethz!gridfile
>Klaus Hinrichs		seismo!mcnc!unc!hinrichs	hinrichs@cs.unc.edu 
>Peter Schorn		seismo!mcnc!unc!schorn		schorn@cs.unc.edu

-- 
Paul A. Vixie       arpa: paul@vixie.UUCP, nike!ptsfa!vixie!paul@seismo.CSS.GOV
San Mateo, Calif    uucp: {ptsfa,qantel,fortune,crash,winfree}!vixie!paul