🚀 go-pugleaf

I just read Bob Campbell's message from Dec 11 and I really feel I should
give some comments on that:

He seems to be VERY fond of compiler options and in particular suggests
several compiler options to beef up the language a bit - his main point
being that a compiler not supporting these features still can compile these
programs, as compiler options are nothing but comments to it. This is one
of the WORST proposals I have seen on this bboard so far!! The idea is to
standardize the language, not to add tons of different extensions that can
somehow be activated through the use of some obscure compiler-options. Now
if one really wants to add features to the language, then I feel it shoud
be done in an ORDERLY and STANDARDIZED manner - and so far I have yet to
see any language where ALL compiler options are nicely standardized!

Some more comments:
- INLINE code : I don't think it is a good idea to add a complete assembler
  to existing modula-compilers; I'd rather prefer a clean interface to
  modules/procedures compiled (assembled) in other languages.
- EXCEPTIONS: It is well-known that the exception mechanism in PL/I
  (dynamically associated exception-handlers) had some serious drawbacks
  which made it practically useless. Thus, one tends to favour statically
  associated exception-handlers (as in CLU or ADA). I don't really think
  one could include an exception-mechanism like the one found in these two
  languages by just providing some library module. The setjmp()/longjmp()
  functions in C are in any case HIGHLY UNSTRUCTURED and violate the
  philosophy of modern structured languages.

So the bottom line is: If you want extensions, then you better had do it
RIGHT in the first place, else leave them out!

Alexander Klaiber
(klaiber@dewey.udel.edu)

<usual disclaimers etc...>