Schematics

Announcing to plt-scheme is fine with me.

BTW, I'm going to be out for the next 6-8 hours, so any server-admin type
support will have to wait till I get back.

Looking forward, there are some issues I think we should take care of before
announcing to c.l.s.  The announcement should make the PLT focus very
clear - the #scheme denizens seemed to have the impression that the Cookbook
was intended to be much more implementation-neutral.  As Felix pointed out,
emphasizing SRFIs where possible doesn't make the Cookbook any more friendly
to other implementations.

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".

Anton


> -----Original Message-----
> From: schematics-development-admin@...
> [mailto:schematics-development-admin@... Behalf Of
> Noel Welsh
> Sent: Wednesday, September 01, 2004 7:10 AM
> To: schematics
> Subject: [Schematics-development] Cookbook release
>
>
> Hi all,
>
> Looks like the Cookbook has fallen off the #scheme radar
> (not  surprising -- they aren't big PLT users on #scheme).
> We also seem to have weathered the initial flood very well.
>  The only problem seems to have been the login, which is
> now fixed.  I'm going to announce to plt-scheme in a few
> hours.  I'm in London from Thurs onwards so will only be
> able to do limited tech support (I'm away all of the next
> week so I'd rather announce now).
>
> Noel
>
> =====
> Email: noelwelsh <at> yahoo <dot> com
> AIM: noelhwelsh
>
>
>

Anton van Straaten wrote:

>Announcing to plt-scheme is fine with me.
>
>BTW, I'm going to be out for the next 6-8 hours, so any server-admin typ=
e
>support will have to wait till I get back.
>
>Looking forward, there are some issues I think we should take care of be=
fore
>announcing to c.l.s.  The announcement should make the PLT focus very
>clear - the #scheme denizens seemed to have the impression that the Cook=
book
>was intended to be much more implementation-neutral.  As Felix pointed o=
ut,
>emphasizing SRFIs where possible doesn't make the Cookbook any more frie=
ndly
>to other implementations.
> =20
>
I disagree. It might be true that you can't use (require (lib "2.ss"=20
"srfi")) in other implementations, but this
ought to be a minor problem, compared to the actual content of the=20
recipe. A SRFI solution ought to run on
other implementations too, the only difference being the way to specify=20
how to use the given SRFI. Hopefully
a module system in R6RS will solve the problem, but until then the=20
current solution is better-than-nothing.

>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-specif=
ic
>functionality, even if it has a SRFI counterpart, we perhaps need to be =
able
>to mark the topic as "intentionally PLT-specific".
> =20
>
After some initial reluctance I agree with you. It could be made=20
visually clear by changing the
background color.

--=20
Jens Axel S=F8gaard

--- Anton van Straaten <anton@...> wrote:

> The announcement should make the PLT focus very
> clear - the #scheme denizens seemed to have the
> impression that the Cookbook
> was intended to be much more implementation-neutral. 

Fair point.

> emphasizing SRFIs where possible doesn't make the
> Cookbook any more friendly to other implementations.

I would hope it still has some use, but this isn't worth
arguing over.

> 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

Well some might argue that other reactions are more
appropriate to Taylor's comments but that is beside the
point.

I think we need gratuitous PLTness -- it is one of our
aims.  For example Taylor's comments could have been
usefully integrated into the StructureChapter introduction
and it would be useful to eludicate the differences between
PLT structures (convenience syntax, inheritance etc.) and
SRFI records (portability).  If anyone can think of
something easily implementable in TWiki that's cool.  

I would like to support all Scheme systems in the distant
future.  I can imagine a system where you have a recipe and
multiple implementations in various Scheme language, and
user preferences control which implementation is shown. 
This would be nice but doesn't seem easy.  Moshi seems a
better platform for this stuff.  I'll be working on it in
the near future so hopefully this vapour will solidify 
soon.

Noel

=====
Email: noelwelsh <at> yahoo <dot> com
AIM: noelhwelsh


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

>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". 
  
Fair enough.  From my perspective, I won't be able to contribute much if we have a strong cross platform requirement, because PLT is the only Scheme I've used enough to know anything about. 
  
>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".    
  
Actually, I think in Taylor's case, his point was fair enough.  It's a chapter on structures, so the intro should contain something on SRFI-9.  I just wish that Taylor would have written up something on SRFI-9, instead of complaining and (apparently) leaving. 
-- 
Gordon Weakliem 
http://www.eighty-twenty.net

Noel wrote:
> > emphasizing SRFIs where possible doesn't make the
> > Cookbook any more friendly to other implementations.
>
> I would hope it still has some use, but this isn't worth
> arguing over.

Oh, I think it definitely has some use.  But I think we're more likely to
turn people off if we imply that the Cookbook is more agnostic than it
really is (at the moment).

> Well some might argue that other reactions are more
> appropriate to Taylor's comments but that is beside the
> point.

Taylor has a unique way of building consensus. ;)  But Felix's reaction
wasn't that different, although he'd previously seen the Cookbook.  After a
while, I think it was Taylor who came back on #scheme and said something
like "oh, so the cookbook is really PLT-specific".  I think we can shortcut
the learning curve on that point.

