[r6rs-discuss] [ANN] scheme-reports.org

[Vincent Manis]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20090824/a79a47bd/attachment.htm