Re: Guile numerical work and uniform arrays

[mike@olan.com (Michael N. Livshin)]

Jim Blandy <jimb@red-bean.com> writes:

> Okay, so here's the $64k question:
> 
> Do you want all of "the basic machine types" available for use in
> uniform arrays?
> 
> Or do you want all of "the types corresponding to the C and FORTRAN
> types" available?
> 
> That is, what do you want to specify in your Guile code --- 64-bit
> IEEE float, or "whatever a C `double' is on this machine"?

Dunno about Clark, but I want the latter.

> Is the purpose to mesh with libraries written in C or FORTRAN, or to
> have exact control over the bytes?

I think that co-existing nicely with C is the purpose of Guile.  So
having "more" control on bytes than C or FORTRAN on the same
architecture whould be pointless and, um, surprising.

> > I would also find it very useful if there were a way to get guile to
> > treat a region of memory as a uniform array (and not try to GC the
> > memory block).  This would let me attach to large chunks of memory
> > allocated by other packages.  
> 
> Should Guile call a hook associated with the array to free its space?

I can't think of exact reasons to shout "NO!", but that is what I want
to do.  When things start to smell like C++, I get wary,

I think Guile should have the concept of "indirect" uniform vectors.
These can appear in several situations: a pointer to something managed
by C, a sub-vector of an existing vector, or as a "handle" to a
vectored field of a record (heh, I had it all working here and then
broke it :-().

In all the above situations, Guile's GC should have no control over
the indirect vector.

I have a (somewhat rough now) design for all this stuff.  When I get a
couple of hours to quietly sit on it and write it all up, I'll post
here.  Hopefull the fact that you see this promise will motivate me
further :)

later,
m.