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

Re: Common Lisp solved this problem 20 years ago

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, 25 Oct 2005, Alan Watson wrote:

>I aplaud this goal. However, rather than create this horrid mess of
>type-specific operators, I would much prefer an approach that used type
>declarations...
>
>Essentially, if you want to do this, follow Common Lisp.
>
>Yes, I know that if you provide Lisp-like macros and these type-specific
>operators, then I can implement these myself. However, my gut tells me
>that this sort of thing should be provided by the compiler writer.

I think I agree.  The way common lisp does it is good; a type
declaration can be added or removed at any time and never ever changes
the semantics of correct code (That is, code that would be correct
without the type declaration).  So an implementation that doesn't
distinguish this stuff simply ignores type declarations, and an
implementation that takes advantage of type information uses them.

And your "safe mode" falls out of it very simply; you can just replace
the declaration syntax with null syntax and recompile and the whole
thing will use generic operations.

The only place this *doesn't* work is when we're relying on semantics
that the generic operators don't have; if you want something that
wraps or saturates or signals rather than returning a bignum, and
you're relying on that as correct and required semantics rather than
an error case, then you need different operators.  But in that case I
don't think you wanted to hide your intent to use overflow behavior
behind a generic '+' or whatever, either.

				Bear