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.
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.
> And there is no way, currently, for hacking on the level of object syntax
> to be done in portable scheme code. I would adore it if there were
> a way to do that, but opening up the read/write functions with 'hooks'
> that a library can stick appropriate routines into and later remove
> them from, would be a very large kettle of worms.
This is a very simple hook, not requiring any sort of full-bore extension
facility. Either things like 1/3 and 1+3i work or they are errors.
> Another problem is that for different applications, you'd want
> different parts of the numeric tower; for, eg, orbit calculations or
> quantum physics, I'd want extended-precison flonums and complex
> numbers - but not rationals. For diophantine equations or number
> theory, I'd want bignums and exact rationals, but neither standard nor
> extended-precision flonums. For crypto, I'd want bignums but not
> flonums. etc.
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.
> I'd go for the ability to
> evaluate expressions like (max-fixnum) or (min-fixnum) to find out the
> limits,
+1
> > Should the binary fixnum/flonum operations allow other than two
> > arguments?
>
> I'd consider it to be a good thing if they did. Rationale; I envision
> an optimization process where the programmer first gets the code
> working using generic operations, and then does small-change
> performance tweeks like using less-general functions where it won't
> affect correctness, while checking against the pristine code for
> errors. Taking out a generic '+' and dropping in an 'fx+' should be a
> primary example of such a tweek, and therefore fx+ should have as many
> of the same argument signatures as + so as to facilitate the smallest
> possible changes being useful.
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*.
--
A poetical purist named Cowan [that's me: jcowan@xxxxxxxxxxxxxxxxx]
Once put the rest of us dowan. [on xml-dev]
"Your verse would be sweeter http://www.ccil.org/~cowan
If it only had metre http://www.reutershealth.com
And rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay