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

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.

*To*: "John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>*Subject*: Re: Arithmetic issues*From*: bear <bear@xxxxxxxxx>*Date*: Tue, 18 Oct 2005 19:12:58 -0700 (PDT)*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051018211220.GL13524@NYCMJCOWA2>*References*: <y9lzmp775oz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0510181143440.2071@xxxxxxxxxxxxxx> <20051018211220.GL13524@NYCMJCOWA2>

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

**Follow-Ups**:**Re: Arithmetic issues***From:*John.Cowan

**References**:**Arithmetic issues***From:*Michael Sperber

**Re: Arithmetic issues***From:*bear

**Re: Arithmetic issues***From:*John.Cowan

- Prev by Date:
**Re: Arithmetic issues** - Next by Date:
**Re: Arithmetic issues** - Previous by thread:
**Re: Arithmetic issues** - Next by thread:
**Re: Arithmetic issues** - Index(es):