On 2009-08-24, at 15:13, Ray Dillinger wrote:
On Sun, 2009-08-23 at 19:55 -0700, Vincent Manis wrote:
...Before picking
names, people should do the standard checks ...
to avoid clashing with the name of an extant (or extinct) language.
Darn! I was hoping to persuade everyone to call the small language
Foogol and the large one Conniver :-)
4. I'd be opposed to having the large language document describe a
set
of libraries that in some way are optional.
I wouldn't. The large language document should describe libs
required for conformance to the large-language standard, libs
required for implementing scheme in particular environments, and
possibly optional libs as well. Absolutely key, though, is that
each library it describes should be defined for a particular task
and that they can be loaded (or - and this is very important -
*not* loaded) separately. One of the biggest failings of the R6
document was its failure to separate libraries in any way.
Agreed re separate loading. My point is that if we have n options,
then we have 2^n combinations that an implementor can choose from,
which hardly reaches any kind of goal of creating a `standard'
language. Same goes for the language + SRFIs approach. If I distribute
some code that is claimed to run on Large Scheme (TM), and it turns
out it needs options A, B, and C to run, but some implementations
don't provide A, while others don't provide B, and nobody (except the
implementation I'm using, which I found in the remainder bin at
Walmart) provides C, I hardly have any portability.
Not allowing options can have the effect of contracting the language
scope somewhat. `You mean you won't go for my proposal of including an
IBM 7094 simulator in the library? How about if we make it an option?'
5. I'm neutral on the subject of standardizing FFI. On the one hand,
the benefits of a portable standard are obvious (both for portability
across implementations and for practical SWIG support); on the other,
it could paralyze the Working Group.
The point here is you have to make a standard that requires things
of implementations running in particular environments, but you
have to do it without requiring every implementation everywhere
to duplicate the salient features of each and every environment.
I wish I had thought this through this clearly when R6 was still
going on; it's an important point but I was treating it as "given"
and I was not at all articulate about it.
This is so incredibly well-said that I wish I'd said it :). It's my
point exactly. FFI was mentioned in the WG2 Draft Charter, which is
why I reacted to it here. I really REALLY don't want to see the WG
bogged down on this, and would therefore propose it be removed from
the Charter (or at least deemed `not practical to add') to avoid it
becoming a roadblock.
I like Bear's suggestion about implementation standards. It would be
nice for implementers to get together and publish non-normative
addenda for the large language in various environments. But that need
not require any work from WG2 (though they might want to edit the
documents into a consistent format or something). The LIMY
implementations might be good candidates for a first effort, if the
implementers are interested.
6. I hope the Working Group considers including some sort of CLOS-
like
facility in the large language.
...CLOS, on the
contrary, is a methodology for providing every feature that anyone
ever thought of. ...
Boy, did I put my foot in my mouth on that one! I had some verbiage
about TinyCLOS and ISLISP originally, but I took it out because the
message was getting too long. Needless to say, I meant that whatever
facility is considered must comply with the first sentence of the
Introduction. :-)
Let me try that sentence again. `I hope the Working Group considers
including some sort of very clean object-oriented facility in the
language, so that records and conditions can be provided in a way that
doesn't contradict the first sentence of the Introduction'.
-- v
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
