Re: Complex numbers & Oakwood suggestions

[Guy Laden <laden@math.tau.ac.il>]

for what its worth i vote againt.
The oakwood guidelines specify most of my reasons.
If efficiency is the issue i think the first thing to do is
profile the performance of programs compiled with an OOC implementation
of the standard language to find the bottlenecks.
I'm not convinced its not possible to achive good performance without
a built-in type.
It would seem logical to me that in many of the cases in which performance
is an issue, vectors will be involved. It should be possible to implement
a complex-vector module with performance comparable to a built-in type.
Even for the general case, a smart allocator might be able to yield
respectable performance. Although i know nothing about this and
cant back it up with any facts at the moment, I suggest
this avenue is explored before language is extended.
The last thing I'd like to see is yet another GNU package that
tries to be everything to everyone.

My main point though is that as I see it, in the context of OOC 
NO language extensions should be implemented, at least not until after
it is complete and a fair comparison can be made between the 'standard'
and the 'extended' version.
Does it realy make sense to experiment with language design in
the context of OOC? Can you seriously picture yourself implementing complex
numbers and then being ruthlessly honest enough to rip them out of the compiler 
because looking at two versions of OOC you've reached a conclusion that
they arent worth the added complexity?

Whatever you decide, I urge you to do it after OOC is complete.

Guy.