[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proper appallation

willc> I believe most users would be happy to learn that implementors 
willc> are talking to each other in an effort to improve the portability
willc> and usefulness of Scheme.

As with Alan, it's hard for me to understand how this can improve things.
The attributes "portability" and "usefulness" are not attributes of an
implementation, they are attributes of a language.

Unless you mean "the spec says X is supposed to happen but some implementor
can't figure out how to make that happen and needs to meet with others to
get some hints", then I don't see what implementors can do that will change
portability or usefulness.

"Usefulness" is determined by having a rich enough set of operations
to get work done.  Traditionally, Scheme as defined by the authors
group has avoided adding the extensions necessary to make Scheme very
useful.  The only "useful" Scheme's I have ever heard of are the ones
where implementors have extended or diverged from the standard in
order to achieve the usefulness.

(Maybe by "usefulness" you meant "efficiency", but it seems to me
that's a very limited notion of what "usefulness" is about or why
Scheme is not useful.  Frankly, I've never heard someone say "I don't
use Scheme because it's not fast enough", and I've really often heard
people say "I don't use Scheme because [in its standard form] it's a
toy."  Sometimes, but not always, these people are aware that some
implementations are not toys "because they've done substantial
extension"; never have I heard one say "because it was fast enough",
even though such implementations probably are in fact faster.  And
anyway, if you want to address speed, you limit yourself by not
considering linguistic changes to support better compilation--and for
linguistic changes you need an authors meeting (don't you?), not an
implementors meeting.)

"Portability" is achieved by implementors simply making better efforts
to agree with the specification, or in places where the spec is vague
to make it more concrete.  I doubt it?  All evidence suggests that
textual brevity is of paramount importance in Scheme and that things
like trapping behavior for floating point, echoing and buffering
behavior for I/O, details of character sets that would support
internationalization, etc. are too "grungy" to put in the language
spec.  I'm willing to be surprised, of course, with a list of
proposals from the implementors to the authors about things that
should be more concretely specified to enhance portability.  But I'm
not holding my breath.

This mailing list being a communication forum for the authors, who do
control issues of usefulness and portability by controlling the
language specification itself, are you saying the best thing the
authors can do is sit still and let a posse of implementors fix things?
Are you saying it's inappropriate for us here on this list to be talking
about what this list is designed for, and that we should just be silent
and wait for another group, a group for which this mailing list was not
devised, decide what is the problem with "portability" and "usefulness"?

This discussion seems to have been founded on observations by Alan and
me that Scheme seems to me to be founded on the idea that if only we
don't add anything to it, we can preserve the illusion that there is
nothing it can't do.  The only problem is that each time we try to add
something, someone says that cuts off the opportunity for them to do
something they might some day want to do because it makes concrete an
idea that was previously only abstract.  So all of us agree not to
move forward, just to protect the right of one of us to move forward,
even though if that person were to propose his move forward, we'd find
there was someone else who would want us not to, and we wouldn't move
forward for him either.

My impression is that when it comes to a vote, it's not the users
asking for things to stand still, but the implementors.  My
impression, unscientific though it may be, is that the people who are
worried about that concreteness are the IMPLEMENTORS, not the USERS.
In my experience, users are usually more practical than that, because
the language is rarely an end in itself to them.  They mostly just
want to get some language defined that they can use, and then just USE
it, so they can get some end-application done which is their real

So it seems mighty strange to me for a group of people to get together
hoping to achieve progress by openly locking out the people who (it
seems to me) have traditionally advocated for progress/change in the
hopes that progress will result from a meeting just of those who have
(it seems to me) traditionally resisted progress.

But then, maybe I'm just misreading the situation...

willc> In fact, I think most users would be appalled by the opposition
willc> to this that some R*RS authors have expressed.

Arrgh. If you/we do care about users (as I do, and as Alan does), why
not INVITE some?  If you don't INVITE them, how can you possibly
pretend to speak for them and what they might or might not be appalled
by?  It's at least defensible to say you're meeting to talk about what
"implementors want for implementors' sake", but when you start to
justify an implementors-only meeting as "the obvious thing to assure
what users want" and to justify the non-inclusion of users as "an
impediment to figuring out what users should get", you're getting into
pretty shaky territory.


By the way, I have confirmed a suspicion I had that there is at least
one party who would have liked to have showed up at the implementors'
meeting but who is forbidden by "company confidentiality" from even
having mentioned the nature of their status as a potential
implementor.  Had that party been permitted to attend as a simple
"interested party", they could have done so with sufficient
"inconspicuousness" that they think they would have attended.  But
because of the format of the meeting, they were unable, because their
company is not at a stage where it is willing to detail their plans
for a scheme product.  I think this is a serious pity, and I hope it
weighs heavily on the consciences of those who have taken it upon
themselves to filter attendance for the sake of the "community".

But then, I'm frankly still reeling from the fact that Alan's open
application for attendance was refused.  That someone was so bold to
actually do this really amazed me.  And I guess given that this could
happen in the open, I shouldn't be surprised at the more subtle effects
such as those I mentioned in the previous paragraph.