> I think we need gratuitous PLTness -- it is one of our
> aims.

That's fine.  But just being picky, point #1 on BeingPltSpecific is "Avoid
_totally_ gratuitous PLT-isms".  All I'm really saying is that we need to be
consistent and clear about what's expected in terms of contributions, to
avoid unnecessary squabbling; and be realistic about how we promote the
Cookbook.

For example, the opening paragraph on BeingPltSpecific reads "our primary
goal is to provide information to users of PLT Scheme".  That's clear
enough.  I think I originally wrote some conflicting text on WebHome, which
currently reads "It is focused on PLT Scheme, although other Scheme dialects
are supported as far as possible".  I'll change the latter, since we don't
really have a way to support other Scheme dialects at present.

> I would like to support all Scheme systems in the distant
> future.  I can imagine a system where you have a recipe and
> multiple implementations in various Scheme language, and
> user preferences control which implementation is shown.
> This would be nice but doesn't seem easy.

I'll write up my ideas along these lines.  Selecting which implementation's
source code snippets is shown may actually not be that hard (the hard part
would be making sure every implementation actually had its own source code
snippet for every case necessary).  Switching the source code is not the
only issue, though.

> Moshi seems a better platform for this stuff.  I'll be
> working on it in the near future so hopefully this
> vapour will solidify soon.

I'd love to see that.  I've toyed with the idea of doing some coding myself.
I'm not sure I'm realistically going to be able to follow through on that,
though.  I can definitely contribute plenty of ideas... ;)

Anton

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

Supporting multiple implementations is right up my research alley (and
related to an adaptive hypermedia showcase site that's on my TODO list
after my new PostgreSQL and HTTP libraries are ready).  Sadly, a wealthy
benefactor will probably have to materialize before I can afford to do
this. :)

> Supporting multiple implementations is right up my research alley
> (and related to an adaptive hypermedia showcase site that's on my
> TODO list after my new PostgreSQL and HTTP libraries are ready).
> Sadly, a wealthy benefactor will probably have to materialize
> before I can afford to do this. :)

I'm all for finding a wealthy benefactor!  ;)

The simple ideas I've had can be summarized as follows (I think I've
mentioned this briefly before):

1.  Under TWiki, we already have many Scheme snippets stored in the Scm web.
We could create a separate web for each supported implementation, and use a
variable to specify which one to use for inclusion.  I haven't actually
tested this, but I believe it shouldn't be too difficult to make that work.

2.  Since Scheme code is already being formatted via a Scheme servlet, we
could easily hook whatever we like in at that level, without being reduced
to Perl hackery.

Neither of the above deals with the question of implementation-specific text
in the topics.  For that, we could just use a simple #ifdef-style approach,
which has an equivalent in TWiki syntax, iirc.  But, that could make the
source text quite unmanageable if many implementations are supported.  For
topics that have a lot of implementation-specific text, we could resort to
having a separate topic for each implementation, again selecting the
appropriate ones based on a variable (set via e.g. the user's preferences or
the URL).
Using separate topics isn't ideal (the cut-and-paste antipattern), but
perhaps better than nothing.

Anton

Gordon Weakliem wrote:

> >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".
>
> Fair enough.  From my perspective, I won't be able to contribute
> much if we have a strong cross platform requirement, because PLT
> is the only Scheme I've used enough to know anything about.

I don't think we'd ever want to expect that an individual contributor
provide info for more than one implementation.  Making an entry
multi-implementation friendly would be the job of users of the respective
implementations.  The only exception is the general requirement that SRFIs
be preferred where possible.

What I was thinking of was if someone wants to describe PLT's define-struct,
rather than SRFI-9, or perhaps PLT's OO system, or module system, etc., we
might want to flag such topics to prevent any unwanted attempts to make
those entries more portable.  Topics like that would be an example of a case
where other implementations would require an entirely different version of
the topic, probably in their own "web" (assuming we get to that point under
TWiki as opposed to Moshi).

> Actually, I think in Taylor's case, his point was fair enough.
> It's a chapter on structures, so the intro should contain
> something on SRFI-9.  I just wish that Taylor would have written
> up something on SRFI-9, instead of complaining and (apparently) leaving.

Taylor's not a PLT fan, and if he left, it's probably because of that,
and/or he wants to see how we respond to the objections raised on #scheme.

Anton