Re: [ANN]: slimmed down boot-9, revision 1

[Greg Harvey <Greg.Harvey@thezone.net>]

Telford Tendys <telford@eng.uts.edu.au> writes:

> On Mon, Feb 01, 1999 at 03:44:35AM -0330, Greg Harvey wrote:
> > Maciej Stachowiak <mstachow@alum.mit.edu> writes:
> > 
> > > > Oops, wasn't keeping a close eye on the standard.  I don't see why
> > > > these couldn't be moved to numbers.c, though (couldn't we just lose
> > > > the $blah functions, and do the entire thing in c?).
> > > 
> > > That would probably be a good idea in general, but numbers.c tries to be
> > > clever about lifting the C double-taking versions of these functions
> > > almost 
> > > directly so it might be more work than you expect (I imagine it would
> > > not
> > > be too hard to provide a "complex" version of each of these functions as
> > > well which takes two doubles per argument (or maybe even use the
> > > built-in 
> > > complex functions on C systems that support them).
> > > 
> > 
> > Actually, I'm right now just taking the very easy, do exactly what the
> > current versions do approach (complex numbers apparently being
> > something that I've completely repressed ;).
> 
> I don't see that complex number support is REQUIRED for RnRS, it's just that
> RnRS specifies that if complex numbers ARE supported then they should be
> supported in line with the standard. I would guess that about 10% of guile
> users will be using complex numbers, maybe less. This is an excellent reason
> to put them in a module.

This is good (and not just because it's very easy to do, though that's
a big part of the appeal for me ... just rename the $foo functions to
foo (and have them accept SCM args, rather than doubles), and provide
a complex module that defines the extended functionality versions). 

> I do feel that there should be at least a real valued sin, cos, etc available
> in the core because a lot more people are going to use these for their real
> valued applications. Also, the real valued functions are going to be faster
> than the transcendental equivalents and, frankly, guile needs all the speed
> it can get.

This is true, though I don't particularly like the way they're done
currently (with the tc7_cxr stuff... this seems to be cuteness for no
particular gain, just moving the argument checks & conversion into
eval, which is a place we should definately be trying to remove any
extra code).

> The dollar sign naming thing is just another symptom of a lack of a functional
> module system. If we had separate namespaces then the core namespace would
> define (sin X) as using real valued X while the complex module namespace
> would define (sin X) as the transcendental. This would allow a logical system
> of extensions and give users their choice of behaviour.

Actually, we can do this now (if I'm not being completely stupid), and
without even modifying much (just change the transcend-complex module
to define the current sin, ... to $sin, and use the code that's
already there). These seem to mostly be a holdover from SCM that
hasn't really been looked at closely.

> And before anyone asks, no, I don't believe that there should be a special
> ``real-numbers'' module that people ask for so that they can get the
> simplified functions -- that is just too topsy-turvy to contemplate.

Yeah, that would be lame.
-- 
Greg