Re: Complex numbers & Oakwood suggestions

[acken@informatik.uni-kl.de]

>  Date: Mon, 5 Feb 96 18:23:47 +1000
>  From: Frank Copeland <fjc@wossname.apana.org.au>
>  
>  I think there is a big difference between implementing a compiler
>  and designing a language, and this sort of thing is clearly in the
>  realm of language design. I have no particular objection to complex
>  numbers or any other construct that may or may not go into a
>  language, but there are wider issues to consider. Like it or not,
>  Oberon-2 is now quite well-defined and widely implemented. Few of
>  those implementations have chosen to extend the core language. In
>  my experience no matter how well-intentioned an extension is, it
>  becomes a positive barrier to portability, and I happen to think
>  portability is important. 

I agree with your portability considerations.  Compilers that do not
keep to the standard aren't worth IMO considering.  An example for
this is the Amiga Oberon system.  About 4-5 years back my interest in
it died abruptly when I found out about it's peculiar notion of the
Oberon language (its implementor even modified the syntax, eg to have
C like designators--a very sick idea).  
  Here comes the `but': Oberon-2 isn't suited for technical
computations involving complex math.  It's a nice, simple, easy to use
general purpose language that lacks a lot of features you would like
for not-even-so-special problems.  If it had all those features it
would be large, complex, and ugly.  And I would never even spent a
minute contemplating to write a compiler for it.  
  But out there are a lot of people that do use complex math.  And
anyone relying on Oberon-2 to do heavy duty complex math is probably
mad from the start or will go crazy in the process of doing it.  My
point is simple: Either we agree that O2 isn't the language of choice
for such computations, get rid of all the complex maths libs (since
noone will use them anyway), and tell everyone to use another
language.  Or we go a tiny step further give those people a little
more comfort by providing them (a tiny part of) the notation they are
used to.  Only in the latter case full-fledged complex libs are a
worthy addition to the compiler, otherwise they are nothing but nice,
but not-so-helpful toys.
  I wouldn't have brought up this discussion if the Oakwood Guidelines
wouldn't show how this extension can be smoothly integrated into the
language.  So, the design issue isn't really an issue.  The
implementation is very simple, too, and adds no complexity to the
compiler worth talking of.  This covers the problems I'm worried
about.
  And finally:  I _do_ want to win over the `techheads' out there that 
can make proper use of the COMPLEX extension.  Do you really want to
them to flock to the C++ banner?

-- mva

PS: Funny to remember that I started this thread with a statement
    along the lines of "I don't really care about complex math..."  ;-)