>>>>> "Per" == Per Bothner <xxxxxx@bothner.com> writes:

Per> xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:

Marc> 1) What if an implementation is not **completely** compliant to R5RS
Marc> (basically all the implementations of Scheme... some aren't
Marc> properly tail-recursive, some don't have call/cc, some don't
Marc> parse tokens exactly as required, etc.).  Does this mean it
Marc> can't conform to SRFI 22?
>>
>> Yes, that's what it means.  I'll specify this more clearly in the next
>> revision.  I don't see any point in dealing with proper subsets of
>> R5RS if we want scripts to be able to run.

Per> Well, it is likely that 99%+ of useful scripts do not need full
Per> tail-calls or call/cc.  Also, some implementation may be able to
Per> support tail-calls and full call/cc but much slower.

I don't know that.  I lot of code I write does depend on tail calls,
and I'd hate to change that habit for scripts.  Moreover, I'd say that
(given the tectonic nature of Perl execution, for example), speed is
not very crucial for most scripts.

Per> What about the optional features of r5rs?  The same arguments apply
Per> to being able to handle say bignums or complex numbers.  Again, 99%
Per> of useful scripts probably need neither, and many Scheme implementations
Per> do not support them.  Does --r5rs require the optional features?

That's a good point, but I'm not sure there's a clear answer.  (Note
that "optional" in R5RS is probably not what you mean.  Or is it?)
Many Schemes *do* support all of these.  In fact, all Schemes I use
regularly do.

The question is really where you want to make the split between
Schemes which can support SRFI 22 and those which cannot.  Should SIOD
be able to support SRFI 22, for instance?

Per> Perhaps we should have an option (or default) to specify
Per> "mini-Scheme": r4rs minus optional features minus call/cc (except
Per> perhaps for exits) and minus tail-calls (except self-tail-calls in do,
Per> let, or named function).

Again, I think specifying a language dialect outside of the existing
standards is outside the purview of this SRFI.  Much better to handle
this kind of thing in a separate SRFI.  I'd definitely consider --r4rs
and --ieee-1178-1990 viable options, as many Schemes currently do not
support DEFINE-SYNTAX all that well, even though, once again, I often
use DEFINE-SYNTAX.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla