Re: Questions about floating numbers, rethink and bug report

[Keith Wright]

> From: Dirk Herrmann <address@hidden>
> cc: address@hidden, address@hidden
> 
> On Sun, 7 Oct 2001, Keith Wright wrote:
> 
> > Bug.
> >     guile> #E3  ==>    3
> >     guile> #e3
> >     ERROR: read:uniform-vector list not found
> > 
> > This violates both R5RS 7.1 ``Case is insignificant'' and 
> > >     The codes for indicating exactness (which can, incidentally, be
> > >  applied to all numerical values) are:
> > >
> > >   * `#e', `#E' -- the number is exact
> 
> Some uniform vector is taking the #e prefix.  More details can be found in
> ice-9/arrays.scm and unif.c and ramap.c.

And in read.c, where |scm_get_hash_procedure| should be changed to
do a case-insensitive comparison so that the same bug does not just
move to a new letter.  The "#i(" prefix to double precision uniform
arrays is a goofy choice of letter (in my FORTRAN opinion), and conflicts
with the "inexact prefix" from RnRS in the same way "#e(" for
unsigned long integer (goofy) conflicts with the "exact prefix".
  ... and the prototype 1/3 suggested for a double precision looks
like an exact rational to me.  Surely the prototype for double
precision should be 1.0d0 (the R5RS way of writing a double
constant)!?

Why do we need eleven different prefix letters for different types of
uniform vector anyway?  Is there not an stunning algorithm that,
given a _single_ code for uniform-array and a list of objects all
of the same type, computes the common type?  So #u(#t #t #f #t)
is a bit vector and #u(3.14 2.71) is floating point.

Keep in mind it is an error to assign to a vector constant
(R5RS, end of 3.4, literal constants are immutable objects,
and 7.1.(2|3) <literal>::='<datum>::=<vector>).

Now I'm getting really wound up.  Why have any special syntax
at all?  If the interpreter is prepared to handle uniform vectors
as a special case, just do it.  Sometimes a later use of the vector
may force the interpreter to convert, but how can that be worse
that forcing 10^n programmers to play "Simon says" in order to
get the short representation.

This would require careful design and implementation to make the
semantics predictable, avoid thrashing representations, and interface
well with C.  Is anybody using uniform vectors?  Do they like them?
Would they like them better if they were more automatic?

>                                           I think this is a bug and should
> be fixed.  It would do good to revamp the whole uniform vector stuff.  
> Doesn't anybody have an opinion on my suggestion to virtualize the vector
> interface (whine :-)?

Missed it.  Was that on this list?  How long ago?  Virtualize?
Is that part of a plan to make them more automatic, or is it
a new implementation technique for the status quo language?

> Regarding the rest of your mail, I have no clear idea yet what to think
> about the issue.

Neither do I.  That's why I wrote two replies to the same question.

-- 
     -- Keith Wright  <address@hidden>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---