🚀 go-pugleaf

In article <315C2FA0.995@cis.uab.edu> Mycroft <drake@cis.uab.edu> writes:
> Richard Pitre wrote:
> > 
> > Why leave out complex numbers and complex
> > transcendental functions? Maybe Oberon is slightly simpler without this
> > but any programs that use complex arithmetic are automatically more  
complicated
> > and less efficient without language support.
> > I see no good argument for leaving complex arithmetic out of Oberon
> > if you've already gone to the trouble to include  floating point numbers.
> > Why alienate so many people who desparately need good tools like this?
> > If you don't think its a problem then its because you've never tried
> > to do it. The readability goes to hell.
> > 
> > richard
> Have you ever wondered why complex numbers are not a part of C, C++, Ada, 

  Every C++ compiler that I've ever used comes with type complex in its
  libraries. I believe that it is part of the C++ standard such as it is.
  Ada includes it in a standard annex. Both C++ and Ada have
  overloaded the necessary operators in the same way that everyone else
  does, including Oberon, for integer and float arithmetic. 

> or
> Smalltalk?  If every extension that someone thought was important was
> incorporated into every language then we would have a bunch of PL/1 compilers

  The notation of syntax of Oberon would suffer an extremely minor change but
  a lot of numerical code would be greatly simplified.

> floating around that no one could use.  Yes, complex numbers are important to
> some scientific calculations,

  Try doing numerical analysis in real world problems without complex numbers.

> but the answer would be to develop a standard
> class module called Complex.  

  You need to preserve the simple standard arithmetic notation that you use
  for floats and integers and you need the efficiency of a builtin.

> In fact, the whole reason for object-oriented
> languages is to be able to make extensions such as that.  
> Unfortunately, 
> while there are many standard modules for handling fancy GUI designs for 
> both Oberon/F and System 3, some of the simple but practical modules have
> been overlooked.  Oberon/F just recently added a string library, but it's
> done almost exclusively from a procedural instead of an OO point of view.
> The procedure call interfaces are bulky and unintuitive.  I'm still looking
> for a string library in any language that will let me handle strings as 
> easily as I can handle them in BASIC.

  From your statements about your string problem I would say that
  you are not understanding the significance of completing the number system
  in the conventional notation for numerical analysis. The number of people
  who need to do numerical analysis is not insignificant.  
  Oberon doesn't have the facilities to implement conventional arithmetic
  notation so that some arithmetic will look one way and some number types and     
  another way for another. The practical options
  are to include complex numbers or provide a mechanism for overloading
  the appropriate operations symbols. I think that the simplicity of the
  language would be almost completely unaffected by incorporating complex 
  numbers.