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. 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.
Russell Lear wrote:
> 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. 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?
>
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...
--
<·······@hotmail.spam.com>
<http://bgb1.hypermart.net/>
Russell Lear <···········@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'.
>>>>> "MA" == Marco Antoniotti <·······@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 ;-).
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
Benjamin Simon <···@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <·······@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?
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'.
>>>>> "MA" == Marco Antoniotti <·······@cs.nyu.edu> writes:
MA> Benjamin Simon <···@atom.amazingmedia.com> writes:
>> >>>>> "MA" == Marco Antoniotti <·······@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
Benjamin Simon <···@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <·······@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" :)
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'.
Marco Antoniotti <·······@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.
It doesn't mention call/cc either, but this is not because the authors
of SICP think call/cc is unimportant.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Marco Antoniotti <·······@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.
--
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'.
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
>> Marco Antoniotti <·······@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).
But you sure seem to be pointing at it as an example of "all that is
in Scheme."
If anything, it uses a _faint_ subset of Scheme: one that makes R*RS
look _powerful_. No strings, no macros, no call/cc, no arrays, no
syntax-lists, no, well, "lots of things."
>> It doesn't mention call/cc either, but this is not because the
>> authors of SICP think call/cc is unimportant.
>
> Sure. I agree.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/multiplexor.html
Rules of the Evil Overlord #114. "I will never accept a challenge from
the hero." <http://www.eviloverlord.com/>
Christopher Browne <········@acm.org> writes:
> If anything, it uses a _faint_ subset of Scheme: one that makes R*RS
> look _powerful_. No strings, no macros, no call/cc, no arrays, no
> syntax-lists, no, well, "lots of things."
Indeed! One of the underlying foundations of CS education at MIT is
that CS education is *not* about teaching languages.
There's a saying there: "Pascal is a useful language for only one
thing: teaching Pascal." The point of 6.001 is not to teach Scheme,
it's to teach programming. Scheme is a good language (surely not the
only one, of course) in which the language can get out of the damn way
and the student can learn something about computer programs.
>>>>> "MA" == Marco Antoniotti <·······@cs.nyu.edu> writes:
MA> Benjamin Simon <···@atom.amazingmedia.com> writes:
>> >>>>> "MA" == Marco Antoniotti <·······@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
Benjamin Simon <···@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. :)
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'.
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Benjamin Simon <···@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 ·······@bcect.com
·······@bcect.com (Michael Sullivan) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
> > Benjamin Simon <···@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ·······@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).
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'.
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).
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
"Jens Axel S�gaard" <······@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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> "Jens Axel S�gaard" <······@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
"Jens Axel S�gaard" <······@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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> "Jens Axel S�gaard" <······@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
·······@bcect.com (Michael Sullivan) writes:
> Marco Antoniotti <·······@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.
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'.
From: Hartmann Schaffer
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3d421209@news.sentex.net>
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ...
> 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.
or in scheme plus a library tailored for a certain problem set
> ...
hs
--
don't use malice as an explanation when stupidity suffices
Marco Antoniotti <·······@cs.nyu.edu> 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.
>
> Of course not. You just end up programming in your SIDJ and therefore
> 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.
·······@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.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> ·······@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?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
>
> > ·······@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'.
From: Bulent Murtezaoglu
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <87d6t64jx8.fsf@nkapi.internal>
>>>>> "DanB" == Daniel Barlow <···@telent.net> writes:
DanB> Scott 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
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3fzy6nx0f.fsf@cley.com>
* 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. 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
Tim Bradshaw <···@cley.com> wrote:
> * 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.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
Michael Sullivan <·······@bcect.com> wrote:
> 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.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
·······@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.
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'.
·······@bcect.com (Michael Sullivan) writes:
> 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
Nils Goesche <···@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.
--
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
Brian Palmer <·······@leland.stanford.edu> writes:
> Nils Goesche <···@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 :-)
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
From: Hartmann Schaffer
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3d4210cf@news.sentex.net>
In article <··············@darkstar.cartan>,
Nils Goesche <···@cartan.de> writes:
> Brian Palmer <·······@leland.stanford.edu> writes:
>
>> Nils Goesche <···@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
··@heaven.nirvananet (Hartmann Schaffer) 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"
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.
From: Hartmann Schaffer
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3d431d45@news.sentex.net>
In article <··············@becket.becket.net>,
·········@becket.net (Thomas Bushnell, BSG) writes:
> ··@heaven.nirvananet (Hartmann Schaffer) 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"
>
> 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.
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?
hs
--
don't use malice as an explanation when stupidity suffices
··@heaven.nirvananet (Hartmann Schaffer) writes:
> In article <··············@becket.becket.net>,
> ·········@becket.net (Thomas Bushnell, BSG) writes:
> > ··@heaven.nirvananet (Hartmann Schaffer) 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"
> >
> > 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.
>
> 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?
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.
Hartmann Schaffer <··@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.
--
Russ Allbery (···@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery <···@stanford.edu> writes:
> Hartmann Schaffer <··@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.
--
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
Brian Palmer <·······@leland.stanford.edu> writes:
> Russ Allbery <···@stanford.edu> writes:
>
> > Hartmann Schaffer <··@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''?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
Nils Goesche <···@cartan.de> writes:
> # #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.
--
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
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@trex8.cs.bell-labs.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> > Nils Goesche <···@cartan.de> writes:
> >
> > > Brian Palmer <·······@leland.stanford.edu> writes:
> > >
> > > > Russ Allbery <···@stanford.edu> writes:
> > > >
> > > > > Hartmann Schaffer <··@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''.
> >
> > Where does it say what it means to be "available for allocation"?
>
> In Webster's dictionary, among others.
Sorry, Erann, but I highly doubt that a definition of this phrase good
enough to stand up to the rigor of PL semantics can be found in
Webster's.
The fact is that it is highly unspecified under which conditions
memory "returned" to the allocator via "free" will be dished out again
by a subsequent allocation. An allocator that makes memory
"avaliable" but then "chooses" to always return fresh memory anyway,
ignoring all that "available" memory returned via "free", would
probably not violate the letter (although perhaps the spirit) of the C
standard.
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
[xnip]
> > > Where does it say what it means to be "available for allocation"?
> >
> > In Webster's dictionary, among others.
>
> Sorry, Erann, but I highly doubt that a definition of this phrase good
> enough to stand up to the rigor of PL semantics can be found in
> Webster's.
Sorry, Matthias, but your doubt is irrelevant. Whenever you write
anything in English (as the C standard is) the semantics bottom out in the
dictionary. You may not like it, but that's the way it is.
> The fact is that it is highly unspecified under which conditions
> memory "returned" to the allocator via "free" will be dished out again
> by a subsequent allocation. An allocator that makes memory
> "avaliable" but then "chooses" to always return fresh memory anyway,
> ignoring all that "available" memory returned via "free", would
> probably not violate the letter (although perhaps the spirit) of the C
> standard.
Unless you have an infinite amount of memory it would violate both the
letter and the spirit, because it would eventually run out of fresh
memory, at which point it would have no choice but to allocate free'd
memory. If it didn't then that memory would not be "available", in
violation of the standard.
There is nothing in either the letter of the spirit of the standard that
requires the following function to return 1:
int f() {
void * p1 = malloc(10);
free(p1);
void * p2 = malloc(10);
return p1 == p2;
}
but both the letter and the spirit of the standard require this snippet to
run forever (assuming no multiprocessing):
void f() {
void *p;
while (1) {
p = malloc(10);
if (!p) return;
free(p);
}
}
E.
From: Hartmann Schaffer
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3d5c4e5e@news.sentex.net>
In article <····················@192.168.1.52>,
···@jpl.nasa.gov (Erann Gat) writes:
> ...
> Unless you have an infinite amount of memory it would violate both the
> letter and the spirit, because it would eventually run out of fresh
> memory, at which point it would have no choice but to allocate free'd
> memory. If it didn't then that memory would not be "available", in
> violation of the standard.
in that case any implementation of malloc/free that doesn't include a
compacting garbage collector violates both the letter and the spirit
of the C standard
> ...
> but both the letter and the spirit of the standard require this snippet to
> run forever (assuming no multiprocessing):
>
> void f() {
> void *p;
> while (1) {
> p = malloc(10);
> if (!p) return;
> free(p);
> }
> }
now try
void f( ) {
void *p1, *p2;
for( ; ; ) {
p1= malloc(10);
p2= malloc(15);
free(p1);
if(!p) return; }
will run out of memory at a point when almost half the available
memory is still free
hs
--
don't use malice as an explanation when stupidity suffices
In article <········@news.sentex.net>, ··@heaven.nirvananet (Hartmann
Schaffer) wrote:
> In article <····················@192.168.1.52>,
> ···@jpl.nasa.gov (Erann Gat) writes:
> > ...
> > Unless you have an infinite amount of memory it would violate both the
> > letter and the spirit, because it would eventually run out of fresh
> > memory, at which point it would have no choice but to allocate free'd
> > memory. If it didn't then that memory would not be "available", in
> > violation of the standard.
>
> in that case any implementation of malloc/free that doesn't include a
> compacting garbage collector violates both the letter and the spirit
> of the C standard
[Code snipped]
No. This is just an oblique way of saying that C suffers from heap
fragmentation, which is not news. All those freed 10-byte memory blocks
are (or at least should be per the standard) still "available" to fill
requests of size <= 10.
> don't use malice as an explanation when stupidity suffices
OK.
E.
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3d6sjwptr.fsf@cley.com>
* Hartmann Schaffer wrote:
> void f( ) {
> void *p1, *p2;
> for( ; ; ) {
> p1= malloc(10);
> p2= malloc(15);
> free(p1);
> if(!p) return; }
> will run out of memory at a point when almost half the available
> memory is still free
If you have an allocator which allocates sequentially, it might, yes
(assuming !p is !p2). If you have an allocator which, for instance,
allocates chunks of 10 or smaller from 0 and ones of 11 or higher from
high memory, this will not be true. In other words, don't be silly.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Hartmann Schaffer wrote:
>
> > void f( ) {
> > void *p1, *p2;
>
> > for( ; ; ) {
> > p1= malloc(10);
> > p2= malloc(15);
> > free(p1);
> > if(!p) return; }
>
> > will run out of memory at a point when almost half the available
> > memory is still free
>
> If you have an allocator which allocates sequentially, it might, yes
> (assuming !p is !p2). If you have an allocator which, for instance,
> allocates chunks of 10 or smaller from 0 and ones of 11 or higher from
> high memory, this will not be true. In other words, don't be silly.
But Hartmann's first allocator is certainly a valid one according to
the C standard. So what's your point?
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3fzxf6u0q.fsf@cley.com>
* Matthias Blume wrote:
> But Hartmann's first allocator is certainly a valid one according to
> the C standard. So what's your point?
He said `... will run out of memory at a point ...' when he should
have said either `... might run out of memory at a point ...' or
`assuming an allocator with the following characteristics ... this
program will run out of memory at a point ...'. So his statement was
just false as it stood.
I'm beginning to think that cll has been invaded by aliens. Are you
small and green with aerials on your head?
--tim
Tim Bradshaw <···@cley.com> writes:
> I'm beginning to think that cll has been invaded by aliens. Are you
> small and green with aerials on your head?
yes.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@hana.shimizu-blume.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> [xnip]
>
> > > > Where does it say what it means to be "available for allocation"?
> > >
> > > In Webster's dictionary, among others.
> >
> > Sorry, Erann, but I highly doubt that a definition of this phrase good
> > enough to stand up to the rigor of PL semantics can be found in
> > Webster's.
>
> Sorry, Matthias, but your doubt is irrelevant. Whenever you write
> anything in English (as the C standard is) the semantics bottom out in the
> dictionary. You may not like it, but that's the way it is.
That's the problem with all semantics that are being specified in
English: they are inherently ambiguous.
> > The fact is that it is highly unspecified under which conditions
> > memory "returned" to the allocator via "free" will be dished out again
> > by a subsequent allocation. An allocator that makes memory
> > "avaliable" but then "chooses" to always return fresh memory anyway,
> > ignoring all that "available" memory returned via "free", would
> > probably not violate the letter (although perhaps the spirit) of the C
> > standard.
>
> Unless you have an infinite amount of memory it would violate both the
> letter and the spirit, because it would eventually run out of fresh
> memory, at which point it would have no choice but to allocate free'd
> memory. If it didn't then that memory would not be "available", in
> violation of the standard.
That it false. "Available" could also mean that there is at least one
allocation/deallocation sequence that causes the memory in question to
be reused for allocation. But that one sequence does not have to be
any of the ones that your program uses. In fact, there are many C
programs that will eventually run out of memory using typical
malloc/free implementations even though the malloc request that ends
up failing asks for no more memory than what is currently "available".
In fact, in typical flat address spaces, allocation of n bytes can fail
even though Omega(n^2) bytes are "available". (Work it out!)
> There is nothing in either the letter of the spirit of the standard that
> requires the following function to return 1:
>
> int f() {
> void * p1 = malloc(10);
> free(p1);
> void * p2 = malloc(10);
> return p1 == p2;
> }
IIRC, this program is in violation of the standard.
> but both the letter and the spirit of the standard require this snippet to
> run forever (assuming no multiprocessing):
> void f() {
> void *p;
> while (1) {
> p = malloc(10);
> if (!p) return;
> free(p);
> }
> }
>
> E.
I very highly doubt that the letter of the standard requires this.
(Otherwise, prove it!)
Matthias
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > <········@shimizu-blume.com> wrote:
> >
> > [xnip]
> >
> > > > > Where does it say what it means to be "available for allocation"?
> > > >
> > > > In Webster's dictionary, among others.
> > >
> > > Sorry, Erann, but I highly doubt that a definition of this phrase good
> > > enough to stand up to the rigor of PL semantics can be found in
> > > Webster's.
> >
> > Sorry, Matthias, but your doubt is irrelevant. Whenever you write
> > anything in English (as the C standard is) the semantics bottom out in the
> > dictionary. You may not like it, but that's the way it is.
>
> That's the problem with all semantics that are being specified in
> English: they are inherently ambiguous.
Perhaps, but asking "where does it say what 'available' means?" is a
rather oblique way of making that point.
Response #1: English specifications are not *inherently* ambiguous since
mathematical specifications can be rendered in English.
Repsonse #2: mathematical specifications are also inherently ambigious.
See David Deutch "The Fabric of Reality" chapter 10.
> > > The fact is that it is highly unspecified under which conditions
> > > memory "returned" to the allocator via "free" will be dished out again
> > > by a subsequent allocation. An allocator that makes memory
> > > "avaliable" but then "chooses" to always return fresh memory anyway,
> > > ignoring all that "available" memory returned via "free", would
> > > probably not violate the letter (although perhaps the spirit) of the C
> > > standard.
> >
> > Unless you have an infinite amount of memory it would violate both the
> > letter and the spirit, because it would eventually run out of fresh
> > memory, at which point it would have no choice but to allocate free'd
> > memory. If it didn't then that memory would not be "available", in
> > violation of the standard.
>
> That it false. "Available" could also mean that there is at least one
> allocation/deallocation sequence that causes the memory in question to
> be reused for allocation.
No it couldn't. And that's a rather cheeky claim to make when by your own
admission you haven't even bothered to read what the standard (the
dictionary in this case) has to say about it.
> In fact, there are many C
> programs that will eventually run out of memory using typical
> malloc/free implementations even though the malloc request that ends
> up failing asks for no more memory than what is currently "available".
> In fact, in typical flat address spaces, allocation of n bytes can fail
> even though Omega(n^2) bytes are "available". (Work it out!)
You are simply making the observation (again, obliquely) that heaps can
fragment. So what? Everyone knows this.
> > There is nothing in either the letter of the spirit of the standard that
> > requires the following function to return 1:
> >
> > int f() {
> > void * p1 = malloc(10);
> > free(p1);
> > void * p2 = malloc(10);
> > return p1 == p2;
> > }
>
> IIRC, this program is in violation of the standard.
You know, Matthias, I make it a point to read everything you post to
c.l.l. and c.l.s. because 99% of the time what you have to say is
worthwhile and I learn a lot. But in this case I am becoming convinced
that you don't really have a point to make here and are just intentionally
being a jerk. This is legal C++ code, and it takes no great leap of the
imagination to render it into legal C.
> I very highly doubt that the letter of the standard requires this.
> (Otherwise, prove it!)
It's an informal standard so I can't "prove" anything about it in the way
that you probably mean here. But again, your doubt is irrelevant. The
way you "prove" this is to write a malloc/free implementation that doesn't
have this property and see if people accept it. The semantics of informal
standards (like natural language) are determined by consensus. Within the
community of C programmers there is consensus on this point. I can't
prove this, but if you go talk to C programmers (and I mean C programmers,
not wise-guy ML programmers who just happen to know C) you will find that
it is so.
BTW, there's a fine illustration of the slipperiness of even formal
standards in a recent thread on c.l.s. that you yourself were involved in
regarding the semantics of (call/cc (lambda (c) (0 (c 1)))). The formal
semantics say unambiguously (once you go through the considerable trouble
to work it out) that the value of this expression in Scheme is 1.
Nonetheless, many Scheme implementations signal an error. The debate over
which of these behaviors is "correct" raged on for weeks and was never
resolved.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@hana.shimizu-blume.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > int f() {
> > > void * p1 = malloc(10);
> > > free(p1);
> > > void * p2 = malloc(10);
> > > return p1 == p2;
> > > }
> >
> > IIRC, this program is in violation of the standard.
>
> This is legal C++ code, and it takes no great leap of the
> imagination to render it into legal C.
Sorry, but the point here is that you are evaluating p1 after calling
free on it. This is not allowed, and yes, it's strange :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
In article <··············@pc022.bln.elmeg.de>, Nils Goesche
<······@cartan.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > <········@shimizu-blume.com> wrote:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > > > int f() {
> > > > void * p1 = malloc(10);
> > > > free(p1);
> > > > void * p2 = malloc(10);
> > > > return p1 == p2;
> > > > }
> > >
> > > IIRC, this program is in violation of the standard.
> >
> > This is legal C++ code, and it takes no great leap of the
> > imagination to render it into legal C.
>
> Sorry, but the point here is that you are evaluating p1 after calling
> free on it. This is not allowed, and yes, it's strange :-)
Actually, what the standard says is that the effects of "using" a free'd
pointer are "undefined." Given the usual computational model for C it is
not unreasonable to suppose that "use" means "dereference."
But be that as it may, here's a modified example that conforms to the
letter of the law:
int f() {
void* p;
int x;
p = malloc(10);
x = (int)p;
free(p);
p = malloc(10);
return x == (int)p;
}
Did you really need me to spell that out for you?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@pc022.bln.elmeg.de>, Nils Goesche
> <······@cartan.de> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > > <········@shimizu-blume.com> wrote:
> > >
> > > > ···@jpl.nasa.gov (Erann Gat) writes:
> > > >
> > > > > int f() {
> > > > > void * p1 = malloc(10);
> > > > > free(p1);
> > > > > void * p2 = malloc(10);
> > > > > return p1 == p2;
> > > > > }
> > > >
> > > > IIRC, this program is in violation of the standard.
> > >
> > > This is legal C++ code, and it takes no great leap of the
> > > imagination to render it into legal C.
> >
> > Sorry, but the point here is that you are evaluating p1 after calling
> > free on it. This is not allowed, and yes, it's strange :-)
>
> Actually, what the standard says is that the effects of "using" a free'd
> pointer are "undefined." Given the usual computational model for C it is
> not unreasonable to suppose that "use" means "dereference."
>
> But be that as it may, here's a modified example that conforms to the
> letter of the law:
>
> int f() {
> void* p;
> int x;
>
> p = malloc(10);
> x = (int)p;
> free(p);
> p = malloc(10);
> return x == (int)p;
> }
>
> Did you really need me to spell that out for you?
No, that was not necessary.
Actually (again, IIRC), this is just as undefined as the earlier
program. Casting pointers to ints has no well-defined meaning
according to the C standard, although certainly every "sane" C
compiler will (again, driven by user expectation) do one particular
thing (which is to say: leave the bits unchanged and interpret the
pointer representation as an int representation).
Anyway, this is certainly way off topic, so let's drop the topic right
here and now.
Matthias
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> Actually (again, IIRC), this is just as undefined as the earlier
> program. Casting pointers to ints has no well-defined meaning
> according to the C standard, although certainly every "sane" C
> compiler will (again, driven by user expectation) do one particular
> thing (which is to say: leave the bits unchanged and interpret the
> pointer representation as an int representation).
Actually, I don't need to assume that. The only invariant that I need to
assume to make my point (which is, by the way, that the behavior of free()
is just as well defined as anything else in the C standard notwithstanding
the lack of a definition of the word "available") is that casting to int
preserves equality. That is a much weaker assumption than preserving the
bits. (I note in passing that the standard does not define the meaning of
the word "equals" either.) You'd have to invent some pretty wacky pointer
semantics for that assumption not to hold.
> Anyway, this is certainly way off topic, so let's drop the topic right
> here and now.
OK.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> The only invariant that I need to
> assume to make my point [ ... ] is that [ in C ] casting [ pointers ] to int
> preserves equality.
But it doesn't.
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>
> > The only invariant that I need to
> > assume to make my point [ ... ] is that [ in C ] casting [ pointers ] to int
> > preserves equality.
>
> But it doesn't.
Then I have three questions for you:
1. In how many existing C compilers does casting pointers to int not
preserve equality?
2. There are at least five circumstances under which (car (cons 5 4))
would do something other than return 5 in a conforming Common Lisp
implementation*. Does that mean that it's correct to say that "In Common
Lisp, (car (cons 5 4)) doesn't return 5"?
3. Didn't you say you wanted to drop this as off-topic?
E.
---
* The five circumstances I could think of offhand:
1. *package* is set to a package that shadows CAR or CONS.
2. *read-base* is set to less than 6 (in which case '5' is a symbol).
3. *read-base* is set to more than 27 (in which case 'car' is a number).
4. (readtable-case *readtable*) is set to :preserve or :downcase
5. The readtable entry for any of the characters in the input string has
been changed
There are no doubt many more.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@hana.shimizu-blume.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> >
> > > The only invariant that I need to
> > > assume to make my point [ ... ] is that [ in C ] casting [ pointers ] to int
> > > preserves equality.
> >
> > But it doesn't.
>
> Then I have three questions for you:
>
> 1. In how many existing C compilers does casting pointers to int not
> preserve equality?
How many C compilers exist? What does this have to do with anything?
> 2. There are at least five circumstances under which (car (cons 5 4))
> would do something other than return 5 in a conforming Common Lisp
> implementation*. Does that mean that it's correct to say that "In Common
> Lisp, (car (cons 5 4)) doesn't return 5"?
What does that have to do with anything?*
> 3. Didn't you say you wanted to drop this as off-topic?
Right. Didn't you agree?
> * The five circumstances I could think of offhand:
>
> 1. *package* is set to a package that shadows CAR or CONS.
> 2. *read-base* is set to less than 6 (in which case '5' is a symbol).
> 3. *read-base* is set to more than 27 (in which case 'car' is a number).
> 4. (readtable-case *readtable*) is set to :preserve or :downcase
> 5. The readtable entry for any of the characters in the input string has
> been changed
* Nice and clever. And completely irrelevant. All these effects
can be explained completely in terms of the language standard. The
effect of casting a pointer to an int in C is outside the language
standard.
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > <········@shimizu-blume.com> wrote:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > >
> > > > The only invariant that I need to
> > > > assume to make my point [ ... ] is that [ in C ] casting [
pointers ] to int
> > > > preserves equality.
> > >
> > > But it doesn't.
> >
> > Then I have three questions for you:
> >
> > 1. In how many existing C compilers does casting pointers to int not
> > preserve equality?
>
> How many C compilers exist?
No, the answer is "zero." Read the question again carefully.
> What does this have to do with anything?
You claimed that "it [C] doesn't" preserve equality when casting pointers
to ints. The only sense in which this statement comes even remotely close
to being true is that this behavior is not required by the standard. But
likewise the Lisp standard does not require (car (cons 5 4)) to be 5. It
is nonetheless wrong to say that (car (cons 5 4)) is not 5. It is
likewise wrong to say that C does not preserve equality when casting
pointers to ints (and, to bring it full circle since you seem to want
everything spelled out for you, it is likewise wrong to say that free() is
allowed to do nothing simply because the standard does not provide a
definition of the word "available.")
E.
From: Ziv Caspi
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3d5fa430.183025957@newsvr>
On Sun, 18 Aug 2002 00:43:20 -0700, ···@jpl.nasa.gov (Erann Gat)
wrote:
[...]
>> > 1. In how many existing C compilers does casting pointers to int not
>> > preserve equality?
>>
>> How many C compilers exist?
>
>No, the answer is "zero." Read the question again carefully.
[...]
I'm not sure my interpretation of "preserve equality" is what you
meant. If I understand the concept correctly, any 64bit compiler
that has 32bit ints fails this test. This is true for Win64 compilers
such as VC, for example.
Ziv
·····@netvision.net.il (Ziv Caspi) writes:
> On Sun, 18 Aug 2002 00:43:20 -0700, ···@jpl.nasa.gov (Erann Gat)
> wrote:
> [...]
> >> > 1. In how many existing C compilers does casting pointers to int not
> >> > preserve equality?
> >>
> >> How many C compilers exist?
> >
> >No, the answer is "zero." Read the question again carefully.
> [...]
>
> I'm not sure my interpretation of "preserve equality" is what
> you meant. If I understand the concept correctly, any 64bit
> compiler that has 32bit ints fails this test. This is true for
> Win64 compilers such as VC, for example.
Well, Erann didn't say `...and back again...', IOW, he didn't claim
the casting operation was injective. All he said was
If p1 == p2, then (int) p1 == (int) p2 in existing C compilers.
By some grace of fate, I never had to write any programs for DOS.
But I imagine that in an architecture where pointers consist of a
segment and offset part, two pointers that compare equal could
very well yield different values when casted to int.
Also, I could imagine several bizarre things that might happen in
a virtual memory architecture with an MMU, and processors that
have special registers for pointer values that are directly
connected to that MMU, but in fact that is quite irrelevant
because it doesn't change the fact that Erann's original point
was quite correct: We all know what `available' means. An
implementor is asked to do `something sensible' in his
architecture to make free'd memory `available' again, whatever
that might mean in his particular architecture. Whether we can
write a portable C program to inspect the effect of free is a
different, and irrelevant, matter.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
What about changing the Subject: line for this thread? Shall we call
`ilias' to do 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'.
From: Greg Menke
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <m38z3456s5.fsf@europa.pienet>
Nils Goesche <···@cartan.de> writes:
>
> By some grace of fate, I never had to write any programs for DOS.
> But I imagine that in an architecture where pointers consist of a
> segment and offset part, two pointers that compare equal could
> very well yield different values when casted to int.
It was moderately evil, particularly when incrementing a pointer
across a buffer. If I recall correctly, incrementing the pointer
affected the offset only until it rolled over, then the segment was
incremented. This would lead to the failure of a == test between the
incremented pointer against another pointer known to be set to the
same address- simply because the seg:offsets of both pointers ended up
different. Casting a seg:offset pointer to a long int would put the
segment into the upper 16 bits and the offset into the lower. I don't
remember if casting a 16 bit pointer to a long would pick up the app's
DS into the upper 16 bits or not.
The problem was more or less addressed by a "huge" pointer type- which
was still a 32 bit quantity. The C compiler normalized huge pointers
after every update by shifting all but the lowest 4 bits of the offset
into the segment, reducing pointer "synonyms" to bit-wise equality.
It added a bit of overhead, but was often necessary.
Naturally (IIRC) both Microsoft and Borland compilers had various bugs
in their huge pointer implementations. In retrospect, its a wonder
anything actually worked in DOS...
Greg Menke
Greg Menke <··········@toadmail.com> writes:
> Nils Goesche <···@cartan.de> writes:
>
> >
> > By some grace of fate, I never had to write any programs for DOS.
> > But I imagine that in an architecture where pointers consist of a
> > segment and offset part, two pointers that compare equal could
> > very well yield different values when casted to int.
>
> It was moderately evil, particularly when incrementing a pointer
> across a buffer. If I recall correctly, incrementing the pointer
> affected the offset only until it rolled over, then the segment was
> incremented. This would lead to the failure of a == test between the
> incremented pointer against another pointer known to be set to the
> same address- simply because the seg:offsets of both pointers ended up
> different. Casting a seg:offset pointer to a long int would put the
> segment into the upper 16 bits and the offset into the lower. I don't
> remember if casting a 16 bit pointer to a long would pick up the app's
> DS into the upper 16 bits or not.
IIRC, it didn't, on Borland at least. Wow, I hadn't thought about
*this* in a long time. I remember writing rather convoluted functions
and APIs where the unifying theme was avoiding checking for pointer
equality. What a long way I've come :)
> The problem was more or less addressed by a "huge" pointer type- which
> was still a 32 bit quantity. The C compiler normalized huge pointers
> after every update by shifting all but the lowest 4 bits of the offset
> into the segment, reducing pointer "synonyms" to bit-wise equality.
> It added a bit of overhead, but was often necessary.
>
> Naturally (IIRC) both Microsoft and Borland compilers had various bugs
> in their huge pointer implementations. In retrospect, its a wonder
> anything actually worked in DOS...
And, naturally, they were different bugs, so linking was ... uh,
"fun". My old policy under DOS was that if it absolutely had to work
correctly, I absolutely had to write it in assembler. Ick.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@hana.shimizu-blume.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > > <········@shimizu-blume.com> wrote:
> > >
> > > > ···@jpl.nasa.gov (Erann Gat) writes:
> > > >
> > > >
> > > > > The only invariant that I need to
> > > > > assume to make my point [ ... ] is that [ in C ] casting [
> pointers ] to int
> > > > > preserves equality.
> > > >
> > > > But it doesn't.
> > >
> > > Then I have three questions for you:
> > >
> > > 1. In how many existing C compilers does casting pointers to int not
> > > preserve equality?
> >
> > How many C compilers exist?
>
> No, the answer is "zero." Read the question again carefully.
Right. Sorry. I got the sense of your question reversed.
> > What does this have to do with anything?
>
> You claimed that "it [C] doesn't" preserve equality when casting pointers
> to ints.
C (the standard) does not say anything about whether or not equality
is preserved. Anyone who writes code relying on preservation of
equality makes a (reasonable) assumption about C implementations,
which nonetheless is not mandated by the standard.
> The only sense in which this statement comes even remotely close
> to being true is that this behavior is not required by the standard.
Right. That's precisely what I was talking about. I am not talking
about what reasonable people expect from a C implementation, I am
talking about how far a stardard-conforming implementation could deviate
from that expectation.
> But
> likewise the Lisp standard does not require (car (cons 5 4)) to be 5.
But it states precisely under which circumstances it is and under
which it isn't (and, in the latter case, states what other result you
would get). There is a big difference between these two.
> it is likewise wrong to say that free() is
> allowed to do nothing simply because the standard does not provide a
> definition of the word "available.")
There is at least one implementation of malloc/free that I am aware of
where, indeed, "free" does nothing. And yet, the implementation is
useful (even highly so), and it does not require infinite amounts of
memory. (I leave it to you to guess how it works.)
In any case, the word "available" is highly ambiguous, no matter what
Webster's has to say about it. Under a very reasonable interpretation
of "available" ("A memory region is available at a point of a
program's execution if there is a call of an allocation primitive
that, if it were to occur at this point, returns all or part of that
region as its result (or part of that result).") there are perfectly
fine implementations of malloc/free (where "free" does more than
nothing) in which a call to "free" does not necessarily result in the
free'd region to be "available" in the above sense.
Ok, I really drop the topic here. If you are interested in further
discussing this, send me e-mail.
Matthias
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> There is at least one implementation of malloc/free that I am aware of
> where, indeed, "free" does nothing.
I presume you're referring to the Boehm conservative GC?
> And yet, the implementation is useful (even highly so),
Indeed. But it does not conform to the standard. (The conclusion I draw
from this is that the standard is badly designed.)
> In any case, the word "available" is highly ambiguous, no matter what
> Webster's has to say about it.
It is no more ambiguous than any other English word.
> Under a very reasonable interpretation
> of "available" ("A memory region is available at a point of a
> program's execution if there is a call of an allocation primitive
> that, if it were to occur at this point, returns all or part of that
> region as its result (or part of that result).") there are perfectly
> fine implementations of malloc/free (where "free" does more than
> nothing) in which a call to "free" does not necessarily result in the
> free'd region to be "available" in the above sense.
They may be "perfectly fine" but they do not conform to the standard.
The Boehm GC, for example, will not actually make a memory region
"available" unless it can't find any potential pointers into that region.
This may be "perfectly fine", but it violates both the letter and the
spirit of the C standard. (The conclusion IMO is that C is badly designed
in this regard.)
E.
From: Duane Rettig
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <4u1lrmpyo.fsf@beta.franz.com>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@hana.shimizu-blume.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > > <········@shimizu-blume.com> wrote:
> > >
> > > > ···@jpl.nasa.gov (Erann Gat) writes:
> > > >
> > > >
> > > > > The only invariant that I need to
> > > > > assume to make my point [ ... ] is that [ in C ] casting [
> pointers ] to int
> > > > > preserves equality.
> > > >
> > > > But it doesn't.
> > >
> > > Then I have three questions for you:
> > >
> > > 1. In how many existing C compilers does casting pointers to int not
> > > preserve equality?
> >
> > How many C compilers exist?
>
> No, the answer is "zero." Read the question again carefully.
This may have no bearing on the current discussion, since I think I
understand what you mean by "equality" here. But way back in the
erly '80s, I worked on HP-1000 minicomputers with RTE-IVb operating
system, and the company I worked for bought HPC from a third party.
The interesting thing about the HP-1000 architecture was that there
were two addressing modes - byte and "word" (a word being 16 bits).
Except for byte pointers, addresses were word-pointers, and thus
casting a (char*) to an (int*) or vice versa always resulted in a
shift.
Again, this has nothing to do with the current question of what
{ int *p; [ ... ] printf( "%d\n", (int) p == (int) p); }
prints, because the operations are equivalent. But it does make
a difference in what
( int *p; [ ... ] printf( "%x %x\n", (int)p, (int)(char *)p); }
would print.
I only mention this because I believe that had the C spec been any
more explicit about pointer relationships so as to resolve your
question, then C would also not have been port-able to the HP-1000
architecure.
To bring us back on-topic to the ng, aren't yo glad that CL isn't
bothered by such vaguenesses? :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> I only mention this because I believe that had the C spec been any
> more explicit about pointer relationships so as to resolve your
> question, then C would also not have been port-able to the HP-1000
> architecure.
That's clearly not true. It might not have been portable with a naive
implementation of pointers, but it certainly would have been portable
(unless there's something you haven't told us about the HP-1000 that made
it not Turing equivalent).
> To bring us back on-topic to the ng, aren't yo glad that CL isn't
> bothered by such vaguenesses? :-)
Indeed!
E.
Matthias Blume <········@shimizu-blume.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>
> > The only invariant that I need to
> > assume to make my point [ ... ] is that [ in C ] casting [ pointers ] to int
> > preserves equality.
>
> But it doesn't.
FWIW, C99 has intptr_t and uintptr_t:
# 7.18.1.4 Integer types capable of holding object pointers
#
# 1 The following type designates a signed integer type with the
# property that any valid pointer to void can be converted to
# this type, then converted back to pointer to void, and the
# result will compare equal to the original pointer:
#
# intptr_t
#
# The following type designates an unsigned integer type with the
# property that any valid pointer to void can be converted to
# this type, then converted back to pointer to void, and the
# result will compare equal to the original pointer:
#
# uintptr_t
However:
# These types are optional.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
From: Andreas Eder
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <m3ptwhrchg.fsf@elgin.eder.de>
···@jpl.nasa.gov (Erann Gat) writes:
> But be that as it may, here's a modified example that conforms to the
> letter of the law:
>
> int f() {
> void* p;
> int x;
>
> p = malloc(10);
> x = (int)p;
> free(p);
> p = malloc(10);
> return x == (int)p;
> }
Well it may conform, but its behaviour is implementation-defined (not
undefined)! So, what happens depends on the specific
implementation. This is definitely not a portable ANSI C program (I
don't know about C99) and depending on the implementation anything
could happen. (I remember yery well an actual implementation that
tried to start the rogue program if you did things like that :-) )
'Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
In article <··············@elgin.eder.de>, Andreas Eder
<············@t-online.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > But be that as it may, here's a modified example that conforms to the
> > letter of the law:
> >
> > int f() {
> > void* p;
> > int x;
> >
> > p = malloc(10);
> > x = (int)p;
> > free(p);
> > p = malloc(10);
> > return x == (int)p;
> > }
>
> Well it may conform, but its behaviour is implementation-defined (not
> undefined)! So, what happens depends on the specific
> implementation.
Yes, that is in fact the point I was trying to make (though my focus was
on the implementation-dependent behavior of free(), not the
implementation-dependent behavior of casting pointers to ints.) The point
I was trying to make, which has been apparently lost in all the noise, is
that 1) the two calls to malloc may (or may not) return different pointers
despite the intervening call to free and 2) if the two pointers are
different, that in and of itself does *not* mean that the free'd memory is
"unavailable" because the possibility remains that it will be allocated at
some future time (or perhaps the block of memory allocated by the second
malloc overlaps the first block partly but not completely.)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> [ ... ] 2) if the two pointers are
> different, that in and of itself does *not* mean that the free'd memory is
> "unavailable" because the possibility remains that it will be allocated at
> some future time [ ... ]
This could also mean that it wasn't "free" that made this memory
"available". Maybe at the point of the second malloc there was *no*
possibility at all of getting this memory back via malloc and friends.
So was it "available" then (at this point). I'd say: no.
(One can view the the entire sequence of memory-management operations
leading up to the allocation that eventually managed to grab it again
as being responsible for that. It is not just the work of "free" alone.)
M.
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > [ ... ] 2) if the two pointers are
> > different, that in and of itself does *not* mean that the free'd memory is
> > "unavailable" because the possibility remains that it will be allocated at
> > some future time [ ... ]
>
> This could also mean that it wasn't "free" that made this memory
> "available". Maybe at the point of the second malloc there was *no*
> possibility at all of getting this memory back via malloc and friends.
If so then that would not be a conforming implementation. The only
circumstance under which that would be relevant is if those free'd bytes
were the *only* available memory left. In that case, a conforming malloc
would have to allocate them.
p = malloc(10);
if (p) {
free(p);
p = malloc(10);
if (p == NULL)
printf("My implementation of free() does not conform to the C standard");
}
E.
[Darn. I am going to break my word again...]
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@hana.shimizu-blume.com>, Matthias Blume
> <········@shimizu-blume.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > [ ... ] 2) if the two pointers are
> > > different, that in and of itself does *not* mean that the free'd memory is
> > > "unavailable" because the possibility remains that it will be allocated at
> > > some future time [ ... ]
> >
> > This could also mean that it wasn't "free" that made this memory
> > "available". Maybe at the point of the second malloc there was *no*
> > possibility at all of getting this memory back via malloc and friends.
>
> If so then that would not be a conforming implementation.
That sounds like definite nonsense to me. Or are you saying that: At
the point after free(p) returns there must exist a number n (of type
size_t) so that a call of malloc(n) (at this very program point when
free(p) has just completed) returns a memory region that wholly or
partially includes the region that had been pointed to by p before the
call of free(p)? I didn't think so.
And in the case that there is no such n at the point when free(p) has
just returned, then the memory that had been pointed to by p is *not*
available. It might become available after the next call of malloc --
perhaps because that call pops another piece of memory out of the
bucket that also holds p, thus "uncovering" p and making it truly
"available" for allocation. In any case, according to my
understanding of what "available" means (namely that something is
"available" if there is a way of getting it), the memory region is
*not* necessarily "available" right after free has returned. I don't
think that the C standard guys meant to rule out such an
implementation. (Of course, I could just walk two offices down the
hall and ask to be sure... :-)
By the way, here is one axiom that I would require to hold for "free":
"If p points to a memory region of size n, then at the point after a
call of free(p) has just returned, any call of malloc(m) with 0 < m <= n
must succeed."
(Of course, this still makes the Boehm-Weiser collector illegal.)
In a real standard, one could (and probably should) strengthen this in
some way to account for "composition" effects where more than one
malloc/free is involved, taking into account more than just one point
of a program's execution.
> The only circumstance under which that would be relevant [ ... ]
See, this is the problem: I am not talking about "relevant" etc. I am
talking about what the C standard says (and what it doesn't). As far
as relevance is concerned, you are almost certainly right.
M.
PS: Follow-up redirected to a more appropriate forum (which I don't
read, though).
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > <········@shimizu-blume.com> wrote:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > > > [ ... ] 2) if the two pointers are
> > > > different, that in and of itself does *not* mean that the free'd
memory is
> > > > "unavailable" because the possibility remains that it will be
allocated at
> > > > some future time [ ... ]
> > >
> > > This could also mean that it wasn't "free" that made this memory
> > > "available". Maybe at the point of the second malloc there was *no*
> > > possibility at all of getting this memory back via malloc and friends.
> >
> > If so then that would not be a conforming implementation.
>
> That sounds like definite nonsense to me.
Don't confuse nonsense with being wrong. They are not the same thing.
> Or are you saying that: At
> the point after free(p) returns there must exist a number n (of type
> size_t) so that a call of malloc(n) (at this very program point when
> free(p) has just completed) returns a memory region that wholly or
> partially includes the region that had been pointed to by p before the
> call of free(p)? I didn't think so.
That is indeed *not* what I'm saying.
What I am saying is that an implementation in which after a call to free
there was "no possibility at all of getting this memory back via malloc"
would not be a conforming implementation.
The particular corner case where this would manifest itself is if there
were no free memory left except for the bytes most recently free'd.
> By the way, here is one axiom that I would require to hold for "free":
> "If p points to a memory region of size n, then at the point after a
> call of free(p) has just returned, any call of malloc(m) with 0 < m <= n
> must succeed."
> (Of course, this still makes the Boehm-Weiser collector illegal.)
Yes. This is precisely the point I was trying to make.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > > int f() {
> > > void * p1 = malloc(10);
> > > free(p1);
> > > void * p2 = malloc(10);
> > > return p1 == p2;
> > > }
> >
> > IIRC, this program is in violation of the standard.
>
> You know, Matthias, I make it a point to read everything you post to
> c.l.l. and c.l.s. because 99% of the time what you have to say is
> worthwhile and I learn a lot. But in this case I am becoming convinced
> that you don't really have a point to make here and are just intentionally
> being a jerk. This is legal C++ code, and it takes no great leap of the
> imagination to render it into legal C.
I may be a jerk (it is not for me to decide this), but the program is
not legal in either C++ or C. (Unfortunately, with C and C++, just
because a compiler accepts it does not mean that a program is legal.
(Actually, I am not sure what the C++ standard has to say about this.
But I am pretty certain that it is not legal C because of the
reference to p1 after it had been sent to "free".))
> > I very highly doubt that the letter of the standard requires this.
> > (Otherwise, prove it!)
>
> It's an informal standard so I can't "prove" anything about it in the way
> that you probably mean here. But again, your doubt is irrelevant. The
> way you "prove" this is to write a malloc/free implementation that doesn't
> have this property and see if people accept it.
Sure. I don't dispute this at all. But this just means that what a C
implementation can or cannot do is highly driven by customer demand
and expectation, not by what the "standard" says. At the point where
I (unfortunately) jumped into this discussion, someone was making a
claim about the "standard" requiring something or the other. Had the
same person said that user expectation requires this same something or
other, I would never raised my voice.
> BTW, there's a fine illustration of the slipperiness of even formal
> standards in a recent thread on c.l.s. that you yourself were involved in
> regarding the semantics of (call/cc (lambda (c) (0 (c 1)))). The formal
> semantics say unambiguously (once you go through the considerable trouble
> to work it out) that the value of this expression in Scheme is 1.
> Nonetheless, many Scheme implementations signal an error. The debate over
> which of these behaviors is "correct" raged on for weeks and was never
> resolved.
Actually, Erann, it was resolved. There was nobody who claimed that
the current standard would rule the above expression illegal or would
leave any doubt about its semantics. (This discussion raged, sure
enough, but that was about something quite different.)
In article <··············@hana.shimizu-blume.com>, Matthias Blume
<········@shimizu-blume.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > > int f() {
> > > > void * p1 = malloc(10);
> > > > free(p1);
> > > > void * p2 = malloc(10);
> > > > return p1 == p2;
> > > > }
> > >
> > > IIRC, this program is in violation of the standard.
> >
> > You know, Matthias, I make it a point to read everything you post to
> > c.l.l. and c.l.s. because 99% of the time what you have to say is
> > worthwhile and I learn a lot. But in this case I am becoming convinced
> > that you don't really have a point to make here and are just intentionally
> > being a jerk. This is legal C++ code, and it takes no great leap of the
> > imagination to render it into legal C.
>
> I may be a jerk (it is not for me to decide this), but the program is
> not legal in either C++ or C. (Unfortunately, with C and C++, just
> because a compiler accepts it does not mean that a program is legal.
> (Actually, I am not sure what the C++ standard has to say about this.
> But I am pretty certain that it is not legal C because of the
> reference to p1 after it had been sent to "free".))
No. What makes the original code snippet illegal C (and legal C++) is the
declaration of p2 following the call to free. In C all declarations must
precede any statement. C++ can interleave statements and declarations.
In neither case does the reference to a free'd pointer make it illegal
code. At worst, the effects of "using" a free'd pointer are "undefined."
But "using" a pointer can be reasonably interpreted to mean
"dereference". In no case does this result in illegal code.
E.
From: Ziv Caspi
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3d5e1a04.82117989@newsvr>
On Fri, 16 Aug 2002 23:23:34 -0700, ···@jpl.nasa.gov (Erann Gat)
wrote:
[...]
>In neither case does the reference to a free'd pointer make it illegal
>code. At worst, the effects of "using" a free'd pointer are "undefined."
>But "using" a pointer can be reasonably interpreted to mean
>"dereference". In no case does this result in illegal code.
This is not true. "Using a pointer" also means reading its value. An
implementation is allowed to the second line below as an error:
free( p );
if ( p == p ) p = p;
See, for example the C FAQ
(http://www.eskimo.com/~scs/C-faq/q7.21.html) and the C Rationale
(http://www.lysator.liu.se/c/rat/c2.html#3-2-2-3).
Ziv
Matthias Blume <········@shimizu-blume.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@hana.shimizu-blume.com>, Matthias Blume
> > <········@shimizu-blume.com> wrote:
> >
> > > Sorry, Erann, but I highly doubt that a definition of this phrase good
> > > enough to stand up to the rigor of PL semantics can be found in
> > > Webster's.
> >
> > Sorry, Matthias, but your doubt is irrelevant. Whenever you write
> > anything in English (as the C standard is) the semantics bottom out in the
> > dictionary. You may not like it, but that's the way it is.
>
> That's the problem with all semantics that are being specified in
> English: they are inherently ambiguous.
Yes, that's right. But it doesn't matter.
> > Unless you have an infinite amount of memory it would violate both the
> > letter and the spirit, because it would eventually run out of fresh
> > memory, at which point it would have no choice but to allocate free'd
> > memory. If it didn't then that memory would not be "available", in
> > violation of the standard.
>
> That it false. "Available" could also mean that there is at least one
> allocation/deallocation sequence that causes the memory in question to
> be reused for allocation. But that one sequence does not have to be
> any of the ones that your program uses. In fact, there are many C
> programs that will eventually run out of memory using typical
> malloc/free implementations even though the malloc request that ends
> up failing asks for no more memory than what is currently "available".
> In fact, in typical flat address spaces, allocation of n bytes can fail
> even though Omega(n^2) bytes are "available". (Work it out!)
That's right, too. But it doesn't matter, either.
> > There is nothing in either the letter of the spirit of the standard that
> > requires the following function to return 1:
> >
> > int f() {
> > void * p1 = malloc(10);
> > free(p1);
> > void * p2 = malloc(10);
> > return p1 == p2;
> > }
>
> IIRC, this program is in violation of the standard.
That's right, too, and it does matter :-) In this case, it is pretty
easy to derive from the standard that the behavior of return p1 == p2;
is undefined (although this statement sounds somewhat funny).
> > but both the letter and the spirit of the standard require this snippet to
> > run forever (assuming no multiprocessing):
> > void f() {
> > void *p;
> > while (1) {
> > p = malloc(10);
> > if (!p) return;
> > free(p);
> > }
> > }
>
> I very highly doubt that the letter of the standard requires this.
> (Otherwise, prove it!)
You're right, it doesn't require it, but it doesn't matter again.
You can't use the standard quotation in question to derive definite
answers like this, that's right. But that doesn't mean that the
snippet is meaningless.
You remind me of a mathematician reading a physics textbook or paper
with the eyes of a mathematician. Whenever he sees that some
physicist differentiates a function, his first thought is ``where did
he say this function is differentiable?''. When the physicist
differentiates again, he asks ``where did he say it was even C^2''?
If the physicist computes the Fourier transform of a function he asks
``Wow, there are a million different spaces with a Fourier transform,
which one is he using? Jeez, now he is assuming the inverse
transformation can be applied; what a freak. Is he working in L^2?
Ah, apparently he thinks he can exchange the limes and the integral
sign. Enough now, I'll write him a letter explaining in all detail
why all of his theories stink, and will make sure to provide him with
counterexamples for /every single step/ he does in this paper! That
will teach him a lesson!''
Unfortunately, the physicist will not appreciate the helpful letter.
Actually, there is no problem at all with the physicist's
mathematics. There /is/ a problem with the understanding of our
/mathematician/, who hasn't understood that this physicist is not
doing mathematics but physics. His /objectives/ are totally
different. Using mathematics is only a means for him to achieve his
real goal, which is to derive statements about the real world. Of
course he is aware of the fact that mathematicians can come up with
freaky counterexamples for lots of things, but his pragmatic reply is:
``Jeez, just make some _reasonable assumptions_ about my functions
that rule out your stupid monster examples and try to understand what
I am actually driving at!''
And this is exactly what reasonable mathematicians do who aren't
utterly ignorant w.r.t. physics and the real world in general: They
are aware of the fact that physicists simply aren't interested in
writing mathematical papers. So, as it is nevertheless interesting
what physicists do mathematically, there is a branch of mathematics
that tries to find those ``reasonable assumptions'' that would render
the physicist's mathematics correct even to our mathematician's eye.
Often, whole new mathematical theories have to be invented to make it
work. Sometimes, these new theories even prove useful to physicists,
and they'll use them, too, in the future (usually after one or two
generations).
So, saying ``The C standard sucks because it is full of ambiguities
and even relies on something as wishy-washy as natural language.'' not
only means getting on everybody's nerves by stating a triviality
everybody knows, it is neither helpful to anybody nor constructive in
any way. Yes, if theorists like you find out ways how to write
standards for real-world languages that are less ambigious, without
being as impenetrable for non-mathematicians as the SML definition,
people will gladly accept them. But if that requires to use totally
different languages whose major design goal is to produce neatly
looking denotational or whatever semantics, people wouldn't be as
happy anymore ;-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3y9b6u3py.fsf@cley.com>
* Nils Goesche wrote:
> Unfortunately, the physicist will not appreciate the helpful letter.
> Actually, there is no problem at all with the physicist's
> mathematics. There /is/ a problem with the understanding of our
> /mathematician/, who hasn't understood that this physicist is not
> doing mathematics but physics. His /objectives/ are totally
> different. Using mathematics is only a means for him to achieve his
> real goal, which is to derive statements about the real world. Of
> course he is aware of the fact that mathematicians can come up with
> freaky counterexamples for lots of things, but his pragmatic reply is:
> ``Jeez, just make some _reasonable assumptions_ about my functions
> that rule out your stupid monster examples and try to understand what
> I am actually driving at!''
This is one of the best articles I've read in cll for a long time.
Sometimes even threads as dire as this one will result in gems like
this: thanks.
Everyone who cares about programming should understand the culture
that drives physics, and why it is so brilliantly successful. C and
Common Lisp are both languages defined the physics way, and it's a
*good* way of defining language. Of course it's not the only way (no
one claims it is), but the formal semantics way of defining languages
is *definitely* not the only way, despite what it's adherents might
think, and it's also not empirically a very successful way.
There's a story about theoretical physicists, who can be read here as
almost-mathematicians:
A theoretical physicist was asked to compute the stability of an
ordinary, four-legged table. He rapidly arrived at preliminary
results concerning the stability of zero- and one-legged tables,
and of those with an infinite number of legs. He spent the rest
of his life trying to arrive at a general result for the stability
of a table with an arbitrary, finite number of legs.
(of course, the mathematician would have been stressing about
whether the infinite number of legs was countable or not.)
--tim
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3hehuu32p.fsf@cley.com>
* Nils Goesche wrote:
> Unfortunately, the physicist will not appreciate the helpful letter.
> Actually, there is no problem at all with the physicist's
> mathematics. There /is/ a problem with the understanding of our
> /mathematician/, who hasn't understood that this physicist is not
> doing mathematics but physics. His /objectives/ are totally
> different. Using mathematics is only a means for him to achieve his
> real goal, which is to derive statements about the real world. Of
> course he is aware of the fact that mathematicians can come up with
> freaky counterexamples for lots of things, but his pragmatic reply is:
> ``Jeez, just make some _reasonable assumptions_ about my functions
> that rule out your stupid monster examples and try to understand what
> I am actually driving at!''
This is one of the best articles I've read in cll for a long time.
Sometimes even threads as dire as this one will result in gems like
this: thanks.
Everyone who cares about programming should understand the culture
that drives physics, and why it is so brilliantly successful. C and
Common Lisp are both languages defined the physics way, and it's a
*good* way of defining language. Of course it's not the only way (no
one claims it is), but the formal semantics way of defining languages
is *definitely* not the only way, despite what its adherents might
think, and it's also not empirically a very successful way.
There's a story about theoretical physicists, who can be read here as
almost-mathematicians:
A theoretical physicist was asked to compute the stability of an
ordinary, four-legged table. He rapidly arrived at preliminary
results concerning the stability of zero- and one-legged tables,
and of those with an infinite number of legs. He spent the rest
of his life trying to arrive at a general result for the stability
of a table with an arbitrary, finite number of legs.
(of course, the mathematician would have been stressing about
whether the infinite number of legs was countable or not.)
--tim
From: Erik Naggum
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3238507745602043@naggum.no>
* Matthias Blume
| That's the problem with all semantics that are being specified in
| English: they are inherently ambiguous.
No, that is not the problem. If they were /inherently/ ambiguous, that
would imply that the writer meant several things at the same time. Such is
normally not the case with specifications, which are neither poetry nor
puns. That only one things is meant is pretty darn obvious. Therefore, the
ambiguity is found in the reader's intent to find it.
What we cannot do, is write such that nobody, given enough energy, could not
find that it could also mean something other than what you intended. Some
people on news make this a sport, thinking that it shows their intellectual
prowess to first find the intended meaning and then hunt for a second
meaning that would be idiotic to hold, in order to pretend that this is the
writer's fault. Be advised that you are up against one such semantic game
artist.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Matthias Blume <········@shimizu-blume.com> writes:
> by a subsequent allocation. An allocator that makes memory
> "avaliable" but then "chooses" to always return fresh memory anyway,
> ignoring all that "available" memory returned via "free", would
> probably not violate the letter (although perhaps the spirit) of the C
> standard.
Possibly not even the spirit. On a machine that supports virtual
memory, we could malloc, free, then malloc again and get what looks
like fresh storage (at a different virtual address) that came from the
same physical bank of chips that we were previously using. The
program would have no way to tell it wasn't fresh, and we're still not
"leaking memory in free"
For that matter, suppose malloc() calls mmap() and free() calls
munmap(). Chances are that everything you allocate will the same
physical pageful of zeroes anyway until you start wriing to it. How
do you tell whether this is happening? Why do you need to?
I am deliberately ignoring the additional fun that can be had here
from considering the effects of a hierarchical memory system (cache,
dram, disk-based vm). Exercise for the reader ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Nils Goesche <······@cartan.de> writes:
> Matthias Blume <········@shimizu-blume.com> writes:
>
> > Nils Goesche <···@cartan.de> writes:
> >
> > > Brian Palmer <·······@leland.stanford.edu> writes:
> > >
> > > > 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''.
> >
> > Where does it say what it means to be "available for allocation"?
>
> Nowhere, I think. The authors of the C standard (and other standards)
> generally assume that their document isn't read by people whose goal
> it is to implement the worst possible C compiler permitted by the
> spec.
Sure. But this does not mean that the above paragraph says "more than
nothing". It simply means that the C standard seems to rely on
unwritten assumptions on what would be a "worst possible"
implementation. In fact, I can think of many things that would make a
C implementation even worse, so just ruling out "worst possible" would
not nail down what "free" has to do. Or are you saying that the
authors of the C standard generally assume the "best possible C
compiler permitted by the spec"? I didn't think so.
> For the same reason, it is unnecessary to mention that a Lisp
> implementation better had a garbage collector. IIRC, The Definition
> of Standard ML doesn't make that requirement, either.
That is right. And some ML implementations get away with having (well
almost) no garbage collector. (They are not the worst either.)
Matthias Blume <········@shimizu-blume.com> writes:
> Nils Goesche <······@cartan.de> writes:
>
> > Matthias Blume <········@shimizu-blume.com> writes:
> >
> > > Where does it say what it means to be "available for allocation"?
> >
> > Nowhere, I think. The authors of the C standard (and other standards)
> > generally assume that their document isn't read by people whose goal
> > it is to implement the worst possible C compiler permitted by the
> > spec.
>
> Sure. But this does not mean that the above paragraph says "more
> than nothing". It simply means that the C standard seems to rely on
> unwritten assumptions on what would be a "worst possible"
> implementation.
That's right. It does not even try to be a mathematical document with
mathematical rigor as, e.g. the ML definition. There are lots of
questions about C you could ask that not even the people in comp.std.c
are able to give a definite answer to (or at least agree on one ;-).
It just isn't written for mathematicians who haven't learned that
there are compromises in the real world. Rather, if the next C
standard was written in DS, I'd expect people other than you or me who
like to read such things to become very upset :-) (And I guess I
wouldn't like it, either. Mathematically defining this complicated
language would probably be much too wordy).
You can have very long debates about whether an expression like
p = p->q = NULL;
invokes undefined behavior or not, but C programmers don't really
care, nor do implementors, nor do I: You do something reasonable, with
the standard as a guide. I'd see at first glance that this expression
is somewhat questionable, so, as a programmer, I'd not use it. As an
implementor, I'd make it work, anyway. Debating about whether the
standard explicitly allows or disallows this is a funny recreational
exercise, but not more. There will always be questions like this
(about C).
> In fact, I can think of many things that would make a C
> implementation even worse, so just ruling out "worst possible" would
> not nail down what "free" has to do. Or are you saying that the
> authors of the C standard generally assume the "best possible C
> compiler permitted by the spec"? I didn't think so.
No, but they assume ``something reasonable'', I'd say :-)
> > For the same reason, it is unnecessary to mention that a Lisp
> > implementation better had a garbage collector. IIRC, The Definition
> > of Standard ML doesn't make that requirement, either.
>
> That is right. And some ML implementations get away with having (well
> almost) no garbage collector. (They are not the worst either.)
Let's say they're almost lacking :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Michael Sullivan
Subject: Standards and deliberately silly implementation (was Re: Question on using Scheme on Large Projects)
Date:
Message-ID: <1fgycjk.4i5cfm194biiaN%michael@bcect.com>
Nils Goesche <······@cartan.de> wrote:
> You can have very long debates about whether an expression like
> p = p->q = NULL;
> invokes undefined behavior or not, but C programmers don't really
> care, nor do implementors, nor do I: You do something reasonable, with
> the standard as a guide. I'd see at first glance that this expression
> is somewhat questionable, so, as a programmer, I'd not use it. As an
> implementor, I'd make it work, anyway. Debating about whether the
> standard explicitly allows or disallows this is a funny recreational
> exercise, but not more. There will always be questions like this
> (about C).
Personally, I have this odd little morbid fantasy about a C compiler
that actually inserts code to dial the red phone any time unquestionably
undefined behavior is invoked.
Michael, "I don't think you should do that, Dave"
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
From: Christopher Browne
Subject: Re: Standards and deliberately silly implementation (was Re: Question on using Scheme on Large Projects)
Date:
Message-ID: <ajgk4s$1bb3ag$1@ID-125932.news.dfncis.de>
In an attempt to throw the authorities off his trail, ·······@bcect.com (Michael Sullivan) transmitted:
> Nils Goesche <······@cartan.de> wrote:
>
>> You can have very long debates about whether an expression like
>
>> p = p->q = NULL;
>
>> invokes undefined behavior or not, but C programmers don't really
>> care, nor do implementors, nor do I: You do something reasonable, with
>> the standard as a guide. I'd see at first glance that this expression
>> is somewhat questionable, so, as a programmer, I'd not use it. As an
>> implementor, I'd make it work, anyway. Debating about whether the
>> standard explicitly allows or disallows this is a funny recreational
>> exercise, but not more. There will always be questions like this
>> (about C).
>
> Personally, I have this odd little morbid fantasy about a C compiler
> that actually inserts code to dial the red phone any time unquestionably
> undefined behavior is invoked.
I always like to point out the "electrodes in somebody's chair"
scenario, myself.
It doesn't have to be a _big_ shock; it doesn't much matter who it is
that _gets_ shocked, whether the programmer, user, some manager, or a
cute furry bunny sitting in a cage. None are likely to be
particularly palatable.
I normally bring up the scenario in a design meeting, when someone
says "that'll never happen" about some condition that I notice.
"OK, if that condition can't happen, then it's OK for me to put code
in that does absolutely heinous things if it does, right?"
They usually back off, at that point...
--
(concatenate 'string "chris" ·@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
Rules of the Evil Overlord #173. "Although it would provide amusement,
I will not confess to the hero's rival that I was the one who
committed the heinous act for which he blames the hero."
<http://www.eviloverlord.com/>
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3lm77x2mu.fsf@cley.com>
* Matthias Blume wrote:
> Or are you saying that the
> authors of the C standard generally assume the "best possible C
> compiler permitted by the spec"? I didn't think so.
No, however they probably assume that a number of implementations will
appear and the ones that are obviously crappy will either die out or
get better. Curiously that is what seems to happen in practice, as
anyone who compares, say, gcc, with some of (all of?) the pcc variants
will tell you.
--tim
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3ptx7bybf.fsf@cley.com>
* Brian Palmer wrote:
> 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
From: Paul F. Dietz
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3D4293DB.22077016@dls.net>
Hartmann Schaffer wrote:
> 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
Brian Palmer wrote
>
> 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."
Bob Bane <····@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 =)
--
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
Brian Palmer <·······@leland.stanford.edu> writes:
> Bob Bane <····@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.
>> 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.
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
Joel Ray Holveck asked how a standard could mandate garbage collection,
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
Brian Palmer wrote:
> 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
From: Kaz Kylheku
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ai5ak9$hvf$5@luna.vcn.bc.ca>
In article <···············@elaine0.Stanford.EDU>, Brian Palmer wrote:
> Nils Goesche <···@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.
Kaz Kylheku <···@ashi.footprints.net> writes:
> 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
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey31y9pa1hx.fsf@cley.com>
Newsgroups: comp.lang.lisp
Subject: Re: Question on using Scheme on Large Projects
References: <··················@newsread1.prod.itd.earthlink.net> <···············@octagon.mrl.nyu.edu> <··············@atom.amazingmedia.com> <···············@octagon.mrl.nyu.edu> <··············@atom.amazingmedia.com> <···············@octagon.mrl.nyu.edu> <··············@atom.amazingmedia.com> <···············@octagon.mrl.nyu.edu> <······························@bcect.com> <···············@cley.com> <······························@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
From: Kaz Kylheku
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ahuag4$4nj$2@luna.vcn.bc.ca>
In article <······························@bcect.com>, Michael Sullivan wrote:
> 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.
Only two small points:
·······@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.
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
--
Jens Axel S�gaard
"Jens Axel S�gaard" <······@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.
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. :)
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'.
Marco Antoniotti wrote:
> "Jens Axel S�gaard" <······@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
>>>>> "MA" == Marco Antoniotti <·······@cs.nyu.edu> writes:
MA> Benjamin Simon <···@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
Benjamin Simon <···@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> MA> Benjamin Simon <···@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.
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'.
>> 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.
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
On 29 Jul 2002 15:26:19 -0700, Joel Ray Holveck <·····@juniper.net> wrote:
> 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
Marco Antoniotti <·······@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 :-
> 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.
·······@dino.dnsalias.com (Stephen J. Bevan) writes:
> Marco Antoniotti <·······@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.
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'.
Marco Antoniotti <·······@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.
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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Marco Antoniotti <·······@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. :)
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'.
From: Hannah Schroeter
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ai6cas$3kc$1@c3po.schlund.de>
Hello!
Marco Antoniotti <·······@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.
>> 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?
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
Joel Ray Holveck <·····@juniper.net> wrote:
> It could be because the languages I use shape the way I think about
> 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 ····················@" "454aa"))
http://cbbrowne.com/info/lisp.html
VERITAS AETERNA -- DON'T SETQ T.
On 29 Jul 2002 16:55:33 -0700, ·········@becket.net (Thomas Bushnell, BSG)
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.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Marco Antoniotti <·······@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.
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.
·······@dino.dnsalias.com (Stephen J. Bevan) writes:
> Marco Antoniotti <·······@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.
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'.
Marco Antoniotti <·······@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.
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.
·······@dino.dnsalias.com (Stephen J. Bevan) writes:
> Marco Antoniotti <·······@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.
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'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> 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.
In an attempt to throw the authorities off his trail, ·······@dino.dnsalias.com (Stephen J. Bevan) transmitted:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>> 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.
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 wrote:
> In an attempt to throw the authorities off his trail,
> ·······@dino.dnsalias.com (Stephen J. Bevan) transmitted:
>> Marco Antoniotti <·······@cs.nyu.edu> writes:
>>> 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.
>
> 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...
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
--
http://www.dataheaven.de
Jochen Schmidt <···@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. 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.
Stephen J. Bevan wrote:
> Jochen Schmidt <···@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.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@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 :-)
> 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.
Stephen J. Bevan wrote:
> Jochen Schmidt <···@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?
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> 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.
On 30 Jul 2002 20:45:27 GMT, Christopher Browne <········@acm.org> wrote:
> - CL has CLIM, which I've never seen running, whilst it is common
In case you are interested, have a look at McCLIM, which has been doing a
lot of progress lately.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
·······@dino.dnsalias.com (Stephen J. Bevan) writes:
> 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 <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Craig Brozefsky <·····@red-bean.com> writes:
> ·······@dino.dnsalias.com (Stephen J. Bevan) writes:
> > 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 agree. However, that is a separate issue to the one I was addressing.
>>>>> "MA" == Marco Antoniotti <·······@cs.nyu.edu> writes:
MA> Benjamin Simon <···@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 <···@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <·······@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?
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 <···@atom.amazingmedia.com> writes:
> >>>>> "MA" == Marco Antoniotti <·······@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
Nils Goesche <······@cartan.de> writes:
> 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.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Nils Goesche <······@cartan.de> writes:
>
> > 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.
Ask Bjarne Stroustrup (sp?) -- his early versions of C++ worked that
way, AFAIK...
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Basile STARYNKEVITCH
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <q5rwurcxdy0.fsf@hector.lesours>
>>>>> "Nils" == Nils Goesche <······@cartan.de> writes:
Nils> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
Nicolas> Nils Goesche <······@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
Basile STARYNKEVITCH <·········@SPAM+starynkevitch.net.invalid> writes:
> >>>>> "Nils" == Nils Goesche <······@cartan.de> writes:
>
> Nils> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Nicolas> Nils Goesche <······@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.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey3adoap4g2.fsf@cley.com>
* Benjamin Simon wrote:
>>>>>> "MA" == Marco Antoniotti <·······@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'.
>>>>> "TB" == Tim Bradshaw <···@cley.com> writes:
TB> * Benjamin Simon wrote:
>>>>>>> "MA" == Marco Antoniotti <·······@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
From: Tim Bradshaw
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ey37kjdmsio.fsf@cley.com>
* 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?
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
>>>>> "TB" == Tim Bradshaw <···@cley.com> writes:
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
Benjamin Simon <···@atom.amazingmedia.com> writes:
> >>>>> "TB" == Tim Bradshaw <···@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).
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'.
From: Will Deakin
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3D47A048.5020304@hotmail.com>
Benjamin Simon wrote:
> TB> and posting news articles is a mistake.
>
> Yikes. I didn't realize I was that effective at arguing ;-).
(sigh)
:(w
From: Hannah Schroeter
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <ai6ce1$3kc$2@c3po.schlund.de>
Hello!
Tim Bradshaw <···@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.
From: Will Deakin
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <3D46B8D2.4030908@hotmail.com>
Hannah Schroeter wrote:
> 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)
Are you sure this would work?
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
The world rejoiced as Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Benjamin Simon <···@atom.amazingmedia.com> writes:
>> >>>>> "MA" == Marco Antoniotti <·······@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.
SICP doesn't comment on continuations, either, so I would not be
particularly inclined to draw many conclusions.
As far as I can see, the purpose of SICP is to use a pretty limited
subset of Scheme to teach about computer science.
A message that rings out pretty clearly is that the fact that so much
can be taught with so few abstractions. Note that it never mentions
arrays, or "structures/records," either.
Its main commentary on OO is actually fairly cautionary, in a footnote
that warns that OO isn't nearly what it's billed to be.
>> >> 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).
If it's in an accepted SRFI, then it's an at least moderately portable
extension.
>> 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.
Entertainingly enough, most of the MOP implementations in use in
Scheme have, as one of the co-authors, one of the co-authors of _The
Art of the Meta Object Protocol_.
There _are_ multiple implementations, much as there are CLOS
implementations that don't conform to MOP. Many of the object
implementations are based on the same code base, much as many CLOS
implementations are based on PCL.
Is it all joy and perfection? Things seldom are. The graphics
options for CL have a tendancy to be painful to make work, too. No
easy answers...
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/rdbms.html
"...Deep Hack Mode--that mysterious and frightening state of
consciousness where Mortal Users fear to tread." -- Matt Welsh
Benjamin Simon [on scheme, and object systems]:
> ... 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.
From: Kaz Kylheku
Subject: Re: Question on using Scheme on Large Projects
Date:
Message-ID: <aht5n9$nu4$1@luna.vcn.bc.ca>
In article <··············@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?
The answer is simple: because this is the year 2002, not 1982.
>>>>> "KK" == Kaz Kylheku <···@ashi.footprints.net> writes:
KK> In article <··············@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