COMPLEX: Summary and language extension

[acken@informatik.uni-kl.de]

Here are the alternatives for COMPLEX implementation as discussed in
the last 2 weeks, together with their advantages and disadvantages.  I
hope I collected all the arguments that were presented.


A. Pointer based implementation: COMPLEX = POINTER TO COMPLEXDesc
adv:
- allows functional notation

disadv:
- every computation allocates a new heap object 
- large overhead in allocated storage (type tag plus allocator
  padding to eg multiples of 16 bytes)
- breaks for large computations on systems that need to explicitly
  call the GC to clean up the heap


B. Record base implementation: COMPLEX = RECORD r, i: REAL END
adv:
- good space efficiency

disadv:
- very cumbersome notation 


C. Predefined data type COMPLEX
adv:
- optimal space efficiency
- allows functional notation
- support for simple operations (constructor, * - / * ~, type
  conversion, RE(), IM()) on language level
- makes O2 more attractive for people dealing with technical, complex
  based computations, hopefully convincing them that O2 is a very good
  alternative to use

disadv:
- not portable to most other compilers (but: this holds only for very
  specialized programs that probably wouldn't be written in O2 without
  COMPLEX support anyway)
- additional complexity of compiler (but: complex operations are
  reduced to real arithmetic by the front-end, only minimal extensions
  are necessary for the back-ends)
- have to choose between cartesian and polar (but: cartesian is
  optimal for most applications, and there is no simple way to support
  polar addition in the front-end)


Alternative C combines the advantages of the other two, and adds some
of its own.  All its disadvantages are restricted in one way or the
other.  IMO the pros of C outweigh the cons, therefore I'll add
predefined complex types to OOC.


------------------------------------------------------------------------


Changes to the O2 language report to incorporate complex data types:

3.2 Numbers are (unsigned) integer, real, or complex constants.  If a
real constant is specified with the suffix i, then it is interpreted
as the imagenary part of a complex number with a real part of zero.

  number = integer | real | complex.
  complex = real "i".

Examples:
  12.3i		COMPLEX		0+12.3i
  4.567E8i	COMPLEX		0+456700000i
  0.577D-6	LONGCOMPLEX	0+0.000000577i


6.1 Basic Types
  9.  COMPLEX	  the cartesian complex numbers in REAL x REAL.
  10. LONGCOMPLEX the cartesian complex numbers in LONGREAL x LONGREAL.
where REAL denotes the range [MIN(REAL)..MAX(REAL)] and LONGREAL the
range [MIN(LONGREAL)..MAX(LONGREAL)].  The types 9 and 10 are called
complex types.  The numeric and complex types together form a directed
acyclic graph; the larger type inlcudes (the values of) the smaller
type: 
  
  LONGCOMPLEX--LONGREAL--REAL--LONGINT--INTEGER--SHORTINT
             \          /
               COMPLEX

8.2.2 Arithmetic operators
The operators +, -, *, and / also apply to operands of complex types.
The type of the result is the smallest type that includes both
operands, except for division (/), where the result is the smallest
non-integer type wich includes both operands.
The operator ~ applies to complex operands and denotes the conjugate
complex value.

8.2.4 Relations
The realtions = and # also apply to complex types.

10.3 Predeclared procedures
Function procedures
Name		Argument type		Result type	Function
RE(z)		COMPLEX			REAL		real part of z
RE(z)		LONGCOMPLEX		LONGREAL	real part of z
IM(z)		COMPLEX			REAL		imagenary part of z
IM(z)		LONGCOMPLEX		LONGREAL	imagenary part of z
LONG(z)		COMPLEX			LONGCOMPLEX	identity
SHORT(z)	LONGCOMPLEX		COMPLEX		identity
CMPLX(x,y)	REAL, REAL		COMPLEX		complex number z=x+yi
LONGCMPLX(x,y)	LONGREAL, LONGREAL	LONGCOMPLEX	complex number z=x+yi


Appendix A: Definition of terms
Type inclusion
Numeric or complex types include (the values of) smaller numeric or 
complex types according to the following DAG:
  LONGCOMPLEX--LONGREAL--REAL--LONGINT--INTEGER--SHORTINT
             \          /
               COMPLEX

Expression compatible
operator	1st operand	2nd operand	result type
+ - *		numeric or	numeric or	smallest numeric or complex
		complex		complex		type including both opnds
/		numeric or	numeric or	smallest non-integer
		complex		complex		type including both opnds
~		complex				same type as opnd
= #		complex		complex		BOOLEAN


------------------------------------------------------------------------


Unless someone has a better proposal for the integration of COMPLEX
into the language O2, I'll implement the above specification as part
of OOC.

-- mva