This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [ANN]: boot-9 slimming r2


Maciej Stachowiak <mstachow@alum.mit.edu> writes:

> Greg Harvey wrote:
> > 
> > Maciej Stachowiak <mstachow@viewlogic.com> writes:
> > 
> > > Greg Harvey wrote:
> > > >
> > > > Greg Harvey <Greg.Harvey@thezone.net> writes:
> > > > >
> > > > > Note: ice-9 needs to be replaced with something more sensible
> > > > > (guile-core is my preference, tho guile-system would also be good).
> > > > > This is the last revision that will be compatable with the current
> > > > > naming.
> > > >
> > >
> > > I think we previously hashed out that (guile ...) is a good namespace
> > > for
> > > modules that are part of Guile.
> > 
> > Just (guile foo), or something more (guile core foo) ? My first
> > thought was that using guile might hose things if you were to have
> > /.../share in your load path... I'll give that a try today.
> > 
> 
> Just (guile foo).

Ok, this shouldn't take but a half hour or so.
 
> Having /..../share in your guile load path shouldn't hurt unless you put
> files with the same names as the guile-core modules directly in 
> /..../share/guile/.
 
That occured to me when I thought a bit about it. I'm just going to
put them in flatly for now, though I think that there could be a bit
more separation (like (guile interface readline), (guile sys threads))
and so on.

> > My thinking is that these aren't operations that are used (or needed)
> > all that often (and certainly not as often as the operations on real
> > numbers), so, while it may not be the nicest way of going about it, it
> > isn't a bad tradeoff to put the cost of having the functions on the
> > people who actually use them, while still providing lightweight
> > versions for average use.
> 
> I dunno - would you think the same thing if the default Guile `+' and
> `*'
> didn't work on complex numbers, even though the guile core supported
> them?
> Or if the default `length' would hang on a circular list (the standard
> allows
> this) but you could load a module that would make it throw an error
> instead?

Yeah, but the difference here is in frequency: 99% of people are going
to use lists, and are going to need them to work right out of the box,
while a very small portion are going to actually care about complex
numbers. As a temporary solution, I don't think this is an
overwhelmingly bad approach.

> I think the right thing to do ultimately is to fix the C code to work
> right in the 
> first place, I might take a look at that myself once I make a little
> more 
> progress on my excessively long free software hacking todo list. C9X
> defines most
> of the relevant functions for complex numbers anyway so it should be
> essentially 
> zero cost to do it that way on reasonably up-to-date systems.

I do think this is the best all around solution (I didn't go this
route initially, because I'd be sure to screw something up with the
complex numbers) It should be as simple as adding

if !SCM_CPLXP(x) {
	function in my numbers.c
} else {
	function on complex number
}

which I'll probably end up doing, if no one beats me to it (someone
beat me to it, please ;). 

-- 
Greg