Question on using Scheme on Large Projects
Russell Lear
Programming" and I'm working on "On Lisp". (On Lisp has really given me a
much better understanding of what you can do with macros! Graham explains
things very clearly) I've re-written a few of my smaller hacks on Scheme
as exercises and have had a lot of fun doing it.
The examples in books (and my own hacks) are good teaching tools but they're
all relatively small, self-contained problems.
Now I'm curious if Scheme influences the way one designs and builds larger
projects. Are Objects & Classes still the abstraction of choice? Do you
use the tools I'm familiar with (UML editors, etc)? Do you draw
interaction/sequence diagrams showing message passing between objects whose
operations have been defined in class diagrams with the implementation in
Scheme/Lisp a mere detail of the implementation?
Thanks for any insight,
Russell.
cr88192
scheme has had a much larger effect on my coding style, even for other
languages. often I write c code now with a style closer to scheme than to
c++ for example.
I would think that classes/objects would be a lot less common in many
cases, and that it may make sense to alter such "class diagrams" in many
cases, but this has just been my experience and others may vary greatly...
Marco Antoniotti
Russell Lear <russe...@earthlink.net> writes:
> First off, I'm new to scheme/lisp. I've read "Scheme and the Art of
> Programming" and I'm working on "On Lisp". (On Lisp has really given me a
> much better understanding of what you can do with macros! Graham explains
> things very clearly) I've re-written a few of my smaller hacks on Scheme
> as exercises and have had a lot of fun doing it.
>
> The examples in books (and my own hacks) are good teaching tools but they're
> all relatively small, self-contained problems.
>
> Now I'm curious if Scheme influences the way one designs and builds larger
> projects.
Yes it does. Essentially it is the Lisp/Scheme way of doing things
that influences you.
> Are Objects & Classes still the abstraction of choice?
That depends on the application. But since you don't have classes and
objects in Scheme (if it ain't in R^NRS, it ain't in Scheme), the
question of using them if you are using Scheme is rather irrelevant.
Use the real thing instead, with packages, classes and objects and all
the bells and whistles standard and portable.
> Do you
> use the tools I'm familiar with (UML editors, etc)? Do you draw
> interaction/sequence diagrams showing message passing between objects whose
> operations have been defined in class diagrams with the implementation in
> Scheme/Lisp a mere detail of the implementation?
I have not much experience in using UML stuff. AFAIU, UML is kind of
geared toward C++/Java kind of OO and not toward CLOS (which uses a
different, more generic kind of dispatching and a different notion of
encapsulation via packages). So, I think you can recast your UML
things in CLOS, but I do not know of any automated tool for that.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Benjamin Simon
>> Are Objects & Classes still the abstraction of choice?
MA> That depends on the application. But since you don't have classes
MA> and objects in Scheme (if it ain't in R^NRS, it ain't in Scheme),
[Sorry start this flame war again, but I think this is pretty absurd]
So if a procedure is defined in the lisp spec you don't use it? You
don't make new procedures? Gosh that's gotta make development mighty
tricky ;-).
In scheme, objects are just regular functions -- I don't see why you
can't create them (or use an already created object system) and use
them?
-Ben
Marco Antoniotti
Benjamin Simon <b...@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> >> Are Objects & Classes still the abstraction of choice?
>
> MA> That depends on the application. But since you don't have classes
> MA> and objects in Scheme (if it ain't in R^NRS, it ain't in Scheme),
>
> [Sorry start this flame war again, but I think this is pretty absurd]
>
> So if a procedure is defined in the lisp spec you don't use it? You
> don't make new procedures? Gosh that's gotta make development mighty
> tricky ;-).
Sure, In Scheme you define things like DEFSTRUCT (and/or define-record
dependeing on your SIDJ - Scheme Implementation Du Jour), MAKE-ARRAY
(multidimensional) DEFCLASS etc etc.
> In scheme, objects are just regular functions -- I don't see why you
> can't create them (or use an already created object system)
Exactly my point. Move over to Common Lisp, use "an already
created object system" and be done with it.
> and use them?
I use an object system every day. It is full fledged and
portable. Why should I give up these features and downgrade to
something less usable?
Benjamin Simon
MA> Benjamin Simon <b...@atom.amazingmedia.com> writes:
>> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
>>
>> >> Are Objects & Classes still the abstraction of choice?
>>
MA> That depends on the application. But since you don't have classes
MA> and objects in Scheme (if it ain't in R^NRS, it ain't in Scheme),
>>
>> [Sorry start this flame war again, but I think this is pretty absurd]
>>
>> So if a procedure is defined in the lisp spec you don't use it? You
>> don't make new procedures? Gosh that's gotta make development mighty
>> tricky ;-).
MA> Sure, In Scheme you define things like DEFSTRUCT (and/or
MA> define-record dependeing on your SIDJ - Scheme Implementation Du
MA> Jour), MAKE-ARRAY (multidimensional) DEFCLASS etc etc.
SICP [1] describes using objects, and doesn't require any of these
constructs.
>> In scheme, objects are just regular functions -- I don't see why you
>> can't create them (or use an already created object system)
MA> Exactly my point. Move over to Common Lisp, use "an already
MA> created object system" and be done with it.
Or use one of the implementations provided by:
http://www.cs.indiana.edu/scheme-repository/code.oop.html
or
http://www.swiss.ai.mit.edu/~jaffer/slib_toc.html
and be done with it.
>> and use them?
MA> I use an object system every day. It is full fledged and
MA> portable.
The ones listed above (slib for example) are portable. I'm not sure if
I would call them "full fledged" as I'm not totally familiar with them
all.
MA> Why should I give up these features and downgrade to something less
MA> usable?
I'm not suggesting you should. I'm just suggesting that saying that you
can't use objects is in Scheme is a silly thing to say and untrue. You
might not like the object systems, but they do exist.
-Ben
Footnotes:
[1] http://mitpress.mit.edu/sicp/full-text/book/book.html
Marco Antoniotti
Benjamin Simon <b...@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
...
> MA> Sure, In Scheme you define things like DEFSTRUCT (and/or
> MA> define-record dependeing on your SIDJ - Scheme Implementation Du
> MA> Jour), MAKE-ARRAY (multidimensional) DEFCLASS etc etc.
>
> SICP [1] describes using objects, and doesn't require any of these
> constructs.
The fact that SICP does not require this constructs does not mean that
they are useless. Tape and Read/Write heads do not require these
objects either, yet they give you the full power of Common Lisp.
Essentially SICP (as far as I remember and unless the latest editions
amemded it) cannot even define `force' on `streams' since it assumes a
Scheme that does not have `define-syntax'. That does not mean that
`force' is useless.
> >> In scheme, objects are just regular functions -- I don't see why you
> >> can't create them (or use an already created object system)
>
> MA> Exactly my point. Move over to Common Lisp, use "an already
> MA> created object system" and be done with it.
>
> Or use one of the implementations provided by:
> http://www.cs.indiana.edu/scheme-repository/code.oop.html
> or
> http://www.swiss.ai.mit.edu/~jaffer/slib_toc.html
Sorry. It ain't in R^nRS, it ain't in Scheme. If you use one of the
above you are using your SIDJ. (I know `slib' - a subset of what is
already in CL - is relatively portable).
> and be done with it.
>
> >> and use them?
> MA> I use an object system every day. It is full fledged and
> MA> portable.
>
> The ones listed above (slib for example) are portable. I'm not sure if
> I would call them "full fledged" as I'm not totally familiar with them
> all.
(equivalent "full fledged" "Common Lisp")
>
> MA> Why should I give up these features and downgrade to something less
> MA> usable?
>
> I'm not suggesting you should. I'm just suggesting that saying that you
> can't use objects is in Scheme is a silly thing to say and untrue. You
> might not like the object systems, but they do exist.
I am not questioning the existence of N different object systems in
your SIDJ. I am questioning the use of a language that forces you to
re-implement - unportably - every single bit that you already have -
portably - in CL.
I understand that this is rethorical and pointless, but as K. Vonnegut
said, "it's for the record" :)
Thomas Bushnell, BSG
> The fact that SICP does not require this constructs does not mean that
> they are useless. Tape and Read/Write heads do not require these
> objects either, yet they give you the full power of Common Lisp.
SICP is not a "how to use Scheme" book, but rather a "how to think
about how to program computers" book.
It doesn't mention call/cc either, but this is not because the authors
of SICP think call/cc is unimportant.
Marco Antoniotti
tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > The fact that SICP does not require this constructs does not mean that
> > they are useless. Tape and Read/Write heads do not require these
> > objects either, yet they give you the full power of Common Lisp.
>
> SICP is not a "how to use Scheme" book, but rather a "how to think
> about how to program computers" book.
I never said that. SICP is one of the most wonderful books about
programming in general out there. I still have to see antoher that
covers as much ground with the same depth. (Well, I suppose there are
a few).
> It doesn't mention call/cc either, but this is not because the authors
> of SICP think call/cc is unimportant.
Sure. I agree.
Cheers.
Benjamin Simon
MA> Benjamin Simon <b...@atom.amazingmedia.com> writes:
>> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
MA> ...
MA> Sure, In Scheme you define things like DEFSTRUCT (and/or
MA> define-record dependeing on your SIDJ - Scheme Implementation Du
MA> Jour), MAKE-ARRAY (multidimensional) DEFCLASS etc etc.
>>
>> SICP [1] describes using objects, and doesn't require any of these
>> constructs.
MA> The fact that SICP does not require this constructs does not mean
MA> that they are useless.
Who said that these constructs are "useless"? All I said is that they
aren't required. Where did you get the idea that I said they were
"useless"?
MA> Essentially SICP (as far as I remember and unless the latest
MA> editions amemded it) cannot even define `force' on `streams' since
MA> it assumes a Scheme that does not have `define-syntax'. That does
MA> not mean that `force' is useless.
SICP does discuss streams, and does require force/delay to be
implemented (which they are in R5RS). But that wasn't my point. My point
is that you can use scheme and objects just fine given what is described
in R5RS.
>> >> In scheme, objects are just regular functions -- I don't see why you
>> >> can't create them (or use an already created object system)
>>
MA> Exactly my point. Move over to Common Lisp, use "an already
MA> created object system" and be done with it.
>>
>> Or use one of the implementations provided by:
>> http://www.cs.indiana.edu/scheme-repository/code.oop.html
>> or
>> http://www.swiss.ai.mit.edu/~jaffer/slib_toc.html
MA> Sorry. It ain't in R^nRS, it ain't in Scheme.
There you go again. I don't get it. Is the following function not
scheme:
(define (foo x)
(+ x 1))
Looks like scheme to me. It isn't defined in R5RS so it must not be,
according to your logic.
MA> If you use one of the above you are using your SIDJ. (I know `slib'
MA> - a subset of what is already in CL - is relatively portable).
Huh? what's "SIDJ"? So if I use the function above, does that mean I'm
not using Scheme, but some other language?
MA> I am not questioning the existence of N different object systems in
MA> your SIDJ. I am questioning the use of a language that forces you
MA> to re-implement - unportably - every single bit that you already
MA> have - portably - in CL.
Ahhh, so this turns into a: "Scheme only specifies what is absolutely
necessary, vs CL specifies everything" argument. This argument doesn't
need to be re-hashed. If that's what you meant in the first place, why
didn't you just say it?
BUT, the point is that when writing Scheme, it is practical to solve
problems in an OO fashion.
-Ben
ozan s yigit
> ... You
> might not like the object systems, but they do exist.
a very good discussion of the details of meroon, a popular object system
on scheme, is found in Queinnec's update of anatomy of lisp[1], chapt. 11
"essence of an object system." useful reading. [one wishes such a book
existed for other members of the family :-]
oz
---
if you want to have your head in the clouds
you need to keep your feet on the ground. -- terry pratchett
---
[1] Christian Queinnec, "Lisp in Small Pieces," Cambridge University
Press, 1996.
Marco Antoniotti
Benjamin Simon <b...@atom.amazingmedia.com> writes:
> SICP does discuss streams, and does require force/delay to be
> implemented (which they are in R5RS). But that wasn't my point. My point
> is that you can use scheme and objects just fine given what is described
> in R5RS.
...
> >> Or use one of the implementations provided by:
> >> http://www.cs.indiana.edu/scheme-repository/code.oop.html
> >> or
> >> http://www.swiss.ai.mit.edu/~jaffer/slib_toc.html
>
> MA> Sorry. It ain't in R^nRS, it ain't in Scheme.
>
> There you go again. I don't get it. Is the following function not
> scheme:
> (define (foo x)
> (+ x 1))
>
> Looks like scheme to me. It isn't defined in R5RS so it must not be,
> according to your logic.
What I meant is that
(define-class (panda-bear animal endengered-specie)
...)
is not in Scheme.
> MA> If you use one of the above you are using your SIDJ. (I know `slib'
> MA> - a subset of what is already in CL - is relatively portable).
>
> Huh? what's "SIDJ"?
Scheme Implementation Du Jour. It is a variation of SLDJ: Scripting
Language Du Jour :)
...
> MA> I am not questioning the existence of N different object systems in
> MA> your SIDJ. I am questioning the use of a language that forces you
> MA> to re-implement - unportably - every single bit that you already
> MA> have - portably - in CL.
>
> Ahhh, so this turns into a: "Scheme only specifies what is absolutely
> necessary,
maning: far less than what is useful.
> vs CL specifies everything"
I would not go that far. There are plenty of things that are not
specified in CL.
> argument. This argument doesn't
> need to be re-hashed. If that's what you meant in the first place, why
> didn't you just say it?
Well, seriously, it was in the thread....
> BUT, the point is that when writing Scheme, it is practical to solve
> problems in an OO fashion.
Yes. But it is way more practical to do so in CL where you have a
portable and standard Object System.
... for the record. :)
Michael Sullivan
> Benjamin Simon <b...@atom.amazingmedia.com> writes:
> > MA> Sorry. It ain't in R^nRS, it ain't in Scheme.
> > There you go again. I don't get it. Is the following function not
> > scheme:
> > (define (foo x)
> > (+ x 1))
> > Looks like scheme to me. It isn't defined in R5RS so it must not be,
> > according to your logic.
> What I meant is that
>
> (define-class (panda-bear animal endengered-specie)
> ...)
But if there are libraries that define "define-class" in terms of RnRS,
then how are they "not portable"? The only difference between this and
using stuffed defined in the CL spec, is that you must include the used
portions of the libraries in your project (that and the fact that the
implementation in some CLs might be optimized in some way). But in any
case, you certainly don't have to rewrite them.
> Scheme Implementation Du Jour. It is a variation of SLDJ: Scripting
> Language Du Jour :)
I think you're confusing Implementation (things that might be hard coded
into the environment) with portable open source libraries.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Jens Axel Søgaard
> Yes. But it is way more practical to do so in CL where
> you have a portable and standard Object System.
> ... for the record. :)
Scheme didn't end with R5RS. Now the SRFIs (surfies)
have taken over
Just for the record:
http://srfi.schemers.org/srfi-9/srfi-9.html
--
Jens Axel Søgaard
Thomas F. Burdick
> Marco Antoniotti <mar...@cs.nyu.edu> wrote:
>
> > Benjamin Simon <b...@atom.amazingmedia.com> writes:
>
> > > MA> Sorry. It ain't in R^nRS, it ain't in Scheme.
>
> > > There you go again. I don't get it. Is the following function not
> > > scheme:
> > > (define (foo x)
> > > (+ x 1))
>
> > > Looks like scheme to me. It isn't defined in R5RS so it must not be,
> > > according to your logic.
>
> > What I meant is that
> >
> > (define-class (panda-bear animal endengered-specie)
> > ...)
>
> But if there are libraries that define "define-class" in terms of RnRS,
> then how are they "not portable"? The only difference between this and
> using stuffed defined in the CL spec, is that you must include the used
> portions of the libraries in your project (that and the fact that the
> implementation in some CLs might be optimized in some way). But in any
> case, you certainly don't have to rewrite them.
This is true to the extent that you don't share code. If I write a
library using object system A, you write one using object system B,
and someone who uses object system C wants to use both these
libraries; everything's a mess. One of the nice features of an OO
interface to a library is the ability to use the library by extending
carefully-selected bits of the inside of the library. If you've got
three different object systems, you can't make the final application
just an extension of the two libraries.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Marco Antoniotti
mic...@bcect.com (Michael Sullivan) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> wrote:
>
...
> > What I meant is that
> >
> > (define-class (panda-bear animal endengered-specie)
> > ...)
>
> But if there are libraries that define "define-class" in terms of RnRS,
> then how are they "not portable"? The only difference between this and
> using stuffed defined in the CL spec, is that you must include the used
> portions of the libraries in your project (that and the fact that the
> implementation in some CLs might be optimized in some way). But in any
> case, you certainly don't have to rewrite them.
Of course not. You just end up programming in your SIDJ and therefore
in (essentially) a subset of Common Lisp.
W.r.t. Object Orientation this is what was happening in CL *before*
CLOS. Hey, I used QSL!
Not only that. Some of the Scheme OO library may not work on all K
Scheme implementations (for K > 1 gozillion). Hence the code you wrote
for your SIDJ (Scheme Implementation Du Jeudi) may not not work on
your SIDS (Scheme Implementation Du Samedi - excuse my French :) ).
> > Scheme Implementation Du Jour. It is a variation of SLDJ: Scripting
> > Language Du Jour :)
>
> I think you're confusing Implementation (things that might be hard coded
> into the environment) with portable open source libraries.
There is no confusion. The terms of the discussion are clear: when
programming in Scheme you are essentially programming in SIDJ. That
is because R^nRS is way too small and lacking to be of any use by
itself. Of course you can define your more or less portable library on
top of Scheme. The issue is that most of the "basic" libraries (e.g
any of the N `record' or Object Systems in Scheme) essentially
duplicate what you have standard in CL.
So, why not use the real thing instead? That's it. Unless you want to
wait for R^NRS for N arbitraly large, at which point you will probably
have a Scheme that looks like... Common Lisp.
Marco Antoniotti
Yep. 1999 a full 10 years later than DEFSTRUCT in CLtL1. And you have
no assurance that SRFI 9 will be available in your SIDJ.
While "Not in R^NRS, not in Scheme" is true by definition, "Not
necessarily, in SRFI implies in SIDJ" is also true. Another mostly true
sentence is "In SRFI, already in Common Lisp".
Out of the 29 "final" SRFIs at least 25 are already in Common Lisp. Of
the four missing, one is related to Time data structures (I will call
on Erik Naggum about this), another to "threading" (something that the
CLIM process interface protty much covers), another to "Real Time
support", and another on "Running Scheme scripts from Unix". I will
grant you that these four cover interesting ground. But please! The
other 25 are just.....
Ok. enough of this. I find myself trolling on CLL. :)
Tim Bradshaw
> But if there are libraries that define "define-class" in terms of RnRS,
> then how are they "not portable"? The only difference between this and
> using stuffed defined in the CL spec, is that you must include the used
> portions of the libraries in your project (that and the fact that the
> implementation in some CLs might be optimized in some way). But in any
> case, you certainly don't have to rewrite them.
The bit of the subject line you are missing is `using scheme'. If you
are using scheme + a bunch of libraries, then you are not just using
scheme. This may seem an annoying point, but see below.
> I think you're confusing Implementation (things that might be hard coded
> into the environment) with portable open source libraries.
I think you are confusing implementation with specification. This is
the standard class-instance confusion which SLDJ people often fall
into - I'm somewhat surprised to see scheme people fall into it like
this. If you are programming to a specification (such as the CL
specification) then you can, for instance, complain when the specific
implementation of that specification that you are using (whether it is
portable open source or not) does not meet that specification. If you
program to an implementation then, unless you want to maintain that
implementation, if it gets changed, you're screwed. I use an old
version of Perl for just exactly this reason, for instance. It does
not matter if the implementation is portable, open source, or not.
Indeed, the cynic in me would argue that the commercial
implementations are safer in many cases - non-monopolist vendors tend
to be a big cautious about changing their implementations in ways that
break a lot of their paying customers' programs...
--tim
Jens Axel Søgaard
> "Jens Axel Søgaard" <use...@soegaard.net> writes:
>
>> Marco Antoniotti wrote:
>>
>>> Yes. But it is way more practical to do so in CL where
>>> you have a portable and standard Object System.
>>
>>> ... for the record. :)
>>
>> Scheme didn't end with R5RS. Now the SRFIs (surfies)
>> have taken over
>>
>> Just for the record:
>>
>> http://srfi.schemers.org/srfi-9/srfi-9.html
>>
>
> Yep. 1999 a full 10 years later than DEFSTRUCT in CLtL1.
> And you have no assurance that SRFI 9 will be available
> in your SIDJ.
I think you overlooked the reference implementation :-)
> Ok. enough of this. I find myself trolling on CLL. :)
:-)
I think the difference is purely political. Kent Pitman
made a very nice point when he said that the
community is part of the language.
http://world.std.com/~pitman/PS/Lambda.html
This just shows why there are two communities.
--
Jens Axel Søgaard
Marco Antoniotti
t...@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> mic...@bcect.com (Michael Sullivan) writes:
>
...
> > But if there are libraries that define "define-class" in terms of RnRS,
> > then how are they "not portable"? The only difference between this and
> > using stuffed defined in the CL spec, is that you must include the used
> > portions of the libraries in your project (that and the fact that the
> > implementation in some CLs might be optimized in some way). But in any
> > case, you certainly don't have to rewrite them.
>
> This is true to the extent that you don't share code. If I write a
> library using object system A, you write one using object system B,
> and someone who uses object system C wants to use both these
> libraries; everything's a mess. One of the nice features of an OO
> interface to a library is the ability to use the library by extending
> carefully-selected bits of the inside of the library. If you've got
> three different object systems, you can't make the final application
> just an extension of the two libraries.
Compound that with the lack of encapsulation facilities in Scheme (not
even in the "final" SRFIs).
Jens Axel Søgaard
> Compound that with the lack of encapsulation facilities
> in Scheme (not even in the "final" SRFIs).
It is exactly the same argument as the object one.
It is possible to write a module system within R5RS
(and thus it is not included in the standard).
Q: How do I mix modules from different implementations?
A: Take a look at S2 - A Scheme to Scheme compiler.
[Don't laugh :-)]
http://mangler.sourceforge.net/
Q: Isn't this impractical?
A: Yes.
--
Jens Axel Søgaard
Michael Sullivan
> * Michael Sullivan wrote:
>
> > But if there are libraries that define "define-class" in terms of RnRS,
> > then how are they "not portable"? The only difference between this and
> > using stuffed defined in the CL spec, is that you must include the used
> > portions of the libraries in your project (that and the fact that the
> > implementation in some CLs might be optimized in some way). But in any
> > case, you certainly don't have to rewrite them.
>
> The bit of the subject line you are missing is `using scheme'. If you
> are using scheme + a bunch of libraries, then you are not just using
> scheme. This may seem an annoying point, but see below.
>
> > I think you're confusing Implementation (things that might be hard coded
> > into the environment) with portable open source libraries.
> I think you are confusing implementation with specification. This is
> the standard class-instance confusion which SLDJ people often fall
> into - I'm somewhat surprised to see scheme people fall into it like
> this.
First of all, it would be beyond a stretch to call me a "scheme" person.
I'm a newbie to lisps in general,[*] and as yet have no idea where I'm
likely to fall regarding the great and terribly important question of
whether Lispers or Schemers are more heavily endowed in the phallus.
Right now, I'm leaning toward thinking I'll be using CL when the time
comes to develop something for someone besides me.
Second, I realize there is a distinction between something which is in
the language spec, and something which is fairly easily and portably
supported by an underlying language, and where there are dozens of
portable implementations lying around. Having a standard is good.
Having it your own way can also be good. Where that trade makes sense
varies depending on the problem, and the style of the programmer, I'd
guess.
The great divide appears to be between those who want most of the
fundamental concepts standardized, and those who want as few fundamental
concepts standardized as is necessary.
My point (or rather Benjamin Simon's point) is that it's needlessly
inflammatory and misses a lot of points to say that Objects and Classes
are not in Scheme (implication that you can't really use objects and
classes as long as you're programming in Scheme).
That's ludicrous. Scheme is expressive enough that it's not even a
weekend hack to make up some very basic support for objects and classes
right out of R^5RS with no extra libraries. Compare that to trying to
do the same in FORTRAN, or plain C.
The fact that you can build a real, efficient, object system solely with
Scheme libraries means that it's pretty legitimate to do OO within
Scheme. Might CLOS be a better choice if you know that you're
predominant paradigm will be OO? Probably. If there weren't advantages
to CLOS, no one would have bothered to implement it. OTOH, depending on
the problem, Smalltalk or even <shudder> Java could turn out to be an
even better choice. But Scheme with the right libraries seems perfectly
legit, especially for someone comfortable with Scheme, and not CL.
Saying that a standardized OO system has advantages over one that isn't
standardized (and Thomas Burdick pointed out the critical gotcha to
working non-standardized in this regard) is a far cry from saying
"Objects and Classes aren't in Scheme". If there's a widely available
open source library, that will run unmodified on any conforming Scheme
implementation, and that provides good object and class abstractions --
then objects and classes are in Scheme for all practical purposes.
> If you are programming to a specification (such as the CL
> specification) then you can, for instance, complain when the specific
> implementation of that specification that you are using (whether it is
> portable open source or not) does not meet that specification. If you
> program to an implementation then, unless you want to maintain that
> implementation, if it gets changed, you're screwed.
But the whole point is, we're not talking about programming to an
implementation. We're talking about plugging in code (that depends only
on the base language spec) as a library. As long as my scheme
implementation meets the R^5RS spec, that library will still work just
fine. The only real issue here is if the some future N breaks the
library, at which point I might have to port it or wait for it to be
ported in order to use a newer Scheme implementation. Just like you
might have to wait for your CL vendor to implement some update to the CL
standard. Okay, so it's two potential points of failure. But then, how
likely is it that some future R^NRS won't run legal R^5RS code?
I have no intention of arguing that there are no advantages to using a
language where the OO paradigm is defined in the language spec, just
that it's ludicrous to say you can't use objects and classes in Scheme.
Nils Goesche
> I have no intention of arguing that there are no advantages to
> using a language where the OO paradigm is defined in the
> language spec, just that it's ludicrous to say you can't use
> objects and classes in Scheme.
Does the existence of the Boehm collector make C a garbage
collected language, then?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
Michael Sullivan
> First of all, it would be beyond a stretch to call me a "scheme" person.
> I'm a newbie to lisps in general,[*]
It appears I left a dangling pointer lying around here. Old habits die
hard. I meant only to note that I'm having the classic experience
described on this newsgroup. I'm thinking "Where have you been all my
life?" a lot. Learning Lisp (the family) is likely to improve my C code
dramatically -- that is -- if I ever write any C code again.
When I was in college, I often told people that I didn't really want to
program for a living because my favorite language was pseudo-code --
actual languages just get so dirty and obnoxious with way too much
syntactical baloney getting in your way. I greatly enjoyed every
theoretical CS class, but got really frustrated in all the practical
ones. I fantasized that one day, some killer AI genius would write a
pseudo-code compiler.
What I didn't realize at the time was that it was done in the 50s.
Marco Antoniotti
mic...@bcect.com (Michael Sullivan) writes:
....
> First of all, it would be beyond a stretch to call me a "scheme" person.
> I'm a newbie to lisps in general,[*] and as yet have no idea where I'm
> likely to fall regarding the great and terribly important question of
> whether Lispers or Schemers are more heavily endowed in the phallus.
Size does matter :)
> Right now, I'm leaning toward thinking I'll be using CL when the time
> comes to develop something for someone besides me.
>
> Second, I realize there is a distinction between something which is in
> the language spec, and something which is fairly easily and portably
> supported by an underlying language, and where there are dozens of
> portable implementations lying around. Having a standard is good.
> Having it your own way can also be good. Where that trade makes sense
> varies depending on the problem, and the style of the programmer, I'd
> guess.
What is questioned in all this thread is whether "having it your own
way" makes sense, when that means "having it the way it is already
standardized and working".
> The great divide appears to be between those who want most of the
> fundamental concepts standardized, and those who want as few fundamental
> concepts standardized as is necessary.
That is the apparent debate. IMHO, that is not the case. It is
between those who realize that in this particular arena, "having as
few concepts standardized" leads to re-implementation and the others.
> My point (or rather Benjamin Simon's point) is that it's needlessly
> inflammatory and misses a lot of points to say that Objects and Classes
> are not in Scheme (implication that you can't really use objects and
> classes as long as you're programming in Scheme).
Well, I agree. I am conscious to be inflammatory. That is why I
should stop right now.
> That's ludicrous. Scheme is expressive enough that it's not even a
> weekend hack to make up some very basic support for objects and classes
> right out of R^5RS with no extra libraries. Compare that to trying to
> do the same in FORTRAN, or plain C.
Nobody is questioning that. That's the reason for all the references
to Tape and Read/Write heads in this thread.
...
> > Tim Bradshaw:
> >
> > If you are programming to a specification (such as the CL
> > specification) then you can, for instance, complain when the specific
> > implementation of that specification that you are using (whether it is
> > portable open source or not) does not meet that specification. If you
> > program to an implementation then, unless you want to maintain that
> > implementation, if it gets changed, you're screwed.
>
> But the whole point is, we're not talking about programming to an
> implementation. We're talking about plugging in code (that depends only
> on the base language spec) as a library.
No. That is not the debate. The debate is why do you need to
re-implement library over library to get essentially to a
re-implementation of Common Lisp. Why not just use the real thing?
I am sorry if there has been so much miscommunication, but I always
wrote my flames with that framework in mind.
...
> I have no intention of arguing that there are no advantages to using a
> language where the OO paradigm is defined in the language spec, just
> that it's ludicrous to say you can't use objects and classes in
> Scheme.
Well. That is exactly the difference between our viewpoints: I am not
arguing that you cannot build an OO system in Scheme (hey I did it in
1986 or around there). I am arguing exactly what you do not want to argue:
at this time and place, choosing CL over Scheme is the wise course of
action because - among other things - you have a standardized OO.
Now seriously: enough of this.
Brian Palmer
> Does the existence of the Boehm collector make C a garbage
> collected language, then?
Somewhat tangentially, could you tell me where in the hyperspec it
says that Common Lisp is a garbage collected language? I just skimmed
through the places I'd've expected it to be specified, and didn't see
it.
--
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess [only] as long as he
keeps it to himself.... -- Thomas Jefferson
Nils Goesche
> Nils Goesche <n...@cartan.de> writes:
> > Does the existence of the Boehm collector make C a garbage
> > collected language, then?
>
> Somewhat tangentially, could you tell me where in the hyperspec it
> says that Common Lisp is a garbage collected language? I just skimmed
> through the places I'd've expected it to be specified, and didn't see
> it.
I guess you are supposed to infer this from the absence of FREE
and hope for the best :-)
Hartmann Schaffer
Nils Goesche <n...@cartan.de> writes:
> Brian Palmer <bpa...@leland.stanford.edu> writes:
>
>> Nils Goesche <n...@cartan.de> writes:
>> > Does the existence of the Boehm collector make C a garbage
>> > collected language, then?
>>
>> Somewhat tangentially, could you tell me where in the hyperspec it
>> says that Common Lisp is a garbage collected language? I just skimmed
>> through the places I'd've expected it to be specified, and didn't see
>> it.
>
> I guess you are supposed to infer this from the absence of FREE
> and hope for the best :-)
malloc (and friends) and free are library functions. you won't find
free in in the language spec either (at least if you exclude the
standard library). so based on your argumentation C is a "garbage
collected language"
hs
--
don't use malice as an explanation when stupidity suffices
Hartmann Schaffer
> top of Scheme. The issue is that most of the "basic" libraries (e.g
> any of the N `record' or Object Systems in Scheme) essentially
> duplicate what you have standard in CL.
or in scheme plus a library tailored for a certain problem set
> ...
Kaz Kylheku
> In scheme, objects are just regular functions -- I don't see why you
> them?
The answer is simple: because this is the year 2002, not 1982.
Thomas Bushnell, BSG
> malloc (and friends) and free are library functions. you won't find
> free in in the language spec either (at least if you exclude the
> standard library). so based on your argumentation C is a "garbage
> collected language"
Standard C no longer distinguishes between the standard library and
the language spec with the rigid wall it once had...instead, they are
really folded quite together--just as they are for Lisp.
Russ Allbery
> malloc (and friends) and free are library functions. you won't find
> free in in the language spec either (at least if you exclude the
> standard library). so based on your argumentation C is a "garbage
> collected language"
The C standard library is part of its specification. You will certainly
find malloc and free in the ISO C99 standard.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Paul F. Dietz
> malloc (and friends) and free are library functions. you won't find
> free in in the language spec either (at least if you exclude the
> standard library). so based on your argumentation C is a "garbage
> collected language"
No, because that subset of the language lacks malloc. From
that I would conclude C is a language that does not allow objects
to be allocated on the heap -- so why should I conclude it has
garbage collection?
Paul
Kaz Kylheku
> The great divide appears to be between those who want most of the
> fundamental concepts standardized, and those who want as few fundamental
> concepts standardized as is necessary.
The latter belong to a bygone era of programming language experimentation.
Sure, in 1975, it would have been premature to standardize certain things.
> My point (or rather Benjamin Simon's point) is that it's needlessly
> inflammatory and misses a lot of points to say that Objects and Classes
> are not in Scheme (implication that you can't really use objects and
> classes as long as you're programming in Scheme).
>
> That's ludicrous. Scheme is expressive enough that it's not even a
> weekend hack to make up some very basic support for objects and classes
> right out of R^5RS with no extra libraries. Compare that to trying to
> do the same in FORTRAN, or plain C.
>
> The fact that you can build a real, efficient, object system solely with
> Scheme libraries means that it's pretty legitimate to do OO within
> Scheme.
Absolutely. But in the real world, you sometimes have to integrate pieces
written by large teams of programmers. You don't want everyone on the
same project speaking a different object system!
This state of affairs is a precursor to standardization; in other words, the
stage that some languages already went through. Lisp already went through an
era of experimentation with object system implementations. CLOS is the result.
To argue that this is better than standardization is to argue that progress
should flow backward, the ultimate conclusion of which is that we should
dismantle our technological society and just work the fields by hand and beast.
> Saying that a standardized OO system has advantages over one that isn't
> standardized (and Thomas Burdick pointed out the critical gotcha to
> working non-standardized in this regard) is a far cry from saying
> "Objects and Classes aren't in Scheme".
But they aren't.
> If there's a widely available
> open source library, that will run unmodified on any conforming Scheme
> implementation, and that provides good object and class abstractions --
> then objects and classes are in Scheme for all practical purposes.
Ah, but what if there are *three* incompatible widely available
libraries that will run unmodified in any language implementation?
Hey, three is better than one right? The more, the merrier.
Nicolas Neuss
mic...@bcect.com (Michael Sullivan) writes:
> My point (or rather Benjamin Simon's point) is that it's needlessly
> inflammatory and misses a lot of points to say that Objects and Classes
> are not in Scheme (implication that you can't really use objects and
> classes as long as you're programming in Scheme).
>
> That's ludicrous. Scheme is expressive enough that it's not even a
> weekend hack to make up some very basic support for objects and classes
> right out of R^5RS with no extra libraries. Compare that to trying to
> do the same in FORTRAN, or plain C.
R5RS does not have (eq)-hash-tables. It is very tricky to make
something like CLOS reasonably efficient without having those.
Therefore, I would say that R5RS is not expressive enough.
> The fact that you can build a real, efficient, object system solely with
> Scheme libraries means that it's pretty legitimate to do OO within
> Scheme. Might CLOS be a better choice if you know that you're
> predominant paradigm will be OO? Probably. If there weren't advantages
> to CLOS, no one would have bothered to implement it. OTOH, depending on
> the problem, Smalltalk or even <shudder> Java could turn out to be an
> even better choice. But Scheme with the right libraries seems perfectly
> legit, especially for someone comfortable with Scheme, and not CL.
>
> Saying that a standardized OO system has advantages over one that isn't
> standardized (and Thomas Burdick pointed out the critical gotcha to
> working non-standardized in this regard) is a far cry from saying
> "Objects and Classes aren't in Scheme". If there's a widely available
> open source library, that will run unmodified on any conforming Scheme
> implementation, and that provides good object and class abstractions --
> then objects and classes are in Scheme for all practical purposes.
I have been there and have implemented my own (ReallyTiny)Clos in
Scheme. But having the much more powerful CLOS at my fingertips, I am
sure I will never use it (or any of the many other ones which are
being written ever and ever again in Scheme courses).
Nicolas.
Thomas F. Burdick
> Marco Antoniotti wrote:
>
> > Compound that with the lack of encapsulation facilities
> > in Scheme (not even in the "final" SRFIs).
>
> It is exactly the same argument as the object one.
> It is possible to write a module system within R5RS
> (and thus it is not included in the standard).
No, it's not quit exactly the same argument. It's /another/ problem.
Having to access N different object systems through M different module
manglings will give you a particularly nasty combinatorial explosion.
Jens Axel Søgaard
> "Jens Axel Søgaard" <use...@soegaard.net> writes:
>
>> Marco Antoniotti wrote:
>>
>>> Compound that with the lack of encapsulation facilities
>>> in Scheme (not even in the "final" SRFIs).
>>
>> It is exactly the same argument as the object one.
>> It is possible to write a module system within R5RS
>> (and thus it is not included in the standard).
>
> No, it's not quit exactly the same argument. It's
> /another/ problem. Having to access N different object
> systems through M different module manglings will give
> you a particularly nasty combinatorial explosion.
It's a different problem, but I still think it is the same argument.
It is _possible_ to write module systems with no other primitives
than those of the standard, and thus there is no lack of encapsulation
facilities (from the minimalist point of view).
Whether it is practical or not is another matter.
--
Jens Axel Søgaard
Thomas F. Burdick
> Whether it is practical or not is another matter.
Of course it's *possible*. If you're not talking about practicality,
you're trolling. No one is doubting that Scheme is turing-complete.
Hartmann Schaffer
i know, but i would argue that there is still a difference between
library functions and "proper language elements.
will C become a garbage collected language when the boehm garbage
collector makes it to the standard library?
Jens Axel Søgaard
> "Jens Axel Søgaard" <use...@soegaard.net> writes:
>
>> Whether it is practical or not is another matter.
>
> Of course it's *possible*. If you're not talking about
> practicality, you're trolling. No one is doubting that
> Scheme is turing-complete.
I have probably not been precise enough [my native
language is not english], I'll try again.
I think minimalistic (and that's the only way to view the R5RS),
so I interpret
Marco> Compound that with the lack of encapsulation facilities in
Marco> Scheme (not even in the "final" SRFIs).
as
"To make encapsulation facilitities, you have to have
add primitives to R5RS".
But that's not true since, the macro system is all you need.
Again, take a look at S2 (which runs at five different implementations).
http://mangler.sourceforge.net/
Thus there it is not /necessary/ to put modules in the standard.
It *is* impratical that different implementations
use different module systems. But this doesn't mean
it is difficult to implement modules using nothing but
the primitives in R5RS.
--
Jens Axel Søgaard
Thomas Bushnell, BSG
Some people use garbage-collected C right now; it's not at all
impossible. (It requires discipline about aliasing, of course.) That
means that there is just no rigid boundary between "garbage collected
language" and not. It's clear that FORTRAN is not, and that Lisp is.
Stephen J. Bevan
> > But if there are libraries that define "define-class" in terms of RnRS,
> > then how are they "not portable"? The only difference between this and
> > using stuffed defined in the CL spec, is that you must include the used
> > portions of the libraries in your project (that and the fact that the
> > implementation in some CLs might be optimized in some way). But in any
> > case, you certainly don't have to rewrite them.
>
> in (essentially) a subset of Common Lisp.
For various projects it doesn't matter whether you write in Scheme or
Common Lisp you'll end up writing in SIDJ or CLIDJ since neither
Scheme nor Common Lisp have interfaces for everything (how could they)
and neither standardise the mechanism for calling out to other
languages (they could do that, but chose not to). The difference, if
any between the two, is at what point and how often you hit this
problem. For something I'm interested in writing, I hit it right from
the start since neither standardises the interface to the PF_KEY or
PF_ROUTE sockets or even TCP/UDP sockets.
Scott Schwartz
> and neither standardise the mechanism for calling out to other
> languages (they could do that, but chose not to).
Moreover, the nonstandard mechanism usually refers to native (system)
functions as "foreign". That's just wrong.
Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
References: <oSL%8.2157$XG5...@newsread1.prod.itd.earthlink.net> <y6cu1mn...@octagon.mrl.nyu.edu> <lf4rend...@atom.amazingmedia.com> <y6cit33...@octagon.mrl.nyu.edu> <lfit33b...@atom.amazingmedia.com> <y6cbs8v...@octagon.mrl.nyu.edu> <lf65z3b...@atom.amazingmedia.com> <y6cptxa...@octagon.mrl.nyu.edu> <1ffxhl8.1x64ct5k3bcmrN%mic...@bcect.com> <ey3fzy6...@cley.com> <1ffxvd9.rtqwx11yv35evN%mic...@bcect.com>
FCC: ~/Net/outgoing/gnus-articles
--text follows this line--
* Michael Sullivan wrote:
> But the whole point is, we're not talking about programming to an
> implementation. We're talking about plugging in code (that depends only
> on the base language spec) as a library.
That library is the implementation I was referring to. Unless it has
a well-defined specification then you either need to stick to one
version, which means it will be increasingly hard to get people to
support you (just watch cll for a while and see people saying that you
should upgrade to the latest, shiniest MK:DEFSYSTEM / UncommonSQL /
whatever), or you can upgrade, and hope that people haven't made any
changes which break your code.
Of course, there are some things which it's just not yet time to have
a standard for, but I don't think an object system is one.
(And of course, the SRFIs may change this by effectively being such
standards.)
--tim
Brian Palmer
> Hartmann Schaffer <h...@heaven.nirvananet> writes:
>
> > malloc (and friends) and free are library functions. you won't find
> > free in in the language spec either (at least if you exclude the
> > standard library). so based on your argumentation C is a "garbage
> > collected language"
>
> The C standard library is part of its specification. You will certainly
> find malloc and free in the ISO C99 standard.
But, there are very few requirements on what they actually do.
An implementaton can get away with something along the lines of
void free(void*ptr) { }
which defines free to do nothing.
I'm using this to attack Tim's assertion that a specification is
superior to an implementation; I think most Lisp programmers
assume there's a garbage collector when they write their programs, and
most C programmers assume there is not. But specifications rarely go
into that sort of detail, because if they do, they become a reference
implementation. And then errata to the standard become patches to that
reference implementation.
Nils Goesche
> Russ Allbery <r...@stanford.edu> writes:
>
> > Hartmann Schaffer <h...@heaven.nirvananet> writes:
> >
> > > malloc (and friends) and free are library functions. you won't find
> > > free in in the language spec either (at least if you exclude the
> > > standard library). so based on your argumentation C is a "garbage
> > > collected language"
> >
> > The C standard library is part of its specification. You will certainly
> > find malloc and free in the ISO C99 standard.
>
> But, there are very few requirements on what they actually do.
> An implementaton can get away with something along the lines of
> void free(void*ptr) { }
> which defines free to do nothing.
What it actually says is
# #include <stdlib.h>
# void free(void *ptr);
#
# Description
#
# The *free* function causes the space pointed to by ptr to be
# deallocated, that is, made available for further allocation. If
# ptr is a null pointer, no action occurs. Otherwise, if the
# argument does not match a pointer earlier returned by the
# calloc, malloc, or realloc function, or if the space has been
# deallocated by a call to free or realloc, the behavior is
# undefined.
which is more than nothing, if you ask me. It's in 7.20.3, which
is titled ``Memory management functions''.
> I'm using this to attack Tim's assertion that a specification is
> superior to an implementation;
So, all the effort that goes into standardization nowadays is
basically wasted? Why did Schemers make an ANSI standard in the
first place, then?
IIRC, early versions of C++ were essentially C preprocessor
hacks. So, should we say ``C, the garbage collected object
system which supports multiple inheritance''?
Tim Bradshaw
> But, there are very few requirements on what they actually do.
> An implementaton can get away with something along the lines of
> void free(void*ptr) { }
> which defines free to do nothing.
> I'm using this to attack Tim's assertion that a specification is
> superior to an implementation; I think most Lisp programmers
> assume there's a garbage collector when they write their programs, and
> most C programmers assume there is not. But specifications rarely go
> into that sort of detail, because if they do, they become a reference
> implementation. And then errata to the standard become patches to that
> reference implementation.
Well, of course they don't go into that much detail, because then
they'd need to have a complete formal semantics for the language, and
that would take a huge amount of work to define, and be of value to
about four people. I suppose that some rather silly people could use
this kind of argument to argue that a specification is not superior to
an implementation, yes. But these people are either just being silly
or are suffering from `one-bit' syndrome as so well described by Erik
Naggum here a few months ago.
--tim
Brian Palmer
> # #include <stdlib.h>
> # void free(void *ptr);
> #
> # Description
> #
> # The *free* function causes the space pointed to by ptr to be
> # deallocated, that is, made available for further allocation. If
> # ptr is a null pointer, no action occurs. Otherwise, if the
> # argument does not match a pointer earlier returned by the
> # calloc, malloc, or realloc function, or if the space has been
> # deallocated by a call to free or realloc, the behavior is
> # undefined.
>
> which is more than nothing, if you ask me. It's in 7.20.3, which
> is titled ``Memory management functions''.
Most of that wording is saying what it is *not* required to do. As for
the 'made available for further allocation', there are no requirements
that malloc actually use that when providing new memory (not that
malloc is required to return anything other than NULL).
> > I'm using this to attack Tim's assertion that a specification is
> > superior to an implementation;
>
> So, all the effort that goes into standardization nowadays is
> basically wasted? Why did Schemers make an ANSI standard in the
> first place, then?
I can't speak for them, but, it seems to me, the purpose of software
standardization is to build a community with a resolve that their
products interoperate with each other. That's why formal semantics can
be skipped. And a benefit of going with an ANSI or ISO standard is
that it then has a "standard" mechanism for debates and opening up
issues in the specification?
But having a language specification isn't necessarily magic, unless it
goes into that sort of detail. And, again, I'd argue that it then
becomes a reference implementation in all but name.
Daniel Barlow
The INS refer to me as "foreign", too. How wrong is that?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Bulent Murtezaoglu
DanB> Scott Schwartz <"schwartz+@usenet "@bio.cse.psu.edu> writes:
[...]
>> Moreover, the nonstandard mechanism usually refers to native
>> (system) functions as "foreign". That's just wrong.
DanB> The INS refer to me as "foreign", too. How wrong is that?
The INS (if you meant the US one) actually refers to you as an alien, or
a non-resident alien, unless you have a GC which some people seem to think
stands for Green Card. CMUCL also calls foreign objects alien.
cheers,
BM
Marco Antoniotti
Daniel Barlow <d...@telent.net> writes:
> Scott Schwartz <"schwartz+@usenet "@bio.cse.psu.edu> writes:
>
> > ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> >> and neither standardise the mechanism for calling out to other
> >> languages (they could do that, but chose not to).
> >
> > Moreover, the nonstandard mechanism usually refers to native (system)
> > functions as "foreign". That's just wrong.
>
> The INS refer to me as "foreign", too. How wrong is that?
I am a "no resident alien". And I did not even get to be in MIIB!
Anyway. You US citizens are Extra-communitarians! :)
What a nice Scheme of things :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Bob Bane
>
> Somewhat tangentially, could you tell me where in the hyperspec it
> says that Common Lisp is a garbage collected language? I just skimmed
> through the places I'd've expected it to be specified, and didn't see
> it.
>
>
It's hidden, and should clearly have been more explicit. There's an
entry in the glossary for "indefinite extent". As I recall, CLtL came
close to requiring GC by saying something like "objects created by CL
have indefinite extent. If a CL implementation can prove that an object
is no longer being used, it may reclaim it."
Benjamin Simon
KK> In article <lf4rend...@atom.amazingmedia.com>, Benjamin Simon wrote:
>> In scheme, objects are just regular functions -- I don't see why you
>> can't create them (or use an already created object system) and use
>> them?
KK> The answer is simple: because this is the year 2002, not 1982.
Huh? What are you trying to get at here?
-Ben
Benjamin Simon
MA> Benjamin Simon <b...@atom.amazingmedia.com> writes:
MA> Sorry. It ain't in R^nRS, it ain't in Scheme.
>> There you go again. I don't get it. Is the following function not
>> scheme:
>> (define (foo x)
>> (+ x 1))
>> Looks like scheme to me. It isn't defined in R5RS so it must not be,
>> according to your logic.
MA> What I meant is that
MA> (define-class (panda-bear animal endengered-specie)
MA> ...)
MA> is not in Scheme.
Why?
MA> If you use one of the above you are using your SIDJ. (I know `slib'
MA> - a subset of what is already in CL - is relatively portable).
Again, how can you prove that the above isn't derived from R5RS Scheme?
MA> I am not questioning the existence of N different object systems in
MA> your SIDJ. I am questioning the use of a language that forces you
MA> to re-implement - unportably - every single bit that you already
MA> have - portably - in CL.
>> Ahhh, so this turns into a: "Scheme only specifies what is absolutely
>> necessary,
MA> meaning: far less than what is useful.
Or:
"A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away."
- Antoine de Saint-Exupery
>> vs CL specifies everything"
MA> I would not go that far. There are plenty of things that are not
MA> specified in CL.
Do you use these constructs? Then do you tell yourself that you are no
longer writing CL? Why was it appropriate for CL to leave those
elements out of the spec?
-Ben
Marco Antoniotti
Benjamin Simon <b...@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> MA> Benjamin Simon <b...@atom.amazingmedia.com> writes:
>
> MA> Sorry. It ain't in R^nRS, it ain't in Scheme.
> >> There you go again. I don't get it. Is the following function not
> >> scheme:
> >> (define (foo x)
> >> (+ x 1))
> >> Looks like scheme to me. It isn't defined in R5RS so it must not be,
> >> according to your logic.
>
> MA> What I meant is that
> MA> (define-class (panda-bear animal endengered-specie)
> MA> ...)
> MA> is not in Scheme.
>
> Why?
It ain't in R^nRS.
>
> MA> If you use one of the above you are using your SIDJ. (I know `slib'
> MA> - a subset of what is already in CL - is relatively portable).
>
> Again, how can you prove that the above isn't derived from R5RS Scheme?
>
I cannot. My argument is that they are not in R^nRS.
>
> MA> meaning: far less than what is useful.
> Or:
>
> "A designer knows he has achieved perfection not when there is
> nothing left to add, but when there is nothing left to take away."
> - Antoine de Saint-Exupery
More or less my point. There is nothing you can take away from the CL
spec without making it less perfect :) Hence there is *a lot* of stuff
that must be added to R^nRS to make it perfect; and, at that point,
you have Common Lisp.
> >> vs CL specifies everything"
>
> MA> I would not go that far. There are plenty of things that are not
> MA> specified in CL.
>
> Do you use these constructs? Then do you tell yourself that you are no
> longer writing CL?
Whenever I use something that is "implementation dependent" I know
exactly what I am using. Take multithreading for example. But I say
I am using an "implementation dependent" set of libraries. The point
is not whether you say or say not this w.r.t. your writing in Scheme.
The point is that whenever you write in Scheme there is way too much
that you have to import that is "implementation dependent". E.g. any
time you write OO code in Scheme (meaning the usual stuff with
classes, methods, message passing, whatever) you are writing in an
implementation dependent manner. The same happens when you use a
record defining library (i.e. DEFSTRUCT).
The bottom line is that when using CL you take for granted *a lot* of
stuff that is inherently implementation dependent in Scheme.
So, why not use the real thing instead?
> Why was it appropriate for CL to leave those
> elements out of the spec?
History and some other considerations, I suppose. I wasn't there.
Tim Bradshaw
>>>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
MA> What I meant is that
MA> (define-class (panda-bear animal endengered-specie)
MA> ...)
MA> is not in Scheme.
> Why?
Because R5RS does not define DEFINE-CLASS.
MA> I would not go that far. There are plenty of things that are not
MA> specified in CL.
> Do you use these constructs? Then do you tell yourself that you are no
> longer writing CL?
I use them. When I do, I'm writing in a language which is not CL:
it's one of CL + some things defined by my program, CL + some things
other people have defined[1], CL + some things defined by the
implementation I use, or (generally) all of these. In the
defined-by-vendor and defined-by-others cases I try to be careful to
isolate the dependencies.
> Why was it appropriate for CL to leave those elements out of the
> spec?
Since any program that makes any definitions extends CL, it's clear
that the spec could not define all programs, since it would then need
to be infinitely large. You have to stop somewhere.
More seriously, I think that most people would agree that in some
cases there are things which aren't in the spec which probably should
have been, and there are probably also a number of things which *now*
might be appropriate to standardise but were not when the spec was
written. Whether these should be standardised by producing a new
version of the CL spec or whether there should be `substandards' (a -
rather good - term coined by Kent Pitman I think) is a matter for
debate. The current situation where various things are defined by
mostly-portable public implementations isn't very nice, but its hard
to escape from unless people are willing and able to put quite a large
amount of time (and therefore of money) into standardisation efforts.
No one is claiming that the CL spec is perfect - we leave that kind of
thing to Scheme.
--tim
Footnotes:
[1] `other people' here means `non-implementors of the program I'm
working on'.
Joel Ray Holveck
>> elements out of the spec?
> History and some other considerations, I suppose. I wasn't there.
Because the ANSI committee made a feature freeze *way* too early
(IMHO), when lots of things like defsystem were still being
experimented with. By the time the spec was published, there was a
lot of consensus on how defsystem should work, but by then it was too
late.
I'll add that my opinion on the timing is *very* humble. I don't know
why they froze the features when they did, or how long it would have
delayed the spec if they froze it later. I do think the committee did
an overall great job despite leaving out some features.
Cheers,
joelh
Brian Palmer
> Brian Palmer wrote
[Does standard say that Lisp is a GC language?]
>
> It's hidden, and should clearly have been more explicit. There's an
> entry in the glossary for "indefinite extent". As I recall, CLtL came
> close to requiring GC by saying something like "objects created by CL
> have indefinite extent. If a CL implementation can prove that an
> object is no longer being used, it may reclaim it."
OK, so that permits GC, but doesn't mandate it. Still, it's good to
know that there's some mention of it, given that GC is one of the
advantages CL offers over languages like C =)
Thomas Bushnell, BSG
> Bob Bane <ba...@removeme.gst.com> writes:
>
> > Brian Palmer wrote
> [Does standard say that Lisp is a GC language?]
> >
> > It's hidden, and should clearly have been more explicit. There's an
> > entry in the glossary for "indefinite extent". As I recall, CLtL came
> > close to requiring GC by saying something like "objects created by CL
> > have indefinite extent. If a CL implementation can prove that an
> > object is no longer being used, it may reclaim it."
>
> OK, so that permits GC, but doesn't mandate it. Still, it's good to
> know that there's some mention of it, given that GC is one of the
> advantages CL offers over languages like C =)
There is no reason to mandate it, and an excellent reason not to.
A given environment might well be able to promise indefinite extent
without GC if, for example, it knows that its lifetime is sharply
limited, or if it simply has so damn much memory it needn't bother.
Stephen J. Bevan
> The bottom line is that when using CL you take for granted *a lot* of
> stuff that is inherently implementation dependent in Scheme.
When using C or Java one takes for granted *a lot* of stuff that is
inherently implementation dependent in Common Lisp. However, I'm
guessing that most people in this group would prefer to add those
things to their Common Lisp rather than program in C or Java. A C or
Java programmer might ask :-
> So, why not use the real thing instead?
To which you would probably list various things that CL has that C or
Java doesn't have and various things that C or Java has that you are
glad that CL doesn't have. A Scheme user would make a similar
argument regarding their use of Scheme over CL. The reasons might
look odd to a CL user, but then the reasons for using CL probably look
odd to a C or Java programmer.
Jens Axel Søgaard
> OK, so that permits GC, but doesn't mandate it. Still,
> it's good to know that there's some mention of it, given
> that GC is one of the advantages CL offers over languages
> like C =)
This reminds my of Clingers "Finite Memories Considered
Harmful (same song, second verse)"-letter from 1985."
[cut]
It is philosophically inconsistent to insist upon proper treatment of
tail recursion and upon garbage collection while allowing finite
memories. Of course, people know to ask about the finite memory bug
when they purchase a computer. Indeed, the bug is often advertised.
[cut]
Reference:
http://zurich.ai.mit.edu/pipermail/rrrs-authors/1985-July/000184.html
--
Jens Axel Søgaard
Marco Antoniotti
ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > The bottom line is that when using CL you take for granted *a lot* of
> > stuff that is inherently implementation dependent in Scheme.
>
> When using C or Java one takes for granted *a lot* of stuff that is
> inherently implementation dependent in Common Lisp. However, I'm
> guessing that most people in this group would prefer to add those
> things to their Common Lisp rather than program in C or Java. A C or
> Java programmer might ask :-
I will grant you that. Especially when it comes to Java (not as much
for C).
>
> > So, why not use the real thing instead?
>
> To which you would probably list various things that CL has that C or
> Java doesn't have and various things that C or Java has that you are
> glad that CL doesn't have. A Scheme user would make a similar
> argument regarding their use of Scheme over CL. The reasons might
> look odd to a CL user, but then the reasons for using CL probably look
> odd to a C or Java programmer.
Not quite. The argument is that the number of things that you must
add to Scheme in order to escape from the "implementation dependent
programming" accusation is just too large and is not comparable to
what you must add to Common Lisp to get to Java.
Joel Ray Holveck
>> know that there's some mention of it, given that GC is one of the
>> advantages CL offers over languages like C =)
> There is no reason to mandate it, and an excellent reason not to.
> A given environment might well be able to promise indefinite extent
> without GC if, for example, it knows that its lifetime is sharply
> limited, or if it simply has so damn much memory it needn't bother.
Perl uses the second tack: it reference counts, and hopes that the
process's lifetime is short enough that it will exit before any cycles
created consume all of the available VM.
Besides, how do you mandate it?
[proposal 1]
A conforming implementation must release memory that will no longer
be used by the program.
Well, this means that the GC must determine liveness, which is a much
different problem. (See the GC-FAQ on "liveness" vs "reachability".)
[proposal 2]
A conforming implementation must release memory that *can* no longer
be used by the program.
This prevents conservative GCs, which are important, for instance,
with some types of FFI.
[proposal 3]
A conforming implementation must release memory as soon as it can
determine, without error, that the data cannot be used again.
The "as soon as" bit prevents generational GC, and requires a GC as
soon as anything becomes dereferenced.
[proposal 4]
Once a conforming implementation can determine, without error, that
data cannot be used again, it must ensure that this memory will be
released at some point in the future.
Maxwell's demon notwithstanding, the second law of thermodynamics
already guarantees this: someday, the computer's memory will be
erased. (OT: IIRC, Maxwell's demon was proven impossible by IBM
because there wasn't a suitable GC!)
Now, we have determined that every Lisp implementation has a GC
courtesy of thermodynamics. Now we just let vendors try to come up
with better implementations.
Cheers,
joelh
Thomas Bushnell, BSG
> Not quite. The argument is that the number of things that you must
> add to Scheme in order to escape from the "implementation dependent
> programming" accusation is just too large and is not comparable to
> what you must add to Common Lisp to get to Java.
Hrm. The situation does have a certain parallelism. Once CL had
macros, and Scheme didn't. But now, Scheme has macros, and provides a
facility that (in the minds of most Scheme programmers) is much
cleaner than the low-level one that CL has.
Similarly, CL lacks call/cc entirely, and that's something that you
*cannot* just implement yourself as a library function, and which
simply does not exist on any CL system I'm familiar with.
Thomas
Marco Antoniotti
tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Not quite. The argument is that the number of things that you must
> > add to Scheme in order to escape from the "implementation dependent
> > programming" accusation is just too large and is not comparable to
> > what you must add to Common Lisp to get to Java.
>
> Hrm. The situation does have a certain parallelism. Once CL had
> macros, and Scheme didn't. But now, Scheme has macros, and provides a
> facility that (in the minds of most Scheme programmers) is much
> cleaner than the low-level one that CL has.
Somehow, the cleanliness of macro systems does not seem relevant to
this debate.
> Similarly, CL lacks call/cc entirely, and that's something that you
> *cannot* just implement yourself as a library function, and which
> simply does not exist on any CL system I'm familiar with.
True. But, as it is very well known, only the most esoteric uses of
call/cc cannot be replaced by the standard facilities in CL.
AFAIAC, the debate is around multidimensional arrays, DEFSTRUCT, CLOS,
the condition system etc etc. These are all things that are not in
Scheme, that must be added to it in a mostly implementation dependent
way and that - in the end - just give you a subset of CL. Otherwise we
fall in the Tape and Read/Write heads argument and the fact that all
cats are grey at night. :)
Benjamin Simon
TB> * Benjamin Simon wrote:
>>>>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
MA> What I meant is that
MA> (define-class (panda-bear animal endengered-specie)
MA> ...)
MA> is not in Scheme.
>> Why?
TB> Because R5RS does not define DEFINE-CLASS.
But what if I could write it in R5RS Scheme -- then is it Scheme?
`foo' isn't in R5RS, but yet:
(define (foo x) x)
seems to look like Scheme to me.
I don't understand why `define-class' is any different from `foo'.
If I understood what `define-class' above was supposed to do, we could
decide once and for all if it could be written in R5RS Scheme. Then, by
using your definition, we could find out if `define-class' is indeed
Scheme. Right?
-Ben
Stephen J. Bevan
> Not quite. The argument is that the number of things that you must
> add to Scheme in order to escape from the "implementation dependent
> programming" accusation is just too large and is not comparable to
> what you must add to Common Lisp to get to Java.
I worked on a Java project where various programs used one or more of
the following standard features of Java: threads, servlets, JDBC,
sockets (plain and SSL), non-blocking IO, crypto/certificates, CORBA
interface, logging, LDAP interface, native language interface and GUI.
While I don't doubt that it is a lot of work to add all the standard
things that Common Lisp has to Scheme (CLOS alone is a huge amount of
work if you wanted to implement it in all its detail), I also think
you are underestimating the work it would take to add to Common Lisp
all the standard things (such as the *subset* above) that are in Java.
If I wanted to do that project with Common Lisp or Scheme then all of
the above would be non-standard features that I'd have to implement or
find in a (S|CL)IDJ. Granted by using Common Lisp I would not have to
also implement or find an OO package as I would in Scheme. However,
I find it difficult to get worked up about adding a few extra package
for Scheme when I'm adding a dozen or more in both languages!
So while I agree that Common Lisp standardised a lot more than Scheme,
it seems to me that various non-trivial programs in either require you
to go well outside the standard, so far that the difference between
the two starts to look pretty small.
Kaz Kylheku
> Nils Goesche <n...@cartan.de> writes:
>> Does the existence of the Boehm collector make C a garbage
>> collected language, then?
>
> Somewhat tangentially, could you tell me where in the hyperspec it
> says that Common Lisp is a garbage collected language?
That Lisp is based on garbage collection is something that everyone knows. The
only reason for looking for this in the spec would be if you were looking for
an excuse not to implement it, so that you could have an implementation that is
conforming on paper only, but useless in practice.
Incidentally, here is a conforming implementation of the 1990 C language
for a UNIX system:
#!/bin/sh
cp /bin/true a.out
echo "might have had errors"
According to that standard, a conforming implementation has to
successfully translate and execute at least one strictly conforming
program which meets all of the implementation limits. It doesn't
say whether the users or implementors select that program. And a
conforming implementation must diagnose syntax errors and constraint
violations, but is free to add additional diagnostics.
Copying /bin/true to a.out meets the first requirement; we simply choose, as
our program, one that produces no output and returns EXIT_SUCCESS from main().
The echo meets the second requirement.
So here you have a standard which, if interpreted very narrowly, says you don't
have to implement the language at all.
But you see, specifications are meant to be used by thinking human
beings who have a real purpose to accomplish.
Brian A Palmer
> But you see, specifications are meant to be used by thinking human
> beings who have a real purpose to accomplish.
That's sort of my point. A 'standard' doesn't mean a whole lot for
real programming projects; instead, it's the implementations of that
standard that matter, and need to be considered. And that's why you
can compare an 'implementation-based' language like Perl or Python
with a language like Lisp; in practice, you're comparing the
meet-of-all-features of the implementations.
--
If you want divine justice, die.
-- Nick Seldon
Tim Bradshaw
> But what if I could write it in R5RS Scheme -- then is it Scheme?
> `foo' isn't in R5RS, but yet:
> (define (foo x) x)
> seems to look like Scheme to me.
> I don't understand why `define-class' is any different from `foo'.
> If I understood what `define-class' above was supposed to do, we could
> decide once and for all if it could be written in R5RS Scheme. Then, by
> using your definition, we could find out if `define-class' is indeed
> Scheme. Right?
Did you read my article? I wrote:
Since any program that makes any definitions extends CL, it's clear
that the spec could not define all programs, since it would then
need to be infinitely large. You have to stop somewhere.
Which I thought was pretty clear, but perhaps it isn't. I'll try and
phrase it more carefully then.
Anything not defined by the standard for language x is not in the
standard for language x. In particular, the ability to define
something using the language as defined by the standard does *not*
make it part of the language as defined by the standard. The only
thing that defines whether something is in a standard is *if it is in
the standard*.
Thus: the macro ORG.TFEB.CONDUIT-PACKAGES:DEFPACKAGE is not part of
ANSI CL, even though it can be portably defined within ANSI CL; the
macro CL:LET* is part of ANSI CL, and can also be portably defined
within ANSI CL; the special operator CL:TAGBODY is part of ANSI CL and
can not portably be defined within ANSI CL (well, not easily); and the
function WELD-REP:WELD-REP is not within ANSI CL and cannot be
portably defined within it.
This is my last word on this. You (and others) have done a good job
of convincing me both that scheme is a language I don't need to worry
about not keeping up with, and posting news articles is a mistake.
Thanks.
--tim
Benjamin Simon
MA> Benjamin Simon <b...@atom.amazingmedia.com> writes:
MA> What I meant is that
MA> (define-class (panda-bear animal endengered-specie)
MA> ...)
MA> is not in Scheme.
>> Why?
MA> It ain't in R^nRS.
(See my previous article, asking again, why isn't it?)
>> "A designer knows he has achieved perfection not when there is
>> nothing left to add, but when there is nothing left to take away."
>> - Antoine de Saint-Exupery
MA> More or less my point. There is nothing you can take away from the
MA> CL spec without making it less perfect :) Hence there is *a lot* of
MA> stuff that must be added to R^nRS to make it perfect; and, at that
MA> point, you have Common Lisp.
I guess that's where we disagree. I think functions that can be derived
don't belong in the spec, and you do think they belong in the spec.
>> >> vs CL specifies everything"
>>
MA> I would not go that far. There are plenty of things that are not
MA> specified in CL.
>>
>> Do you use these constructs? Then do you tell yourself that you are no
>> longer writing CL?
MA> Whenever I use something that is "implementation dependent" I know
MA> exactly what I am using. Take multithreading for example.
Funny, that's *exactly* what I do in Scheme.
MA> But I say I am using an "implementation dependent" set of
MA> libraries.
Again, exactly what I do.
MA> The point is not whether you say or say not this w.r.t. your
MA> writing in Scheme. The point is that whenever you write in Scheme
MA> there is way too much that you have to import that is
MA> "implementation dependent".
I see. So somehow frequency matters? Scheme doesn't provide for
multithreading in your our spec, so it's flawed. CL doesn't either, and
it's perfect. Interesting.
MA> E.g. any time you write OO code in Scheme (meaning the usual stuff
MA> with classes, methods, message passing, whatever) you are writing
MA> in an implementation dependent manner.
We've been through this before -- this simply isn't true. I can do OO
stuff in a non implementation specific manner. Defining an function
that isn't in the spec, in terms of the spec, shouldn't be considered
"implementation specific." Or should it?
That's not to say that in Scheme you do use a lot of "implementation
specific" tools. But, OO isn't (necessarily) one of them.
-Ben
Benjamin Simon
TB> * Benjamin Simon wrote:
>> But what if I could write it in R5RS Scheme -- then is it Scheme?
>> `foo' isn't in R5RS, but yet:
>> (define (foo x) x)
>> seems to look like Scheme to me.
>> I don't understand why `define-class' is any different from `foo'.
>> If I understood what `define-class' above was supposed to do, we could
>> decide once and for all if it could be written in R5RS Scheme. Then, by
>> using your definition, we could find out if `define-class' is indeed
>> Scheme. Right?
TB> Did you read my article? I wrote:
I thought I did :-)
TB> Since any program that makes any definitions extends CL, it's
TB> clear that the spec could not define all programs, since it would
TB> then need to be infinitely large. You have to stop somewhere.
OK, we agree on this.
TB> Which I thought was pretty clear, but perhaps it isn't. I'll try
TB> and phrase it more carefully then.
Thanks.
TB> Anything not defined by the standard for language x is not in the
TB> standard for language x.
OK.
TB> In particular, the ability to define something using the language
TB> as defined by the standard does *not* make it part of the language
TB> as defined by the standard.
OK. So, as soon as you use `defun' you are no longer writing in CL?
TB> The only thing that defines whether something is in a standard is
TB> *if it is in the standard*.
Correct. But the previous poster was saying that if it's not in the
standard it isn't Scheme. I was saying that was silly.
TB> Thus: the macro ORG.TFEB.CONDUIT-PACKAGES:DEFPACKAGE is not part of
TB> ANSI CL, even though it can be portably defined within ANSI CL;
The only issue I was taking not of, is that the previous poster was
saying that, once you use this macro you are no longer writing in CL.
You are now writing inn CLDJ. Or something like that.
TB> This is my last word on this. You (and others) have done a good
TB> job of convincing me both that scheme is a language I don't need to
TB> worry about not keeping up with,
:-) At least I convinced you about something.
My only point was to try to answer an absurd comment that the original
poster made. Why should he spread mis-information about a language,
simply because he doesn't like it?
TB> and posting news articles is a mistake.
Yikes. I didn't realize I was that effective at arguing ;-).
-Ben
Nils Goesche
> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> MA> More or less my point. There is nothing you can take away from
> MA> the CL spec without making it less perfect :) Hence there is *a
> MA> lot* of stuff that must be added to R^nRS to make it perfect;
> MA> and, at that point, you have Common Lisp.
>
> I guess that's where we disagree. I think functions that can be
> derived don't belong in the spec, ...
But that's a fairly idiotic opinion. So, assq, assv and assoc don't
belong into the Scheme spec. Suppose they were taken out. Now,
everybody will implement their own slow, buggy and slightly different
version of them. Joe's one will behave as in r5rs, Jack's one will
behave as in CL, and Jeff's one will behave as Jack's one, except that
it won't ignore nil's in it. Jeffrey's version will behave as Jeff's
one, except that it will return #f on failure. And so on. Now, you
include libraries into your code, all use assoc, one from each. How
are they supposed to work? (Unfortunately, packages don't ``belong''
into the spec, either, which would at least allow you to include 42
different versions of assoc easily into your code).
Whenever you encounter a function or macro that is now in the CL spec
but has to be removed from it according to you, (much fun
reimplementing LOOP and FORMAT for a start), you'll have to write a
replacement; of course, you will implement only what you need at the
moment, and whenever you need an additional feature, that would have
been there in the first place if the standard had been written by
people other than you, you'll have to go back and enhance your
personal library again. All this assuming that you know what to
reimplement in the first place... The decades of experience included
in the CL spec are probably not worth much to you, as you know better
how to do everything, anyway, or what?
> MA> E.g. any time you write OO code in Scheme (meaning the usual stuff
> MA> with classes, methods, message passing, whatever) you are writing
> MA> in an implementation dependent manner.
>
> We've been through this before -- this simply isn't true. I can do OO
> stuff in a non implementation specific manner. Defining an function
> that isn't in the spec, in terms of the spec, shouldn't be considered
> "implementation specific." Or should it?
>
> That's not to say that in Scheme you do use a lot of "implementation
> specific" tools. But, OO isn't (necessarily) one of them.
Right, just as you can turn C into an OO system by adding a bunch of
preprocessor macros. So, OO support doesn't belong into language
specs either, is that your point?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Marco Antoniotti
ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > Not quite. The argument is that the number of things that you must
> > add to Scheme in order to escape from the "implementation dependent
> > programming" accusation is just too large and is not comparable to
> > what you must add to Common Lisp to get to Java.
>
> I worked on a Java project where various programs used one or more of
> the following standard features of Java: threads, servlets, JDBC,
> sockets (plain and SSL), non-blocking IO, crypto/certificates, CORBA
> interface, logging, LDAP interface, native language interface and GUI.
>
> While I don't doubt that it is a lot of work to add all the standard
> things that Common Lisp has to Scheme (CLOS alone is a huge amount of
> work if you wanted to implement it in all its detail), I also think
> you are underestimating the work it would take to add to Common Lisp
> all the standard things (such as the *subset* above) that are in
> Java.
I am not underestimating and I am not questioning the fact that the
library set of Java is "a pretty good thing". I am questioning its
usefulness. If the hordes of Schemers tweaking around the language to
(1) first make it closer to Common Lisp and (2) adding to this
implementation dependent way some more implementation dependent code
to get to Java.
Just work on Common Lisp and help making Common Lisp closer to Java.
(Which is what a lot of the people who - more wisely - elected Common
Lisp as their language of choice).
>
> If I wanted to do that project with Common Lisp or Scheme then all of
> the above would be non-standard features that I'd have to implement or
> find in a (S|CL)IDJ. Granted by using Common Lisp I would not have to
> also implement or find an OO package as I would in Scheme. However,
> I find it difficult to get worked up about adding a few extra package
> for Scheme when I'm adding a dozen or more in both languages!
>
> So while I agree that Common Lisp standardised a lot more than Scheme,
> it seems to me that various non-trivial programs in either require you
> to go well outside the standard, so far that the difference between
> the two starts to look pretty small.
We agree on this. But the question stands: between Scheme and Common
Lisp why not just working in Common Lisp?
I think that in this recurring debate there is something that came
up. I may be making a sweeping generalization here, but here it is:
Common Lisp programmers do not like packages which are not
ANSI-spec-grade, and working to extend the language in meaningful and
non ANSI-breaking ways is a lot of work. Whipping up a Scheme
interpreter (while a worthwhile exercise) is instead something people
like very much because it is somewhat easier.
Marco Antoniotti
Benjamin Simon <b...@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
...
> MA> More or less my point. There is nothing you can take away from the
> MA> CL spec without making it less perfect :) Hence there is *a lot* of
> MA> stuff that must be added to R^nRS to make it perfect; and, at that
> MA> point, you have Common Lisp.
>
> I guess that's where we disagree. I think functions that can be derived
> don't belong in the spec, and you do think they belong in the spec.
No. I look at the specs and read what is in there and what it is not.
Seeing CLOS in the CL ANSI spec and nothing (nil, nihil, niente, nada,
zip) like it in R^nRS I conclude that CL is a more solid foundation to
build less "implementation dependent code". The same applies to
multi-dimensional arrays, DEFSTRUCTS, the condition system etc etc.
You conclude different things. I conclude that by working in Scheme
you are wasting precious resources to make Common Lisp better. Note
that the opposite does not apply, since Scheme is inherently less than
Common Lisp.
...
> I see. So somehow frequency matters? Scheme doesn't provide for
> multithreading in your our spec, so it's flawed. CL doesn't either, and
> it's perfect. Interesting.
Yes. Somehow both spces are flawed in this respect. Networking is
another flawed aspect of both specs. For them not to be flawed we
require clarvoyance of the authors. :)
> MA> E.g. any time you write OO code in Scheme (meaning the usual stuff
> MA> with classes, methods, message passing, whatever) you are writing
> MA> in an implementation dependent manner.
>
> We've been through this before -- this simply isn't true. I can do OO
> stuff in a non implementation specific manner. Defining an function
> that isn't in the spec, in terms of the spec, shouldn't be considered
> "implementation specific." Or should it?
Let's do some Jesuit's exercise here. To do CLOS in Scheme you must
load an "implementation" of it. Now what guarantees you the behavior
of the specific implementation? Some documentation. Eventually this
documentation is ... the Common Lisp ANSI spec.
The same applies when you define `make-array' in Scheme.
And here are the two cruxes. (1) Suppose you have a Scheme library
that uses your CL conformant make-array. Now you start using a
different library that loads a slightly different `make-array'. You
can see very well what ensues. (2) you still have to load a
`make-array' library to get you to .... Common Lisp.
> That's not to say that in Scheme you do use a lot of "implementation
> specific" tools. But, OO isn't (necessarily) one of them.
It is your right to think so. I do not necessarily disagree. My
argument is that you need CL to do some basic programming and you do
end up doing that in Scheme by loading (dangerously) a set of
libraries.
So the question stands: why not using CL instead to start with?
Marco Antoniotti
Benjamin Simon <b...@atom.amazingmedia.com> writes:
> >>>>> "TB" == Tim Bradshaw <t...@cley.com> writes:
>
>
> TB> The only thing that defines whether something is in a standard is
> TB> *if it is in the standard*.
>
> Correct. But the previous poster was saying that if it's not in the
> standard it isn't Scheme. I was saying that was silly.
...
> My only point was to try to answer an absurd comment that the original
> poster made. Why should he spread mis-information about a language,
> simply because he doesn't like it?
Well, my sentence "It ain't in R^nRS, it ain't in Scheme" is silly but
effective as a rrthorical device. :) It is as effective as your
argument that all languages are Turing equivalent (since I can define
`define-class' with Read/Write Heads and Tape).
Hannah Schroeter
Tim Bradshaw <t...@cley.com> wrote:
>[...]
>can not portably be defined within ANSI CL (well, not easily); and the
>function WELD-REP:WELD-REP is not within ANSI CL and cannot be
>portably defined within it.
Depends on what it should do.
(cl:defpackage "WELD-REP" (:use "COMMON-LISP"))
(cl:in-package "WELD-REP")
(cl:defun weld-rep () "foo")
(cl:export 'weld-rep)
SCNR!
Kind regards,
Hannah.
Hannah Schroeter
Marco Antoniotti <mar...@cs.nyu.edu> wrote:
>[...]
>True. But, as it is very well known, only the most esoteric uses of
>call/cc cannot be replaced by the standard facilities in CL.
Are coroutines so esoteric nowadays?
>[...]
Kind regards,
Hannah.
Will Deakin
> Depends on what it should do.
>
> (cl:defpackage "WELD-REP" (:use "COMMON-LISP"))
> (cl:in-package "WELD-REP")
> (cl:defun weld-rep () "foo")
> (cl:export 'weld-rep)
What happens if weld-rep calls (golden-lemur::monkey-spank 'bert)
where monkey-spank is special chastisment function on bert monkey that
is only implemented in the golden-lemur(c) common lisp implementation.
How would defpackage help if you wanted to run this on cmucl?
;)w
Stephen J. Bevan
[ I've snipped all the earlier stuff since this seems to be the main
issue ]
> We agree on this. But the question stands: between Scheme and Common
> Lisp why not just working in Common Lisp?
Your thesis is that people are spending a lot of time adding features
to Scheme that are already in Common Lisp and so they might as well
start with Common Lisp in the first place. To an extent I think that
ignores the fact that the features being added to Scheme are not
always identical to those found in Common Lisp, for example hygenic vs
non-hygenic macros and a module system vs a package system. However,
I'll ignore that issue for now.
My thesis is that to be able to compete with Java I need to add dozens
of features to Scheme or Common Lisp. As such the choice of Scheme
and Common Lisp as a language is pretty much arbitrary given that I'd
end up programming in a (SI|CLI)DJ. Once I'm writing in an IDJ it
makes little difference whether defstruct is part of the standard (in
Common Lisp) or just another feature of the implementation (Scheme).
Of course I'd prefer it if the features were standardised in the hope
that it would mean I could run on multiple implementations and avoid
being locked into a single implementation. However, as I noted before
if I have to add a dozen features to either, the fact that I'd have to
add three more for Scheme gets lost in the noise. If the numbers were
different i.e. I only needed to add one feature to either above the
three I needed to add to Scheme then Common Lisp starts to look like a
big win. However, that's not the situation I'm faced with when
contemplating large projects (the context of this thread).
Consequently the choice is currently more about the quality of the
implementation and what (non-standard) features it contains than about
the language per se.
Marco Antoniotti
ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> [ I've snipped all the earlier stuff since this seems to be the main
> issue ]
>
> > We agree on this. But the question stands: between Scheme and Common
> > Lisp why not just working in Common Lisp?
>
> Your thesis is that people are spending a lot of time adding features
> to Scheme that are already in Common Lisp and so they might as well
> start with Common Lisp in the first place. To an extent I think that
> ignores the fact that the features being added to Scheme are not
> always identical to those found in Common Lisp, for example hygenic vs
> non-hygenic macros and a module system vs a package system. However,
> I'll ignore that issue for now.
That is ok with me. However, check out the SRFI's to see how
different they are from what is already standardized in CL.
> My thesis is that to be able to compete with Java I need to add dozens
> of features to Scheme or Common Lisp. As such the choice of Scheme
> and Common Lisp as a language is pretty much arbitrary given that I'd
> end up programming in a (SI|CLI)DJ. Once I'm writing in an IDJ it
> makes little difference whether defstruct is part of the standard (in
> Common Lisp) or just another feature of the implementation (Scheme).
That is a valid argument as well.
> Of course I'd prefer it if the features were standardised in the hope
> that it would mean I could run on multiple implementations and avoid
> being locked into a single implementation. However, as I noted before
> if I have to add a dozen features to either, the fact that I'd have to
> add three more for Scheme gets lost in the noise. If the numbers were
> different i.e. I only needed to add one feature to either above the
> three I needed to add to Scheme then Common Lisp starts to look like a
> big win. However, that's not the situation I'm faced with when
> contemplating large projects (the context of this thread).
> Consequently the choice is currently more about the quality of the
> implementation and what (non-standard) features it contains than about
> the language per se.
Given that most CL implementations are top-quality and that they all
strive to implement the standard, I wager that all in all you are
still better in choosing Common Lisp rather than Scheme for large
projects. If you use Scheme you will still have to contend with more
variation than if you use Common Lisp.
Paolo Amoroso
> Because the ANSI committee made a feature freeze *way* too early
> (IMHO), when lots of things like defsystem were still being
> experimented with. By the time the spec was published, there was a
> lot of consensus on how defsystem should work, but by then it was too
> late.
Kent Pitman has the draft of the DEFSYSTEM proposal he submitted to X3J13
available at his site.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso
wrote:
> Similarly, CL lacks call/cc entirely, and that's something that you
> *cannot* just implement yourself as a library function, and which
> simply does not exist on any CL system I'm familiar with.
I seem to understand that CALL/CC was intentionally left out while
standardizing Common Lisp.
Stephen J. Bevan
> Given that most CL implementations are top-quality and that they all
> strive to implement the standard, I wager that all in all you are
> still better in choosing Common Lisp rather than Scheme for large
> projects. If you use Scheme you will still have to contend with more
> variation than if you use Common Lisp.
I agree in theory but in practice the sheer number of features that
need to be added would tend to force one towards picking a (S|CL)IDJ.
This removes the variation issue and hence any advantage CL may have
in this area. In the context of needing at least a dozen features
that aren't in Scheme or CL only the standardisation of or
availability of portable implementations of a significant number of
them would convince me that either language is significantly better
for large projects than the other. Until/Unless that happens then
to a large extent the choice is not Scheme vs CL but (Scheme|CL)
implementation vs (Scheme|CL) implementation.
Joel Ray Holveck
>> call/cc cannot be replaced by the standard facilities in CL.
> Are coroutines so esoteric nowadays?
From my humble viewpoint, yes. I have been programming for a while,
and can think of three programs I wrote that used coroutines. (One
was in Scheme, and used call/cc. Another was in Java, and started two
threads and used mutexes to simulate coroutines. The third was in
assembly, and was a serial driver.)
I can't think of having ever seen (textbooks discussing the topic
notwithstanding) anybody else's code that uses coroutines. I don't
claim, at this point, to have read enough code to make that
statistically useful.
Let's face it, coroutines just aren't used very much these days. I
very rarely am confronted by a problem where I think, "Gee, coroutines
would make this so much easier!"
It could be because the languages I use shape the way I think about
problems.
Cheers,
joelh
Christopher Browne
If the SRFI folks came out with a set of consistent extensions for a
"significant number" of the needed extensions, say:
[regexes, sockets, http request processing, process control,
access to GTK/Tk, RDBMSes, XML]
then that would make Scheme an easier choice for a number of classes
of applications than CL.
I don't think anyone should feel terribly "comfortable" about any of
this:
- for a CL-partisan to pooh-pooh this risks complacency, as if you
simply _assume_ it is sufficient to have a bigger, better base,
there's a risk of the system falling behind because people are
working harder on Scheme extensions...
- There are "wins" on both sides of the fence on the items I've
mentioned:
- There are _generally_ more mature Scheme regex implementations;
- There are some nice CL socket libraries, albeit not as
interoperable as would be nice;
- For process control, there's probably a bit of "Advantage:
Scheme";
- CL has CLIM, which I've never seen running, whilst it is common
for Schemes to have interfaces to GTK/Tk;
- CommonSQL suggests "Advantage: CL";
- I've done all my XML work in CL, but there are generally more
mature XML parsers for Scheme.
Picking out any one of these factors and saying "Ooh! CL supports
this better! CL _MUST_ be better!" isn't something people ought to
do.
The fact that the support for so many of these things are so _POOR_,
for one or another language, should give _all_ partisans reason to
pause.
If your reaction goes something like "Oh, but you're WRONG!!! I can
get CLG to run on CMU-CL, so Common Lisp has just the same graphics
support as Scheme," then you're definitely falling into danger.
I just tried doing an install of CLG, and it requires libraries that
have recently been made obsolete (GTK 1.3). And it's only "good" for
a few CL implementations. If it were to be considered "part of what's
available with CL," then it's surely fair to draw SRFI's in with
Scheme...
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://cbbrowne.com/info/lisp.html
Rules of the Evil Overlord #69. "All midwives will be banned from the
realm. All babies will be delivered at state-approved
hospitals. Orphans will be placed in foster-homes, not abandoned in
the woods to be raised by creatures of the wild."
<http://www.eviloverlord.com/>
Christopher Browne
> problems.
If you have to go looking for coroutine libraries, you'll certainly
not be big on using them.
- Perl people wind up using regexes a lot, because Perl makes it easy to
do so;
- APL people use vectors and arrays for everything, because the
alternatives are very painful;
- In Lisp, people tend to use lists rather a lot.
- In C, people curse at memory management especially when doing string
processing, because there's a lot of manual management needed.
- If you're accustomed to more dynamic languages with richer sets of
string operators, that will doubtless shape the way you think about
string processing.
No surprises there.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://cbbrowne.com/info/lisp.html
VERITAS AETERNA -- DON'T SETQ T.
Jochen Schmidt
Of course living things happen to change over time...
> - There are "wins" on both sides of the fence on the items I've
> mentioned:
>
> - There are _generally_ more mature Scheme regex implementations;
Really? Have tried them all? I stopped to count the regex implementations in
CL a while ago... ;-)
Seriously - I think the one in CL-AWK could be good. Then there is CLISPs
regex package which seems to be mature too. ACL comes with a mature regex
package too. I think in this point there is no significant difference with
Scheme and CL.
> - There are some nice CL socket libraries, albeit not as
> interoperable as would be nice;
As maintainer of ACL-COMPAT which is used by a webserver (Portable
AllegroServe) I tend to disagree. It's a complete Socket API which is
portable between ACL, CMUCL, LispWorks, MCL and OpenMCL. Chris Double has
written a library which makes that API accessible for Corman Lisp too.
Please if you have looked at it and still have issues about interoperability
then contact us and we will see what we can do.
> - For process control, there's probably a bit of "Advantage:
> Scheme";
Can you explain a bit further? The CLIM-SYS spec is there for a long time
and nearly every MP package is interoperable at at least this level.
Additionally to that ACL-COMPAT contains code to make MP code portable
between the above implementations. Again - if you are unhappy with what is
offered (for free!!!) - please let us know.
> - CL has CLIM, which I've never seen running, whilst it is common
> for Schemes to have interfaces to GTK/Tk;
Well why does CLIM not count? - CLIM is already available in ACL, Genera
,LispWorks and MCL. With ACL and LW you can use it on Unix/Linux _and_ and
Windows. With MCL you can access the Macintosh platform. There is a free
implementation of CLIM which makes quick progress (McCLIM). There is CAPI
on LispWorks (Windows+Linux/Unix). There is CommonGraphics in AllegroCL.
There is Garnet for several platforms. There is MCL with _really_
impressive GUI support. ACL is said to have bindings for GTK in the next
release. A new version of CLG is in the works too.
This is not saying that CL has "better" support for GUIs than Scheme - but I
disagree that it is generally worse! I always prefer coding with CLIM over
coding directly to the GTK API.
> - CommonSQL suggests "Advantage: CL";
I do not know if Scheme has something similar. CommonSQL (and UncommonSQL)
makes heavy use of CLOS and the MOP. So there might be nothing like that in
Scheme but I would be careful with such claims.
> - I've done all my XML work in CL, but there are generally more
> mature XML parsers for Scheme.
CL-XML looks ok to me.
> Picking out any one of these factors and saying "Ooh! CL supports
> this better! CL _MUST_ be better!" isn't something people ought to
> do.
Of course.
> The fact that the support for so many of these things are so _POOR_,
> for one or another language, should give _all_ partisans reason to
> pause.
I agree.
> If your reaction goes something like "Oh, but you're WRONG!!! I can
> get CLG to run on CMU-CL, so Common Lisp has just the same graphics
> support as Scheme," then you're definitely falling into danger.
No my reaction is more that I question that you can really rule that without
even knowing for example CLIM. The quality of the CLIM implementations
differs but at least the one in MCL seems to be excellent.
> I just tried doing an install of CLG, and it requires libraries that
> have recently been made obsolete (GTK 1.3). And it's only "good" for
> a few CL implementations. If it were to be considered "part of what's
> available with CL," then it's surely fair to draw SRFI's in with
> Scheme...
Well if you count all the implementation dependent stuff of Scheme then you
would have to cound all the implementation dependent stuff of CL too.
Actually I don't think that the problem is really which language offers more
or less features at all. The problems why this discussions arise so often
is simply the different opinions about small or big standards.
I don't think there is much i could take away from ANSI CL until I would
really feel it to be a worse language. I can imagine alot of stuff to add
to Scheme to make it a better language. And don't tell me that there is no
difference if something is specified in a standard or simply implemented
"somewhere", "somehow".
I think multidimensional Arrays should be part of the spec. A condition
system should be part of the spec. An object-system should be a part too.
There are many things I could add. If it would be so easy I would wish ANSI
Common Lisp would contain facilities to extend for example streams or
sequences or hash-tables. I wish it would contain something about
threading.
But I do not see any such change in near future so all we could do is to try
to try to build up quasi-standards (like SRFI).
ciao,
Jochen
William D Clinger
and listed 4 proposals, all of which I believe to have been facetious.
For a serious answer to his question, see
William D Clinger. Proper tail recursion and space efficiency.
In the Proceedings of the 1998 ACM Conference on Programming
Language Design and Implementation, June 1998, pages 174-185.
This paper regards both garbage collection and proper tail recursion
as space safety properties, and shows how a standard can mandate
those safety properties in particular, as well as several others.
Will
Stephen J. Bevan
> > - There are some nice CL socket libraries, albeit not as
> > interoperable as would be nice;
>
> As maintainer of ACL-COMPAT which is used by a webserver (Portable
> AllegroServe) I tend to disagree. It's a complete Socket API which is
> portable between ACL, CMUCL, LispWorks, MCL and OpenMCL. Chris Double has
> written a library which makes that API accessible for Corman Lisp too.
> Please if you have looked at it and still have issues about interoperability
> then contact us and we will see what we can do.
I have no complaints about the portability but I will take this
opportunity explain why I'd have difficultly using this socket library
or most of the built in ones included in various CL or Scheme
implemenations: lack of support for non-blocking I/O (an equivalent of
select/poll/kqueue or /dev/poll on a arbitrary set of
sockets/file-descriptors, not just one and a read/write
function/method that doesn't block) and multi-cast sockets. Combine
that with wanting SSL over a non-blocking socket and the situation
usually gets worse (Java can't do this either). Since most (all?)
Scheme and Common Lisp implementations have a "foreign" language
interface it is possible to work around this. However, that pushes me
further into using (S|CL)IDJ unless I take on the additional task (as
you did with Portable AlegroServe, and more power to you) of porting
the interface to various other implementations.
Jochen Schmidt
> Jochen Schmidt <j...@dataheaven.de> writes:
>> > - There are some nice CL socket libraries, albeit not as
>> > interoperable as would be nice;
>>
>> As maintainer of ACL-COMPAT which is used by a webserver (Portable
>> AllegroServe) I tend to disagree. It's a complete Socket API which is
>> portable between ACL, CMUCL, LispWorks, MCL and OpenMCL. Chris Double
>> has written a library which makes that API accessible for Corman Lisp
>> too. Please if you have looked at it and still have issues about
>> interoperability then contact us and we will see what we can do.
>
> I have no complaints about the portability but I will take this
> opportunity explain why I'd have difficultly using this socket library
> or most of the built in ones included in various CL or Scheme
> implemenations: lack of support for non-blocking I/O (an equivalent of
> select/poll/kqueue or /dev/poll on a arbitrary set of
> sockets/file-descriptors, not just one and a read/write
> function/method that doesn't block) and multi-cast sockets.
Yes this is certainly were it begins to get dirty. Actually the ACL API
provides a function WAIT-FOR-INPUT-AVAILABLE which at least solves part of
that problem (waiting for _input_ on multiple streams). I have an
implementation of that function in ACL-COMPAT which works with LispWorks on
Linux and should work with Lispworks on Windows (not tested). I think it
would not that difficult to support other systems as well.
I have to say that I would prefer a WAIT-FOR-IO which returns for each given
stream if there is :input, :output or :io possible. I can imagine on how to
implement such a thing in UNIX lisp-systems but I do not know how to do it
under Windows.
I do not have any ideas about multi-cast sockets - but this is only because
i never needed them.
> Combine
> that with wanting SSL over a non-blocking socket and the situation
> usually gets worse (Java can't do this either).
Hm... well - my CL-SSL binding to OpenSSL is supposed to work with
non-blocking sockets. LispWorks uses non-blocking sockets internally so
this had to work.
> Since most (all?)
> Scheme and Common Lisp implementations have a "foreign" language
> interface it is possible to work around this. However, that pushes me
> further into using (S|CL)IDJ unless I take on the additional task (as
> you did with Portable AlegroServe, and more power to you) of porting
> the interface to various other implementations.
For Common Lisp the UFFI project of defining a portable FFI API looks
promising.
Stephen J. Bevan
> Yes this is certainly were it begins to get dirty. Actually the ACL API
> provides a function WAIT-FOR-INPUT-AVAILABLE which at least solves part of
> that problem (waiting for _input_ on multiple streams).
If you just want to wait for input I agree. Unfortunately I don't, I
need :-
> I have to say that I would prefer a WAIT-FOR-IO which returns for each given
> stream if there is :input, :output or :io possible.
Throw in an indication whether there has been an error and it would be
all that I need :-)
> I do not have any ideas about multi-cast sockets - but this is only because
> i never needed them.
I would be quite happy to ignore them but some things like RIP-2 (RFC
2453) use them and so if you don't have multi-cast sockets you can't
implement RIP-2. Lest anyone suggest that RIP(-2) is aging and we
should all use OSPF then that just opens up another socket interface
problem since OSPF doesn't use TCP or UDP, it uses IP datagrams
directly (protocol 89).
> Hm... well - my CL-SSL binding to OpenSSL is supposed to work with
> non-blocking sockets. LispWorks uses non-blocking sockets internally so
> this had to work.
Ideally I'd prefer not to use OpenSSL and instead using an SSL coded
in the host language, mainly for reasons of safety and security.
However, I realise that is a pretty tall order.
Jochen Schmidt
> Jochen Schmidt <j...@dataheaven.de> writes:
>> Yes this is certainly were it begins to get dirty. Actually the ACL API
>> provides a function WAIT-FOR-INPUT-AVAILABLE which at least solves part
>> of that problem (waiting for _input_ on multiple streams).
>
> If you just want to wait for input I agree. Unfortunately I don't, I
> need :-
>
>> I have to say that I would prefer a WAIT-FOR-IO which returns for each
>> given stream if there is :input, :output or :io possible.
>
> Throw in an indication whether there has been an error and it would be
> all that I need :-)
Well if all platform for which such a function should be defined would offer
the full select() functionality then this would be probably no problem.
Since you sound as if you use a select() based system - why not using the
FFI to call select()?
>> I do not have any ideas about multi-cast sockets - but this is only
>> because i never needed them.
>
> I would be quite happy to ignore them but some things like RIP-2 (RFC
> 2453) use them and so if you don't have multi-cast sockets you can't
> implement RIP-2. Lest anyone suggest that RIP(-2) is aging and we
> should all use OSPF then that just opens up another socket interface
> problem since OSPF doesn't use TCP or UDP, it uses IP datagrams
> directly (protocol 89).
Well - I think it may be a matter of time and money...
> > Hm... well - my CL-SSL binding to OpenSSL is supposed to work with
> > non-blocking sockets. LispWorks uses non-blocking sockets internally so
> > this had to work.
>
> Ideally I'd prefer not to use OpenSSL and instead using an SSL coded
> in the host language, mainly for reasons of safety and security.
> However, I realise that is a pretty tall order.
Implement all of SSL in Common Lisp is not a trivial task - but given enough
money and time... ;-)
Seriously - I do not really know what reasons of safety and security mean
here. As soon as you communicate through some socket you leave the
lisp-world and enter the harsh C world of your OS (if you don't have a
lispmachine ;-) ). There is not much difference in security or safety if
you call read() or ssl_read(). Or did you mean something specific?
Stephen J. Bevan
> Well if all platform for which such a function should be defined would offer
> the full select() functionality then this would be probably no problem.
>
> Since you sound as if you use a select() based system - why not using the
> FFI to call select()?
I do, I define my own API to sockets and poll (or select if I must)
instead of using whatever is supplied by the implementation pushing me
further into (S|CL)IDJ.
> Seriously - I do not really know what reasons of safety and security mean
> here. As soon as you communicate through some socket you leave the
> lisp-world and enter the harsh C world of your OS (if you don't have a
> lispmachine ;-) ).
For the most part I trust the OS to get things right (I don't use
Windows :-). What I trust a lot less is third-party C code,
especially code that I have to expose to a network connection.
> There is not much difference in security or safety if
> you call read() or ssl_read(). Or did you mean something specific?
For me there is a big difference between read() and ssl_read(). The
former goes directly to the OS (at least under Unix) and only involves
using buffers that *I* allocate and have control over. The latter
involves various buffers inside the (C) SSL implmentation that I have
little or no control over and which I'm exposing directly to the
network. Any bug in buffer handling related to input over the socket
and it opens the door to stack smashing and possibly a compromised
box. For example, see :-
http://www.openbsd.org/errata.html#ssl
which coincidentally came out today but wasn't the catalyst for my
post. Barring errors in the (Scheme|CL) compiler then the worst that
any buffer overflow error should do in a pure (Scheme|CL) SSL
implementation is take down the session associated with that socket.
Nicolas Neuss
> Right, just as you can turn C into an OO system by adding a bunch of
> preprocessor macros. So, OO support doesn't belong into language
> specs either, is that your point?
Is this really possible? How does it look like? C macro should be
much too weak for that.
Nicolas.
Will Deakin
> TB> and posting news articles is a mistake.
>
> Yikes. I didn't realize I was that effective at arguing ;-).
:(w
Nils Goesche
Ask Bjarne Stroustrup (sp?) -- his early versions of C++ worked that
way, AFAIK...
Basile STARYNKEVITCH
Nils> Nicolas Neuss <Nicola...@iwr.uni-heidelberg.de> writes:
Nicolas> Nils Goesche <car...@cartan.de> writes:
Nils>> Right, just as you can turn C into an OO system by adding a
Nils>> bunch of preprocessor macros. So, OO support doesn't belong
Nils>> into language specs either, is that your point?
Nicolas> Is this really possible? How does it look like? C macro
Nicolas> should be much too weak for that.
Nils> Ask Bjarne Stroustrup (sp?) -- his early versions of C++
Nils> worked that way, AFAIK...
The early versions of C++ (probably called C with classes) was
implemented by a translator which read code and translated it into C
code. It was not, IIRC, a set of /lib/cpp C preprocessor macros. But C
was used as a target language.
And early implementations of C++ (using Cfront) worked the same
way. BTW, the generated C code was not machine independent (generated
C code was different on 32 or 64 bits, bigendian or littleendian,
machines).
Regards.
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France
Nils Goesche
> >>>>> "Nils" == Nils Goesche <car...@cartan.de> writes:
>
> Nils> Nicolas Neuss <Nicola...@iwr.uni-heidelberg.de> writes:
> Nicolas> Nils Goesche <car...@cartan.de> writes:
>
> Nils>> Right, just as you can turn C into an OO system by adding a
> Nils>> bunch of preprocessor macros. So, OO support doesn't belong
> Nils>> into language specs either, is that your point?
>
> Nicolas> Is this really possible? How does it look like? C macro
> Nicolas> should be much too weak for that.
>
> Nils> Ask Bjarne Stroustrup (sp?) -- his early versions of C++
> Nils> worked that way, AFAIK...
>
> The early versions of C++ (probably called C with classes) was
> implemented by a translator which read code and translated it into C
> code. It was not, IIRC, a set of /lib/cpp C preprocessor macros. But
> C was used as a target language.
Nice to hear, actually. Somebody told me years ago that it was done
with C preprocessor macros; I was wondering since how that could
possibly work. Thanks for the information.
Craig Brozefsky
> I worked on a Java project where various programs used one or more of
> the following standard features of Java: threads, servlets, JDBC,
> sockets (plain and SSL), non-blocking IO, crypto/certificates, CORBA
> interface, logging, LDAP interface, native language interface and GUI.
>
> While I don't doubt that it is a lot of work to add all the standard
> things that Common Lisp has to Scheme (CLOS alone is a huge amount of
> work if you wanted to implement it in all its detail), I also think
> you are underestimating the work it would take to add to Common Lisp
> all the standard things (such as the *subset* above) that are in Java.
I understand what you say is missing, but in my personal experience
with CL I have not found that to be a real critical issue. I found
that the parts that people commonly identify as missing from CL,
threads, servlets, JDBC, CORBA, LDAP, GUI are either not really
missing, or are not difficult to comprehend and then implement in some
fashion properly tailored to my needs as opposed to a "least common
denominator" standard. I have asked myself if perhaps I am blinded by
a naive "not invented here" fetish, but I think it has to do with an
improvement in my ability to comprehend protocols and interfaces
across several diffrerent programming paradigms that I got from
writing CL all day.
I have spent the last couple years writing CL, and some of it was
re-implementing, or dealing with, the missing elements you allude too.
That "added work" has overall been overshadowed by what lies beyond
the hastily assembled industry standards that castrate Java. Perhaps
that's a bit too hyperbolic, reminescent of the pablum you get reading
any psuedo-academic comentary on LISP, but I can honestly say that *I*
am the limiting factor as far as any aesthetic progress in the code
base I work on daily, not the language it is implemented in, CL.
--
Sincerely,
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig