RE: Cookbook release

Jens wrote:
> Anton van Straaten wrote:
> >As Felix pointed out, emphasizing SRFIs where possible doesn't
> >make the Cookbook any more friendly to other implementations.
>
> I disagree. It might be true that you can't use (require (lib
> "2.ss" "srfi")) in other implementations, but this ought to be
> a minor problem, compared to the actual content of the recipe.

That alone would be a minor problem, although we'd still want to make clear
that, for example, posting code that uses some other implementation's module
mechanism isn't welcome (until we can support implementation-specific code
snippets).  We're currently assuming people will figure that out - I think
we need to make it explicit.  I'll take a stab at doing some of that.

> >We may also need a more explicit policy about allowing "gratuitous"
> >PLT-specificness to exist, if we want to allow that, since otherwise
> >reactions like Taylor's may be common: "why is xxx PLT-specific,
> >you can do it with a SRFI like this".  If someone wants to document
> >some PLT-specific functionality, even if it has a SRFI counterpart,
> >we perhaps need to be able to mark the topic as "intentionally
> >PLT-specific".
> >
> >
> After some initial reluctance I agree with you. It could be made
> visually clear by changing the background color.

Yeah - the truth is that supporting SRFI-scheme vs. PLT Scheme means we're
really supporting two implementations already, so we may as well look at
supporting N implementations, even if it's not perfect.  I'll give it some
thought.

Anton



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click