Arithmetic issues Michael Sperber (18 Oct 2005 06:03 UTC)
Re: Arithmetic issues felix winkelmann (18 Oct 2005 07:00 UTC)
Re: Arithmetic issues John.Cowan (18 Oct 2005 17:36 UTC)
Re: Arithmetic issues Aubrey Jaffer (19 Oct 2005 18:13 UTC)
Re: Arithmetic issues John.Cowan (19 Oct 2005 18:21 UTC)
Re: Arithmetic issues bear (18 Oct 2005 19:52 UTC)
Re: Arithmetic issues John.Cowan (18 Oct 2005 21:12 UTC)
Re: Arithmetic issues bear (19 Oct 2005 02:13 UTC)
Re: Arithmetic issues John.Cowan (19 Oct 2005 02:19 UTC)
Re: Arithmetic issues bear (19 Oct 2005 03:23 UTC)
Re: Arithmetic issues Andre van Tonder (19 Oct 2005 11:47 UTC)
Re: Arithmetic issues Aubrey Jaffer (19 Oct 2005 14:14 UTC)
Re: Arithmetic issues Andre van Tonder (19 Oct 2005 16:00 UTC)

Re: Arithmetic issues bear 19 Oct 2005 02:12 UTC


On Tue, 18 Oct 2005, John.Cowan wrote:

>bear scripsit:
>
>> I think the problem with that is that you then need to be able to hack
>> the reader/writer so as to recognize or write the syntax of rational
>> and complex numbers depending on whether the library is loaded.

>Writing is not really an issue: the logic can be present even if it is not
>used.  The lexer has to be able to detect various kinds of potential numbers
>anyway so as to be sure they are not identifiers.

Hmmm.  CL does a pretty good thing here; they have a syntactic
entity called a "potential number" and guarantee that no potential
number will ever be read as an identifier or non-numeric datum.
Potential numbers are a pretty liberal regular expression that all
actual number syntaxes are subsets of.  And if some implementation
wants to provide an extension of the numeric tower, they just need
to pick a syntax for their new numeric type that is also a subset
of the potential numbers.  Then they're guaranteed that no
implementation will misread its extended numbers as identifiers.

In scheme, on the other hand, it's fairly common for the lexer
to treat any entity that doesn't parse as a number as an identifier.
This allows some traditional names such as 1+ for functions, but
doesn't reserve any lexical space for expansion of the numeric
tower.  Maybe that behavior should be forbidden.

> Ratnums are cheap if you have flonums, as has been shown.  I would
> like evidence that complex numbers other than complex flonums are
> actually useful.

Um.  Ratnums are cheap if you have bignums.  Flonums don't actually
get you any significant part of the way toward ratnums.

> Even if you waive the fact that flonum and fixnum + and * are not
> associative, it's easy to write macros that transmute multiple-argument
> versions into 2-argument fx+ and fx*.

This is true, but somewhat inconvenient.

				Bear