CL & Practicality
Tuang
for real applications, and that Scheme is good for teaching
programming concepts but isn't very practical as a real production
platform.
Though I've often heard that claim repeated (by people who didn't seem
to have any particular axe to grind beyond just wanting to get real
work done), I've never heard anybody explain why they believe CL is
"more practical" than Scheme "for real applications".
I'm just learning both of them (CL primarily because of that claim and
Scheme just because that's the language used in SICP), and I don't yet
know enough about either for it to be obvious to me why CL is said to
be more practical.
Could anyone tell me what about CL makes it more practical, and also
whether the CL advantages apply to free implementations (of both CL
and Scheme) as well?
Thanks.
Adam Warner
> I've heard many times that Common Lisp is "more practical" than Scheme
> for real applications, and that Scheme is good for teaching programming
> concepts but isn't very practical as a real production platform.
>
> Though I've often heard that claim repeated (by people who didn't seem
> to have any particular axe to grind beyond just wanting to get real work
> done), I've never heard anybody explain why they believe CL is "more
> practical" than Scheme "for real applications".
Mainly it's that tonnes of extra functionality is portably defined in
Common Lisp (packages, Common Lisp Object System, more powerful macros,
extra data types, hash tables, multidimensional arrays, powerful
looping and formatting constructs, etc.) You can't even rely upon Scheme
implementations supporting, for example, exact rationals ("Implementations
of Scheme are not required to implement the whole tower of subtypes...").
> I'm just learning both of them (CL primarily because of that claim and
> Scheme just because that's the language used in SICP), and I don't yet
> know enough about either for it to be obvious to me why CL is said to be
> more practical.
>
> Could anyone tell me what about CL makes it more practical, and also
> whether the CL advantages apply to free implementations (of both CL and
> Scheme) as well?
The free CL implementations largely support the whole of ANSI Common Lisp:
<http://www.cliki.net/Common%20Lisp%20implementation>
There are numerous extensions to R5RS Scheme implementations that will
also improve their practicality. You will need to research how much this
could reduce the portability of your code.
Regards,
Adam
Ray Dillinger
If you write all of your own code, they are about equally practical.
But if you want to pull together code from a lot of different sources
and integrate them into a new project, CL wins hands down.
I like scheme because it's minimal. If I want objects, or message
contexts, or packages, or just about anything else, they are easy
to implement and I can make them do exactly what the particular
project needs. So I have access to all of that stuff without having
to carry around tedious lists of definitions from someone else's
code in my head. And obviously, if I'm writing all the code, it's
really easy for me to control the namespace; I know when to not
use a particular name, or in what contexts names can be reused.
With Common Lisp though, you have all that stuff - objects, packages,
modules, frameworks, and so on and so on -- predefined, which means
you have to memorize this huge arbitrary list of functions and API's
that other people defined, which may or may not be exactly the right
thing for what you're writing, and use them. But you can pull together
a bunch of code that other people wrote in Common Lisp a lot easier
than you can pull together a bunch of code that other people wrote in
scheme, because the CL guys didn't each roll their own object system,
packages, modules, etc. CLOS might not have been exactly optimal for
what each of them were doing, but when you come along after the fact
and take the code they wrote and put it together, it's nice to have
just one ojbect system. The packages and modules may not have been
exactly right for whatever they were doing, but when you're coming
along after the fact to put things together, it sure is nice that
everybody used the *same* package and module system; It minimizes
your hassles with compensating for other people's using names without
knowing what names were going to be used in other modules.
Common Lisp and Scheme are both like All-terrain vehicles; it's
just that Scheme is more like a dune-buggy or ATV and CL is more
like a bulldozer. The surveyors and explorers are going to go out
with light nimble vehicles that can handle the terrain and find
routes to problem solutions that exactly fit the needs of the problem.
But no two of them are likely to find exactly the same route, or to
be able to share substantial parts of the routes they find, except
that they will talk with each other about the terrain and features.
When civil engineers want to build roads they follow with earthmoving
equipment, which can also "handle" the terrain, although in a
different way, and create routes that are a lot easier for later
people to drive on or switch between.
Bear
Wade Humeniuk
For me practical means in CL,
1) Packages - reduces naming conflicts for functions, variables ...
2) Conditions - Practical code involves having good ways of dealing with
errors. The orthogonality of the condition/error system
seems to allow a good way of dealing with most errors.
3) Implementaions of CL are mature, complete and well thought out. Excellent
performance, A-1 garbage collection. 40+ years of history and development.
4) The orientation of the CL implementors in focusing on "practical" matters.
There are probably other things, but I try not to think about it too hard anymore.
Wade
Nils Goesche
> Could anyone tell me what about CL makes it more practical,
For one thing, it's bigger: There is simply more stuff you can
rely on to be present in a half-way conforming implementation.
Then, CL was /designed/ to be practically useful. Scheme was
designed to have as small a standard as possible, and to make
proving theorems about the language easier, and to make writing a
Scheme implementation a suitable assignment for CS sophomores.
To give just one example, think about what UNWIND-PROTECT does in
Common Lisp, why it's there and why Scheme doesn't have it.
> and also whether the CL advantages apply to free
> implementations (of both CL and Scheme) as well?
Sure.
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0
Nils Goesche
> Tuang wrote:
> >
> > Could anyone tell me what about CL makes it more practical,
> > and also whether the CL advantages apply to free
> > implementations (of both CL and Scheme) as well?
>
> If you write all of your own code, they are about equally
> practical.
No, that's not true, actually. I had thought so for a long time
myself, but then it dawned upon me that writing it all yourself
is /not/ an alternative, not even a theoretical one. That's
because that would presuppose that you /could/ redo it all
yourself if you wanted to. But if you believe that, you are
forgetting about the /decades/ of development and the /great/
number of extremely smart people who have been working on it
during all those decades to arrive at the form it has now. No,
rethinking all that and repeating all of their experience is
/not/ an option, not even a theoretical one!
Coby Beck
"Ray Dillinger" <be...@sonic.net> wrote in message
news:3F81B895...@sonic.net...
> Tuang wrote:
> >
> > I've heard many times that Common Lisp is "more practical" than Scheme
> > for real applications, and that Scheme is good for teaching
> > programming concepts but isn't very practical as a real production
> > platform.
> >
>
This could only make sense if you mean "if you reimplement everything for
yourself". If I use CLOS, I am still writing all my own code.
> I like scheme because it's minimal. If I want objects, or message
> contexts, or packages, or just about anything else, they are easy
> to implement and I can make them do exactly what the particular
> project needs.
With the extensibility and flexibility CL gives you, there is absolutely no
reason you can not have the best of both worlds.
> So I have access to all of that stuff without having
> to carry around tedious lists of definitions from someone else's
> code in my head. And obviously, if I'm writing all the code, it's
> really easy for me to control the namespace; I know when to not
> use a particular name, or in what contexts names can be reused.
You need to add to this that you must be working alone for any advantages of
reinventing wheels to come to fruition.
> With Common Lisp though, you have all that stuff - objects, packages,
> modules, frameworks, and so on and so on -- predefined, which means
> you have to memorize this huge arbitrary list of functions and API's
Why must you memorize it all? Get a book and learn how to use a reference.
Also, just because it is already defined doesn't mean you have to find and
use it. You can still implement it yourself. Doing this is often a
learning exercise and it is sometimes as fast as finding what you want.
Again, the best of both worlds, ie if you think it is an advantage to
implement everything yourself, what stops you in CL?
> Common Lisp and Scheme are both like All-terrain vehicles; it's
> just that Scheme is more like a dune-buggy or ATV and CL is more
> like a bulldozer. The surveyors and explorers are going to go out
> with light nimble vehicles that can handle the terrain and find
> routes to problem solutions that exactly fit the needs of the problem.
I disagree completely with this analogy.
Cheers,
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Marco Antoniotti
Ray Dillinger wrote:
> Common Lisp and Scheme are both like All-terrain vehicles; it's
> just that Scheme is more like a dune-buggy or ATV and CL is more
> like a bulldozer.
I like better a military analogy here.
Scheme is like the Norwegian Military (small and rather good at few
things), CL is like the US Military (big and good at everything)
(Nominations for "Language most similar to the Italian Military" are
accepted)
Cheers
--
Marco
Tuang
That sounds right to me. While in theory I could write all my own
libraries to do anything in any language, that would be a pretty
impractical basis for comparing tools, and my question is about the
practical advantage(s) of CL over Scheme for real (non-research)
software projects.
But then this brings up something I've frankly been wondering about.
It's my understanding (and I'm posting to have my understanding
corrected) that there are fewer than 1000 "operators" (I think they're
called) in Common Lisp. That's probably about twenty times as many as
there are in Scheme, but Java probably has more than twenty times as
many as Common Lisp, depending on what you consider to be the
equivalent of an operator.
If the major practical advantage of CL over Scheme is the large amount
of reusable, portable, free functions already built, debugged, and
tested by others, then wouldn't a Scheme based on Java be even more
practical than CL by that measure? (I realize that my original
question was CL vs. Scheme, not CL vs. Scheme/Java, but it's not an
academic or legalistic question. I'm looking for practicality for
general-purpose programming projects.)
One counter argument I can imagine would be performance. From what I
hear (and I'm mostly thinking about free implementations of all of
these), no Java can compete with CMUCL for performance, and I'd guess
that Scheme+Java would be even slower than pure Java (again, correct
me if I'm wrong). But then that changes the practicality argument for
CL from getting more functionality to giving up some pre-built
functionality (relative to a Scheme-on-Java) in exchange for higher
performance.
Nils Goesche
> But then this brings up something I've frankly been wondering
> about. It's my understanding (and I'm posting to have my
> understanding corrected) that there are fewer than 1000
> "operators" (I think they're called) in Common Lisp. That's
> probably about twenty times as many as there are in Scheme, but
> Java probably has more than twenty times as many as Common
> Lisp, depending on what you consider to be the equivalent of an
> operator.
Well, there are 978 external symbols in the "CL" package, the
meaning of whose is defined by the ANSI CL Standard. There is no
such thing as an ANSI Java Standard, so I think you should rather
compare this with the C or C++ Standard. Also, Common Lisp
functions can typically be used in much more flexible ways than,
say, `strcpy´, so I don't think even such a comparison would be
fair. Then, what you're actually using is an implementation, of
course, as you do in Java. When I fire up the one I use, I get
CL-USER 1 > (let ((syms (make-hash-table :test #'eq)))
(dolist (package (list-all-packages))
(do-external-symbols (sym package)
(setf (gethash sym syms) t)))
(hash-table-count syms))
15387
and by adding a few common libraries, I could crank up this
number a lot.
BTW, is there anything in Java now that lets you do something
like
printf("0x%02X", x);
? Last time I checked, I had to install some GNU library to be
able to do this...
Pascal Costanza
> It's my understanding (and I'm posting to have my understanding
> corrected) that there are fewer than 1000 "operators" (I think they're
> called) in Common Lisp. That's probably about twenty times as many as
> there are in Scheme, but Java probably has more than twenty times as
> many as Common Lisp, depending on what you consider to be the
> equivalent of an operator.
>
> If the major practical advantage of CL over Scheme is the large amount
> of reusable, portable, free functions already built, debugged, and
> tested by others, then wouldn't a Scheme based on Java be even more
> practical than CL by that measure? (I realize that my original
> question was CL vs. Scheme, not CL vs. Scheme/Java, but it's not an
> academic or legalistic question. I'm looking for practicality for
> general-purpose programming projects.)
Each language has its own "vision" of how things should be done. So Java
libraries are written with a Java mindset while Lisp libraries are
written with a Lisp mindset, and so on.
When you use a Scheme based on Java and rely on Java libraries, you are
actually mixing two different mindsets and this has the potential of
making some things harder than necessary. For example, in Lisp and
Scheme it is very natural to use lists as a data structure for many
tasks whereas in Java, vectors are the preferred container class, mostly
for historical reasons. This is just one example.
There are good reasons to use a Java-based Scheme, for example if you
want to script Java applications, or want to experiment with Java
libraries. However, you might not actually learn about the Lisp/Scheme
mindset.
Then there is an important difference between the Common Lisp and Scheme
mindset: In Scheme, there seem to be some unspoken rules about how
programs should be written. For example, recursion is strongly preferred
over iteration, higher-order functions are strongly preferred over
macros, and generally a functional programming style is strongly
preferred over object-oriented and imperative styles.
In the Common Lisp community, it is generally accepted that you can use
whatever is best to get your concrete job done. Some problems are best
solved with a functional approach, some with an object-oriented
approach, some with iteration, and so forth. This is reflected in the
ANSI Common Lisp standard: it integrates many different programming
paradigms and generally doesn't make judgements wrt to supposedly good
or bad programming style.
Of course, there are some usable and practical Scheme implementations
out there that also support a broad range of programming styles.
However, my impression is that Common Lisp is generally more open in
this regard, especially by providing these things out of the box.
Pascal
P.S.: Recently I have read a good quote: "You don't learn how to cook by
studying recipe quantities." ;)
Adam Warner
> That sounds right to me. While in theory I could write all my own
> libraries to do anything in any language, that would be a pretty
> impractical basis for comparing tools, and my question is about the
> practical advantage(s) of CL over Scheme for real (non-research)
> software projects.
>
> But then this brings up something I've frankly been wondering about.
> It's my understanding (and I'm posting to have my understanding
> corrected) that there are fewer than 1000 "operators" (I think they're
> called) in Common Lisp. That's probably about twenty times as many as
> there are in Scheme, but Java probably has more than twenty times as
> many as Common Lisp, depending on what you consider to be the equivalent
> of an operator.
You're conflating core language and core language+library issues but yes,
there are aspects of ANSI Common Lisp that could be improved through
portable definition of extra functionality (e.g. networking). Thus there
are a number of us who believe that ANSI Common Lisp is still too small
for optimum creation of portable code. De facto standards are helping to
fill in the gaps (e.g. BSD sockets).
Those who complain about the large size of the language are an amusement;
as are those who claim that the language should only provide one obvious
way to do something.
BTW it is just plain nonsense that Scheme should be the preferred option
for research/academic software projects instead of Common Lisp (at least
in all but a few well-defined areas, and even then defining a subset of
Common Lisp could be a suitable option).
> If the major practical advantage of CL over Scheme is the large amount
> of reusable, portable, free functions already built, debugged, and
> tested by others, then wouldn't a Scheme based on Java be even more
> practical than CL by that measure?
To obtain access to a wide set of de facto standard libraries this could
indeed be a reasonable approach. A Java Native Interface to Common Lisp
could also be a reasonable approach. I don't believe any is currently
available for a non-proprietary implementation of Common Lisp. Christopher
Double has made his JNI code for Corman Lisp freely available, which could
help if attempting to create your own interface:
<http://www.double.co.nz/cl/>
> (I realize that my original question was CL vs. Scheme, not CL vs.
> Scheme/Java, but it's not an academic or legalistic question. I'm
> looking for practicality for general-purpose programming projects.)
Lisp is also great for tackling the "hard" problems where library
availability will be the least of your concerns. I'll give you an example
how this can happen by accident. I have a numeric optimisation problem
that I thought was well-defined enough that Fortran would be a suitable
option, just for the raw speed. After a number of exploratory CMUCL
benchmarks I found CMUCL's general and floating point performance was good
enough when using appropriate declarations, non-descriptor representations
and block compilation to at least convince myself to use it for
exploratory work.
I later discovered I needed my functions to return multiple values to feed
hints to the custom optimiser. The return of multiple values is supported
by the language and CMUCL's "Python implements uses of multiple values
particularly efficiently. Multiple values can be kept in arbitrary
registers, so using multiple values doesn't imply stack manipulation and
representation conversion."
I've recently discovered that I need discrete, symbolic sets as a choice
option and I have to rewrite the optimiser to support this. Using macros I
may store the underlying representation of the symbolic sets as
non-descriptor arrays of types bit, (unsigned-byte 2), etc. if speed is
still an issue. I have also discovered that I need my agents to build
singly-linked lists of some decisions (in a way that it is not directly
amenable to representation as vectors).
Of course everything but the higher level abstractions could be achieved
in Fortran or any other (hopefully fast) general-purpose language. It's
just that the higher abstractions are important to be able to make
progress, debug the model and later be able to extend and rewrite the
model while still maintaining reasonable computational speed (and even in
places where CMUCL is poor, e.g. multidimensional arrays, I can build
macro abstractions upon one dimensional arrays).
> One counter argument I can imagine would be performance. From what I
> hear (and I'm mostly thinking about free implementations of all of
> these), no Java can compete with CMUCL for performance,
Some Java implementations are surprisingly fast for low-level
computations, I/O and (micro) benchmarks so this is a dangerous assumption
in general. But once you start using smart abstractions to hide complexity
and move computations to compile time you should be able to perform
convincingly better.
> and I'd guess that Scheme+Java would be even slower than pure Java
> (again, correct me if I'm wrong).
Not if you have a native implementation of Scheme or Lisp and interface to
Java (refer earlier comment).
> But then that changes the practicality argument for CL from getting more
> functionality to giving up some pre-built functionality (relative to a
> Scheme-on-Java) in exchange for higher performance.
What you've missed in this final comment is that Java is simply not as
practical for tackling hard problems that require a high level of
abstraction, and this is not a controversial characterisation. Java is for
"narrowly focused solutions that are tailored to a specific problem"
(Gilad Bracha, resident Computational Theologist at Sun Microsystems) and
attempts to improve the power of the language will be resisted: "I am
keenly aware of the drawbacks of such an approach, but I don't see it
changing very quickly."
<http://www.artima.com/weblogs/viewpost.jsp?thread=5246>
<http://groups.google.com/groups?selm=pan.2003.08.21.05.03.10.879996%40consulting.net.nz>
Tuang, the best way to discover the practicality of Common Lisp is to
begin coding.
Good luck,
Adam
Pierpaolo BERNARDI
"Marco Antoniotti" <mar...@cs.nyu.edu> ha scritto nel messaggio news:3kzgb.5$KR3...@typhoon.nyu.edu...
> (Nominations for "Language most similar to the Italian Military" are
> accepted)
Intercal. No contest.
P.
Tuang
> tuan...@hotmail.com (Tuang) writes:
>
> > But then this brings up something I've frankly been wondering
> > about. It's my understanding (and I'm posting to have my
> > understanding corrected) that there are fewer than 1000
> > "operators" (I think they're called) in Common Lisp. That's
> > probably about twenty times as many as there are in Scheme, but
> > Java probably has more than twenty times as many as Common
> > Lisp, depending on what you consider to be the equivalent of an
> > operator.
>
> Well, there are 978 external symbols in the "CL" package, the
> meaning of whose is defined by the ANSI CL Standard. There is no
> such thing as an ANSI Java Standard, so I think you should rather
> compare this with the C or C++ Standard.
I don't think that's quite an accurate portrayal of Java. No, there's
no ANSI standard, but there's something a lot more meaningful: a
proprietary "standard" that includes a test suite of thousands of
tests against which all Java implementations are tested. If they can't
pass all of the tests, they can't call themselves Java(r). (Of course
there are some controversial edge cases.) Imagine applying that
standard to Common Lisp or C++ before allowing them to use the name
"Lisp" or "C++".
(And, yes, I know how the circumstances are different.)
> Also, Common Lisp
> functions can typically be used in much more flexible ways than,
> say, `strcpy´, so I don't think even such a comparison would be
> fair.
Well, I don't think "strcpy" would be a good comparison, either. I
think the vast Java libraries exposed by some Scheme implementations
are more potentially useful.
> Then, what you're actually using is an implementation, of
> course, as you do in Java.
Calling Java an "implementation" instead of a "standard" is, again,
not a very useful way to think of it, unless your point is one of
control ("who controls the standard?") instead of practical
usefulness. From a practical standpoint, the fact that there are
*lots* of implementations out there that pass the rigorous compliance
test suite creates the *appearance* of there being only one Java
implementation.
I was thinking after I posted my question about Scheme+Java vs. CL for
practicality that CL has more going for it than just a performance
advantage. The built-in CL operators are really designed to do Lispy
things, while the Java libraries are designed with Java exclusively in
mind. I'm not sure how well they'll actually work in combination with
Scheme, in practice. It's not enough for them to be easily callable
from Scheme if most of them just don't match the style of programming
well enough to be very practical.
>
> BTW, is there anything in Java now that lets you do something
> like
>
> printf("0x%02X", x);
>
> ? Last time I checked, I had to install some GNU library to be
> able to do this...
There's no "printf" in Java, per se, but there are more verbose
approaches with a lot more control over formatting, i18n, etc. You
don't have to use GNU or other non-standard libraries. You can pass a
"formatter" to System.out.printline() or use something like
Integer.toHexString(myInt); to create the substrings and concatenate
them. Java's type checking doesn't allow for method signatures with an
unknown number of parameters.
The language that really did this well was C#. It has a special syntax
that allows for a flexible number of params without losing type
safety. You can get your printf, though it's called Writeline and it
has a much richer set of formatting symbols than I've seen in any
other language. (I haven't yet examined CL's "format", though.) For
example, you can say:
Console.WriteLine("{0:#0;(#0);<zero>}", i);
and it tells it how to format positive vals, negative vals, and zero
vals. All of the standard printf symbols are available, plus some new
ones, and more parameters for each.
Phil Greenspun recently commented that a Lisp built for the .Net
framework would entice him into becoming a code monkey again. I prefer
Linux servers, but having used C# and .Net a bit, I definitely see his
point.
I'm going to see what CL has to offer first, though, without any
external libraries, and see how far that takes me.
Tuang
> Tuang wrote:
>
> > It's my understanding (and I'm posting to have my understanding
> > corrected) that there are fewer than 1000 "operators" (I think they're
> > called) in Common Lisp. That's probably about twenty times as many as
> > there are in Scheme, but Java probably has more than twenty times as
> > many as Common Lisp, depending on what you consider to be the
> > equivalent of an operator.
> >
> > If the major practical advantage of CL over Scheme is the large amount
> > of reusable, portable, free functions already built, debugged, and
> > tested by others, then wouldn't a Scheme based on Java be even more
> > practical than CL by that measure? (I realize that my original
> > question was CL vs. Scheme, not CL vs. Scheme/Java, but it's not an
> > academic or legalistic question. I'm looking for practicality for
> > general-purpose programming projects.)
>
> Each language has its own "vision" of how things should be done. So Java
> libraries are written with a Java mindset while Lisp libraries are
> written with a Lisp mindset, and so on.
>
> When you use a Scheme based on Java and rely on Java libraries, you are
> actually mixing two different mindsets and this has the potential of
> making some things harder than necessary. For example, in Lisp and
> Scheme it is very natural to use lists as a data structure for many
> tasks whereas in Java, vectors are the preferred container class, mostly
Yes. Our posts "crossed in the mail", but I came to this same
(tentative) conclusion myself after considering things a bit.
I hadn't really expected the answer that most people gave, which was
essentially that the major practical advantage of CL over Scheme was
that CL had more pre-built, standard (i.e., portable) "stuff". I was
expecting something more along the lines of a different programming
paradigm or some such thing.
So then I thought, well if having more pre-built, portable stuff is
CL's major practical advantage over Scheme, then a Scheme based on
Java that had easy access to all of Java's libs might be even more
useful. (A CL based on Java might, by that measure, be even more
practical, but I haven't heard of any.)
After asking about this, though, I considered how I use the Java
libraries and how I'm now learning to work in both CL and Scheme. The
approach, of course, is radically different. In CL, you always seem to
be working with set operations: intersection, union, filtering, etc.,
various types of tree traversals, dynamic creation of functions, etc.
You can't even pass a function as a parameter in Java (unlike
C#...sort of).
Though a lot of the Java libraries for dealing with the "outside
world" would be quite useful (database, i18n, portable GUI,
networking, SOAP and other XML uses, servlets, etc.), the core Lispy
stuff is mostly missing from Java. Java is not fundamentally based on
linked lists of cons cells, as CL and Scheme appear to be, so Java's
libraries don't offer much Lispy functionality.
So for the core operations you're back to what Scheme and CL
themselves offer, and here it appears clear that CL has a *lot* more
built in Lispy functionality.
So then, I guess it comes down to whether the the Lispy functionality
that Scheme *does* offer, plus the outward facing Java libs is a
better solution than the much larger Lispy toolkit offered by CL, plus
whatever additional libs are available for the external stuff.
That seems to imply that Scheme/Java might be better for scripting
type tasks where your code isn't the major player but mainly a
coordinator of important external systems, while CL might be better if
the code you are writing is itself the major player.
Does this seem reasonable?
Tuang
> Hi Tuang,
>
> > That sounds right to me. While in theory I could write all my own
> > libraries to do anything in any language, that would be a pretty
> > impractical basis for comparing tools, and my question is about the
> > practical advantage(s) of CL over Scheme for real (non-research)
> > software projects.
> >
> > But then this brings up something I've frankly been wondering about.
> > It's my understanding (and I'm posting to have my understanding
> > corrected) that there are fewer than 1000 "operators" (I think they're
> > called) in Common Lisp. That's probably about twenty times as many as
> > there are in Scheme, but Java probably has more than twenty times as
> > many as Common Lisp, depending on what you consider to be the equivalent
> > of an operator.
>
> You're conflating core language and core language+library issues
Yes, I now see that.
> but yes,
> there are aspects of ANSI Common Lisp that could be improved through
> portable definition of extra functionality (e.g. networking). Thus there
> are a number of us who believe that ANSI Common Lisp is still too small
> for optimum creation of portable code. De facto standards are helping to
> fill in the gaps (e.g. BSD sockets).
>
> Those who complain about the large size of the language are an amusement...
As Java has grown, the designers have found better ways to do many
things, have implemented the new, and have deprecated the old. They've
also repeatedly stated that you can't rely on them carrying the
deprecated APIs forever into the future, so the compiler warns you if
you use functionality that is now deprecated and suggests what you
should replace it with.
Is there any likelihood that ANSI Common Lisp might develop in a
similar fashion, so the standard doesn't necessarily have to get
bigger or massively fork in order for CL to get better?
> [lots of other useful and interesting stuff...]
>
> Tuang, the best way to discover the practicality of Common Lisp is to
> begin coding.
I already have. I'm still at the "doing the exercises in the book"
stage, but I like it.
>
> Good luck,
> Adam
Thanks.
Peter Seibel
> As Java has grown, the designers have found better ways to do many
> things, have implemented the new, and have deprecated the old. They've
> also repeatedly stated that you can't rely on them carrying the
> deprecated APIs forever into the future, so the compiler warns you if
> you use functionality that is now deprecated and suggests what you
> should replace it with.
>
> Is there any likelihood that ANSI Common Lisp might develop in a
> similar fashion, so the standard doesn't necessarily have to get
> bigger or massively fork in order for CL to get better?
There are a lot of differences between the way Common Lisp and Java
are standardized (not least of which is what "standardized" means in
each case) that suggest the answer to your literal question is "no".
But I think the answer to what I presume to suspect is your "real"
question, is "yes". That is, there is a way that Common Lisp can and
likely will grow libraries to meet the needs of changing times.
Before I explain how that could happen let me make a few observations:
First, there is essentially no need to change the language standard
itself in order to support any of a number of useful libraries.
Including, thanks to macros, libraries of new control constructs or
even whole new models of software development.
Second, because there is no single vendor who controls Lisp the way
Sun controls Java, useful libraries will not come into existence
simply because some engineers at some company decide they should and
make them part of the "standard" library.
That said, the way librarise are developed in Lisp is much the same
way they are developed in Perl or Python: someone sees a need, writes
some code, and other people start using that code because it's useful.
If it's really useful, and well written, etc. it will become widely
adopted, perhaps even becoming a defacto standard.
The one piece that is currently missing, in my view, compared to the
way things work in the Perl and Python communities is that there's no
single source for the "standard" libraries. The Cliki gathers
information about different libraries but it neither provides them
directly nor provides an overall organization the way, say, Perl's
CPAN does. Also, since there are many different implementations of
Common Lisp, there's no process by which certain libraries get
"promoted" to being shipped with the language itself, the way the most
useful Perl and Python libraries do.
But the last bit probably doesn't have to matter. If someone were to
make a project of collecting information about the libraries that are
out there and maybe even maintaining a list of libraries that are
being written but not yet done or even desirable but not yet being
worked on I suspect that it could become the single source for
high-quality libraries. Especially if they also helped the library
authors package their libraries in a standard way so that users don't
have to spend a lot of energy figuring out how to get a library
installed, etc. If it became a good enough resource, the folks running
it might be able to "bless" the particularly high-quality libs so
people know which ones they are.
Unfortunately, all that is a fair bit of work and most of it is not
about having fun hacking on code but rather about organizing other
people's work, dealing with people who think you organized it wrong,
and putting up with compliants from ungrateful users. It takes a
special kind of person to do it. But there are various efforts
underway that could grow into such a thing when the right person comes
along: CLOCC seems to intend to be such a thing though the current
selection of libraries is a bit random. The libraries list on Cliki
could become such a thing. The contrib section of SBCL is another
possibility though it might need to be separated from SBCL in order to
serve the purpose I'm imagining. And the newly created "Sourceforge
for Common Lisp", http://www.common-lisp.net, looks like an attempt at
least to do just what I'm describing though it's still pretty young.
So my hopes are high that if Kenny's right and Lisp is about to have a
renaissance, that such a thing will arise. (I'd try and help out with
such an effort right now if I weren't working on my book. Maybe after
I'm done. If it hasn't happened already.)
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Pascal Costanza
> I hadn't really expected the answer that most people gave, which was
> essentially that the major practical advantage of CL over Scheme was
> that CL had more pre-built, standard (i.e., portable) "stuff". I was
> expecting something more along the lines of a different programming
> paradigm or some such thing.
Scheme tends to favor the functional programming style, while CL tends
to favor a mixed functional/object-oriented/imperative programming
style. So, yes, there is also a difference in this respect.
However, most "serious" Scheme implementations come with lots of
additions that cover some of the ground that CL already covers in its
standard.
(As a sidenote, these things sound admittedly somewhat strange to a Lisp
newbie. In the Lisp mindset, there is no real difference between a
language and a library. You can actually provide a "programming
paradigm" as a library in Lisp languages. So you can add
obect-orientedness to Scheme as a library, and logic programming to both
Scheme and Common Lisp as a library. This is hard to grasp at first, and
this will make your brain hurt for some time ;) - but this will
definitely pay off in the long run once you get it!)
> So then I thought, well if having more pre-built, portable stuff is
> CL's major practical advantage over Scheme, then a Scheme based on
> Java that had easy access to all of Java's libs might be even more
> useful. (A CL based on Java might, by that measure, be even more
> practical, but I haven't heard of any.)
There are two I have heard about recently:
http://jatha.sourceforge.net and http://armedbear-j.sourceforge.net/
(but beware: at the moment, these are "only" subsets of Common Lisp and
works in progress)
> After asking about this, though, I considered how I use the Java
> libraries and how I'm now learning to work in both CL and Scheme. The
> approach, of course, is radically different. In CL, you always seem to
> be working with set operations: intersection, union, filtering, etc.,
> various types of tree traversals, dynamic creation of functions, etc.
> You can't even pass a function as a parameter in Java (unlike
> C#...sort of).
In Java, dynamic inner classes and especially anonymous inner classes
mimick closures. (Intentionally so - the designers of inner classes
wanted to add an "object-oriented variant" of closures to Java.)
> Though a lot of the Java libraries for dealing with the "outside
> world" would be quite useful (database, i18n, portable GUI,
> networking, SOAP and other XML uses, servlets, etc.), the core Lispy
> stuff is mostly missing from Java. Java is not fundamentally based on
> linked lists of cons cells, as CL and Scheme appear to be, so Java's
> libraries don't offer much Lispy functionality.
>
> So for the core operations you're back to what Scheme and CL
> themselves offer, and here it appears clear that CL has a *lot* more
> built in Lispy functionality.
Yes.
> So then, I guess it comes down to whether the the Lispy functionality
> that Scheme *does* offer, plus the outward facing Java libs is a
> better solution than the much larger Lispy toolkit offered by CL, plus
> whatever additional libs are available for the external stuff.
>
> That seems to imply that Scheme/Java might be better for scripting
> type tasks where your code isn't the major player but mainly a
> coordinator of important external systems, while CL might be better if
> the code you are writing is itself the major player.
>
> Does this seem reasonable?
It's hard to answer such questions without a specific context. It
depends on your requirements.
If you need to work with Java libraries, and need to have a Lisp that is
embedded in the JVM, then Scheme is probably the best choice.
If you merely need to interact with an Java application, for example via
the net, then you can find good CL libraries for this task.
If you want to learn about the Lisp mindset with a focus on functional
programming, go for "pure" Scheme.
If you want to learn about Lisp with a focus on macro programming and/or
mixing programming styles, go for Common Lisp.
It's really up to you to decide what's best for you. (And this is
actually one of the things that I like most about the Lisp community in
general: it's all about making up your own mind. Most programming
languages are designed with the premise that programmers must be forced
to program in a certain style, according to some aesthetics that the
language designer has more or less accidentally picked. Not so in Lisp.
In the Lisp community, you rather adopt your own programming style while
having the opportunity to learn from the vast experience that Lispers
have gained in the past from experimenting with language features. The
amazing result of this approach is that many Lispers have agreed upon a
considerable large set of best practices, despite the danger of
divergence that such an approach seems to have.)
Pascal
Christopher C. Stacy
Tuang> As Java has grown, the designers have found better ways to do many
Tuang> things, have implemented the new, and have deprecated the old. They've
Tuang> also repeatedly stated that you can't rely on them carrying the
Tuang> deprecated APIs forever into the future, so the compiler warns you if
Tuang> you use functionality that is now deprecated and suggests what you
Tuang> should replace it with.
Tuang> Is there any likelihood that ANSI Common Lisp might develop in a
Tuang> similar fashion, so the standard doesn't necessarily have to get
Tuang> bigger or massively fork in order for CL to get better?
We already went through this process with Lisp, for about 40 years,
culminating in quite a serious frenzy for about 10 years, concluding
in the mid 1980s. We decided that we needed a standard that would be
stable, with which we could write real and enduring software, but with
which we could still experiment, and which would be highly portable onto
the current and future computer architectures and operating systems.
The result was called Common Lisp.
Common Lisp already embodies the "better ways" -- it's no longer
a "work in progress"; and it includes all the things that are needed
to extend it and change it and build on top of it. You don't need
to change the language to add features. If you want to change the
way things work, you can change them, because unlike JAVA and other
programming languages, the user can change the very language itself.
If all you want is some libraries, then just buy them (perhaps bundled
with the compiler from your vendor) or write them yourself.
Robert Klemme
"Tuang" <tuan...@hotmail.com> schrieb im Newsbeitrag
news:df045d93.0310...@posting.google.com...
> Adam Warner <use...@consulting.net.nz> wrote in message
news:<pan.2003.10.08....@consulting.net.nz>...
> > > It's my understanding (and I'm posting to have my understanding
> > > corrected) that there are fewer than 1000 "operators" (I think
they're
> > > called) in Common Lisp. That's probably about twenty times as many
as
> > > there are in Scheme, but Java probably has more than twenty times as
> > > many as Common Lisp, depending on what you consider to be the
equivalent
> > > of an operator.
> >
> > You're conflating core language and core language+library issues
>
> Yes, I now see that.
IMHO from a practical point of view the core lib is at least as important
as the language itself. So while plain counting of operators might not be
the appropriate measure for comparison, I think when considering
practicability libraries and even IDE's should be regarded, too.
Just my 2c.
robert
Paolo Amoroso
> So my hopes are high that if Kenny's right and Lisp is about to have a
> renaissance, that such a thing will arise. (I'd try and help out with
> such an effort right now if I weren't working on my book. Maybe after
You are already helping ;-)
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Ralph Richard Cook
point for Common Lisp to really catch on we need a standard way to
handle sockets, URL's, etc. For servers and other programs people
write a standard way to handle multithreading would be nice. Least
important but handy would be a XML standard (NOT DOM, we have S-exprs,
we can get closer to the Lisp way with our XML).
We've cut our mullets, it's time for our language to join the 21st
century as well.
Christopher C. Stacy
Ralph> Something has happened since the 80's called the Internet. At this
Ralph> point for Common Lisp to really catch on we need a standard way to
Ralph> handle sockets, URL's, etc. For servers and other programs people
Ralph> write a standard way to handle multithreading would be nice. Least
Ralph> important but handy would be a XML standard (NOT DOM, we have S-exprs,
Ralph> we can get closer to the Lisp way with our XML).
You don't need to change the language to do any of those things.
Thomas F. Burdick
> Something has happened since the 80's called the Internet. At this
> point for Common Lisp to really catch on we need a standard way to
> handle sockets, URL's, etc.
Really now. So, other languages have all standardized this? Because,
I think I remember there being very different ways of accessing
sockets on Windows, Unix, and MacOS <= 9.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Ray Dillinger
Just sitting down and reviewing, finally, because of this thread on
CLL, I decided to compare. I'm actually pretty neutral about the
language choice at this point. I don't want to argue about anything;
I just think this is an interesting list.
I really like the aesthetics of scheme -- how all values are just
values, regardless of whether they are functions or escape procedures
or anything else. I like the generality of its semantic constructs
and the way things are made as simple as they can reasonably be.
On the other hand, there are lots of points in the list below where
Common Lisp has a clear advantage, and most of them are at their most
acute in large shops or on large projects.
Additions and corrections are, of course, welcome.
Bear
PS. Hope you're using a monospace font!
What Common Lisp has got: What Scheme has got:
Much better developed standard SLIB + SRFI's + a hundred little
libraries libs that each do things differently
and aren't very standardized.
(Arguably Scheme is the place where new ideas fight for mindshare
and prove themselves - but the fights and the multiplicity
of contenders commits most code to one idea or another and
limits the code's interoperability, longevity, and/or
portability.)
A well-defined comprehensive A well-defined minimal spec plus
spec and several implementations dozens of variously comprehensive
which provide some extensions. implementations.
Escaping continuations only. Fully reentrant continuations.
Scheme just wins on this point.
(I have heard the arguments about whether fully reentrant
continuations are worth the cost of stack copying, or the
cost of heap-allocating and garbage collecting invocation
frames. I don't care. I'm just noting here that you can
do a *LOT* of things with them that are hard to do without
them.)
Lots of iterative constructs Memory-safe tail recursion avoids
the need for iteration syntax.
There's a looping construct, but
it's more complicated than tail
recursion so hardly anyone uses it.
If you care for them, you can
roll your own using continuations.
Both Lexically and Dynamically Lexical scope only, per the standard.
scoped special vars. Common Dynamically scoped vars are provided
Lisp just wins on this point. by some implementations as an extension
but code using them is not portable.
(I have heard the arguments about whether Dynamic scoping
is or is not a Bad Idea in the first place. I don't care.
I'm just noting that you can do things with it that you
can't easily do without it.)
C numeric types plus bignums Implementation-defined numeric types,
and complex nums, but no exact/ in some implementations failing to
inexact distinction. include bignums or complex nums. An
exact/inexact distinction is required
by the standard but properly implemented
in only about 3/4 of scheme systems.
In a good implementation, numerics
(capabilities and correctness) are
better than most CLs; on average,
they are worse.
Optional type declarations Optional type declarations provided
allow blazing fast numeric by a few implementations as extensions.
code to skip typechecking. Code using them is nonportable. Some
Common Lisp just wins on numeric implementations provide blazing speed
calculation speed. but generally at the expense of numeric
type richness and/or standard
conformance.
Signals and conditions, catch Roll your own using fully reentrant
and throw. continuations, or use any of several
libraries.
CLOS Roll your own objects using closures
and macros, or any of several OO
libraries. TinyCLOS and Meroon are
the most popular.
Well-defined standard module At least three competing well-defined
system. Common Lisp just wins module systems which it's a pain in
on this point. the butt to move modules between.
(or roll your own using scope, macros,
and/or preprocessing code).
Readtables for low-level Implementation-defined means of doing
macrology. Common Lisp wins low-level macrology - none of it
here. portable.
gensym tricks to avoid implicit hygienic macros with define-syntax and
variable captures in high-level syntax-case. You *can't* capture a
macros. variable in a macro except explicitly.
(Different people claim this as a "win" for both languages.
I don't care. There is little difference in what I can do
with it, nor in how hard it is to do it, so I'm not the guy
to judge a winner here.)
One-argument eval assumes environment specifier is second arg to
environment eval, allowing access to multiple
environments. Scheme just wins here.
Lambda syntax supports keyword Available as add-on library developed
arguments & default vals for using macros, but widely ignored.
optional arguments.
Symbols have properties, Variables have values and also names.
including but not limited to The names are lexically indistinguishable
function value and data value. from symbols but the value of a variable
is not a property of its name symbol.
Property lists are an extension
provided by relatively few schemes.
Native hash tables. Library hash tables.
Well-defined means of doing A fragile hack that depends on common
binary I/O. Common Lisp just character encodings and/or assumption
wins here. that character ports act as byte ports.
Assertions. Common Lisp just In scheme you have to do this as two
wins here. macros; one for development, that signals
an error if the condition isn't true, and
one for production code which "expands"
into nothing and gets out of the way.
The compiler will not use your assertions
to produce better code.
Large runtime environment Small runtime environment, easily
embeddable. Scheme wins here.
Björn Lindberg
> C numeric types plus bignums Implementation-defined numeric types,
> and complex nums, but no exact/ in some implementations failing to
> inexact distinction. include bignums or complex nums. An
> exact/inexact distinction is required
> by the standard but properly implemented
> in only about 3/4 of scheme systems.
> In a good implementation, numerics
> (capabilities and correctness) are
> better than most CLs; on average,
> they are worse.
Common Lisp also has rationals as a numeric type.
Björn
Kenny Tilton
Ray Dillinger wrote:
> Just sitting down and reviewing, finally, because of this thread on
> CLL, I decided to compare. I'm actually pretty neutral about the
> language choice at this point. I don't want to argue about anything;
> I just think this is an interesting list.
Me, too. I have never Schemed, so a lot of this was news to me. Thx for
the trouble. Based on the subject I thought this was a troll auto-artcle
sent in by a bot whenever the Lisp v. Scheme thing dies down.
Judging by what you offered (along with any fixes that come along), it
seems to me debates on specific issues are the only thing that make
sense--these creatures are too distinct in intent as well as content to
bear comparison.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Ray Dillinger
In scheme, those real numbers which are also exact are generally
those which can be expressed as rationals, and rational syntax is
used for them. But whether a number belongs to any particular
representation type is determined by its value, so if you add
exact reals you could get an exact real which also happens to be
an exact integer, and it's indistinguishable from the result of
adding two integers.
Bear
Björn Lindberg
I am not a language lawyer, but isn't this true of Common Lisp also? Ie,
[1]> (+ 1/3 4/5) ; Adding rationals produces rationals
17/15
[2]> (+ 1/3 2/3) ; Adding rationals giving an exact integer...
1
[3]> (type-of *) ; ...yields an integer
FIXNUM
Björn
Ray Dillinger
> > > Common Lisp also has rationals as a numeric type.
> > In scheme, those real numbers which are also exact are generally
> > those which can be expressed as rationals, and rational syntax is
> > used for them. But whether a number belongs to any particular
> > representation type is determined by its value, so if you add
> > exact reals you could get an exact real which also happens to be
> > an exact integer, and it's indistinguishable from the result of
> > adding two integers.
>
> I am not a language lawyer, but isn't this true of Common Lisp also?
Okay, right. So this is more-or-less a point of agreement between
the two languages, except that while the scheme standard defines
rational syntax, it doesn't actually require all implementations to
provide it.
Bear
Bruce Hoult
Ray Dillinger <be...@sonic.net> wrote:
> A well-defined comprehensive A well-defined minimal spec plus
> spec and several implementations dozens of variously comprehensive
> which provide some extensions. implementations.
Arrr ... the Scheme spec seems to be more in the way of a "guideline".
> Escaping continuations only. Fully reentrant continuations.
> Scheme just wins on this point.
>
> (I have heard the arguments about whether fully reentrant
> continuations are worth the cost of stack copying, or the
> cost of heap-allocating and garbage collecting invocation
> frames. I don't care. I'm just noting here that you can
> do a *LOT* of things with them that are hard to do without
> them.)
I disagree with this terminology. CL has dynamically *non*-escaping
continuations (as does Dylan). The alternatives are 1) no continuations
(Pascal), 2) single-use continuations within a single function (C's
return, break, continue), 3) first-class single use, non-dynamically
escaping continuations (CL, Dylan), 4) first-class, single use, escaping
continuations (?), 5) multiple use continuations (Scheme).
> Lots of iterative constructs Memory-safe tail recursion avoids
> the need for iteration syntax.
> There's a looping construct, but
> it's more complicated than tail
> recursion so hardly anyone uses it.
> If you care for them, you can
> roll your own using continuations.
Macros. You mean macros.
> Both Lexically and Dynamically Lexical scope only, per the standard.
> scoped special vars. Common Dynamically scoped vars are provided
> Lisp just wins on this point. by some implementations as an extension
> but code using them is not portable.
fluid-let is easily implemented given before/after unwind-protect
thunks, and the Scheme I'm using has it built in.
> Large runtime environment Small runtime environment, easily
> embeddable. Scheme wins here.
This is a big reason we're going to be shipping Scheme in our
pre-exiting C/C++ product soon. The implementation we're using
(Chicken) is designed to be easily embedded, and call to/from C code.
Gwydion Dylan would also work (better in many ways) but Scheme's
continuations mean we can take a highly callback-driven C interface and
make it look like straight-line code.
-- Bruce
Ray Dillinger
> Ray Dillinger <be...@sonic.net> wrote:
>
> > A well-defined comprehensive A well-defined minimal spec plus
> > spec and several implementations dozens of variously comprehensive
> > which provide some extensions. implementations.
>
> Arrr ... the Scheme spec seems to be more in the way of a "guideline".
I think it gives implementors too much freedom to not support
all the things it defines, such as numeric representations.
But, as would have pleased Majikthise and Vroomfondel, it provides
rigidly defined areas of doubt and uncertainty. :-/
> > Escaping continuations only. Fully reentrant continuations.
> I disagree with this terminology. CL has dynamically *non*-escaping
> continuations (as does Dylan). The alternatives are 1) no continuations
> (Pascal), 2) single-use continuations within a single function (C's
> return, break, continue), 3) first-class single use, non-dynamically
> escaping continuations (CL, Dylan), 4) first-class, single use, escaping
> continuations (?), 5) multiple use continuations (Scheme).
Okay, I'll go with that. Scheme's continuations do give people
an unbelievable amount of power. Your terminology is probably
better than mine.
>
> > Lots of iterative constructs Memory-safe tail recursion avoids
... ...
> > If you care for them, you can
> > roll your own using continuations.
>
> Macros. You mean macros.
Right. I did.
> > Both Lexically and Dynamically Lexical scope only, per the standard.
> > scoped special vars. Common Dynamically scoped vars are provided
> > Lisp just wins on this point. by some implementations as an extension
> > but code using them is not portable.
>
> fluid-let is easily implemented given before/after unwind-protect
> thunks, and the Scheme I'm using has it built in.
I had forgotten about unwind-protect. I've been not using it because
support for it isn't yet widespread. You're right, given that and
macros, dynamic variables are easy to provide. Of course, they're
more efficient if the implementation provides them as a built-in.
Bear
Paul F. Dietz
>>fluid-let is easily implemented given before/after unwind-protect
>>thunks, and the Scheme I'm using has it built in.
>
>
> I had forgotten about unwind-protect. I've been not using it because
> support for it isn't yet widespread. You're right, given that and
> macros, dynamic variables are easy to provide. Of course, they're
> more efficient if the implementation provides them as a built-in.
Dynamic variables in multiple threads are more difficult.
Paul
Ralph Richard Cook
>Really now. So, other languages have all standardized this? Because,
>I think I remember there being very different ways of accessing
>sockets on Windows, Unix, and MacOS <= 9.
Not all languages, but Java and Python has, and my opinion is this is
one of the things that contributed to the explosion of these
languages; a standard way to do work over the Internet (and
Intranets). Yes, Java has had Sun, and more recently IBM pushing it on
the hype machine, but Python hasn't and it's starting to take off as
well.
A lot of Java's technologies have been built on the foundation of a
cross-platform (source and binary) way of pushing bytes through
sockets. java.net, RMI, JINI, JNDI, JMS, JDBC (type 4 drivers), SOAP,
etc. If Common Lisp had a similar foundation (either a real or
de-facto standard) I think we could get a similar explosion of
interoperable Lisp software.
cst...@dtpq.com (Christopher C. Stacy) wrote:
>You don't need to change the language to do any of those things.
Going back to the mullet era again, there were different OOP systems
built on Lisp, mostly done through macros, so adding OOP didn't
require "changing the language". However, it sure helps to have one
standard, CLOS, so software built on it has no problem coexisting with
each other. Sockets and threads need the same treatment.
Kenny Tilton
Ralph Richard Cook wrote:
> ...If Common Lisp had a similar foundation (either a real or
> de-facto standard) I think we could get a similar explosion of
> interoperable Lisp software.
Did you just volunteer? Marc Battyani can't do everthing, you know.
Seriously, Lisp has won[1], but I agree: we won't reap the benefits
until stuff like sockets comes off the shelf. Seamlessly. We need less
market-share whining from Lispniks and more code. Unfortunately, only a
select few are putting their keystrokes where their mouth is.
Maybe it will be the newbies who make that happen. A lot of strong
lispniks work for Lisp vendors, putting all their energy into excellent
proprietary code, a problem unknown to Python or Perl. The rest are
tired old farts like Erann who only know what is not possible and think
the answer is to discard the language and the name. Et tu, Brute?
I get the feeling newbies are holding back because they are intimidated
by the depth of CL. I say to hell with it, churn out some libs, let the
nit pickers polish via their whining. Apparemtly that is the only
contribution they have to offer.[2]
kenny
[1] It's not really winning when the only thing happening is that more
and more people start enjoying something, because there is no less happy
person one can point to.
[2] Sorry for the sh*tty tone, but if yer not part of the solution, yer
part of the problem. Start. Coding. Tomorrow!! :)
Ray Dillinger
I have to admit here that I use dynamic variables hardly at all
unless forced to. So I may be seeing issues where none are, or
considering problems that smart people have already solved.
But it's not even clear to me what the semantics of dynamic
variables *ought* to be in a multithreaded model.
In particular the "race" situations become extremely baroque and
complex when some of the values that have to be protected with
mutexes are procedures that themselves have to protect and unprotect
other values. IOW, do you get a lock on the code that releases
mutexes when you execute the code that acquires mutexes, and not
release that lock until after it runs, so that no other procedure
changes the value of that code before you execute it? Ow...
Bear
Thomas F. Burdick
> "Paul F. Dietz" wrote:
> >
> > Ray Dillinger wrote:
> >
> > >>fluid-let is easily implemented given before/after unwind-protect
> > >>thunks, and the Scheme I'm using has it built in.
> > >
> > >
> > > I had forgotten about unwind-protect. I've been not using it because
> > > support for it isn't yet widespread. You're right, given that and
> > > macros, dynamic variables are easy to provide. Of course, they're
> > > more efficient if the implementation provides them as a built-in.
> >
> > Dynamic variables in multiple threads are more difficult.
>
>
> I have to admit here that I use dynamic variables hardly at all
> unless forced to. So I may be seeing issues where none are, or
> considering problems that smart people have already solved.
>
> But it's not even clear to me what the semantics of dynamic
> variables *ought* to be in a multithreaded model.
I think it's pretty obvious: the global value is visible to all
threads, and dynamic bindings are thread-local.
> In particular the "race" situations become extremely baroque and
> complex when some of the values that have to be protected with
> mutexes are procedures that themselves have to protect and unprotect
> other values. IOW, do you get a lock on the code that releases
> mutexes when you execute the code that acquires mutexes, and not
> release that lock until after it runs, so that no other procedure
> changes the value of that code before you execute it? Ow...
?!?!?! Scheme hacks to imitate dynamic binding in a single-threaded
environment are just that, hacks. Don't model your understanding of
dynamic binding based on that particular, questionable implementaion!
Think how it would work in a simple interpreter for a dynamically
scoped Lisp: you have a binding stack, that's just an alist. LET
conses a new pair onto the head, and SETQ modifies said pair. This
extends easily and painlessly to multiple threads:
thread X binding stack
thread 1 +---+---+ +---+---+
binding | A | 3 | | B | 4 |
stack +---+---+ +---+---+
| ^ ^
+---------->+-|-+---+ +-|-+---+ +-- global
| * | *--->| * | *---+ | bindings
+---+---+ +---+---+ | |
V V
thread 2--> +---+---+ +---+---+ +---+---+ +---+---+
binding | * | *--->| * | *--->| * | *--->| * | |
stack +-|-+---+ +-|-+---+ +-|-+---+ +-|-+---+
V V V V
+---+---+ +---+---+ +---+---+ +---+---+
| A |#\I| | B |#\J| | A | 1 | | B | 2 |
+---+---+ +---+---+ +---+---+ +---+---+
prunes...@comcast.net
> But it's not even clear to me what the semantics of dynamic
> variables *ought* to be in a multithreaded model.
Essentially, they should be thread-local.
> In particular the "race" situations become extremely baroque and
> complex when some of the values that have to be protected with
> mutexes are procedures that themselves have to protect and unprotect
> other values. IOW, do you get a lock on the code that releases
> mutexes when you execute the code that acquires mutexes, and not
> release that lock until after it runs, so that no other procedure
> changes the value of that code before you execute it? Ow...
You arrange the locks in a hierarchy. If necessary, you suspend
multithreading when acquiring a lock.
It is best not to make your locking code too complex. Even simple
locking code is often buggy.
Daniel Barlow
>> other values. IOW, do you get a lock on the code that releases
>> mutexes when you execute the code that acquires mutexes, and not
>> release that lock until after it runs, so that no other procedure
>> changes the value of that code before you execute it? Ow...
>
> You arrange the locks in a hierarchy. If necessary, you suspend
> multithreading when acquiring a lock.
And how do you suspend multithreading on a machine with more than one
CPU?
(Answer: very slowly)
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
prunes...@comcast.net
> prunes...@comcast.net writes:
>
>>> other values. IOW, do you get a lock on the code that releases
>>> mutexes when you execute the code that acquires mutexes, and not
>>> release that lock until after it runs, so that no other procedure
>>> changes the value of that code before you execute it? Ow...
>>
>> You arrange the locks in a hierarchy. If necessary, you suspend
>> multithreading when acquiring a lock.
>
> And how do you suspend multithreading on a machine with more than one
> CPU?
>
> (Answer: very slowly)
You use the bus-locking primitives provided by the CPU.
Ralph Richard Cook
>
>
>Ralph Richard Cook wrote:
>
>> ...If Common Lisp had a similar foundation (either a real or
>> de-facto standard) I think we could get a similar explosion of
>> interoperable Lisp software.
>
>Did you just volunteer? Marc Battyani can't do everthing, you know.
>
>Seriously, Lisp has won[1], but I agree: we won't reap the benefits
>until stuff like sockets comes off the shelf. Seamlessly. We need less
>market-share whining from Lispniks and more code. Unfortunately, only a
>select few are putting their keystrokes where their mouth is.
>
Java has a hardware company to keep things from getting fragmented.
Python has a Benevolent Dictator for Life (Guido) to keep things
together. Maybe we should hope for the ANSI committee to come together
again.
>Maybe it will be the newbies who make that happen. A lot of strong
>lispniks work for Lisp vendors, putting all their energy into excellent
>proprietary code, a problem unknown to Python or Perl. The rest are
>tired old farts like Erann who only know what is not possible and think
>the answer is to discard the language and the name. Et tu, Brute?
>
>I get the feeling newbies are holding back because they are intimidated
>by the depth of CL. I say to hell with it, churn out some libs, let the
>nit pickers polish via their whining. Apparemtly that is the only
>contribution they have to offer.[2]
>
>kenny
>
>[1] It's not really winning when the only thing happening is that more
>and more people start enjoying something, because there is no less happy
>person one can point to.
>
>[2] Sorry for the sh*tty tone, but if yer not part of the solution, yer
>part of the problem. Start. Coding. Tomorrow!! :)
I plead guilty to newbie intimidation, but pledge to do better, and
with portable libraries. Googling around I see that clocc has the Port
library, with cross-implementation for sockets. Perhaps
com-metacircles-clim-sys-mp for multithreading.
Until, of course, Peter's book comes out with all that wonderful
MP3-streaming code which sets the new de-facto standards (No pressure,
Peter).
Bruce Nagel
> Java has a hardware company to keep things from getting fragmented.
> Python has a Benevolent Dictator for Life (Guido) to keep things
> together. Maybe we should hope for the ANSI committee to come together
> again.
So maybe what we really need is for the Lisp Luminaries to form a
committee to get some of the lingering issues settled in a de facto
manner. Considering the time and expense involved in the previous ANSI
standardization, it seems unlikesy at best that it will happen again soon.
Too many people still have a stake in that standard not changing. But if
a majority of the Big Names in Lisp put their heads together and
hammered something out, I imagine everyone could live with the results as
a de facto standard, and most everyone would use it. Clisp, for instance,
has many additions beyond ANSI, new de facto standards for various
things the ANSI standard neglected to standardize could still be
included. I think all we're wanting is money to fund it or people
willing to volunteer..
Bruce
--
nag...@sdf.lonestar.org www.not-art.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Habit diminishes the conscious attention
with which our acts are performed.
Craig Brozefsky
> Scheme is like the Norwegian Military (small and rather good at few
> things), CL is like the US Military (big and good at everything)
Except maintaining occupations against guerilla resistance forces,
witness Vietnam, Afghanistan and Iraq. We should not expect CL to
take over Collab.Net, or Yahoo, where the java, C and perl guerilla
fighters will draw the CL occupation forces into a painful hunt for
anti-lambda resistors that will alienate them from the general
programming public.
These are things we must keep in mind in our quest for total world CL
domination. It is hard, unappreciated work to build a global
hegemony, even if its just a programming language.
> (Nominations for "Language most similar to the Italian Military" are
> accepted)
Expect
--
Sincerely, Craig Brozefsky <cr...@red-bean.com>
No war! No racist scapegoating! No attacks on civil liberties!
Chicago Coalition Against War & Racism: www.chicagoantiwar.org
Kenny Tilton
Craig Brozefsky wrote:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
>
>>Scheme is like the Norwegian Military (small and rather good at few
>>things), CL is like the US Military (big and good at everything)
>
>
> Except maintaining occupations against guerilla resistance forces,
> witness Vietnam, Afghanistan and Iraq. We should not expect CL to
> take over Collab.Net, or Yahoo, where the java, C and perl guerilla
> fighters will draw the CL occupation forces into a painful hunt for
> anti-lambda resistors that will alienate them from the general
> programming public.
>
> These are things we must keep in mind in our quest for total world CL
> domination. It is hard, unappreciated work to build a global
> hegemony, ...
Zen: make no effort
Tai chi: win without fighting
Kevin Coster: build it and he will come.
hth.