Ray,
In your message...
From [EMAIL PROTECTED] Tue Nov 4 01:47:26 2008
From: Ray Dillinger <[EMAIL PROTECTED]>
To: Thomas Lord <[EMAIL PROTECTED]>
Cc: [email protected]
Subject: Re: [r6rs-discuss] voting process
"useful libraries" at this technical juncture of history
mostly require ways for Scheme code to connect with whatever
applications form the "standard method" for doing things.
This is particularly true of the business environment, in
which particular applications (which are mostly NOT written
in scheme) are established as "known solutions" and "best
practices." Companies will not consider moving away from
these applications at this time so if scheme can't talk to
them then the adoption of scheme by these companies is a
lost cause.
With all due respect, I disagree. Companies are happy to use
non-standard features (I have personally seen them do it) of
implementations of their favorite languages and platforms. Indeed,
to most companies I have met, they don't put their weight behind
some theoretical language specification so much as they do the
implementation and company backing that implementation.
Furthermore, of all the problems I have had getting Scheme into
companies, connecting to existing technologies has never caused me
a problem, because the companies see that I can do it just fine.
For example, we will see no widespread scheme web applications
until there is a standard way for Scheme (not a particular
implementation of scheme, but *standard* scheme) to interface
with Apache, IIS, Firefox, and Internet Explorer.
This is already possible and I do it to an extent that allows me
to develop interesting Scheme web applications. The fact that there
isn't some standard way isn't a problem that needs such a drastic
and -- frankly -- currently intractible solution as you are suggesting.
In order to create such a way we have to agree on at least
a syntax allowing scheme code to make calls into C and C++
runtimes and handle "callbacks" from C and C++ runtimes.
That's not part of the core language, but it's a *VERY*
important library that a scheme system probably shouldn't
be shipped without.
Agreement is not something Scheme is meant to be, IMO. If it were,
then we ought to also converge on one true reference implementation
like other languages with this attitude. Rather, I think that we
should be focusing on leveraging our differences of opinion and our
different approach to our advantage. I have done this successfully
in commercial environments, and some people have done it even more
effectively in others. Why try to make Scheme into something that
will remove all the niceties of Scheme and give us nothing that we
couldn't already get in some other language? I agree that an FFI
would be nice, but it isn't the job of the Scheme Steering Committee
to be thinking about this, IMO.
Rather than focusing our attention on such things at the SC level,
we should instead elect SC members whose goal and job it is to
determine the best approaches to better improving on the foundational
values of Scheme as a language, who will let the community work at
solving the problem, and let the editors work at taking the standard
solutions and putting them together according to the spirit of
Scheme.
Of course, this is just my opinion.
> The net effect would be to create a kind of semi-democratic,
> non-profit, Institute for the Advancement of Scheme. I'm
> not sure there is any lesser hope worth aiming for.
In a purely practical engineering sense, I cannot emphasize
enough the importance to corporate or other serious adoption
of scheme of a standard way to interoperate with the standard
applications used throughout the business world. Scheme
cannot succeed if one cannot easily write standard portable
libraries interfacing scheme code to: ... and about a hundred
other "standard accepted solutions." In practical terms,
this means we need to standardize at least a scheme syntax
for making a call into a foreign runtime and a convention
for handling "callbacks" from that runtime.
I disagree with you, because you presume that all Schemes should be
designed and oriented towards corporations. The Scheme language
standard should not require anything that does not adequately or
reasonably fit into the domains of all the different uses of Scheme,
in general. Obviously, sometimes this might be a grey area, but
FFI isn't.
Moreover, this conversation is not useful in the context of the SC,
to me, because I don't want the SC in charge of choosing the next
features. I want them in charge of choosing how to decide if a
feature is worth using, or to decide the abstract goals and approaches
and design of Scheme that will be used as the overarching principle
when the Editors actually decide whether an FFI should go in the
standard, and how.
Thus, when we talk of SC members, we shouldn't be getting down to
this level of detail. I do believe, however, that we ought to
discuss whether the SC should be restricting the direction of Scheme
towards adoption only in the corporate world, or whether we ought
to have a broader outreach. We ought to discuss whether the SC
should restrict the features and the nature of features allowed to
remain or be added to the next revision such that they adhere to
de facto standards, and such that excessive or strictly unnecessary
features are optional. We might even want to argue whether the SC
should encourage the addition of features which are not already
commonly presumed to have a single "best, standard approach." I
would argue that features which are not already researched enough
to have a single solution, should not be in a language standard.
Aaron Hsu
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
