🚀 go-pugleaf

The  following proposals  we find  acceptable, though  we don't  have a strong
opinion of most of  them:   WG104, WG007,  WG086, WG012,  WG099, WG132, WG089,
WG041, WG074, WG080, WG050, WG051, WG056, WG003,  WG061, WG114,  WG115, WG116,
WG120, WG102, WG121, WG122, WG109, WG110.  

The following proposals we explicitly welcome:   WG088,  WG126, WG015, WG131,
WG034, WG075, WG117, WG069.  

The following proposals we find problematic or of dubious value:

WG106, case (ii):  We believe that this would be too big a change.  Like it or
not, Modula-2 is a spartan language, equipped only with minimum features.  A
UCSD-Pascal-like string type would  be contrary  to the  general philosophy of
the language.  Proposal WG106, case (i) we agree with. A shorter name should be
found for StringTerminator. EOS, end of string, is one possibility.

WG035: What are "the constants N and W"?

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.  the same holds for PROCEDURES, RECORDs and ARRAYs.  

WG113:  Does that mean,  the language  should not  allow one-pass compilation?
Whether or not  one-pass compilers  are a  good idea  is probably  a matter of
taste, fact is that they will need the FORWARD construct.  Excluding this from
the language means, however, that  it is  impossible to  keep certain programs
portable.  The standard should enhance portability of  Modula-2 programs, not
prevent it!

WG118:    Why  should MIN  and MAX  not work  for REALs?   What  is the "other
mechanism to deliver the various characteristics of the type REAL"?

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

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.

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.

WG110:  We support these proposals.  However  we would  like to  point out the
necessity of exporting constants of opaque types, at least a  null value (e.g.
"CONST Null = OpaqueType (NIL);") should be exportable.

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