Re: Seeds of the "movement" [was: peasant revolt]

[Michael Vanier <mvanier@bbb.caltech.edu>]

> X-Authentication-Warning: fast.cs.utah.edu: majordom set sender to owner-plt-scheme@flux.cs.utah.edu using -f
> Date: Wed, 24 Jan 2001 00:28:58 -0500 (EST)
> From: Shriram Krishnamurthi <sk@cs.brown.edu>
> Content-Type: text/plain; charset=us-ascii
> Sender: owner-plt-scheme@fast.cs.utah.edu
> Precedence: bulk
> 
> Brent,
> 
> To be realistic:
> 
> > (1)  Agreement amongst the various Schemes as to a "standard library":
> 
> It won't happen.  Some of the points of departure are genuine
> differences in philosophy, eg, over the nature of modules/objects.
> Others are technical differences that are somewhat less deep but
> perhaps even more insoluble.  As an example, Guile has (had?)
> primitives that introduced aliasing into the language.  We would
> shudder at this; their attitude was, so what?  Of course, they don't
> have a MrSpidey-like tool, or study how semantics affects compilation
> (something Mike Vanier and you have indirectly alluded to a few times
> in the past few days), to understand why that could matter.

Now I'm confused.  What do you mean by aliasing in this context?  I got
tired of guile mainly because of the (lack of) documentation problems, but
I wish them the best.

> I used to be a strong advocate of cross-Scheme portability.  I tired
> Matthias out on this topic early in my grad career.  No longer; I see
> now what he knew then.  Cross-Scheme portability is an energy vampire.
> 
> As I've said before, it's misleading to think about Scheme as a
> language.  Think of it as a model, an idea.  It serves that purpose
> superbly.  When you translate ideas into languages, you get everything
> from SIOD to PLT Scheme.  In some ways, PLT Scheme may be closer in
> spirit to something like Python than it is to SIOD.  So if you're
> going to unify any two languages, which two make more sense?  (I'm not
> suggesting we unify with Python, just illustrating a point.)

I agree.  The problem with RNRS Scheme is that too many fundamentally
important issues are left unanswered (like modules), presumably because the
authors couldn't agree on what the Right Thing was.  It would be nice if
there was a section in R6RS on "currently unsolved problems" or "areas of
fundamental disagreement".  As it stands, people reading the document are
left with the idea that all these brilliant people still don't realize how
important a module system is to a programming language.  Of course, macros
complicate the module problem considerably, but that's another story.

One of the "problems" of having a fundamentally extensible language like
scheme is that people go ahead and extend it in mutually incompatible ways.
If you don't like the object system in python, you can either put up with
it, bug Guido to change it, hack the python core, or move to a different
language.  In scheme or lisp, you just write a few macros.  Getting other
people to adopt your approach is a whole different problem, because they've
all written _their_ own object systems as well, which they want _you_ to
adopt :-)  Personally, I prefer too much choice over too little, but this
does hamper standardization efforts.

> 
> > (2)  Easy distribution of modules:
> 
> I don't see any problem creating an archive.  Indeed, Matthew Flatt
> runs one already, and I doubt he's turning away too many comers.  I
> think the bigger problem is the contributions, not the existence of
> the archive.  In my very opinionated belief, time spent on Scheme
> unification efforts is time better spent on fatting the archive.
> 
> Shriram
> 

But one problem I've had is with multiple .plt extensions.  For instance, I
added the readline.plt extension (which works fine) and then the swindle
CLOS-like extension (which works fine), but when I run swindle I don't get
readline anymore.  I'm sure there's a (probably trivial) solution to this,
but it's an example of something that should be somewhat more
straightforward than it is. 

Mike