[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Arithmetic issues

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.




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