From: Ray Dillinger
Subject: CFP: scheme standard libraries
Date:
Message-ID: <335C8066.1562@sonic.net>
First things first. I am not a standards body, nor a journal,
and as far as I know there is not going to be a conference
on this topic. I'm a user, and a would-be language implementor,
trying to elicit opinions from people about what ought to be
in standard scheme libraries for WIMP, multimedia, and FFI.
I'm going to review the proposals I get, put them online,
debate them in these fora, pick and choose among them the
things I think are most useful and consistent with the
spirit and semantics of the language, and collect them into
a document, which I intend to make publically available,
subject to no limitation or condition of any kind. If there
are enough interested people to form a "committee," I'll
cheerfully put it to a vote instead of doing the picking
and choosing myself; I'm a relative neophyte as a language
designer after all.
We need standard libraries and functionality for scheme. I'm
interested in defining a "functionality standard" for the
language.
R4RS is a language standard, and it's a good one. But some
questions about the things that make a language practical and
usable are beyond the scope of a language standard.
In particular, we need a specification for standard libraries.
In part, I'm asking what's out there -- if there are existing
libraries or methods of doing things that handle these utility
functions, and they are well-designed and well-behaved, then
by all means let's write their semantics into a standard!
Right now, I'm going to address the crying needs:
1) We need a WIMP library. Windows, Icons, Menus, and Pointers.
What do they look like in scheme? What should they
look like in scheme?
2) MultiMedia. We need a way to handle sound and graphics.
Who's got one? What's it like?
3) FFI. We need standard methods for calling libraries and
other modules not written in scheme, nor written
specifically for scheme systems, without tne need to
recompile those modules. Some development tools
provide libraries without source code for c compilers.
There ought to be a standard way to use those libraries
in a scheme program.
4) FPI. We need standard methods for compiling libraries and
other modules that can be used or called from programs
not written in scheme. A module written in scheme
ought to be able to replace a module written in C
with *NO* modifications to the source of the C program
that calls it.
These things need to be as portable as possible. I'm thinking
that some of these services might be written as independent
"dispatcher" type applications to run concurrently with scheme
environments -- they'd send and recieve characters to scheme
via ports. Then the interface to them could be written in
plain scheme code and imported to any R4RS compliant system.
That's a stopgap measure -- it is my sincere hope that
scheme implementors, with standards in hand, would build
the functionality directly and more efficiently into their
systems.
I'm "punting" on a couple of things:
1) a Standard Object System
2) a Standard low-level Macro System
until such time as various issues surrounding them become
clearer.
Your assistance is requested,
Ray Dillinger
In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
First things first. I am not a standards body, nor a journal,
and as far as I know there is not going to be a conference
on this topic. I'm a user, and a would-be language implementor,
trying to elicit opinions from people about what ought to be
in standard scheme libraries for WIMP, multimedia, and FFI.
Before all these can be achieved,
the first thing needed is a one real __standard__ module system
with functors, like what is available in *ML.
First-class environments could trivialize that,
but they are not standard, either.
Without modules, you'd end up with a large bloated namespace
of predefined functions, and I think all the purpose
of Scheme vs CommonLISP would be lost...
Just my 2 centimes worth (not even mine -- all this has been
said again and again before).
== Fare' -- ······@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"
From: Ray Dillinger
Subject: Re: CFP: scheme standard libraries
Date:
Message-ID: <335CF8FE.5F60@sonic.net>
Francois-Rene Rideau wrote:
>
> In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
>
> First things first. I am not a standards body, nor a journal,
> and as far as I know there is not going to be a conference
> on this topic. I'm a user, and a would-be language implementor,
> trying to elicit opinions from people about what ought to be
> in standard scheme libraries for WIMP, multimedia, and FFI.
>
> Before all these can be achieved,
> the first thing needed is a one real __standard__ module system
> with functors, like what is available in *ML.
> First-class environments could trivialize that,
> but they are not standard, either.
> Without modules, you'd end up with a large bloated namespace
> of predefined functions, and I think all the purpose
> of Scheme vs CommonLISP would be lost...
I agree that we need some kind of standard way of doing modular
programming: But I see it mainly as a compilation-methods issue
rather than a namespace issue.
Most of the programs I work on, I put in one huge file. Every
time I change three lines, I recompile the whole %^&* thing.
This is plainly not the way to do it, but Scheme systems that
support programs that have multiple files are rare. The idea
of standard libraries assumes that the library code can sit in
its own file and you can write programs that call it, rather
than copying the contents of that file into the top of your
sourcecode file.
So here's a proposal:
=============================================================
|(compile port1)
|Port1 must be a port open to read scheme source code (most
|likely the result of opening a source file to read). This
|expression returns a port open to read compiled scheme source
|code. The exact format of compiled scheme source code is
|implementation dependent; it can be machine code or bytecode;
|a "pure" interpreter may even simply write whatever it reads
|from port1 directly. An error is signaled if what is read at
|port1 is not valid scheme code.
=============================================================
|(include port2)
|port2 must be a port open to read compiled scheme code.
|Evaluating the include expression has the same effect on
|the environment that evaluating the expressions whose compiled
|forms are read by port2 would.
=============================================================
Questions? Comments? Additions? Corrections? How would you
improve this proposal?
Bear
In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
From: Ray Dillinger <····@sonic.net>
Date: Tue, 22 Apr 1997 10:44:30 -0700
Organization: Cognitive Dissidents
Lines: 63
References: <·············@sonic.net> <···············@drakkar.ens.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01Gold (WinNT; I)
Francois-Rene Rideau wrote:
..
>
> of predefined functions, and I think all the purpose
> of Scheme vs CommonLISP would be lost...
I agree that we need some kind of standard way of doing modular
programming: But I see it mainly as a compilation-methods issue
rather than a namespace issue.
Most of the programs I work on, I put in one huge file. Every
time I change three lines, I recompile the whole %^&* thing.
That's because you are using Scheme.
This is plainly not the way to do it, but Scheme systems that
support programs that have multiple files are rare. The idea
of standard libraries assumes that the library code can sit in
its own file and you can write programs that call it, rather
than copying the contents of that file into the top of your
sourcecode file.
So here's a proposal:
=============================================================
|(compile port1)
|Port1 must be a port open to read scheme source code (most
|likely the result of opening a source file to read). This
|expression returns a port open to read compiled scheme source
|code. The exact format of compiled scheme source code is
|implementation dependent; it can be machine code or bytecode;
|a "pure" interpreter may even simply write whatever it reads
|from port1 directly. An error is signaled if what is read at
|port1 is not valid scheme code.
=============================================================
|(include port2)
|port2 must be a port open to read compiled scheme code.
|Evaluating the include expression has the same effect on
|the environment that evaluating the expressions whose compiled
|forms are read by port2 would.
=============================================================
Questions? Comments? Additions? Corrections? How would you
improve this proposal?
Comments. These issues have been solved in CL for years. DEFSYSTEMS
in CL exists (MK:DEFSYSTEM in the AI.Repository of CMU is an excellent
example) and can be used to do this sort of project management.
Conclusion: switch to CL. Given the Memory and the power available
today on any machine there is no reason to use a smaller and less
capable Lisp system.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
> I agree that we need some kind of standard way of doing modular
> programming: But I see it mainly as a compilation-methods issue
> rather than a namespace issue.
>
> Most of the programs I work on, I put in one huge file. Every
> time I change three lines, I recompile the whole %^&* thing.
>
>That's because you are using Scheme.
>
>Comments. These issues have been solved in CL for years. DEFSYSTEMS
>in CL exists (MK:DEFSYSTEM in the AI.Repository of CMU is an excellent
>example) and can be used to do this sort of project management.
>
>Conclusion: switch to CL. Given the Memory and the power available
>today on any machine there is no reason to use a smaller and less
>capable Lisp system.
I suspect a lot of Schemers who haven't "switched" are
biased not against CL's size so much as one or two
mortifying design choices such as the
symbol-function/symbol-value distinction, the need for
funcall and #', and the inability to rely on tail-call
optimization. These are perceived as "lacks", not as
"extras". And the rueful thing is that these "lacks" are by
no means some kind of technically necessary price that had
to be paid for the genuine "extras" of CL over Scheme.
Regards,
--d
--
http://www.cs.rice.edu/~dorai
In article <··········@news.gte.com> ····@bunny.gte.com (Dorai Sitaram) writes:
From: ····@bunny.gte.com (Dorai Sitaram)
Newsgroups: comp.lang.scheme,comp.lang.lisp
Date: 26 Apr 1997 22:43:15 GMT
Organization: GTE Laboratories Incorporated
Lines: 36
Xref: agate comp.lang.scheme:20136 comp.lang.lisp:27428
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
> I agree that we need some kind of standard way of doing modular
> programming: But I see it mainly as a compilation-methods issue
> rather than a namespace issue.
>
> Most of the programs I work on, I put in one huge file. Every
> time I change three lines, I recompile the whole %^&* thing.
>
>That's because you are using Scheme.
>
>Comments. These issues have been solved in CL for years. DEFSYSTEMS
>in CL exists (MK:DEFSYSTEM in the AI.Repository of CMU is an excellent
>example) and can be used to do this sort of project management.
>
>Conclusion: switch to CL. Given the Memory and the power available
>today on any machine there is no reason to use a smaller and less
>capable Lisp system.
I suspect a lot of Schemers who haven't "switched" are
biased not against CL's size so much as one or two
mortifying design choices such as the
symbol-function/symbol-value distinction, the need for
funcall and #', and the inability to rely on tail-call
optimization. These are perceived as "lacks", not as
"extras". And the rueful thing is that these "lacks" are by
no means some kind of technically necessary price that had
to be paid for the genuine "extras" of CL over Scheme.
These "features" have generated endless discussions about CL
vs. Scheme. I myself believe that 'funcall' is esthetically
unpleasant, yet I am not so bothered by it. As for the distinction
between symbol-function/symbol-value, I have never been bothered so
much by it while programming.
Allow me to be blunt and to start up another flame. (Of course you
don't have to jump in :) )
I have the most definite impression (and with all the qualifications
of the case) that Scheme is favored over CL mostly by implementors.
I.e. C/C++ hackers.
CL gives you so much more power in terms of programmer support that -
and this may definitively be a problem of mine - I simply cannot see
what is to be gained by keeping on programming with far less
standardized tools and programming environments (keywords arguments
being the single most useful thing that CL has over Scheme). My take
- and personal experience - is that a lot of Schemers (once again, not
all of course) have not really tried to do any significant programming
in CL using CL style. This feeling is also corroborated by some of
the postings that have appeared over these newsgroups.
The morale of this story is an invitation to Schemers to give another
try to CL while keeping all WEB pointers to CLtL2 and the Hyperspec
ready.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
From: Ray Dillinger
Subject: Re: CFP: scheme standard libraries
Date:
Message-ID: <3365B254.298D@sonic.net>
I'd like to point out that I wasn't talking about CL.
I have nothing against CL or CL programmers. But the language
I want to extend is Scheme. Call it a sentimental attachment;
I love it because it's so clean and easy to explain and the
learning curve is so short. People who love CL love it for
different reasons.
CL is *not* extended scheme; there are a number of problems
that schemers solve in significantly different ways than
CL'ers. The two languages have different emphasis.
The scheme standard has grown only very slowly, because its
emphasis has been on simplicity and conceptual elegance.
Thus, we have the single namespace, evaluate the function
name as an expression, etc... in scheme, we have been trying
to create a language where you have few rules and few
exceptions to those rules. So there's a lot of wait-and-
see to decide what the rules ought to be; it requires a
lot of diligent work by scholars and language theorists
to discern the subtle advantages of one solution over
another. The reason we don't have a standard structure
for objects yet, is because no single object structure has
yet emerged which is clearly superior to other design
decisions.
The CL standard has grown swiftly, because CL users wanted
a common language including all the system-interface issues
where no clear answers have emerged yet to the satisfaction
of the schemers -- the choices made weren't so important
as the fact that the choices *were* made, so that the
extended functionality and interfaces to C code and so on
that CL embodies, are embodied in the same way across many
different implementations of CL. The choices behind CL are
driven by a different set of values -- The syntax, while
more complex than that of scheme, contains a plethora of
hints to help the compilers produce efficient code. The
development of CL has stressed practicality, power,
portability, and efficient compilation.
To use an analogy, the scheme community is like a bunch
of engineers surveying a new continent and trying to
find the absolute best route for train tracks to cross
it, minimizing the number of switches and complexity of
the map while also maximizing the capability for smooth
and conflict-free rail traffic flow. The CL crew landed
on a similar continent with a load of bricks they wanted
to deliver across it next tuesday and just looked long
enough to be sure that the territory through which they
were driving their rails didn't have obvious pitfalls.
At this time, it's easier to get goods delivered
across the CL continent; but though the schemer's rails
don't go everywhere yet, the trains run smoothly, all
use the same guage, and the maps and interchanges are
easy to understand. (at least thats the ideal; because
the scheme rail system is *so* small, individual metro
areas have developed a lot of their own rail on this
continent, and no two cities seem to follow the same
rules; Gambitville has subways, SIODville has a monorail,
all the platforms in Guileville are on the left side of
the train .... And not all of the cities have certain
structures you'd expect, like Graphic Art Galleries or
Ports. Most of them say it's just until the "official"
rail gets there though.)
So, if we could please back down from the edge of this
flamewar we seem to be standing on the edge of, I'd like
to see anyone who wants to argue particular approaches and
the pros and cons of each, rather than people who want to
tell me "XXXX can do this" or "why don't you just copy CL?"
or whatever.
In short, I'm looking for scheme-style solutions --
I'm asking where the citizens think the scheme tracks
*ought* to go. Hopefully solutions that introduce no
new syntax and only a minimal number of new functions,
out of which the functionality needed can be easily
built. Solutions that don't depend on weird
polymorphisms or anything else I couldn't explain to a
smart eight-year-old in about fifteen seconds.
Bear
In article <·············@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
...deleted stuff about Scheme and CL
> In short, I'm looking for scheme-style solutions --
> I'm asking where the citizens think the scheme tracks
> *ought* to go. Hopefully solutions that introduce no
> new syntax and only a minimal number of new functions,
> out of which the functionality needed can be easily
> built. Solutions that don't depend on weird
> polymorphisms or anything else I couldn't explain to a
> smart eight-year-old in about fifteen seconds.
I sincerly belive that a "standard" module system for Scheme is something
that needs to be added before other things. Scheme -> C (and the other
way) is second on my list.
--
Best Wishes, Bengt
Email: ······@damek.kth.se
From: Ray Dillinger
Subject: Re: CFP: scheme standard libraries
Date:
Message-ID: <3366DE1A.7E1D@sonic.net>
Bengt Kleberg wrote:
> I sincerly belive that a "standard" module system for Scheme is something
> that needs to be added before other things. Scheme -> C (and the other
> way) is second on my list.
>
<weeping in frustration -- yet another person says "we need X" without
bothering to try to say specifically what X might be....>
Yes, a module system is needed. All the things I want to add ought to
be modules. But saying that a module system is needed does not give
me any clues about what you think a good module system would include!!!
The entire point of this was to try to extract *SPECIFIC* *PROPOSALS*
for the module system (and the other stuff). We all agree that it's
what we need; I was asking, not what we need, but what *specific form*
it should take!! Doesn't *anybody* have an opinion?
Bear
Ray Dillinger <····@sonic.net> writes:
> Yes, a module system is needed. All the things I want to add ought to
> be modules. But saying that a module system is needed does not give
> me any clues about what you think a good module system would include!!!
>
> The entire point of this was to try to extract *SPECIFIC* *PROPOSALS*
> for the module system (and the other stuff). We all agree that it's
> what we need; I was asking, not what we need, but what *specific form*
> it should take!! Doesn't *anybody* have an opinion?
I do.
0) Look at the proposals already in the Scheme repository
1) Take a look the OCAML module system and at EuLisp's
2) Decide what to do about such things as type checking
3) don't hesitate to drop the lame R4RS semantics for (define foo bar)
y) Trivially implement it in a Scheme with first-class environments.
z) For those who hate first-class things,
standardize a subset that gives enough matches functionality,
and they are free to reimplement w/o fce
(i.e. using a meta-language to deal w/ environments).
Scheme might seem elegant at first glance.
It has too many legacies (like ugly define set-car! set! stuff --
long live references a la ML).
Standardizers had first-class continuations,
but both didn't bother to make a standard module system,
and refused to standardize first-class environments which
would have allowed people to experiment with them.
Well, see
http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/Languages.html#Scheme
== Fare' -- ······@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"
Ray Dillinger <····@sonic.net> writes:
> ...
> The entire point of this was to try to extract *SPECIFIC* *PROPOSALS*
> for the module system (and the other stuff). ...
Matthias Blume had a proposal for a module system; i believe it is available
from his home page on princeton. i am not sure, but there may be a few
proposals for the next revised report.
oz
>>>>> "Marco" =3D=3D Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> =
writes:
Marco> CL gives you so much more power in terms of programmer support that =
-
Marco> and this may definitively be a problem of mine - I simply cannot see
Marco> what is to be gained by keeping on programming with far less
Marco> standardized tools and programming environments (keywords arguments
Marco> being the single most useful thing that CL has over Scheme). My tak=
e
Marco> - and personal experience - is that a lot of Schemers (once again, n=
ot
Marco> all of course) have not really tried to do any significant programmi=
ng
Marco> in CL using CL style. This feeling is also corroborated by some of
Marco> the postings that have appeared over these newsgroups.
Maybe the opposite is true also? I think there are admirable CL
implementations, and there's no question that eminently effective
software development can be done in CL. It just so happens that the
same also holds for Scheme. Of course, the development environments
vary between Scheme implementations.
But, for example, if we just focus on package systems, it so happens
that this is hard enough to design that there's little agreement on
what it should look like in the Scheme community. CL's package system
is standardized but mediocre. At least two Scheme systems I know
(Scheme 48 and MzScheme) have systems that are far more expressive
than CL's. (I.e. with first-class and higher-order modules.)
Also, the lack of tail recursion and first-class continuations may
seem minor to CL programmers who've come to live without them, but
they are significant to Scheme programmers who build eminently useful
and effective abstractions with them that would be much harder (or, in
the case of call/cc, impossible) in CL.
So, just as there may be good reasons to use CL for a specific
applications, there may be reasons just as valid to use Scheme for a
different application realm.
One thing which is bothering me conceptually about CL is the fact that
the standard is not very modular. It is sufficiently large that there
seem to be few (if any at all) free 100% complete CL implementations
out there. Does CL allow you to specifiy dependencies on *parts* of
the standard in a sufficiently elegant way? If not, the compatibility
issue is not much improved in CL over what's in Scheme. (I.e. you
have the choice between a language with complete implementations of a
small standard and incomplete implementations of a large standard.)
Of course I may be oversimplifying or wrong.
--
Cheers =3D8-} Mike
Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla
In article <···············@modas.informatik.uni-tuebingen.de> ·······@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
From: ·······@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Newsgroups: comp.lang.scheme,comp.lang.lisp
Date: 29 Apr 1997 13:24:36 +0200
Organization: Wilhelm-Schickard-Institut, Kakerlakenzuchtverein
Lines: 53
Sender: ·······@modas.informatik.uni-tuebingen.de
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Newsreader: Gnus v5.4.46/XEmacs 20.2(beta2)
Xref: agate comp.lang.scheme:20279 comp.lang.lisp:27586
>>>>> "Marco" =3D=3D Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> =
writes:
Marco> CL gives you so much more power in terms of programmer support that =
-
Marco> and this may definitively be a problem of mine - I simply cannot see
Marco> what is to be gained by keeping on programming with far less
Marco> standardized tools and programming environments (keywords arguments
Marco> being the single most useful thing that CL has over Scheme). My tak=
e
Marco> - and personal experience - is that a lot of Schemers (once again, n=
ot
Marco> all of course) have not really tried to do any significant programmi=
ng
Marco> in CL using CL style. This feeling is also corroborated by some of
Marco> the postings that have appeared over these newsgroups.
Maybe the opposite is true also?
It might as well be.
I think there are admirable CL
implementations, and there's no question that eminently effective
software development can be done in CL. It just so happens that the
same also holds for Scheme. Of course, the development environments
vary between Scheme implementations.
The problem is that the "degree of variation" is way too high and, AFAIK,
there are NO signs of convergence.
But, for example, if we just focus on package systems, it so happens
that this is hard enough to design that there's little agreement on
what it should look like in the Scheme community. CL's package system
is standardized but mediocre. At least two Scheme systems I know
(Scheme 48 and MzScheme) have systems that are far more expressive
than CL's. (I.e. with first-class and higher-order modules.)
I have no problems in admitting that CL package system is limited and
that better systems have been devised. But the above criticism stands.
Also, the lack of tail recursion and first-class continuations may
seem minor to CL programmers who've come to live without them, but
they are significant to Scheme programmers who build eminently useful
and effective abstractions with them that would be much harder (or, in
the case of call/cc, impossible) in CL.
Tail recursion is an implementation issue and the best CL's have it in
their guts. first-class continuations are useful, but not essential.
A standard hash table is not essential, but much more useful than
first-class continuations. The Java core API is a monument to this
simple fact. (And, AFAIK, Slib is not part of RxRS)
So, just as there may be good reasons to use CL for a specific
applications, there may be reasons just as valid to use Scheme for a
different application realm.
I never questioned this.
One thing which is bothering me conceptually about CL is the fact that
the standard is not very modular. It is sufficiently large that there
seem to be few (if any at all) free 100% complete CL implementations
out there. Does CL allow you to specifiy dependencies on *parts* of
the standard in a sufficiently elegant way? If not, the compatibility
issue is not much improved in CL over what's in Scheme. (I.e. you
have the choice between a language with complete implementations of a
small standard and incomplete implementations of a large standard.)
Of course I may be oversimplifying or wrong.
While this is one of the recognized weaknesses of CL (even among CL
die-hard supporters) the problem of "what is in the standard" is
always paramount. But then again, this is an old argument.
Having said so, allow me to respond publicly to those who wrote to me
in private.
I know that many people switched back and forth from CL and Scheme and
I recognize this fact (I myself did the switch from Scheme to CL).
If anybody feels treated unjustly by my comments, I apologize. Of
course I do not have hard statistical data to support my "feelings".
They must be taken for what they are.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
> In article <··········@news.gte.com> ····@bunny.gte.com (Dorai Sitaram) writes:
> I suspect a lot of Schemers who haven't "switched" are
> biased not against CL's size so much as one or two
> mortifying design choices such as the
> symbol-function/symbol-value distinction, the need for
> funcall and #', and the inability to rely on tail-call
> optimization.
A comment: I have never worked with a Lisp compiler that did not
optimize tail-calls.
In article <············@math.okstate.edu> Mark McConnell <·······@math.okstate.edu> writes:
From: Mark McConnell <·······@math.okstate.edu>
Newsgroups: comp.lang.scheme,comp.lang.lisp
Date: Wed, 30 Apr 1997 16:13:15 -0500
Organization: Math Dept., Oklahoma State University
Lines: 10
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4d)
Xref: agate comp.lang.scheme:20294 comp.lang.lisp:27598
> In article <··········@news.gte.com> ····@bunny.gte.com (Dorai Sitaram) writes:
> I suspect a lot of Schemers who haven't "switched" are
> biased not against CL's size so much as one or two
> mortifying design choices such as the
> symbol-function/symbol-value distinction, the need for
> funcall and #', and the inability to rely on tail-call
> optimization.
A comment: I have never worked with a Lisp compiler that did not
optimize tail-calls.
As a matter of fact older versions of GCL (I haven't used it for a
while) were not fully "tail recursive". CMUCL is.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
In article <············@math.okstate.edu>, Mark McConnell
<·······@math.okstate.edu> wrote:
> > In article <··········@news.gte.com> ····@bunny.gte.com (Dorai Sitaram)
writes:
> > I suspect a lot of Schemers who haven't "switched" are
> > biased not against CL's size so much as one or two
> > mortifying design choices such as the
> > symbol-function/symbol-value distinction, the need for
> > funcall and #', and the inability to rely on tail-call
> > optimization.
>
> A comment: I have never worked with a Lisp compiler that did not
> optimize tail-calls.
Symbolics Common Lisp does not. Sigh.
--
http://www.lavielle.com/~joswig/
> In article <············@math.okstate.edu>, Mark McConnell
> <·······@math.okstate.edu> wrote:
>
> > A comment: I have never worked with a Lisp compiler that did not
> > optimize tail-calls.
>
Oh, to be young and in love!
I wrote one once.
--
--Keith
This mail message sent by GNU emacs and Linux.
Power to the people. Linux is here.
Food, Shelter, Source code.
* Mark McConnell wrote:
>> In article <··········@news.gte.com> ····@bunny.gte.com (Dorai Sitaram) writes:
>> I suspect a lot of Schemers who haven't "switched" are
>> biased not against CL's size so much as one or two
>> mortifying design choices such as the
>> symbol-function/symbol-value distinction, the need for
>> funcall and #', and the inability to rely on tail-call
>> optimization.
> A comment: I have never worked with a Lisp compiler that did not
> optimize tail-calls.
But many do/did not -- for instance Symbolics. And this is a nasty
problem if you tend to write stuff that quietly assumes tail-call
elimination as I do -- you don't see the errors until you try it on
sufficiently big data that you get stack overflows
--tim
In article <···············@drakkar.ens.fr>, ······@ens.fr (Francois-Rene
Rideau) wrote:
> In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
>
> First things first. I am not a standards body, nor a journal,
> and as far as I know there is not going to be a conference
> on this topic. I'm a user, and a would-be language implementor,
> trying to elicit opinions from people about what ought to be
> in standard scheme libraries for WIMP, multimedia, and FFI.
>
> Before all these can be achieved,
> the first thing needed is a one real __standard__ module system
...deleted
I agree.
--
Best Wishes, Bengt
Email: ······@damek.kth.se
In article <·······················@sl103.modempool.kth.se> ······@damek.kth.se (Bengt Kleberg) writes:
From: ······@damek.kth.se (Bengt Kleberg)
Date: Tue, 22 Apr 1997 21:35:52 +0100
Organization: DAMEK, KTH
Lines: 21
References: <·············@sonic.net> <···············@drakkar.ens.fr>
In article <···············@drakkar.ens.fr>, ······@ens.fr (Francois-Rene
Rideau) wrote:
> In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
>
> First things first. I am not a standards body, nor a journal,
> and as far as I know there is not going to be a conference
> on this topic. I'm a user, and a would-be language implementor,
> trying to elicit opinions from people about what ought to be
> in standard scheme libraries for WIMP, multimedia, and FFI.
>
> Before all these can be achieved,
> the first thing needed is a one real __standard__ module system
...deleted
I agree.
ANSI CL has packages which are already pretty good at this. A good
and standard module system for Scheme will probably take the next 5/6
years to come by.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
In article <···············@infiniti.PATH.Berkeley.EDU>,
·······@infiniti.PATH.Berkeley.EDU (Marco Antoniotti) wrote:
>
> In article <···············@drakkar.ens.fr>, ······@ens.fr (Francois-Rene
> Rideau) wrote:
> > Before all these can be achieved,
> > the first thing needed is a one real __standard__ module system
...deleted
> ANSI CL has packages which are already pretty good at this. A good
> and standard module system for Scheme will probably take the next 5/6
> years to come by.
So the work should have begun some time ago.
But surely there are some Scheme systems that have modules? Perhaps they
are a good starting point? If the CL system is ok, why not use it?
--
Best Wishes, Bengt
Email: ······@damek.kth.se
Bengt Kleberg (······@damek.kth.se) wrote:
> But surely there are some Scheme systems that have modules? Perhaps they
> are a good starting point? If the CL system is ok, why not use it?
The question is what you want to do with modules, what your general
translation model is like, and why you're going for Scheme in the first
place. CL is a very powerful and non-trivial system, and picking pieces
out of it and transferring them to Scheme won't always create anything
with the original consistency and usability, nor would it necessarily
fit to Scheme's somewhat different approach. If you want something
mostly like CL, you should probably just use CL and adapt those areas
which you don't like, instead of trying to make Scheme look like CL.
There's quite much flexibility in CL to help you perform such things.
I for one don't think CL's package model fits Scheme very well;
something like multiple lexical top-level environments with imports
as read-only access to top-level bindings of other modules would be
preferable. Add a simple way to have macros ask for translation-time
import of modules and elaboration of initializations, and you've got
a reasonably flexible model (leaving things like module redefinition
to the development environment, perhaps with something like "open mode"
and "closed mode" for modules, the latter allowing more optimizations,
like direct calls and inlining, for those definitions which aren't
set! in their defining module). If people want it, this could be
extended with facilities for dynamic module manipulation (making them
into mutable environment objects), but IMO code which doesn't depend
on such dynamic facilities should be easily recognizable as not doing
so, supporting a mostly declarative/functional programming style and
a reasonably straight-forward static analysis of dependencies.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
From: Ray Dillinger
Subject: Re: CFP: scheme standard libraries
Date:
Message-ID: <335FF83D.6688@sonic.net>
So what do people want out of a module system or package system?
I'm a straightforward soul; if I can make a change in one
module and not have to recompile the entire system to make it
work, I'll be (reasonably) happy.
After that, you have a bunch of subtle issues... the more you
tell the compiler about a module, the more optimization it can
do. "This will never be called from outside this module" is an
invitation to inline something and throw away the function
definition, for example. "The only kind of number this will
ever be passed is an integer" is an invitation to optimize
away your typechecking and variant-case code.
Basically, the problem with separating things into packages
is that the compiler no longer has global knowledge during
compilation. When you compile a source file, it can't tell
how other modules will use it -- so it has to generate
very robust code that checks for and handles all the cases --
even the ones that are flatly impossible. So you get slower
machine code that takes up more space, or you wind up
burdening the programmer with keeping track of optimization
issues rather than just solving problems.
And then there are a bunch of namespace-collision issues.
CL "solves" them by having each package be a separate
namespace, but I've always hated that solution myself; I
like being able to ask what <symbol> is bound to and get
an unequivocal answer for any single environment.
One thing that might work better, would be to have a lexical
scoping structure of some kind, such that the local names
don't get bound outside the scope of the module. In schemes
that allow nested function declarations, I often control
namespace by defining functions that can only be called from
within another function, within the lexical scope of that
function. If nested function definitions are *Required*
by the language, they are an excellent way to control
namespace and provide optimization information naturally in
a way that simply reflects the structure of the code.
Bear
>>>>> "Ray" =3D=3D Ray Dillinger <····@sonic.net> writes:
Ray> So what do people want out of a module system or package system?
Since this issue is a hard one, I suggest sticking with one of the
available module systems. Scheme 48 and MzScheme come to mind. Both
models are quite powerful. (First-class modules & interfaces ...) I
tend to prefer the one in Scheme 48 since it's inherently
non-intrusive. I also have some code to make it translate into more
naive systems such as Bigloo's.
--
Cheers =3D8-} Mike
Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla
In article <·············@sonic.net> Ray Dillinger <····@sonic.net> writes:
[On the CL package system]
And then there are a bunch of namespace-collision issues.
CL "solves" them by having each package be a separate
namespace, but I've always hated that solution myself; I
like being able to ask what <symbol> is bound to and get
an unequivocal answer for any single environment.
Package prefixes should get you pretty unequivocal answers.
E.g. FOO::BAZ is BAZ in package FOO. The colon is a `package marker'
(according to the standard readtable, that is), and with a doubled
package marker you dig out internal variables, too.
(Or did I misunderstand you?)
rthappe
On Tue, 22 Apr 1997 02:09:58 -0700, Ray Dillinger <····@sonic.net>
wrote:
>We need standard libraries and functionality for scheme. I'm
>interested in defining a "functionality standard" for the
>language.
Sounds good to me!
>1) We need a WIMP library. Windows, Icons, Menus, and Pointers.
> What do they look like in scheme? What should they
> look like in scheme?
Hmmm - CLIM might provide some interesting ideas. Is there a CLIM
for Scheme out there?
>2) MultiMedia. We need a way to handle sound and graphics.
> Who's got one? What's it like?
File format independence would be nice!
How about:
OOP
A module system
>I'm "punting" on a couple of things:
>
> 1) a Standard Object System
> 2) a Standard low-level Macro System
>
>until such time as various issues surrounding them become
>clearer.
Ah. Right :-)
> Your assistance is requested,
If you're ever stuck for a decision, I could probably offer an
opinion, at least.
> Ray Dillinger
ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
> Hmmm - CLIM might provide some interesting ideas. Is there a CLIM
> for Scheme out there?
I have a really tiny subset of CLIM for Scheme->C in QobiScheme, available
free from my home page.
Jeff (home page http://www.emba.uvm.edu/~qobi)