[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] meaning of r7rs standard feature identifier
- To: scheme-reports@x
- Subject: [Scheme-reports] meaning of r7rs standard feature identifier
- From: Per Bothner <per@x>
- Date: Sat, 10 Nov 2012 12:09:43 -0800
What is the intended meaning of the standard feature identifier 'r7rs?
Does it mean every requirement in the R7RS specification must be
implemented 100% according to spec? Of course every implementation
is likely to have bugs, and others may find some parts of the spec
difficult or impossible to implement (for compatibility or
technical reasons), so 100% conformance is unlikely.
Specifically, suppose Kawa implements R7RS as far as we can.
However, full continuations may be a ways off. Should Kawa
define the r7rs feature? What about an implementation that
does not support full tailcalls? Or one where full tailcalls
are optional but not the default (as in Kawa)? Exceptions may
also be difficult on some platforms - I haven't yet tried to
implement R7RS-style exceptions for Kawa.
I know there are purists who insist a language isn't "Scheme"
unless it supports full continuations and tailcalls, but such
a language is still very useful, and (I claim) may still have
the "Scheme nature". It would be nice if such as language could
still claim to be r7rs or at least "r7rs-like".
I'd suggest some extra feature names:
by analogy with full-unicode.
Perhaps then another name to indicate full compatibility:
full-r7rs or strict-r7rs
If the decision is that r7rs is only for 100% conformant
implementations, perhaps we could have some other name
for implementations that support *most* of r7rs?
Scheme-reports mailing list