[plt-scheme] Scheme Steering Committee Position Statement

PLT is not really a ``large'' language. It's just an implementation
with a large number of libraries (like ``standard'' Perl) and
sub-languages (like the teaching languages). Libraries become part of
the language definition as a result of creeping featurism. I would
support going the ``small'' route and finding portable ways to
introduce new constructs along with keeping the base features as
simple as possible. It's probably impossible to get all
implementations to agree on a ``standard way'' to define structs, for
example.

Libraries need to live or die depending on usage. Whether a standard
is ``large'' or ``small'' depends on how it is organized. Therefore,
R7RS should focus mainly on portability concerns, but avoid doing
anything rash. A collection of suggested FFI procedures would help,
but not a complete C interface.

Oh well, I guess we're doomed anyway...

On Fri, Aug 21, 2009 at 11:53 AM, namekuseijin<namekuseijin at gmail.com> wrote:
> On Fri, Aug 21, 2009 at 3:17 PM, David Van Horn<dvanhorn at ccs.neu.edu> wrote:
>> Sam TH wrote:
>>>
>>> On Fri, Aug 21, 2009 at 12:18 PM, Eduardo Bellani<ebellani at gmail.com>
>>> wrote:
>>>>
>>>> http://scheme-reports.org/2009/position-statement.html
>>>>
>>>> Any comments?
>>>
>>> I'm disappointed that people think that a Scheme that works well for
>>> education and research can't be the same as one that works well for
>>> writing large-scale programs.  I think the existence of PLT Scheme, in
>>> which large quantities of all three are done, is an existence proof of
>>> the opposite.
>>
>> Agreed.
>>
>> I also think the large v. small language is a false dichotomy.  If you want
>> to write a module (library) using nothing but lambda and apply, you can do
>> that in R6RS.
>
> Yes, with a mere (import (rnrs base)) it provides an even smaller
> subset than R5RS.
>
> All batteries-included Scheme implementations provide pretty much
> everything a programmer needs for real world tasks.  I just wish all
> of them provided at least one common interface for such features as
> IPC, FFI etc, beside their specific.  That's where I see
> standardization efforts could focus instead of relying on people
> possibly agreeing upon one or other SRFIs and hopefully providing
> support.
>
> my 1 cent...
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>