http://lisp-univ-etc.blogspot.com/2008/08/re-acceptable-lisp.html
(a somewhat emotional article with strong subjective opinions on other
programming languages)
Recently I've been thinking about programming languages in general and
how they relate to Common Lisp, spurred by such questions (and
discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need
a better type system?, What do you LISPers think of Haskell?, Paul
Graham's Arc is released today... what is the long term impact? etc.
As far as I understand, what people mean, when they talk about
acceptable Lisp, is not Lisp per se, but a universal high-level
programming language. It's just, that Lisp has made a bold claim to be
such one. Is it? More on that later.
...So, first I've analyzed the languages, which are wide-spread now,
weather they can deliver universality, so to say.
Kent Pitman has very accurately noted (Q16: Scheme in CS), that most
people program in assembly languages, be they concrete, like C/C++, or
abstract, like Java. And that is understandable, because these
languages allow a straightforward solution, and for the majority is
content with that. And that's one of the most important arguments, why
purely functional programming languages can't become universally-
accepted.
What about high-level languages? First of all, what kind of an animal
is that? My idea is, that it should be a language, in which you can
declare what to do and not how, think of any problem in terms of its
domain vocabulary and not in terms of moving bits and bytes around.
But that's, obviously, an oversimplification. One of the most
important qualities of a high-level language is, that it provides
efficient means of abstraction (and the function is the most important
— that's why languages without first-class functions don't count as
high-level). The high-level language should not only provide means to
solve a real-world problem, but as well to solve a problem of solving
such problems. Well, although I can't express concisely and clearly,
what's that, I'm sure, that there exists a common understanding, or
rather feeling, of that concept among the people, who raise such
questions.
So, what languages do we consider high-level?
Python is an attempt at a high-level language. But it's stuck in the
middle of a road from imperative to high-level. The goal of the
language's design was not to achieve universality, but to create a
robust dynamically-typed object-oriented language for scripting, and
it's reached, but there's no more ambitious aims ahead...
Ruby is definitely not an "acceptable Lisp" — it's a clean Perl (with
a "mixin" of Smalltalk). The aim of a language is power, but in a
somewhat myopic (Perl) view, i.e.: the ability to hack (which in the
context is the opposite of build complex systems) neatly and fast.
That's why everything, which was considered in the historical context
of the language's creation as a powerful feature to have, was
incorporated into it. From classes to keyword parameters to regular-
expressions to anonymous functions. Surely a lot of the achievements
of language design from Lisp ans Smalltalk and other languages are in
Ruby, but it's not "turtles all the way down" -- not uniform enough to
be able to efficiently develop new high-level concepts on top of it,
which will fit (so you're mostly left with what's already in the
language. (Btw, Mr. Braitwaite tries to prove the opposite).
C# (it seems, they are incorporating first-class functions in C#3) is
an interesting example of a language, which is based on C++ and Java
and gradually moves to high-levelness. But still it lacks underlying
vision of universality, it's very similar to Python in a way, that the
imperative paradigm with it's class-oriented extension if considered
the most important and basic one, thus limiting the others to being
second-level citizens.
Erlang is just a DSL for concurrency programming. It's functional, but
not at all intended to be universal.
Haskell is definitely different from the previously discussed
languages, because it really is built on the basis of an abstract
ideology and not as a pile of features. It's 2 fundamentals are pure
functionality and type-inference, and as a manifestation of this ideas
it achieves prominent results. But this ideas do not lead to a
language, capable of adapting to every problem and producing the most
natural solution.
Forth, J et al.. Why they can't be universal? I think it's a debate
between an ordinary to ourselves (alphabetic) language and an
hieroglyphic one. They are definitely a way of their own, and a very
interesting one, but not a way to unification, I think.
Scheme is a high-level language, built from a set of Lisp "axioms",
whose biggest flaw is prohibition of real macros. Paul Graham's Arc is
an attempt to bring macros to Scheme, but, i think, it's early to say,
weather it will succeed as a separate language or a successor to
Scheme.
Common Lisp
Is Common Lisp an acceptable Lisp, i.e. is it a universal high-level
programming language? I don't think, that it is, and that has been
proven by history, so to say (it's not even near to being universally
accepted). But it, surely, is the most advanced language in this
direction and it posesses some of the high-level features, that are
not present in other languages (and these features are actually the
features of "ideal" Lisp, from which Common Lisp derives its name).
Briefly about them:
* Parens are not a drawback. On the contrary, they are a powerful
basis for abstraction, because they help to denote a form — the
universal building block of it. Form is both data and code. Then there
are S-expressions which are supported by parens, but have the other
underlying concept — prefix notation, which unifies operations (mostly
coded in infix notation in other languages) and function application
(either prefix or suffix, but never infix).
* As Paul Graham has pointed, the best way to design a language is to
start from the most general set of axioms. And Lisp (Common Lisp
included) follows this principle, moreover its set of axioms is
probably the most general one.
* Macros are built on top of Lisp's general-purpose s-expressions
being code and data. I think it's obvious, why they are obligatory to
a high-level programming language -- because syntactic abstraction is
one of the most common ones.
* No "religious" adherence to any specific programming paradigm, but
taking the best principles from every one (at least at the time of
language's design).
* A concise standard. It's funny, when other language programmers
"complain" about the CL standard being bloated, incomplete and
outdated. Maybe, the only language, which can claim to have at least a
somewhat accurate, complete and up to date one is Java (or rather
could), while others either don't have any (Ruby, Python etc.) or have
a lot of revisions, vendor-specific parts and incompatibilities
between them (JavaScript, C++ and so on). And the fact, that the
functional programming languages, which usually have clear formal
specifications, are constantly in the process of revising them, as for
me, seems to prove, that they just didn't reach maturity yet.
But, still, there are some features, or rather underlying principles,
that Common Lisp lacks.
* What static typing folks want?
I "belong" to the dynamic typing camp, but I think, I understand, what
the other camp needs. The Lisp idea, that variables don't have types
and only values have, should be acceptable to them. But they want a
compiler subsystem, which checks one of the dimension of the program's
correctness (the dimension, that really allows verification), based on
the programmer's declaration. And that surely can be considered an
important high-level feature. Moreover, it seems to be a reachable
goal.
What CL has is optional type declaration and runtime check. Qi
implements static type-checking and type-inference, and besides other
functional-paradigm features. But it abandons prefix-notation and
multi-paradigm approach as a whole. Thus it's a very advanced
functional language with roots in Lisp, but not Lisp. Neither it is
universal.
What can be done inside Lisp to add static type-checking to dynamic
one? I think there's a possibility at least to implement partial
"lexical" type-checking for lexical variables. But how to do that
properly is a different question. Anyway, I'm sure, that although a
"universal language's" type system can have a deep mathematical
foundation, it should allow not only logical formalisms for defining
types, but as well plainer and simpler variants.
* What Schemers wanted, and why they chose Scheme?
As far as I understand, people who choose Scheme over CL do that not
because it nil and false, nor for the lack of macros. And not because
it's Lisp-1, but to be more precise, because it supports evaluation of
the car of a list, while CL only allows function (and macros, and
special-forms) names in it. I don't see, why there can't be a
compromise between the 2 approaches: leave multiple namespaces, which
is, as practice shows, very beneficial, and at the same time treat the
function cell (car of a list) differently: if it's a name, it should
be from the function namespace, while if it's a list -- it's a form,
which should be evaluated and produce either a function object or a
function name.
* Some idiosyncrasies, mostly inherited, should be removed (not all
functions are generic; errors do not subclass standard-object etc.).
The MOP should be in the standard. And the tradition of incorporating
the best from every paradigm should be continued: at least the
concurrency-oriented paradigm is relevant.
* Community process.
If the ideal Lisp is ever to appear it should have a standard and a
process of modifying it without loosing backward compatibility.
I understand, what kind of a difficult and bureaucratic process was
the effort for the Common Lisp standard, and that it's not going to be
repeated. Well, it's not necessary. The times have changed, and now
excellent implementations of a language are produced by the community,
which is globally distributed. There's no central power and a big
client (like DARPA), which demands official standard. The standard
should and could be produced by the community as a result of a
consensus. Why Python, Perl or Arc will never become universal?
Because their development is mostly determined by the tastes and
preferences of their "benevolent dictators", and their views, whatever
enlightened and advanced be them, are subjective and can't be accepted
universally. Today there's virtually no other power in the Lisp world,
except its users. Nor big organizations, like Microsoft, Google or
DARPA, neither dominant implementation producers. So I think, that if
the members of the CL community with the biggest impact on it, like
the participants of the original standardization process, who are
still active in the Common Lisp world: Kent Pitman and Daniel
Weinreib,-- as well as the new generation of prominent lispers: Pascal
Constanza, Edi Weitz, Paul Graham,-- and others were able to self-
organize and setup a community process for the creation of the new
Lisp standard, it could yield a desired result.
Maybe it's time to start advancing from Common Lisp to Universal
Lisp?..
"...So, first I've analyzed the languages, which are wide-spread now,
weather they can deliver universality, so to say."
The "weather" should have been written as "whether".
On Mon, 25 Aug 2008 12:27:26 -0700, Vsevolod wrote:
> http://lisp-univ-etc.blogspot.com/2008/08/re-acceptable-lisp.html (a
> somewhat emotional article with strong subjective opinions on other
> programming languages)
Next time it is enough to post the link.
> Recently I've been thinking about programming languages in general and
> how they relate to Common Lisp, spurred by such questions (and
> discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a
> better type system?, What do you LISPers think of Haskell?, Paul
> Graham's Arc is released today... what is the long term impact? etc.
>
> [...]
>
> Maybe it's time to start advancing from Common Lisp to Universal Lisp?..
Gee, I just love it when people start big philosophical discussions on
Where Programming Languages Should Go. Especially if they seem to be at
the level of a homework assignment for a freshman philosophy course.
Your single-paragraph summaries of programming languages enlightened many
of us. I was not aware that one can evaluate programming languages by
checking a grocery list of features. Does language X have feature A?
Language Y is just a B with a little of C.
And clearly, the objective of language design is not creating a valuable
practical tool, but satisfying every group we can think of. Especially
the "static typing folks".
Remember that actual programming is detrimental to the development of a
proper perspective. It is best to take a cursory glance at programming
languages (reading more than the first paragraph of Wikipedia articles is
too much), then meditate on The Universal Lisp.
Good luck,
Tamas
On Aug 26, 11:24 am, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 25 Aug 2008 12:27:26 -0700, Vsevolod wrote:
> >http://lisp-univ-etc.blogspot.com/2008/08/re-acceptable-lisp.html(a
> > somewhat emotional article with strong subjective opinions on other
> > programming languages)
>
> Next time it is enough to post the link.
>
> > Recently I've been thinking about programming languages in general and
> > how they relate to Common Lisp, spurred by such questions (and
> > discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a
> > better type system?, What do you LISPers think of Haskell?, Paul
> > Graham's Arc is released today... what is the long term impact? etc.
>
> > [...]
>
> > Maybe it's time to start advancing from Common Lisp to Universal Lisp?..
>
> Gee, I just love it when people start big philosophical discussions on
> Where Programming Languages Should Go. Especially if they seem to be at
> the level of a homework assignment for a freshman philosophy course.
>
> Your single-paragraph summaries of programming languages enlightened many
> of us. I was not aware that one can evaluate programming languages by
> checking a grocery list of features. Does language X have feature A?
> Language Y is just a B with a little of C.
>
> And clearly, the objective of language design is not creating a valuable
> practical tool, but satisfying every group we can think of. Especially
> the "static typing folks".
>
> Remember that actual programming is detrimental to the development of a
> proper perspective. It is best to take a cursory glance at programming
> languages (reading more than the first paragraph of Wikipedia articles is
> too much), then meditate on The Universal Lisp.
>
> Good luck,
>
> Tamas
Don't take my words to seriously, I'm just trying to reason on the
topics, that interest me, and this is the place, where you can easily
get opinions, different from yours. And if you have no opinion, that
doesn't mean, that nobody else isn't allowed to :)
Cheers,
Vsevolod
On Tue, 26 Aug 2008 06:58:06 -0700, Vsevolod wrote:
> Don't take my words to seriously, I'm just trying to reason on the
> topics, that interest me, and this is the place, where you can easily
> get opinions, different from yours. And if you have no opinion, that
> doesn't mean, that nobody else isn't allowed to :)
But I do have an opinion! :-)
Occasionally, people come along and suggest that Feature X is missing
from CL, and adding it would be an improvement. Hence Qi, Liskell, Arc,
etc. What they are missing is that CL is a great language because it is
extremely well-engineered, and the existing features fit together very
nicely.
Adding the Next Great Feature looks like a grand idea, until you realize
that it could potentially break a lot of the existing harmony of the
language. Sure, maybe it can be achieved again, but that takes a lot of
effort (look at the history of Lisp). Many are willing to theorize on
what is missing from Lisp, but few would be willing to make the effort to
polish the Ultimate Lisp to the level of maturity CL currently has. It
is not only the features which make a good language, but the design of
the fine details.
Best,
Tamas
> What they are missing is that CL is a great language because it is
> extremely well-engineered, and the existing features fit together very
> nicely.
I completely agree with you.
Dick Gabriel said: "I think there will be a next Lisp". (http://
www.dreamsongs.com/WIB.html. 3.6 The Next Lisp)
And actually I'm willing to put effort in the direction of "the
Ultimate Lisp" and plan to do that, when I'm ready. But, surely, my
efforts won't be enough, and, moreover, as I've mentioned above, one-
man efforts can't lead to something as finely thought-out and
engineered, as well as acceptable, as, for example, Common Lisp
Vsevolod
On Aug 26, 9:06 pm, Vsevolod <········@gmail.com> wrote:
> > What they are missing is that CL is a great language because it is
> > extremely well-engineered, and the existing features fit together very
> > nicely.
>
> I completely agree with you.
>
> Dick Gabriel said: "I think there will be a next Lisp". (http://www.dreamsongs.com/WIB.html. 3.6 The Next Lisp)
> And actually I'm willing to put effort in the direction of "the
> Ultimate Lisp" and plan to do that, when I'm ready. But, surely, my
> efforts won't be enough, and, moreover, as I've mentioned above, one-
> man efforts can't lead to something as finely thought-out and
> engineered, as well as acceptable, as, for example, Common Lisp
>
So what is it you want from a Lisp that cannot be implemented by
shadowing (= redefining) symbols in the CL package and surface syntax
via reader macros?
--
Mikael Jansson
http://mikael.janson.be/hacking/limp
On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>> What they are missing is that CL is a great language because it is
>> extremely well-engineered, and the existing features fit together very
>> nicely.
> I completely agree with you.
>
> Dick Gabriel said: "I think there will be a next Lisp". (http://
> www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm willing
> to put effort in the direction of "the Ultimate Lisp" and plan to do
> that, when I'm ready. But, surely, my efforts won't be enough, and,
> moreover, as I've mentioned above, one- man efforts can't lead to
> something as finely thought-out and engineered, as well as acceptable,
> as, for example, Common Lisp
>
> Vsevolod
He also said:
"There should be a simple, easily implementable kernel to the Lisp. That
kernel should be both more than Scheme -- modules and macros -- and less
than Scheme -- continuations remain an ugly stain on the otherwise clean
manuscript of Scheme.
The kernel should emphasize implementational simplicity, but not at the
expense of interface simplicity. Where one conflicts with the other, the
capability should be left out of the kernel. One reason is so that the
kernel can serve as an extension language for other systems, much as GNU
Emacs uses a version of Lisp for defining Emacs macros."
With the right kernel we could put the rest of Common Lisp in something
Like: http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/, much like what
PCL did for CLOS.
However the most minimal kernel most lispers seem to want these days is:
http://www.lispworks.com/documentation/HyperSpec/Front/
Matt
Matthew D Swank wrote:
> He also said:
> "There should be a simple, easily implementable kernel to the Lisp. That
> kernel should be both more than Scheme -- modules and macros -- and less
> than Scheme -- continuations remain an ugly stain on the otherwise clean
> manuscript of Scheme.
What's wrong with continuations?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 26 ago, 20:37, Jon Harrop <····@ffconsultancy.com> wrote:
> Matthew D Swank wrote:
> > He also said:
> > "There should be a simple, easily implementable kernel to the Lisp. That
> > kernel should be both more than Scheme -- modules and macros -- and less
> > than Scheme -- continuations remain an ugly stain on the otherwise clean
> > manuscript of Scheme.
>
> What's wrong with continuations?
Penis envy.
Jon Harrop wrote:
> Matthew D Swank wrote:
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp. That
>> kernel should be both more than Scheme -- modules and macros -- and less
>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>> manuscript of Scheme.
>
> What's wrong with continuations?
They interact badly with side effects.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2008-08-27, Pascal Costanza <··@p-cos.net> wrote:
> Jon Harrop wrote:
>> Matthew D Swank wrote:
>>> He also said:
>>> "There should be a simple, easily implementable kernel to the Lisp. That
>>> kernel should be both more than Scheme -- modules and macros -- and less
>>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>>> manuscript of Scheme.
>>
>> What's wrong with continuations?
>
> They interact badly with side effects.
That's not an argument for leaving them out of a language.
Side effects interact badly with other side effects, yet decent programming
languages support side effects. :)
But there is still a salient point here. Continuations are not some quick fix
path to speculative, nondeterministing programming. A continuation allows the
program to jump back to some saved point in its execution. However, this saved
point doesn't save the entire machine state. It could be argued that the
continuation saves only some relatively uninteresting pieces of the machine
state: namely some entities like lexical variables which are defined in the
programming language. In real software, you have external state: open files,
external databases, hardware, connections to other processes, et cetera. In
recognition of this, Scheme gives you dynamic-wind. With this, you are supposed
to take on the responsibility of saving and restoring any aspect of the world
that should work together with the continuation. Good luck!
For instance, if, deeply in some code, it is assumed that a database
transaction is in progress, then whenever you temporarily escape out of that
code via a continuation, you have to roll back that transaction. You may never
go back to that point again, so the database has to be in a state as if that
code never executed. But if you resume the code via a continuation, you have
to restore the transaction to exactly what it was at that point prior to the
escape, so that this partially completed transaction can continue. This is not
a matter of just adding a liberal sprinking of dynamic-wind and crossing your
fingers.
The nice thing about ordinary dynamic control transfers (the kind which escape
from a dynamic scope and can never return, triggering once-only unwind-protect
cleanup), is that they can settle everything. If code bails in the middle of
an incomplete transaction, the unwind-protect rolls it back, and that is final.
There are no questions about what if that code is resurrected and wants to
finish the transaction, and where do you stick the information needed to be able to do that, and how do you represent it, etc.
On Aug 27, 11:42 am, Pascal Costanza <····@p-cos.net> wrote:
> Jon Harrop wrote:
> > Matthew D Swank wrote:
> >> He also said:
> >> "There should be a simple, easily implementable kernel to the Lisp. That
> >> kernel should be both more than Scheme -- modules and macros -- and less
> >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> >> manuscript of Scheme.
>
> > What's wrong with continuations?
>
> They interact badly with side effects.
Lisp is the language that gives you control not shields you from your
own stupidity. If continuations have problem in some program with side
effects that don't use them in that particular place. Don't blame a
powerful tools because you have problem using it.
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
On 1 sep, 10:19, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Aug 27, 11:42 am, Pascal Costanza <····@p-cos.net> wrote:> Jon Harrop wrote:
> > > Matthew D Swank wrote:
> > >> He also said:
> > >> "There should be a simple, easily implementable kernel to the Lisp. That
> > >> kernel should be both more than Scheme -- modules and macros -- and less
> > >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> > >> manuscript of Scheme.
>
> > > What's wrong with continuations?
>
> > They interact badly with side effects.
>
> Lisp is the language that gives you control not shields you from your
> own stupidity. If continuations have problem in some program with side
> effects that don't use them in that particular place. Don't blame a
> powerful tools because you have problem using it.
Lisp does in fact shield me from my own stupidity (eg, (aref nil 1)
does not segfault), but more importantly it should shield me from
*your* stupidity (and you from mine). Your statement above tells me
that you're not actually familiar with the sorts of problems that
continuations systematically introduce.
One very easy to understand example is mapcar. Imagine you're mapping
across a 10 element list:
(mapcar (lambda (x) ...)
'(0 1 2 3 4 5 6 7 8 9))
I see 10 continuations that can be captured here returning from calls
to the anonymous function. Every one of them is a bad idea. What do
you think will happen if my function is:
(lambda (x)
(call/cc
(lambda (cont)
(when (zerop x) (setq *cont* cont))
x)))
Now when I reinvoke that continuation in *cont*
(funcall *cont* "zero")
what happens? Do I have a mapcar that returns
(0 1 2 3 4 5 6 7 8 9 "zero")
or
("zero" 1 2 3 4 5 6 7 8 9)
? Depends on how mapcar is implemented. In other words, *you* as a
library author have to be aware of all possible continuations that I
as your user might throw through your library, exposing all sorts of
grotty implementation details that cannot be seen in a language
without multiply-invokable continuations.
After playing around with them for a while, I think continuations have
no place in an impure functional language, which is one of the hats
that Lisp wears. They force your functional abstractions to be leaky.
On Sep 1, 3:48 pm, "Thomas F. Burdick" <········@gmail.com> wrote:
> On 1 sep, 10:19, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
>
>
> > On Aug 27, 11:42 am, Pascal Costanza <····@p-cos.net> wrote:> Jon Harrop wrote:
> > > > Matthew D Swank wrote:
> > > >> He also said:
> > > >> "There should be a simple, easily implementable kernel to the Lisp. That
> > > >> kernel should be both more than Scheme -- modules and macros -- and less
> > > >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> > > >> manuscript of Scheme.
>
> > > > What's wrong with continuations?
>
> > > They interact badly with side effects.
>
> > Lisp is the language that gives you control not shields you from your
> > own stupidity. If continuations have problem in some program with side
> > effects that don't use them in that particular place. Don't blame a
> > powerful tools because you have problem using it.
>
> Lisp does in fact shield me from my own stupidity (eg, (aref nil 1)
> does not segfault), but more importantly it should shield me from
> *your* stupidity (and you from mine). Your statement above tells me
> that you're not actually familiar with the sorts of problems that
> continuations systematically introduce.
Not very much. But considering the benefits I'm willing to pay the
price. Things I like to do are very easy with continuations and very
hard without them.
>
> One very easy to understand example is mapcar. Imagine you're mapping
> across a 10 element list:
>
> (mapcar (lambda (x) ...)
> '(0 1 2 3 4 5 6 7 8 9))
>
> I see 10 continuations that can be captured here returning from calls
> to the anonymous function. Every one of them is a bad idea. What do
> you think will happen if my function is:
>
> (lambda (x)
> (call/cc
> (lambda (cont)
> (when (zerop x) (setq *cont* cont))
> x)))
>
> Now when I reinvoke that continuation in *cont*
>
> (funcall *cont* "zero")
>
> what happens? Do I have a mapcar that returns
>
> (0 1 2 3 4 5 6 7 8 9 "zero")
>
> or
>
> ("zero" 1 2 3 4 5 6 7 8 9)
This one. I understand the implementation leaked. But so what? In the
language I'm working almost everything is transparent anyway so
exposing the control flow is no big deal. Actually I'm thinking about
exposing the enviroment too. I believe that opaqueness just gets in
the way. Take c++/c# protected fields and compare it with cl with-
slots. Which system is better in your eyes?
>
> ? Depends on how mapcar is implemented. In other words, *you* as a
> library author have to be aware of all possible continuations that I
> as your user might throw through your library, exposing all sorts of
> grotty implementation details that cannot be seen in a language
> without multiply-invokable continuations.
That's expecting to much from a library authors, if you fallow that
scrutiny will there be any library that could pass your rigorous tests
to be usable. I've seen so many buggy libraries or ones that could be
broken with certain inputs coming from multibillione companies and
pedigreed open source projects but people still use them and build
their software with them.Continuation might make easier to blow your
head but if they make problems don't use them in your project, it's
as simple as that. It's much easier than not having them when you need
them. Every powerful feature has an oponents for introduction in
*lesser* languages because it would make the code unsafe, how about cl
macros and anonymous functions, or forth direct stack manipulation.
It's like a nuclear weapon, it could surely make a lot of trouble if
left uncared but it will makes enemies think twice invading you.
>
> After playing around with them for a while, I think continuations have
> no place in an impure functional language,
There is no pure functional languages, only those posing as such.
> which is one of the hats that Lisp wears.
> They force your functional abstractions to be leaky.- Hide quoted text -
>
> - Show quoted text -
Thomas F. Burdick wrote:
> On 1 sep, 10:19, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>>On Aug 27, 11:42 am, Pascal Costanza <····@p-cos.net> wrote:> Jon Harrop wrote:
>>
>>>>Matthew D Swank wrote:
>>>>
>>>>>He also said:
>>>>>"There should be a simple, easily implementable kernel to the Lisp. That
>>>>>kernel should be both more than Scheme -- modules and macros -- and less
>>>>>than Scheme -- continuations remain an ugly stain on the otherwise clean
>>>>>manuscript of Scheme.
>>
>>>>What's wrong with continuations?
>>
>>>They interact badly with side effects.
>>
>>Lisp is the language that gives you control not shields you from your
>>own stupidity. If continuations have problem in some program with side
>>effects that don't use them in that particular place. Don't blame a
>>powerful tools because you have problem using it.
>
>
> Lisp does in fact shield me from my own stupidity (eg, (aref nil 1)
> does not segfault), but more importantly it should shield me from
> *your* stupidity (and you from mine). Your statement above tells me
> that you're not actually familiar with the sorts of problems that
> continuations systematically introduce.
>
> One very easy to understand example is mapcar. Imagine you're mapping
> across a 10 element list:
>
> (mapcar (lambda (x) ...)
> '(0 1 2 3 4 5 6 7 8 9))
>
> I see 10 continuations that can be captured here returning from calls
> to the anonymous function. Every one of them is a bad idea. What do
> you think will happen if my function is:
>
> (lambda (x)
> (call/cc
> (lambda (cont)
> (when (zerop x) (setq *cont* cont))
> x)))
>
> Now when I reinvoke that continuation in *cont*
>
> (funcall *cont* "zero")
>
> what happens? Do I have a mapcar that returns
>
> (0 1 2 3 4 5 6 7 8 9 "zero")
>
> or
>
> ("zero" 1 2 3 4 5 6 7 8 9)
>
> ? Depends on how mapcar is implemented. In other words, *you* as a
> library author have to be aware of all possible continuations that I
> as your user might throw through your library, exposing all sorts of
> grotty implementation details that cannot be seen in a language
> without multiply-invokable continuations.
>
> After playing around with them for a while, I think continuations have
> no place in an impure functional language, which is one of the hats
> that Lisp wears. They force your functional abstractions to be leaky.
Some brilliant wag once summarized the case against continuations by
falling back on Spinal Tap's fine line between stupid and clever.
Continuations start out as brilliant and then the wheels came off, as
per the above. I always assumed that would happen to Cells because they
were so...clever. I digress. Now I am Mr. Web 2.0 thanks to Franz's nice
session management and how am I managing state? With a frickin data
structure one uses to manage state.
Too easy?
Meanwhile Patrick Collison dumped Lisp to do his Lispy Web language in C
why? Because he needed control over the stack. Why did he need control
over the stack? Because he needed continuations. Fortunately he still
made his fortune. Using Ruby.
Moral somewhere.
kxo
Kenny <·········@gmail.com> writes:
> Now I am Mr. Web 2.0 thanks to Franz's nice session management and how
> am I managing state? With a frickin data structure one uses to manage
> state.
>
> Too easy?
Yes, there are some words about the "stateless purity of HTTP" and
"making sure things are just as hard as they are with CGI", but I have
delightfully misplaced them.
--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.
Slobodan Blazeski wrote:
> On Aug 27, 11:42 am, Pascal Costanza <····@p-cos.net> wrote:
>> Jon Harrop wrote:
>>> Matthew D Swank wrote:
>>>> He also said:
>>>> "There should be a simple, easily implementable kernel to the Lisp. That
>>>> kernel should be both more than Scheme -- modules and macros -- and less
>>>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>>>> manuscript of Scheme.
>>> What's wrong with continuations?
>> They interact badly with side effects.
> Lisp is the language that gives you control not shields you from your
> own stupidity. If continuations have problem in some program with side
> effects that don't use them in that particular place. Don't blame a
> powerful tools because you have problem using it.
The problem is that two completely unrelated parts of a program may
interact badly because of continuations, and it's hard to protect your
code from that.
(I agree that when in doubt you should give more power, not less. But
the problem is there anyway.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2008-08-26, Jon Harrop <···@ffconsultancy.com> wrote:
> Matthew D Swank wrote:
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp. That
>> kernel should be both more than Scheme -- modules and macros -- and less
>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>> manuscript of Scheme.
>
> What's wrong with continuations?
Continuations are one of those features that, as a user, you will probably pay
for even if you don't use them.
Of course, I mean real, first-class, re-invocable, dynamic continuations: the
kind which capture the entire call stack, so that you can re-enter a previously
saved context, and then return through its entire call chain, which may
traverse separate compilation units.
This type of object is the only thing that is worthy of being called
``continuation'', but the distinction needs to be made because of lesser hacks
which are called continuations.
If you implement real continuations so that there is no cost to programs which
don't use continuations, the implementation will suck donkey dung for programs
that do use continuations.
The problem is that a separately-compiled module of code which calls other
modules will have to support being traversed by continuations even if it
doesn't actually use them. If it is compiled to use a regular stack for its
local variables (i.e. user doesn't pay for the continuation feature that isn't
being used), the creation of a continuation will become expensive; it will have
to go back and clone the entire stack.
Lexical closures don't have this problem. If you don't use them, you don't pay.
A function that doesn't close over anything can be compiled in a way that is
oblivious to lexical closures. If a parent function calls some external child
function that makes closures, that activity has no interaction with the parent
function.
On Aug 27, 11:07 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-08-26, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Matthew D Swank wrote:
> >> He also said:
> >> "There should be a simple, easily implementable kernel to the Lisp. That
> >> kernel should be both more than Scheme -- modules and macros -- and less
> >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> >> manuscript of Scheme.
>
> > What's wrong with continuations?
>
> Continuations are one of those features that, as a user, you will probably pay
> for even if you don't use them.
And pay with gold, making implementation of lisp is a piece of cake,
making one that supports (proper) continuations is a hard work.
>
> Of course, I mean real, first-class, re-invocable, dynamic continuations: the
> kind which capture the entire call stack, so that you can re-enter a previously
> saved context, and then return through its entire call chain, which may
> traverse separate compilation units.
I hope you don't mean copying the stack by capturing the continuation
because that's not implementation of call/cc that's an ugly hack.
Anyone thinks about copying few MBs of stack.
>
> This type of object is the only thing that is worthy of being called
> ``continuation'', but the distinction needs to be made because of lesser hacks
> which are called continuations.
>
> If you implement real continuations so that there is no cost to programs which
> don't use continuations, the implementation will suck donkey dung for programs
> that do use continuations.
There is always some cost in implementing continuations, complexity of
the implementation, memory use, getti ng rid of the call stack, source
to source transformations, nothing comes for free in the life, will it
show in your code depends mostly on what kind of code you're making.
>
> The problem is that a separately-compiled module of code which calls other
> modules will have to support being traversed by continuations even if it
> doesn't actually use them. If it is compiled to use a regular stack for its
> local variables (i.e. user doesn't pay for the continuation feature that isn't
> being used), the creation of a continuation will become expensive; it will have
> to go back and clone the entire stack.
>
> Lexical closures don't have this problem. If you don't use them, you don't pay.
> A function that doesn't close over anything can be compiled in a way that is
> oblivious to lexical closures. If a parent function calls some external child
> function that makes closures, that activity has no interaction with the parent
> function.
Jon Harrop wrote:
> Matthew D Swank wrote:
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp. That
>> kernel should be both more than Scheme -- modules and macros -- and less
>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>> manuscript of Scheme.
>
> What's wrong with continuations?
Well.... I was the coordinator for the IEEE scheme standard,
and we discussed continuations A LOT. Let me see if I recall
all the objections.
1) Scheme has argument evaluation in unspecified order and this
is an important property for optimized implementations - often
you can get a 20% speedup by finding the "right" order to evaluate
the arguments of a particular call in. But continuations expose
argument evaluation order. So do side effects, but whatever.
2) Stack captures. Continuations require both static (lexical)
environment and dynamic (function call frames) environment to be
captured so that you can reenter a function at the point where a
continuation was captured. The obvious method for doing this
(allocate call frames on the heap and let the garbage collector
reap them when no continuation points at them anymore) makes your
implementation dog slow in general. The hack for doing this
(copy the entire stack when capturing a continuation and again
when invoking one) make any code using continuations dog slow.
The more advanced strategy for handling this (CPS transformation)
is a whole-program process and very hard to apply to systems
allowing separate compilation of modules.
3) Module systems. Modules that do not use continuations can
be compiled to run more efficiently if and only if it can be
guaranteed that none of the modules that they call will ever
capture their environments in a continuation. Thus in a scenario
where separate compilation is allowed and the compiler doesn't
necessarily know the entirety of the possible call stack when
compiling, they must be compiled in the less-efficient way that
is safe for continuation-using code - even if continuations are
never actually used in a project.
4) External state. Continuations capture the program state, but
not the state of objects external to the program (filesystems,
databases, network connections) which the program interacts with.
Thus when the context is restored by invoking the continuation,
the state of these objects is often left "out of sync" with
the program itself. (note, this was before "dynamic-wind" was
considered for addition to the standard. But dynamic-wind itself
has profound problems for systems that want to use continuations
for rapid context switching, because it imposes a penalty in
computing time unknowable to the module author on switches into
and out of that module.)
5) Threading models. The model of a program that uses continuations
is implicitly a single-threaded model with continuations allowing
the implementation of cooperative multitasking. Instead of a
"stack" of invocation frames, with continuations you have a tree
of invocation frames, and the program semantics depend on this.
If you have multiple active CPUs (or OS-level threading) you wind
up with multiple trees of invocation frames, and there are semantic
problems with escapes from one tree into another.
6) Continuations make the control-flow graph of a program undecidable
(I'm not sure that this is actually true, but many people certainly
believed that it was) and thereby prohibit many compiler optimizations.
7) Continuations restrict Memoization. A savvy compiler can often
spot subroutines that are side-effect free and memoize the results of
calls to those subroutines in order to short-circuit further calls.
But in a system where continuations can expose evaluations, you have
to actually perform every evaluation.
8) ... there was an 8, and a 9, and a 10, but I forget what they were
just now.
Bear
Ray Dillinger wrote:
> Jon Harrop wrote:
>
> > Matthew D Swank wrote:
> >> He also said:
> >> "There should be a simple, easily implementable kernel to the Lisp. That
> >> kernel should be both more than Scheme -- modules and macros -- and less
> >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> >> manuscript of Scheme.
> >
> > What's wrong with continuations?
>
>
> Well.... I was the coordinator for the IEEE scheme standard,
> and we discussed continuations A LOT. Let me see if I recall
> all the objections.
>
> 1) Scheme has argument evaluation in unspecified order and this
> is an important property for optimized implementations - often
> you can get a 20% speedup by finding the "right" order to evaluate
> the arguments of a particular call in. But continuations expose
> argument evaluation order. So do side effects, but whatever.
>
> 2) Stack captures. Continuations require both static (lexical)
> environment and dynamic (function call frames) environment to be
> captured so that you can reenter a function at the point where a
> continuation was captured. The obvious method for doing this
> (allocate call frames on the heap and let the garbage collector
> reap them when no continuation points at them anymore) makes your
> implementation dog slow in general. The hack for doing this
> (copy the entire stack when capturing a continuation and again
> when invoking one) make any code using continuations dog slow.
Yes but it seems that a lot of scheme implementation are doing that
anyway. In my eyes it's not an implementation but rather a hack. But
if you don't use call/cc a lot it probably doesn't matter.
> The more advanced strategy for handling this (CPS transformation)
> is a whole-program process and very hard to apply to systems
> allowing separate compilation of modules.
Wai the minute. What prevents you from CPS conversion definition by
definition in the repl and storing that in the s-expressions. I'm
currently working on it so I don't think it's very hard.
read the
(defun double (x) (* 2 x))
CPS convert it to
(defun double (k x) (* 2 x k))
store it for futher evaluation in whatever you use.
>
> 3) Module systems. Modules that do not use continuations can
> be compiled to run more efficiently if and only if it can be
> guaranteed that none of the modules that they call will ever
> capture their environments in a continuation. Thus in a scenario
> where separate compilation is allowed and the compiler doesn't
> necessarily know the entirety of the possible call stack when
> compiling, they must be compiled in the less-efficient way that
> is safe for continuation-using code - even if continuations are
> never actually used in a project.
>
> 4) External state. Continuations capture the program state, but
> not the state of objects external to the program (filesystems,
> databases, network connections) which the program interacts with.
> Thus when the context is restored by invoking the continuation,
> the state of these objects is often left "out of sync" with
> the program itself. (note, this was before "dynamic-wind" was
> considered for addition to the standard. But dynamic-wind itself
> has profound problems for systems that want to use continuations
> for rapid context switching, because it imposes a penalty in
> computing time unknowable to the module author on switches into
> and out of that module.)
>
> 5) Threading models. The model of a program that uses continuations
> is implicitly a single-threaded model with continuations allowing
> the implementation of cooperative multitasking. Instead of a
> "stack" of invocation frames, with continuations you have a tree
> of invocation frames, and the program semantics depend on this.
> If you have multiple active CPUs (or OS-level threading) you wind
> up with multiple trees of invocation frames, and there are semantic
> problems with escapes from one tree into another.
The only job is done in the primitive operators in the abstract
machine.
So what prevents me from having a multiple worker processes doing my
computation.Since the order of evalution of scheme is unspecified what
stops me from doing something like this:
(* (func1 args) (func2 args))
-> (* (execute-in-thread1 func1 args) (execute-in-thread2 func2
args))
>
> 6) Continuations make the control-flow graph of a program undecidable
> (I'm not sure that this is actually true, but many people certainly
> believed that it was) and thereby prohibit many compiler optimizations.
And there are people who suggest CPS just for that
Control Flow Analysis in Scheme
www.cs.purdue.edu/homes/suresh/502-Fall2006/papers/shivers-cfa.pd
link is broken
http://74.125.39.104/search?q=cache:G0Ay2OE6IE4J:www.cs.purdue.edu/homes/suresh/502-Fall2006/papers/shivers-cfa.pdf+cps+lisp+graph+compiling+flow+analysis&hl=en&ct=clnk&cd=1
>
> 7) Continuations restrict Memoization. A savvy compiler can often
> spot subroutines that are side-effect free and memoize the results of
> calls to those subroutines in order to short-circuit further calls.
> But in a system where continuations can expose evaluations, you have
> to actually perform every evaluation.
>
> 8) ... there was an 8, and a 9, and a 10, but I forget what they were
> just now.
>
> Bear
Ray Dillinger <····@sonic.net> writes:
> Jon Harrop wrote:
>
>> Matthew D Swank wrote:
>>> He also said:
>>> "There should be a simple, easily implementable kernel to the Lisp. That
>>> kernel should be both more than Scheme -- modules and macros -- and less
>>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>>> manuscript of Scheme.
>>
>> What's wrong with continuations?
>
>
> Well.... I was the coordinator for the IEEE scheme standard,
> and we discussed continuations A LOT. Let me see if I recall
> all the objections.
>
> 1) Scheme has argument evaluation in unspecified order and this
> 2) Stack captures. Continuations require both static (lexical)
> 3) Module systems. Modules that do not use continuations can
> 4) External state. Continuations capture the program state, but
> 5) Threading models. The model of a program that uses continuations
> 6) Continuations make the control-flow graph of a program undecidable
> 7) Continuations restrict Memoization. A savvy compiler can often
> 8) ... there was an 8, and a 9, and a 10, but I forget what they were
With all these objections, how did continuations made it into scheme?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
Pascal J. Bourguignon wrote:
> Ray Dillinger <····@sonic.net> writes:
>> Well.... I was the coordinator for the IEEE scheme standard,
>> and we discussed continuations A LOT. Let me see if I recall
>> all the objections.
...
> With all these objections, how did continuations made it into scheme?
Most of these objections are of limited technical merit and
consequence, and some were addressed by academic research that
provided viable strategies for getting around them. Consensus
did evolve and the objections were addressed to our satisfaction
in the discussions. I intended to tell you what the objections
were, not to assert that all of them are perfectly true and as
bad as they sound.
>> 1) Scheme has argument evaluation in unspecified order
It's true that continuations can expose evaluation order, but so
can side effects. The people making this argument believed that
continuations could do so in a more drastic and unexpected way,
by having a captured continuation passed to a procedure that
doesn't expect one as an argument value. But practical experience
indicated that this was never a problem in real-world code.
>> 2) Stack captures. Continuations require both static (lexical)
The advanced strategy (conversion to continuation passing style)
works just fine to address this problem, and was deemed "easy
enough" that it doesn't pose a very serious implementation problem
unless you're targeting a machine with stack reflection, such as
the JVM, or need binary-level call compatibility without an
interface layer - both of which were considered too specialized
to hold up the standard. And with a few rather simple inter-module
hacks, the problems we feared about the scalability of CPS tend
not to become dire until people are doing million-plus line
programs.
>> 3) Module systems. Modules that do not use continuations can
The absence of a specified module system (in that version of the
standard) made this argument less compelling than it might
otherwise have been. At the time no scheme code using any module
system was portable between implementations anyway, so this objection
was not yet an immediate problem. It was generally agreed that if
a module system were standard, it would be more important, and that
a module system should be standardized. Consensus failed to emerge
at that time about what the standardized module system should be.
>> 4) External state. Continuations capture the program state, but
This one, of the whole batch, is exactly as bad as it sounds. The
need to maintain coherent external state sharply limits the utility
of continuations. Dynamic-wind had not yet been specified.
>> 5) Threading models. The model of a program that uses continuations
>> 6) Continuations make the control-flow graph of a program undecidable
>> 7) Continuations restrict Memoization. A savvy compiler can often
>> 8) ... there was an 8, and a 9, and a 10, but I forget what they were
These were addressed by research papers by Matthias Felleisen
http://www.ccs.neu.edu/scheme/pubs/ , and Daniel Friedman,
http://www.cs.indiana.edu/~dfried/ , who between them have
published a whole library of stuff that everyone who intends
to design a language ought to read, as well as many other
authors who wrote papers which were then cutting edge research
and still the primary reference on how to actually do most of
this stuff.
These papers are now mostly collected at
http://library.readscheme.org/ , which will provide those
interested in lispy language design with many weeks of
beneficial reading and hard work.
Bear
In article <····················@newsfe07.iad>,
Matthew D Swank <··················@gmail.com> wrote:
> On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>
> >> What they are missing is that CL is a great language because it is
> >> extremely well-engineered, and the existing features fit together very
> >> nicely.
> > I completely agree with you.
> >
> > Dick Gabriel said: "I think there will be a next Lisp". (http://
> > www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm willing
> > to put effort in the direction of "the Ultimate Lisp" and plan to do
> > that, when I'm ready. But, surely, my efforts won't be enough, and,
> > moreover, as I've mentioned above, one- man efforts can't lead to
> > something as finely thought-out and engineered, as well as acceptable,
> > as, for example, Common Lisp
> >
> > Vsevolod
>
> He also said:
> "There should be a simple, easily implementable kernel to the Lisp. That
> kernel should be both more than Scheme -- modules and macros -- and less
> than Scheme -- continuations remain an ugly stain on the otherwise clean
> manuscript of Scheme.
>
> The kernel should emphasize implementational simplicity, but not at the
> expense of interface simplicity. Where one conflicts with the other, the
> capability should be left out of the kernel. One reason is so that the
> kernel can serve as an extension language for other systems, much as GNU
> Emacs uses a version of Lisp for defining Emacs macros."
This has been done with EuLisp to some extend. Check out the EuLisp spec.
It has a level-0 language and a level-0 library.
Level-1 then specifies reflective functionality and
some control structures and low-level functionality.
The Germans tried to define a DIN Kernel Lisp
(An approach to the DIN Kernel Lisp definition,
http://www.brics.dk/~hosc/vol04/04-cengarle-al.html ). There
is critique by Baker about that attempt:
http://home.pipeline.com/~hbaker1/CritLisp.html
I guess some of that work then went into ISLisp.
http://www.open-std.org/JTC1/SC22/WG16/
OpenLisp, an implementation of ISLisp, btw., seems
to run on small devices, too:
http://openlisp.free.fr/forum/viewtopic.php?f=2&t=28
>
>
> With the right kernel we could put the rest of Common Lisp in something
> Like: http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/, much like what
> PCL did for CLOS.
>
> However the most minimal kernel most lispers seem to want these days is:
> http://www.lispworks.com/documentation/HyperSpec/Front/
>
> Matt
--
http://lispm.dyndns.org/
On 2008-08-26, Matthew D Swank <··················@gmail.com> wrote:
> On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>
>>> What they are missing is that CL is a great language because it is
>>> extremely well-engineered, and the existing features fit together very
>>> nicely.
>> I completely agree with you.
>>
>> Dick Gabriel said: "I think there will be a next Lisp". (http://
>> www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm willing
>> to put effort in the direction of "the Ultimate Lisp" and plan to do
>> that, when I'm ready. But, surely, my efforts won't be enough, and,
>> moreover, as I've mentioned above, one- man efforts can't lead to
>> something as finely thought-out and engineered, as well as acceptable,
>> as, for example, Common Lisp
>>
>> Vsevolod
>
> He also said:
> "There should be a simple, easily implementable kernel to the Lisp. That
> kernel should be both more than Scheme -- modules and macros -- and less
> than Scheme -- continuations remain an ugly stain on the otherwise clean
> manuscript of Scheme.
>
> The kernel should emphasize implementational simplicity, but not at the
> expense of interface simplicity.
Simplicity is for amateurs. Or maybe for seasoned hackers who are breaking new
ground.
Production quality, N-th generation systems should emphasize reliability and
performance.
If you keep simplicity out of a kernel, it doesn't disappear. It simply moves
somewhere else, and possibly multiplies, because certain things can't be done
in a straightforward way outside of the kernel.
On Wed, 27 Aug 2008 17:36:09 +0000, Kaz Kylheku wrote:
> On 2008-08-26, Matthew D Swank <··················@gmail.com> wrote:
>> On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>>
>>>> What they are missing is that CL is a great language because it is
>>>> extremely well-engineered, and the existing features fit together
>>>> very nicely.
>>> I completely agree with you.
>>>
>>> Dick Gabriel said: "I think there will be a next Lisp". (http://
>>> www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm
>>> willing to put effort in the direction of "the Ultimate Lisp" and plan
>>> to do that, when I'm ready. But, surely, my efforts won't be enough,
>>> and, moreover, as I've mentioned above, one- man efforts can't lead to
>>> something as finely thought-out and engineered, as well as acceptable,
>>> as, for example, Common Lisp
>>>
>>> Vsevolod
>>
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp.
>> That kernel should be both more than Scheme -- modules and macros --
>> and less than Scheme -- continuations remain an ugly stain on the
>> otherwise clean manuscript of Scheme.
>>
>> The kernel should emphasize implementational simplicity, but not at the
>> expense of interface simplicity.
>
> Simplicity is for amateurs. Or maybe for seasoned hackers who are
> breaking new ground.
>
> Production quality, N-th generation systems should emphasize reliability
> and performance.
>
> If you keep simplicity out of a kernel, it doesn't disappear. It simply
> moves somewhere else, and possibly multiplies, because certain things
> can't be done in a straightforward way outside of the kernel.
Well the desire for a kernel/library separation is mostly a pragmatic one
in my case. With a correct reference implementation of most of common
lisp as portable library, the leaning curve and time investment to
implement the kernel and bootstrap a proper lisp would not be so steep.
For example, despite the hand-wringing over R6RS, having the libraries
and macro-system basically available off-the shelf in psyntax makes it
easy to adopt.
Also the explicit kernel/library separation would hopefully encourage
more language experimentation, with the kernel basically providing a
common runtime in which these lisps can coexist.
Matt
Matthew D Swank <··················@gmail.com> writes:
> Well the desire for a kernel/library separation is mostly a pragmatic one
> in my case. With a correct reference implementation of most of common
> lisp as portable library, the leaning curve and time investment to
> implement the kernel and bootstrap a proper lisp would not be so steep.
Why "would"? "Is"!
> Also the explicit kernel/library separation would hopefully encourage
> more language experimentation, with the kernel basically providing a
> common runtime in which these lisps can coexist.
The Common Lisp kernel is specified in CLHS. Mind all the operators
marked "Special Operators". All the rest is library macros or functions.
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
On Aug 28, 2:17 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
>
> > Also the explicit kernel/library separation would hopefully encourage
> > more language experimentation, with the kernel basically providing a
> > common runtime in which these lisps can coexist.
>
> The Common Lisp kernel is specified in CLHS. Mind all the operators
> marked "Special Operators". All the rest is library macros or functions.
>
A kernel ends up being both more and less than the special forms. Is
the list of special forms minimal? What about basic data types; what
about the type system itself? How much of the macro system has to be
there?
With just the special forms we can't even do any i/o. As for all the
rest, there is PCL, and Pitman's condition system implementation.
That is a lot, but there could also be most of cltl1 if we knew where
the bottom was.
Matt
akopa <··················@gmail.com> writes:
> On Aug 28, 2:17�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>>
>> > Also the explicit kernel/library separation would hopefully encourage �
>> > more language experimentation, with the kernel basically providing a
>> > common runtime in which these lisps can coexist. �
>>
>> The Common Lisp kernel is specified in CLHS. �Mind all the operators
>> marked "Special Operators". �All the rest is library macros or functions.
>>
>
> A kernel ends up being both more and less than the special forms.
Yes, you can include a little more.
> Is the list of special forms minimal?
No. You can implement everything with LAMBDA.
> What about basic data types; what about the type system itself?
This is covered by the Special Operator THE ;-)
> How much of the macro system has to be there?
None. You can implement the macro system with only the Special
Operators. You'll prefer to use also some basic functions, themselves
implemented only with the Special Operators.
> With just the special forms we can't even do any i/o.
Indeed, but you can implement COMMON-LISP I/O function only with the
Special Operators, and possibly primitive, system specific functions
found in the SYSTEM package. The point here is that it depends on the
kind of implementation you need. If you need to interface with some
system, you'll have to implement the SYSTEM package to give access to
these "primitive" I/O routines. But you could as well implement a CL
for a closed, embedded environment where all I/O is done from memory
(for example, if the hardware ensure persistence of RAM).
(defun sys:write (object stream) (sys::enqueue object (stream-data stream)))
(defun sys:read (stream) (sys::dequeue (stream-data stream)))
But anyways, this is out of the scope of CL.
> As for all the rest, there is PCL, and Pitman's condition system
> implementation. That is a lot, but there could also be most of
> cltl1 if we knew where the bottom was.
There's no bottom, it's all turtles all the way down.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
>> What about basic data types; what about the type system itself?
> This is covered by the Special Operator THE ;-)
ATOM?
Matthias Buelow <···@incubus.de> writes:
> Pascal J. Bourguignon wrote:
>
>>> What about basic data types; what about the type system itself?
>> This is covered by the Special Operator THE ;-)
>
> ATOM?
(THE ATOM 42)
I mean that if you want to implement THE in some way, you bring with
it the whole specification of the type system.
I also means that of course, along with these Special Operators, you
have all the implicit CL notions, those that don't have necessary a
symbol attached to them, but that are nonetheless important to
implement to realize CL semantics, like environments, or function call.
((lambda (x) (* x x)) 2)
Here, there are no special operators. But indeed it must be
evaluated. Implementing the Special Operators means implementing the
EVAL or the COMPILE function, and implementing them entirely means
implementing the evaluation (or compilation) of the above form.
Ok, but now I see that perhaps you meant that some data types can be
more primtive than others. Indeed, we don't need to implement all the
data types as primitives. For example, we can implement hash-tables
over vectors. And the choice of "primitive" datatypes is rather
orthogonal to the set of Special Operators. For lisp we would want
CONS and SYMBOL (after all, EVAL and COMPILE take s-exprs). To
implement the reader we'd like to have CHARACTER (but it could be
implemented over FIXNUM). For efficiency of the implementation it
would be nice if VECTOR was primitive. But again, it will depend on
the target, and what underlying data type are available.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal J. Bourguignon wrote:
>>>> What about basic data types; what about the type system itself?
>>> This is covered by the Special Operator THE ;-)
>> ATOM?
>
> (THE ATOM 42)
Ok, with handler-bind (and the corresponding evaluator-internal
primitive), it can work (you'll have to catch the error that occurs for
non-atoms and return nil in that case.)
Vsevolod <········@gmail.com> writes:
> On Aug 26, 11:24 am, Tamas K Papp <······@gmail.com> wrote:
>> On Mon, 25 Aug 2008 12:27:26 -0700, Vsevolod wrote:
>> >http://lisp-univ-etc.blogspot.com/2008/08/re-acceptable-lisp.html(a
>> > somewhat emotional article with strong subjective opinions on other
>> > programming languages)
>>
>> Next time it is enough to post the link.
>>
>> > Recently I've been thinking about programming languages in general and
>> > how they relate to Common Lisp, spurred by such questions (and
>> > discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a
>> > better type system?, What do you LISPers think of Haskell?, Paul
>> > Graham's Arc is released today... what is the long term impact? etc.
>>
>> > [...]
>>
>> > Maybe it's time to start advancing from Common Lisp to Universal Lisp?..
>>
>> Gee, I just love it when people start big philosophical discussions on
>> Where Programming Languages Should Go. Especially if they seem to be at
>> the level of a homework assignment for a freshman philosophy course.
>>
>> Your single-paragraph summaries of programming languages enlightened many
>> of us. I was not aware that one can evaluate programming languages by
>> checking a grocery list of features. Does language X have feature A?
>> Language Y is just a B with a little of C.
>>
>> And clearly, the objective of language design is not creating a valuable
>> practical tool, but satisfying every group we can think of. Especially
>> the "static typing folks".
>>
>> Remember that actual programming is detrimental to the development of a
>> proper perspective. It is best to take a cursory glance at programming
>> languages (reading more than the first paragraph of Wikipedia articles is
>> too much), then meditate on The Universal Lisp.
>>
>> Good luck,
>>
>> Tamas
>
> Don't take my words to seriously, I'm just trying to reason on the
> topics, that interest me, and this is the place, where you can easily
> get opinions, different from yours. And if you have no opinion, that
> doesn't mean, that nobody else isn't allowed to :)
This is also a place where you can easily be killfile'd or
otherwise ignored if you post long and poorly thought out or
researched articles.
On Aug 26, 8:37 am, Raymond Wiker <····@RawMBP.local> wrote:
> Vsevolod <········@gmail.com> writes:
> > On Aug 26, 11:24 am, Tamas K Papp <······@gmail.com> wrote:
> >> On Mon, 25 Aug 2008 12:27:26 -0700, Vsevolod wrote:
> >> >http://lisp-univ-etc.blogspot.com/2008/08/re-acceptable-lisp.html(a
> >> > somewhat emotional article with strong subjective opinions on other
> >> > programming languages)
>
> >> Next time it is enough to post the link.
>
> >> > Recently I've been thinking about programming languages in general and
> >> > how they relate to Common Lisp, spurred by such questions (and
> >> > discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a
> >> > better type system?, What do you LISPers think of Haskell?, Paul
> >> > Graham's Arc is released today... what is the long term impact? etc.
>
> >> > [...]
>
> >> > Maybe it's time to start advancing from Common Lisp to Universal Lisp?..
>
> >> Gee, I just love it when people start big philosophical discussions on
> >> Where Programming Languages Should Go. Especially if they seem to be at
> >> the level of a homework assignment for a freshman philosophy course.
>
> >> Your single-paragraph summaries of programming languages enlightened many
> >> of us. I was not aware that one can evaluate programming languages by
> >> checking a grocery list of features. Does language X have feature A?
> >> Language Y is just a B with a little of C.
>
> >> And clearly, the objective of language design is not creating a valuable
> >> practical tool, but satisfying every group we can think of. Especially
> >> the "static typing folks".
>
> >> Remember that actual programming is detrimental to the development of a
> >> proper perspective. It is best to take a cursory glance at programming
> >> languages (reading more than the first paragraph of Wikipedia articles is
> >> too much), then meditate on The Universal Lisp.
>
> >> Good luck,
>
> >> Tamas
>
> > Don't take my words to seriously, I'm just trying to reason on the
> > topics, that interest me, and this is the place, where you can easily
> > get opinions, different from yours. And if you have no opinion, that
> > doesn't mean, that nobody else isn't allowed to :)
>
> This is also a place where you can easily be killfile'd or
> otherwise ignored if you post long and poorly thought out or
> researched articles.
The essay was better than most of what passes for discourse here. I
am saddened how snide and thin-skinned and smirkingly arrogant this
list often is.
On Sep 2, 2:05 am, samantha <········@gmail.com> wrote:
> On Aug 26, 8:37 am, Raymond Wiker <····@RawMBP.local> wrote:
>
>
>
> > Vsevolod <········@gmail.com> writes:
> > > On Aug 26, 11:24 am, Tamas K Papp <······@gmail.com> wrote:
> > >> On Mon, 25 Aug 2008 12:27:26 -0700, Vsevolod wrote:
> > >> >http://lisp-univ-etc.blogspot.com/2008/08/re-acceptable-lisp.html(a
> > >> > somewhat emotional article with strong subjective opinions on other
> > >> > programming languages)
>
> > >> Next time it is enough to post the link.
>
> > >> > Recently I've been thinking about programming languages in general and
> > >> > how they relate to Common Lisp, spurred by such questions (and
> > >> > discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a
> > >> > better type system?, What do you LISPers think of Haskell?, Paul
> > >> > Graham's Arc is released today... what is the long term impact? etc.
>
> > >> > [...]
>
> > >> > Maybe it's time to start advancing from Common Lisp to Universal Lisp?..
>
> > >> Gee, I just love it when people start big philosophical discussions on
> > >> Where Programming Languages Should Go. Especially if they seem to be at
> > >> the level of a homework assignment for a freshman philosophy course.
>
> > >> Your single-paragraph summaries of programming languages enlightened many
> > >> of us. I was not aware that one can evaluate programming languages by
> > >> checking a grocery list of features. Does language X have feature A?
> > >> Language Y is just a B with a little of C.
>
> > >> And clearly, the objective of language design is not creating a valuable
> > >> practical tool, but satisfying every group we can think of. Especially
> > >> the "static typing folks".
>
> > >> Remember that actual programming is detrimental to the development of a
> > >> proper perspective. It is best to take a cursory glance at programming
> > >> languages (reading more than the first paragraph of Wikipedia articles is
> > >> too much), then meditate on The Universal Lisp.
>
> > >> Good luck,
>
> > >> Tamas
>
> > > Don't take my words to seriously, I'm just trying to reason on the
> > > topics, that interest me, and this is the place, where you can easily
> > > get opinions, different from yours. And if you have no opinion, that
> > > doesn't mean, that nobody else isn't allowed to :)
>
> > This is also a place where you can easily be killfile'd or
> > otherwise ignored if you post long and poorly thought out or
> > researched articles.
>
> The essay was better than most of what passes for discourse here. I
> am saddened how snide and thin-skinned and smirkingly arrogant this
> list often is.
Please excuse the out of order (in multiple ways commment). A very
interesting exchange grew out of what initially looked rough. Never
mind.
P� Mon, 25 Aug 2008 21:27:26 +0200, skrev Vsevolod <········@gmail.com>:
>
> Maybe it's time to start advancing from Common Lisp to Universal
> Lisp?..
You raise some interesting points here.
I might add Mathematica to the list of languages.
I guess my ideal language would look like Mathematica. Compile into
machine code with the same efficiency as C.
It would have a Haskel inferred type system. And a Eiffel's object system.
Finally a ACL2 style but fully automated proof of correctness of
algorithms.
I think you are right that CL is not the final word and that it is time to
move on.
--------------
John Thingstad
On Aug 26, 1:16 pm, "John Thingstad" <·······@online.no> wrote:
> På Mon, 25 Aug 2008 21:27:26 +0200, skrev Vsevolod <········@gmail.com>:
>
>
>
> > Maybe it's time to start advancing from Common Lisp to Universal
> > Lisp?..
>
> You raise some interesting points here.
> I might add Mathematica to the list of languages.
> I guess my ideal language would look like Mathematica. Compile into
> machine code with the same efficiency as C.
> It would have a Haskel inferred type system. And a Eiffel's object system.
> Finally a ACL2 style but fully automated proof of correctness of
> algorithms.
> I think you are right that CL is not the final word and that it is time to
> move on.
>
> --------------
> John Thingstad
Could you, please, elaborate a little on this questions:
Why is Mathematica's "look" superior to Common Lisp's?
In which aspects do you think Eiffel's object system is superior to
CLOS?
Do you think, that Hindley-Milner type system (and it's implementation
in Haskell) is the final word in type systems in practical application
and why?
Vsevolod
P� Tue, 26 Aug 2008 15:45:21 +0200, skrev Vsevolod <········@gmail.com>:
>
> Could you, please, elaborate a little on this questions:
> Why is Mathematica's "look" superior to Common Lisp's?
> In which aspects do you think Eiffel's object system is superior to
> CLOS?
> Do you think, that Hindley-Milner type system (and it's implementation
> in Haskell) is the final word in type systems in practical application
> and why?
>
> Vsevolod
Here is a example Matematica 'program' to print the first 9 rows of
Pascal's triangle
TableForm[Table[Binomial[n, k], {n, 0, 8}, {k, 0, n}]]
I find the function name capitalized and followed by [] to be more
readable.
Similarly the special forms are just attributes that are given to such a
form.
The functions are well though out and powerful.
The pattern matching is awesome.
What regards inheritance I find that classes should inherit behaviour as
well as name. This is a fundamental weakness of all object systems.
Only in Eiffel can you inherit behaviour as well. For instance the
function 'next' should specify that there is a scheme of well orderedness.
Similarly multiple inheritance is handled in a way which is less
confusing. You explicitly say what is included and what is called through
a lattice rather than rely on a ad hock pre determined scheme.
I should note that I like the seperation of classes and methods and the
natural way that allows you to define multi-methods in CLOS.
I find that types should be optional and that the way it is handed in CL
is too cumbersome.
Ideally I would like to just specify the type of the input parameters and
the return type and have the compiler infer the rest.
Simulary class and type should be the same concept.
--------------
John Thingstad
John Thingstad wrote:
> P� Mon, 25 Aug 2008 21:27:26 +0200, skrev Vsevolod <········@gmail.com>:
>
>>
>> Maybe it's time to start advancing from Common Lisp to Universal
>> Lisp?..
>
>
> You raise some interesting points here.
> I might add Mathematica to the list of languages.
> I guess my ideal language would look like Mathematica. Compile into
> machine code with the same efficiency as C.
> It would have a Haskel inferred type system. And a Eiffel's object system.
> Finally a ACL2 style but fully automated proof of correctness of
> algorithms.
> I think you are right that CL is not the final word and that it is time
> to move on.
I am looking at the seniors tennis circuit.
kt
P� Tue, 26 Aug 2008 13:39:12 +0200, skrev Kenny <·········@gmail.com>:
> John Thingstad wrote:
>> P� Mon, 25 Aug 2008 21:27:26 +0200, skrev Vsevolod <········@gmail.com>:
>>
>>>
>>> Maybe it's time to start advancing from Common Lisp to Universal
>>> Lisp?..
>> You raise some interesting points here.
>> I might add Mathematica to the list of languages.
>> I guess my ideal language would look like Mathematica. Compile into
>> machine code with the same efficiency as C.
>> It would have a Haskel inferred type system. And a Eiffel's object
>> system.
>> Finally a ACL2 style but fully automated proof of correctness of
>> algorithms.
>> I think you are right that CL is not the final word and that it is time
>> to move on.
>
> I am looking at the seniors tennis circuit.
>
> kt
lol
--------------
John Thingstad
On Aug 25, 2:27 pm, Vsevolod <········@gmail.com> wrote:
> ...So, first I've analyzed the languages, which are wide-spread now,
> weather they can deliver universality, so to say.
>
Do we really need or want a 'universal language'? What's the benefit?
I think there is a lot to be gained from having multiple programming
language communities:
New interesting ideas can be played around with in new languages, and
for particular problems these new languages can then become quite
useful. Eventually these ideas might be incorporated into other more
general purpose languages. This sort of cross-fertilization is good I
think.
I think a more interesting unification of languages would be a common
interface and semantics for calling methods and accessing data from
another language's binaries: this used to be true (e.g. c to fortran,
or vice versa), and what little I know about Microsoft's CLR looks
interesting in this respect... but none of these are really universal,
yet. Having such a universal cross-language semantics would let people
write subsystems in whatever language they are familiar with and/or is
most suitable for the particular task.
On Aug 27, 12:29 am, DeverLite <············@gmail.com> wrote:
> Do we really need or want a 'universal language'?
Need -- don't know, but I suppose, not. Want -- perhaps. At least the
people, who speculate on this topic (not only me, as you can see all
over the internet and in this newsgroup in particular), want. (I don't
mean, though, that I'm not content with the current CL).
As well, it's a pity, that people, who can make a lot in the CL world,
move away to other languages -- this means, that CL doesn't fully meet
their demands (I mean someone, like Paul Graham and Peter Norvig --
not the ones, who are constantly searching for something new or just
don't know, what they want, and follow the wave).
Vsevolod
In article
<····································@z66g2000hsc.googlegroups.com>,
Vsevolod <········@gmail.com> wrote:
> On Aug 27, 12:29 am, DeverLite <············@gmail.com> wrote:
> > Do we really need or want a 'universal language'?
>
> Need -- don't know, but I suppose, not. Want -- perhaps. At least the
> people, who speculate on this topic (not only me, as you can see all
> over the internet and in this newsgroup in particular), want. (I don't
> mean, though, that I'm not content with the current CL).
> As well, it's a pity, that people, who can make a lot in the CL world,
> move away to other languages -- this means, that CL doesn't fully meet
> their demands (I mean someone, like Paul Graham and Peter Norvig --
> not the ones, who are constantly searching for something new or just
> don't know, what they want, and follow the wave).
>
> Vsevolod
Sorry, but that is bullshit.
Programming languages are tools. There are different types of users,
tasks, different applications to build and different building
methods used. There is not the one tool to build all things.
Do you use a screwdriver for everything? Hammering
nails into the wall? Would the ultimate screwdriver help
with that?
If somebody wants to experiment with new tools, fine.
But this does not make all other tools obsolete.
What we see is that there are different programming languages
with different implementations. There is some overlap in
functionality and there are differences. What is important
to some (say, Lisp syntax or Python's syntax) is
less important to others. Each group of users see
good reasons to like the special feature set. There
are a lot of features that are not possible to have in
one tool. So each tool (which a Common Lisp) has a specific
set of features that in combination make it useful.
Common Lisp had been designed to support an incremental,
interactive software development style where flexibility
is very important. It had been designed to support
the development of complex software by experts. It was
for example not designed to support the education
of computer science students with a minimal language.
I was also not designed to create mission critical
applications that require lots of static checks
(say, like Ada). It was also not designed as a language
to write some kind of business systems in - some which
require decimal numbers.
Paul Graham has some specific design goals. He wants
a smaller, simpler language. He wants short identifiers.
He wants some special magic in the language (read
his book 'On Lisp'?). He has all kinds of design goals
expressed. These goals make the design of that language
not attractive to 'me'. But it could be that there
are others that have similar preferences like Paul.
Peter Norvig doesn't do much with Lisp anymore. Well,
he works for Google, which uses mostly zero Lisp, AFAIK.
Python is popular at Google and it is good enough for
him to use it as an educational language for his
AI books, and it is good enough for them to use
it as a language to write their software in.
If you start at Google, your chance to introduce
Lisp there is close to zero, I guess. The nearest
you get to Lisp at Google is a Symbolics Lisp Machine in their computer
museum:
http://flickr.com/photos/mwichary/2179390059/in/set-72157603670797176/
There have been lots of attempts to design a 'better' Lisp.
Some nice Lisps have been defined. None of them gained
much market/mind share. None of them was able to replace
Common Lisp. Lots of work had been put into EuLisp,
Dylan and ISLisp. They are really good language designs.
But if you want to develop now an application in Lisp,
the current Common Lisp implementations are to beat and
that is very, very hard.
I'm sure that a small team of highly skilled hackers
could get a new and smaller Lisp based on something
like Dylan going in a few years. Lots of implementations
started that way in the 80s.
One can develop a new nice Lisp, sure. But it never
will be the 'universal language'.
Why do we have so
many different types of motorized vehicles?
Had Mercedes failed to built the ultimate car? The
universal car? One which you can drive on the
Autobahn and the in Blackforest for work? One that
transports a container and can be used to drive for
shopping in the city?
Programming languages are used by people to write software.
Find a group of people that need a better tool
and develop something for them.
Unless you have a more specific idea than to define the
'universal language', you will FAIL, badly.
--
http://lispm.dyndns.org/
On Aug 27, 10:28 am, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@z66g2000hsc.googlegroups.com>,
>
> Vsevolod <········@gmail.com> wrote:
> > On Aug 27, 12:29 am, DeverLite <············@gmail.com> wrote:
> > > Do we really need or want a 'universal language'?
>
> > Need -- don't know, but I suppose, not. Want -- perhaps. At least the
> > people, who speculate on this topic (not only me, as you can see all
> > over the internet and in this newsgroup in particular), want. (I don't
> > mean, though, that I'm not content with the current CL).
> > As well, it's a pity, that people, who can make a lot in the CL world,
> > move away to other languages -- this means, that CL doesn't fully meet
> > their demands (I mean someone, like Paul Graham and Peter Norvig --
> > not the ones, who are constantly searching for something new or just
> > don't know, what they want, and follow the wave).
>
> > Vsevolod
>
> Sorry, but that is bullshit.
>
> Programming languages are tools. There are different types of users,
> tasks, different applications to build and different building
> methods used. There is not the one tool to build all things.
> Do you use a screwdriver for everything? Hammering
> nails into the wall? Would the ultimate screwdriver help
> with that?
>
> If somebody wants to experiment with new tools, fine.
> But this does not make all other tools obsolete.
> What we see is that there are different programming languages
> with different implementations. There is some overlap in
> functionality and there are differences. What is important
> to some (say, Lisp syntax or Python's syntax) is
> less important to others. Each group of users see
> good reasons to like the special feature set. There
> are a lot of features that are not possible to have in
> one tool. So each tool (which a Common Lisp) has a specific
> set of features that in combination make it useful.
> Common Lisp had been designed to support an incremental,
> interactive software development style where flexibility
> is very important. It had been designed to support
> the development of complex software by experts. It was
> for example not designed to support the education
> of computer science students with a minimal language.
> I was also not designed to create mission critical
> applications that require lots of static checks
> (say, like Ada). It was also not designed as a language
> to write some kind of business systems in - some which
> require decimal numbers.
>
> Paul Graham has some specific design goals. He wants
> a smaller, simpler language. He wants short identifiers.
> He wants some special magic in the language (read
> his book 'On Lisp'?). He has all kinds of design goals
> expressed. These goals make the design of that language
> not attractive to 'me'. But it could be that there
> are others that have similar preferences like Paul.
>
> Peter Norvig doesn't do much with Lisp anymore. Well,
> he works for Google, which uses mostly zero Lisp, AFAIK.
> Python is popular at Google and it is good enough for
> him to use it as an educational language for his
> AI books, and it is good enough for them to use
> it as a language to write their software in.
> If you start at Google, your chance to introduce
> Lisp there is close to zero, I guess. The nearest
> you get to Lisp at Google is a Symbolics Lisp Machine in their computer
> museum:http://flickr.com/photos/mwichary/2179390059/in/set-72157603670797176/
>
> There have been lots of attempts to design a 'better' Lisp.
> Some nice Lisps have been defined. None of them gained
> much market/mind share. None of them was able to replace
> Common Lisp. Lots of work had been put into EuLisp,
> Dylan and ISLisp. They are really good language designs.
> But if you want to develop now an application in Lisp,
> the current Common Lisp implementations are to beat and
> that is very, very hard.
> I'm sure that a small team of highly skilled hackers
> could get a new and smaller Lisp based on something
> like Dylan going in a few years. Lots of implementations
> started that way in the 80s.
>
> One can develop a new nice Lisp, sure. But it never
> will be the 'universal language'.
>
> Why do we have so
> many different types of motorized vehicles?
> Had Mercedes failed to built the ultimate car? The
> universal car? One which you can drive on the
> Autobahn and the in Blackforest for work? One that
> transports a container and can be used to drive for
> shopping in the city?
>
> Programming languages are used by people to write software.
> Find a group of people that need a better tool
> and develop something for them.
>
> Unless you have a more specific idea than to define the
> 'universal language', you will FAIL, badly.
>
> --http://lispm.dyndns.org/
I always try to compare programming languages to natural ones (like
the authors of SICP did, when they coined their famous phrase). And I
think this comparison is much more important, than a screwdriver or a
mercedes ones -- those are very limited metaphors. Or, at least,
programming languages may be compared with your hands, because with
them you can make the screwdriver and the mercedes. But that's
philosophy.
Speaking about CL, I understand, what you say about how it fits it's
goals. Moreover it works fine for most of the tasks I can imagine
(because it's more, than just a tool, I think).
But I am trying to understand, what can be done to CL to improve it
without parting with it, like the designers of Qi, Arc and others did.
(By the way, you brought up interesting articles about DKLisp, I'll
definitely read them). And that was not a demand from my side to
create a better Lisp, just a thought-provocation. I am quite content
with the current CL. But, I think, even it can be improved. :)
Vsevolod
In article
<····································@79g2000hsk.googlegroups.com>,
Vsevolod <········@gmail.com> wrote:
> I always try to compare programming languages to natural ones (like
> the authors of SICP did, when they coined their famous phrase). And I
> think this comparison is much more important, than a screwdriver or a
> mercedes ones -- those are very limited metaphors.
No, programming languages are actually also like tools.
They express algorithms that run on machines and these
algorithms are doing something. There are different
languages for controlling different kind of machines.
Communication of algorithmic ideas to other humans is one
purpose. The other purpose is to program machines to
do something (sometimes even something useful).
> Or, at least,
> programming languages may be compared with your hands, because with
> them you can make the screwdriver and the mercedes. But that's
> philosophy.
Natural languages are tools for communication. In natural
languages you also find no 'universal language'.
Natural languages are in many ways different from
formal languages or programming languages.
>
> Speaking about CL, I understand, what you say about how it fits it's
> goals. Moreover it works fine for most of the tasks I can imagine
> (because it's more, than just a tool, I think).
> But I am trying to understand, what can be done to CL to improve it
> without parting with it, like the designers of Qi, Arc and others did.
> (By the way, you brought up interesting articles about DKLisp, I'll
> definitely read them). And that was not a demand from my side to
> create a better Lisp, just a thought-provocation. I am quite content
> with the current CL. But, I think, even it can be improved. :)
That's no surprise. It is clear to most here that especially
Common Lisp can be improved. There are lots of small issues
with the standard. There are lots of larger issues with
the language. There have been some authors with very critical
remarks when Common Lisp appeared. There was a first round of
improvements with the ANSI CL standard. Since then most
of the improvements have been done by implementors and users
(and not by the language designers).
For example implementors have been implementing streams
and conditions with CLOS (Gray streams, ...). Threading
had been added, etc. Once can imagine that there
could be some effort to put some small and medium improvements
into CL. But these improvements will not make Common Lisp
an 'universal language'. It is not even the universal Lisp.
People like to experiment with new (or old) and different designs.
See for some older proposal:
http://lispm.dyndns.org/lisp/modernizing-cl.text
Or see
http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
for more specific changes that are proposed.
There is also a proposal to use this as a way
to specify and communicate changes/extensions to CL:
http://cdr.eurolisp.org/final.html
>
> Vsevolod
--
http://lispm.dyndns.org/
On Aug 27, 12:17 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@79g2000hsk.googlegroups.com>,
>
> http://lispm.dyndns.org/lisp/modernizing-cl.text
> http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
> http://cdr.eurolisp.org/final.html
I know about CDR and think, that it's a good idea. I even wanted to
submit a document there -- a reader syntax for hash-tables -- but
decided, that it was to small an issue (just a single function).
For the other links -- thanks a lot.
Vsevolod
Vsevolod wrote:
> On Aug 27, 12:17 pm, Rainer Joswig <······@lisp.de> wrote:
>> In article
>> <····································@79g2000hsk.googlegroups.com>,
>>
>> http://lispm.dyndns.org/lisp/modernizing-cl.text
>> http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
>> http://cdr.eurolisp.org/final.html
> I know about CDR and think, that it's a good idea. I even wanted to
> submit a document there -- a reader syntax for hash-tables -- but
> decided, that it was to small an issue (just a single function).
> For the other links -- thanks a lot.
Please don't only submit "big improvements." It's the small one that
will add up over a mid-term period and can eventually be combined into
something bigger. But if you you wait for a "big thing" before you do
anything, nothing will happen.
Incremental growth is better than big-bang solutions.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Aug 27, 2:17 am, Rainer Joswig <······@lisp.de> wrote:
>
> No, programming languages are actually also like tools.
>
I don't like that metaphor/analogy. Certainly editors and compilers
are tools, but the language itself is a building material. So for a
building material analogy, the current state of affairs is that you
use steal when you need tensile strength, concrete when you need to
handle compression, carbon fiber when you want it light, wood when you
want it to be easy to work with, plastic when you want it cheap...
There's nothing wrong with looking for a single building material that
has all of those desirable properties at the same time.
Vsevolod wrote:
> As far as I understand, what people mean, when they talk about
> acceptable Lisp, is not Lisp per se, but a universal high-level
> programming language.
I think the phrase "acceptable Lisp" means something far more specific than
you imply. For example, OCaml is almost certainly not regarded as an
acceptable Lisp because it has a static type system and a macro system
designed to handle syntax.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 25 Ago, 21:27, Vsevolod <········@gmail.com> wrote:
> read all (no, thanks)
You know, we are at high-end here.
High-end discussions are by definition very personal and always
objective.
So, please don't come here (or anywhere else) expecting some major
consensus...
-PM
On Aug 30, 5:50 pm, ········@gmail.com wrote:
> On 25 Ago, 21:27, Vsevolod <········@gmail.com> wrote:
>
> > read all (no, thanks)
>
> You know, we are at high-end here.
> High-end discussions are by definition very personal and always
> objective.
>
> So, please don't come here (or anywhere else) expecting some major
> consensus...
>
> -PM
I don't, and after reading it for quite a while I know what this group
is like.
I was more interested in the discussion and I've got a lot of food for
thought actually.
(Hope, that in the process, nobody's feelings were hurt :)
Best regards,
Vsevolod
QUOTE
What CL has is optional type declaration and runtime check. Qi
implements static type-checking and type-inference, and besides other
functional-paradigm features. But it abandons prefix-notation and
multi-paradigm approach as a whole.
UNQUOTE
Actually Qi is prefix - just like Lisp.
Mark
Mark Tarver wrote:
> Actually Qi is prefix - just like Lisp.
>
I'm not convinced. You've got quite infixy pattern match and type
declaration syntax IIRC, and it's pretty ubiquitous.
Okay, it's always localised within toplevel-prefix forms like
(datatype ...) and (define ...), and there's plenty of precedent in
lisp for such localised-infixy things, but qi code seems to have more
infix than I at least am totally comfortable with. type declarations
are particularly unlispy looking.
Sure, they might macro-map to end-user-usable lispier syntax underneath
(I haven't really looked), but if so, you still encourage the infixy
stuff as "idiomatic" qi.
e.g. (from memory, might not be quite valid or meaningful qi)
(define blah
foo -> bar )
not
(define blah
(-> foo bar))
X : A ;
=======
X : B ;
not
(<=> ((/- X A))
((/- X B)))
etc.
On 31 Aug, 05:11, David Golden <············@oceanfree.net> wrote:
> Mark Tarver wrote:
> > Actually Qi is prefix - just like Lisp.
>
> I'm not convinced. You've got quite infixy pattern match and type
> declaration syntax IIRC, and it's pretty ubiquitous.
>
> Okay, it's always localised within toplevel-prefix forms like
> (datatype ...) and (define ...), and there's plenty of precedent in
> lisp for such localised-infixy things, but qi code seems to have more
> infix than I at least am totally comfortable with. type declarations
> are particularly unlispy looking.
>
> Sure, they might macro-map to end-user-usable lispier syntax underneath
> (I haven't really looked), but if so, you still encourage the infixy
> stuff as "idiomatic" qi.
>
> e.g. (from memory, might not be quite valid or meaningful qi)
>
> (define blah
> foo -> bar )
>
> not
>
> (define blah
> (-> foo bar))
>
> X : A ;
> =======
> X : B ;
>
> not
>
> (<=> ((/- X A))
> ((/- X B)))
>
> etc.
Its entirely up to you
(define foo
[X | Y] -> Y)
(define foo
(cons X Y) -> Y)
are both legal.
Mark
On Aug 31, 4:35 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> > > Actually Qi is prefix - just like Lisp.
> (define foo
> (cons X Y) -> Y)
what about the arrow? ;)
Mark Tarver wrote:
> Its entirely up to you
>
> (define foo
> [X | Y] -> Y)
>
> (define foo
> (cons X Y) -> Y)
>
> are both legal.
>
Uhm. And the '->' still sitting infix
between its lhs and rhs in both of the above ?
On 31 Aug, 17:14, David Golden <············@oceanfree.net> wrote:
> Mark Tarver wrote:
> > Its entirely up to you
>
> > (define foo
> > [X | Y] -> Y)
>
> > (define foo
> > (cons X Y) -> Y)
>
> > are both legal.
>
> Uhm. And the '->' still sitting infix
> between its lhs and rhs in both of the above ?
C:\Documents and Settings\User\Desktop\Qi II\Qi 9.2>lisp.exe -M
lispinit.mem sta
rtup.txt
Qi 2007, Copyright (C) 2001-2007 Mark Tarver
www.lambdassociates.org
version 9.2 (Turbo-E)
(0-) (define unlispy-rule
[Arrow Patterns Result] -> (append Patterns [Arrow Result]))
unlispy-rule
(1-)
(define mapcan
_ [] -> []
F [X | Y] -> (append (F X) (mapcan F Y)))
mapcan
(2-)
(define macroexpand
[define F | Rules] -> [define F | (mapcan unlispy-rule Rules)]
X -> X)
WARNING:
DEFUN/DEFMACRO: redefining function macroexpand in C:\Documents and
Settings\Use
r\Desktop\Qi II\Qi 9.2\startup.txt, was defined in C:\Documents and
Settings\Use
r\Desktop\Qi II\Qi 9.2\Qi 9.2.txtmacroexpand
(3-) (define factorial
(-> (0) 1)
(-> (X) (* X (factorial (- X 1)))))
factorial
(4-) (factorial 6)
720
I think the moral here is - be careful of what you wish for.
Mark
On Aug 31, 7:39 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 31 Aug, 17:14, David Golden <············@oceanfree.net> wrote:
>
> > Mark Tarver wrote:
> > > Its entirely up to you
>
> > > (define foo
> > > [X | Y] -> Y)
>
> > > (define foo
> > > (cons X Y) -> Y)
>
> > > are both legal.
>
> > Uhm. And the '->' still sitting infix
> > between its lhs and rhs in both of the above ?
>
> C:\Documents and Settings\User\Desktop\Qi II\Qi 9.2>lisp.exe -M
> lispinit.mem sta
> rtup.txt
>
> Qi 2007, Copyright (C) 2001-2007 Mark Tarverwww.lambdassociates.org
> version 9.2 (Turbo-E)
>
> (0-) (define unlispy-rule
> [Arrow Patterns Result] -> (append Patterns [Arrow Result]))
> unlispy-rule
>
> (1-)
> (define mapcan
> _ [] -> []
> F [X | Y] -> (append (F X) (mapcan F Y)))
> mapcan
>
> (2-)
> (define macroexpand
> [define F | Rules] -> [define F | (mapcan unlispy-rule Rules)]
> X -> X)
>
> WARNING:
> DEFUN/DEFMACRO: redefining function macroexpand in C:\Documents and
> Settings\Use
> r\Desktop\Qi II\Qi 9.2\startup.txt, was defined in C:\Documents and
> Settings\Use
> r\Desktop\Qi II\Qi 9.2\Qi 9.2.txtmacroexpand
>
> (3-) (define factorial
> (-> (0) 1)
> (-> (X) (* X (factorial (- X 1)))))
> factorial
>
> (4-) (factorial 6)
> 720
>
> I think the moral here is - be careful of what you wish for.
>
> Mark
And with this new macroexpand, will all other Qi 'machinery' work as
previously?
Is there an 'idiomatic way' to program in Qi (I mean from your point
of view -- I understand, that anyone is free to do what he likes) and
does this prefix pattern matching variant align with the idiomatic
way?
Thanks,
Vsevolod
On 31 Aug, 20:09, Vsevolod <········@gmail.com> wrote:
> On Aug 31, 7:39 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > On 31 Aug, 17:14, David Golden <············@oceanfree.net> wrote:
>
> > > Mark Tarver wrote:
> > > > Its entirely up to you
>
> > > > (define foo
> > > > [X | Y] -> Y)
>
> > > > (define foo
> > > > (cons X Y) -> Y)
>
> > > > are both legal.
>
> > > Uhm. And the '->' still sitting infix
> > > between its lhs and rhs in both of the above ?
>
> > C:\Documents and Settings\User\Desktop\Qi II\Qi 9.2>lisp.exe -M
> > lispinit.mem sta
> > rtup.txt
>
> > Qi 2007, Copyright (C) 2001-2007 Mark Tarverwww.lambdassociates.org
> > version 9.2 (Turbo-E)
>
> > (0-) (define unlispy-rule
> > [Arrow Patterns Result] -> (append Patterns [Arrow Result]))
> > unlispy-rule
>
> > (1-)
> > (define mapcan
> > _ [] -> []
> > F [X | Y] -> (append (F X) (mapcan F Y)))
> > mapcan
>
> > (2-)
> > (define macroexpand
> > [define F | Rules] -> [define F | (mapcan unlispy-rule Rules)]
> > X -> X)
>
> > WARNING:
> > DEFUN/DEFMACRO: redefining function macroexpand in C:\Documents and
> > Settings\Use
> > r\Desktop\Qi II\Qi 9.2\startup.txt, was defined in C:\Documents and
> > Settings\Use
> > r\Desktop\Qi II\Qi 9.2\Qi 9.2.txtmacroexpand
>
> > (3-) (define factorial
> > (-> (0) 1)
> > (-> (X) (* X (factorial (- X 1)))))
> > factorial
>
> > (4-) (factorial 6)
> > 720
>
> > I think the moral here is - be careful of what you wish for.
>
> > Mark
>
> And with this new macroexpand, will all other Qi 'machinery' work as
> previously?
> Is there an 'idiomatic way' to program in Qi (I mean from your point
> of view -- I understand, that anyone is free to do what he likes) and
> does this prefix pattern matching variant align with the idiomatic
> way?
>
> Thanks,
> Vsevolod- Hide quoted text -
>
> - Show quoted text -
Yes; very much so. The macroexpand function works on the Qi reader.
So after the definition provided, you can load all your programs in
prefix notation. I put these two functions in a file and loaded them.
(define factorial
(-> (0) 1)
(-> (X) (* X (factorial (- X 1)))))
(define rev
(-> (()) ())
(-> ((cons X Y)) (append (reverse Y) (cons X ()))))
If you wanted to accomodate signatures in the functions it would
require a few more lines in macroexpand.
You can program Qi to look like ML or Haskell if you wanted. But
personally I don't like the total prefix notation much - its longer
and more bracket cluttered than the native idiom.
But Qi actually supports an M-level and an S-level syntax. [...] is
just short for (cons ...) and is parsed as such. The advantage of the
S-level syntax is that it gives Qi the same metaprogramming capability
that Lisp has got (perhaps better in some ways). The advantage of the
M-level is its brevity when writing programs. Historically Lisp was
supposed to have both. So in a sense Qi has restored something that
was part of the original intention, except that McCarthy's intended M-
level was different from Qi.
Mark
> > > (3-) (define factorial
> > > (-> (0) 1)
> > > (-> (X) (* X (factorial (- X 1)))))
> > > factorial
Cool, you added extra parenthesis around the input parts, 0 and X.
Why? I'm struggling to see why not just use (-> 0 1)
This is all actually what I meant by the post at:
http://groups.google.co.uk/group/Qilang/browse_thread/thread/f1fabe523b04eb5e?fwc=1
Thanks for the macro code, maybe I'll look into using the language
again.
> > > I think the moral here is - be careful of what you wish for.
In this case, if I did that I'd instead have to rip out my guts from
the feeling their giving me.
By formatting the data with prefix, you pave the way for
a) Greater ability to re-use the code as data and in macro's.
b) Possibility of writing your code more concisely as a result.
The (-> 0 1) above might become (0 1) as similar to a let form. Dare I
say it, but if ever an indentation syntax reader were introduced, I
would use it, and I would type this:
mydef factorial
0 1
X (* X (factorial (- X 1))
I would imagine you used the current Qi syntax (partly) to make the
code easier for people to type. Personally, I find the above to be
even easier, regardless of whether an arrow is necessary to focus the
eyes.
For those of you spinning with rage at my insolence, here's the above
code without my hypothetical indent-reader:
(mydef factorial
(0 1)
(X (* X (factorial (- X 1))))
Of course, if you like, those wrapping parens can be removed anyway in
the same way that Qi does,
but I would see that as a bad idea.
Ali
On 31 ago, 23:07, Ali <·············@gmail.com> wrote:
> > > > (3-) (define factorial
> > > > (-> (0) 1)
> > > > (-> (X) (* X (factorial (- X 1)))))
> > > > factorial
>
> Cool, you added extra parenthesis around the input parts, 0 and X.
> Why? I'm struggling to see why not just use (-> 0 1)
What if the defined functions takes more than 1 argument? The
parenthesis mean a list of arguments, in this particular case, just
one.
Why do people living in Lisp keep mumbling about parenthesis? It gets
away with ambiguities and is an excelent aid in simple structured
editing.
On Sep 1, 6:04 am, namekuseijin <············@gmail.com> wrote:
> What if the defined functions takes more than 1 argument? The
> parenthesis mean a list of arguments, in this particular case, just
> one.
Sorry, I assumed there would be only one output. The extra parens are
okay if you want the structure though.
Thanks again for the extra code Mark, I wasn't arguing that it can't
be implemented in Qi,
I was arguing the case for why I will code in that way rather than the
default.
On 1 Sep, 03:07, Ali <·············@gmail.com> wrote:
> > > > (3-) (define factorial
> > > > (-> (0) 1)
> > > > (-> (X) (* X (factorial (- X 1)))))
> > > > factorial
>
> Cool, you added extra parenthesis around the input parts, 0 and X.
> Why? I'm struggling to see why not just use (-> 0 1)
>
> This is all actually what I meant by the post at:http://groups.google.co.uk/group/Qilang/browse_thread/thread/f1fabe52...
>
> Thanks for the macro code, maybe I'll look into using the language
> again.
>
> > > > I think the moral here is - be careful of what you wish for.
>
> In this case, if I did that I'd instead have to rip out my guts from
> the feeling their giving me.
> By formatting the data with prefix, you pave the way for
> a) Greater ability to re-use the code as data and in macro's.
> b) Possibility of writing your code more concisely as a result.
>
> The (-> 0 1) above might become (0 1) as similar to a let form. Dare I
> say it, but if ever an indentation syntax reader were introduced, I
> would use it, and I would type this:
>
> mydef factorial
> 0 1
> X (* X (factorial (- X 1))
>
> I would imagine you used the current Qi syntax (partly) to make the
> code easier for people to type. Personally, I find the above to be
> even easier, regardless of whether an arrow is necessary to focus the
> eyes.
>
> For those of you spinning with rage at my insolence, here's the above
> code without my hypothetical indent-reader:
>
> (mydef factorial
> (0 1)
> (X (* X (factorial (- X 1))))
>
> Of course, if you like, those wrapping parens can be removed anyway in
> the same way that Qi does,
> but I would see that as a bad idea.
>
> Ali
As in
C:\Documents and Settings\User\Desktop\Qi II\Qi 9.2>lisp.exe -M
lispinit.mem sta
rtup.txt
Qi 2007, Copyright (C) 2001-2007 Mark Tarver
www.lambdassociates.org
version 9.2 (Turbo-E)
(0-) (define myrule
Rule -> (let Patterns (all-but-last Rule)
Result (last Rule)
(append Patterns [-> Result])))
myrule
(1-) (define all-but-last
[_] -> []
[X | Y] -> [X | (all-but-last Y)])
all-but-last
(2-) (define mapcan
_ [] -> []
F [X | Y] -> (append (F X) (mapcan F Y)))
mapcan
(3-) (define last
[X] -> X
[_ | Y] -> (last Y))
last
(4-) (define macroexpand
[mydef F | Rules] -> [define F | (mapcan myrule Rules)]
X -> X)
WARNING:
DEFUN/DEFMACRO: redefining function macroexpand in C:\Documents and
Settings\User\Desktop\Qi II\Qi 9.2\startup.txt, was defined in C:
\Documents and Settings\User\Desktop\Qi II\Qi 9.2\Qi
9.2.txtmacroexpand
(5-) (mydef factorial
(0 1)
(X (* X (factorial (- X 1)))))
factorial
(6-) (factorial 4)
24
-> does carry some information though in Qi - its not just noise - <-
is an alternative. See http://www.lambdassociates.org/studies/study05.htm
for an example.
Qi II improves on Qi I by removing 'macroexpand' and allowing you to
declare any function as akin to macroexpand. So the above would be in
Qi II identical except instead of
(define macroexpand
[mydef F | Rules] -> [define F | (mapcan myrule Rules)]
X -> X)
We might have
(define mylanguage
[mydef F | Rules] -> [define F | (mapcan myrule Rules)]
X -> X)
and to declare that mylanguage is used as a sugar function (i.e. to
change the syntax of the reader) we write
(sugar in mylanguage 0)
meaning that the function mylanguage is to be used to change the input
and that the function is to be applied in 0th position (ie. before any
other sugar function). This allows you to import syntactic changes
without overwriting previous syntax changes because there is no longer
a single 'macroexpand' function. Analogously by swapping 'out' for
'in' you can program the printer.
The ability to create sugar functions in Qi II really displaces not
all but quite a lot of what is done in Lisp by DEFMACRO. It
effectively allows you to create your own language on top of Qi with
your own shorthands and conventions.
Mark
On Sep 1, 10:33 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> The ability to create sugar functions in Qi II really displaces not
> all but quite a lot of what is done in Lisp by DEFMACRO. It
> effectively allows you to create your own language on top of Qi with
> your own shorthands and conventions.
As far as I understand, you are talking about a list of functions,
which define rules of code transformation and which are applied in a
specified order. But that's more the analogue of Lisp's *reader*
macros, not the (compiler) macros, isn't it? It's not something, that
you can apply in one place and leave aside in the other.
So, returning to my previous question: if I define this new
macroexpand in such way and try to load the code, written in infix
manner, it won't compile, right?
Vsevolod
I'm having trouble understanding your criteria for a language to be
"high-level" and for it to be "universal". You discuss various
improvements that could be made to Common Lisp, but exactly what does
a language have to achieve to be "high-level", and what must it
achieve to be "universal"?
Of course high-level languages provide efficient means of abstraction,
and one could even say that they are higher-level to the extent that
they provide more and better means of abstraction. But surely Java
provides all kinds of abstraction. What's the specific bar that needs
to be passed? I disagree with you that there's a common feeling that
we all share. Rather, I think it is a matter of degree.
Starting a community process to come up with a new language
definition, whether upward-compatible with Common Lisp or not, is
easy, but completing the process is very hard. Getting consensus on
language design issues is a great deal of work. I remember pretty
clearly how hard it was to forge together the original "Common Lisp:
The Language". And now, there are eleven implementations, and you'd
somehow have to get all of them to agree to all of the changes.
I hope that we can have some good discussions at the International
Lisp Conference about the possible directions that the community can
take to solve some of the major problems in Common Lisp today.
Regarding what is a "problem", there will be more agreement on some
than on others. Probably everybody agrees that the absence of
standardized thread support is a problem. I think that it's a problem
that we don't explicitly specify what conditions are signaled for all
(or, as many as possible) unusual outcomes, but maybe other people
don't care so much, or maybe the implementers consider it too much
trouble. Is it a "problem" that tail recursive calls are not defined
to not use up the stack? That one's harder!
On Sep 2, 11:16 am, Dan Weinreb <····@alum.mit.edu> wrote:
> I'm having trouble understanding your criteria for a language to be
> "high-level" and for it to be "universal". You discuss various
> improvements that could be made to Common Lisp, but exactly what does
> a language have to achieve to be "high-level", and what must it
> achieve to be "universal"?
>
> Of course high-level languages provide efficient means of abstraction,
> and one could even say that they are higher-level to the extent that
> they provide more and better means of abstraction. But surely Java
> provides all kinds of abstraction. What's the specific bar that needs
> to be passed? I disagree with you that there's a common feeling that
> we all share. Rather, I think it is a matter of degree.
By universal [Lisp] I mean the one, which will be accepted by all the
interested parties: those, who prefer Scheme over CL (for production
systems, not for teaching), those, who express a strong desire to have
static typing. As well, by those, who start such projects, as Arc,
Clojure and other Lisp variants, instead of embracing CL. Maybe, after
all, even by those who say, that Ruby/Python/Javascript/etc is an
acceptable Lisp, meaning, that CL is not.
Surely, I don't know, if such a language is at all possible, and, even
more, needed...Or maybe it's just a matter of attitude.
But, at least the demands to it can be formulated.
Speaking about high-level, I know, that I've made an undersupported
claim, because I can't give some good definition. Moreover, I think
it's a kind of a philosophical question, but I believe, that Common
Lispers at least in this direction have a similar philosophy (I derive
this from my experience with the language and discussions I see about
it among it's users). For me, the language is high-level if it
supports the basic abstractions worked out by decades of computer
science development, as well as gives ways to define your own
abstractions (which is best realized in CL macro-system).
The single paradigm languages often limit you in this aspect. I can
argue, why Java isn't high-level (at least in all aspects): because
function in it is not a first-class object, and function, no matter,
weather it's viewed as a side-effect free transformation (like in
functional languages) or as a general computation (as in Lisp) is the
primary means of abstraction. This brings to the situation, when many
algorithms need to be expressed in some unnatural way in Java. But,
for sure it has a lot of support for abstraction, and, obviously, it's
not an assembler, where you you are limited to a predefined set of
operations. But even Assembler is Turing complete.
> Starting a community process to come up with a new language
> definition, whether upward-compatible with Common Lisp or not, is
> easy, but completing the process is very hard. Getting consensus on
> language design issues is a great deal of work. I remember pretty
> clearly how hard it was to forge together the original "Common Lisp:
> The Language". And now, there are eleven implementations, and you'd
> somehow have to get all of them to agree to all of the changes.
>
> I hope that we can have some good discussions at the International
> Lisp Conference about the possible directions that the community can
> take to solve some of the major problems in Common Lisp today.
> Regarding what is a "problem", there will be more agreement on some
> than on others. Probably everybody agrees that the absence of
> standardized thread support is a problem. I think that it's a problem
> that we don't explicitly specify what conditions are signaled for all
> (or, as many as possible) unusual outcomes, but maybe other people
> don't care so much, or maybe the implementers consider it too much
> trouble. Is it a "problem" that tail recursive calls are not defined
> to not use up the stack? That one's harder!
I can only add my voice to others, who think the process of evolving a
language for Common Lisp is important at least to incorporate in it
the individual achievements made throughout the years of it's use.
And I think, that CDR.eurolisp.org is a good step in that direction,
alas not very much supported yet.
As for me, I'm just a user and I'll try to participate if I can add
some value.
Thanks for your reply
Vsevolod
On Sep 2, 5:43 pm, Vsevolod <········@gmail.com> wrote:
> interested parties: those, who prefer Scheme over CL (for production
> systems, not for teaching), those, who express a strong desire to have
> static typing. As well, by those, who start such projects, as Arc,
> Clojure and other Lisp variants, instead of embracing CL. Maybe, after
> all, even by those who say, that Ruby/Python/Javascript/etc is an
> acceptable Lisp, meaning, that CL is not.
> And I think, that CDR.eurolisp.org is a good step in that direction,
One would imagine, but correct me if I'm wrong, that the designers of
all of the above mentioned languages prefer their language over the
others.
Ruby appeared sometime after Python. Yukihiro Matsumoto looked at
Python and other languages, and then wrote the language that he wanted
to use. Even so, there are still people who prefer Python (or other
languages) and will never switch to Ruby, even though Ruby was
designed after Python, and is better in the eyes of Yukihiro. Yukihiro
might just happen to think that Ruby is the Universal Language.
The same happened with Arc (and the other recent lisps). I would
imagine that in Paul Graham's eyes, Arc is the Universal Lisp. Yet
even though it was designed much later than CL and Scheme, there are
still people... etc. etc. ... better in the eyes of Paul.
*Even if* you were to design a super-duper language which you thought
exceeded the others in every way, not everyone will agree with you
that its the best way of doing things.
So my conclusion is that you don't need other people to agree on which
language is better than all the others and have everyone using the
same thing. The only important thing is that *your* favourite language
has sufficient libraries to do what *you* want in the time-frame you
want. They all do some things differently and they all have their
reasons for it. If your favourite language doesn't have these
libraries, the choice is to either write some, or look at your second
favourite language.
On Sep 2, 11:48 pm, Ali <·············@gmail.com> wrote:
> On Sep 2, 5:43 pm, Vsevolod <········@gmail.com> wrote:
>
> > interested parties: those, who prefer Scheme over CL (for production
> > systems, not for teaching), those, who express a strong desire to have
> > static typing. As well, by those, who start such projects, as Arc,
> > Clojure and other Lisp variants, instead of embracing CL. Maybe, after
> > all, even by those who say, that Ruby/Python/Javascript/etc is an
> > acceptable Lisp, meaning, that CL is not.
> > And I think, that CDR.eurolisp.org is a good step in that direction,
>
> One would imagine, but correct me if I'm wrong, that the designers of
> all of the above mentioned languages prefer their language over the
> others.
>
> Ruby appeared sometime after Python. Yukihiro Matsumoto looked at
> Python and other languages, and then wrote the language that he wanted
> to use. Even so, there are still people who prefer Python (or other
> languages) and will never switch to Ruby, even though Ruby was
> designed after Python, and is better in the eyes of Yukihiro. Yukihiro
> might just happen to think that Ruby is the Universal Language.
>
> The same happened with Arc (and the other recent lisps). I would
> imagine that in Paul Graham's eyes, Arc is the Universal Lisp. Yet
> even though it was designed much later than CL and Scheme, there are
> still people... etc. etc. ... better in the eyes of Paul.
>
> *Even if* you were to design a super-duper language which you thought
> exceeded the others in every way, not everyone will agree with you
> that its the best way of doing things.
>
> So my conclusion is that you don't need other people to agree on which
> language is better than all the others and have everyone using the
> same thing. The only important thing is that *your* favourite language
> has sufficient libraries to do what *you* want in the time-frame you
> want. They all do some things differently and they all have their
> reasons for it. If your favourite language doesn't have these
> libraries, the choice is to either write some, or look at your second
> favourite language.
What you say is obvious. Except, that you just don't get, that I'm not
talking about *my* language.
And you miss the fact, that many of the abovementioned people in some
point in time either based their work on CL, or compared it with CL,
or took a lot of ideas from CL. So my assumption is that if CL was
even more universal, they could just do everything in CL (Like me :).
And actually I don't care so much about the libraries, because I can
easily find what I need or write it, if necessary. I care more about
conceptual ideas, which those prominent people can come up with).
Cheers,
Vsevolod
Vsevolod wrote:
> Ali wrote:
>> So my conclusion is that you don't need other people to agree on which
>> language is better than all the others and have everyone using the
>> same thing. The only important thing is that *your* favourite language
>> has sufficient libraries to do what *you* want in the time-frame you
>> want. They all do some things differently and they all have their
>> reasons for it. If your favourite language doesn't have these
>> libraries, the choice is to either write some, or look at your second
>> favourite language.
> What you say is obvious. Except, that you just don't get, that I'm not
> talking about *my* language.
But you are, in a way.
You're talking about the language that's better in your eyes. But the
point Ali was making (and the point Dan Weinreb was making earlier) is
that there's no objective criteria for "high-level" or "universal." I
think you have to decide first exactly what you mean. And having made
up your mind, you can only carry through the idea by coding it up, and
seeing whether other people like it.
Specifically; I encourage you to write a lisp system. It doesn't have
to be big or terribly robust to give you a lot of perspective and ways
to approach problems. And this is the important part: when people see
and use it, they will learn about different ways lisps can be. That's
how a community learns the things they need to know to design the lisp
you actually want. There are a lot of new users in Lisp right now and
they bring with them new energy and new inexperience. They need to see
many dialects to get a good sense of lispy language design. They need,
too, to see many dialects to get the feeling they're allowed to design
their own. And it is the ferment of new ideas that those lisp newbies
can bring about that will result in the advancement of lisp you've let
us know you want.
I wrote a lisp. And it's not hard; it's practically a rite of passage
for lispers. You can make one by yourself, as Kent Pitman said just a
few days ago, in a couple of weeks. I picked specific things I wanted
in the language I write code in, and specific things I needed just for
the particular application domain I intend to use the language in, and
coded to that specification.
You've said you think "universality" means that users of all languages
should find the new language acceptable. My friend, that's just never
going to happen. Face it, the users include Xah Lee who believes that
fully parenthesized prefix notation is a manifestation of evil, and so
folks like me who will never agree with him about that will never find
acceptable the same languages he does.
My specific application for lisp on the other hand, requires what I'll
call "universality" -- I'm using it to represent abstract syntax trees
of programming languages in a compiler suite. My goal is the creation
of a dialect in which a direct parse of the target language yields the
syntax tree of the program, and the syntax tree represented in my lisp
dialect, plus appropriate function definitions, will exactly represent
the semantics of the program. My goal is to make a computing "Rosetta
stone" system in which it doesn't matter what language individual bits
of code are written in. An appropriate front-end for each language to
render its parse trees as lisp and assign semantics to its forms would
allow code written in that language to work together with code written
in any other supported language. And of course, it should be possible
to support any extant language. So, I can define "universality" by an
objective criterion - the ability to duplicate the semantics of almost
all other computer languages. In the long run, I hope writing parsers
plus omegalisp descriptions of language semantics will suffice as both
formal semantics and implementation for computer languages, and that a
translation of any code from any language into omegalisp be sufficient
to allow all that code to interoperate freely. But I know that I will
have to push the boundaries of compiler and interpreter technology for
an acceptably fast implementation, so this is a long-term project.
Bear
On Sep 2, 12:43 pm, Vsevolod <········@gmail.com> wrote:
> On Sep 2, 11:16 am, Dan Weinreb <····@alum.mit.edu> wrote:
>
> > I'm having trouble understanding your criteria for a language to be
> > "high-level" and for it to be "universal". You discuss various
> > improvements that could be made to Common Lisp, but exactly what does
> > a language have to achieve to be "high-level", and what must it
> > achieve to be "universal"?
>
> > Of course high-level languages provide efficient means of abstraction,
> > and one could even say that they are higher-level to the extent that
> > they provide more and better means of abstraction. But surely Java
> > provides all kinds of abstraction. What's the specific bar that needs
> > to be passed? I disagree with you that there's a common feeling that
> > we all share. Rather, I think it is a matter of degree.
>
> By universal [Lisp] I mean the one, which will be accepted by all the
> interested parties: those, who prefer Scheme over CL (for production
> systems, not for teaching), those, who express a strong desire to have
> static typing. As well, by those, who start such projects, as Arc,
> Clojure and other Lisp variants, instead of embracing CL. Maybe, after
> all, even by those who say, that Ruby/Python/Javascript/etc is an
> acceptable Lisp, meaning, that CL is not.
> Surely, I don't know, if such a language is at all possible, and, even
> more, needed...Or maybe it's just a matter of attitude.
> But, at least the demands to it can be formulated.
>
> Speaking about high-level, I know, that I've made an undersupported
> claim, because I can't give some good definition. Moreover, I think
> it's a kind of a philosophical question, but I believe, that Common
> Lispers at least in this direction have a similar philosophy (I derive
> this from my experience with the language and discussions I see about
> it among it's users). For me, the language is high-level if it
> supports the basic abstractions worked out by decades of computer
> science development, as well as gives ways to define your own
> abstractions (which is best realized in CL macro-system).
>
> The single paradigm languages often limit you in this aspect. I can
> argue, why Java isn't high-level (at least in all aspects): because
> function in it is not a first-class object, and function, no matter,
> weather it's viewed as a side-effect free transformation (like in
> functional languages) or as a general computation (as in Lisp) is the
> primary means of abstraction. This brings to the situation, when many
> algorithms need to be expressed in some unnatural way in Java. But,
> for sure it has a lot of support for abstraction, and, obviously, it's
> not an assembler, where you you are limited to a predefined set of
> operations. But even Assembler is Turing complete.
>
>
>
> > Starting a community process to come up with a new language
> > definition, whether upward-compatible with Common Lisp or not, is
> > easy, but completing the process is very hard. Getting consensus on
> > language design issues is a great deal of work. I remember pretty
> > clearly how hard it was to forge together the original "Common Lisp:
> > The Language". And now, there are eleven implementations, and you'd
> > somehow have to get all of them to agree to all of the changes.
>
> > I hope that we can have some good discussions at the International
> > Lisp Conference about the possible directions that the community can
> > take to solve some of the major problems in Common Lisp today.
> > Regarding what is a "problem", there will be more agreement on some
> > than on others. Probably everybody agrees that the absence of
> > standardized thread support is a problem. I think that it's a problem
> > that we don't explicitly specify what conditions are signaled for all
> > (or, as many as possible) unusual outcomes, but maybe other people
> > don't care so much, or maybe the implementers consider it too much
> > trouble. Is it a "problem" that tail recursive calls are not defined
> > to not use up the stack? That one's harder!
>
> I can only add my voice to others, who think the process of evolving a
> language for Common Lisp is important at least to incorporate in it
> the individual achievements made throughout the years of it's use.
> And I think, that CDR.eurolisp.org is a good step in that direction,
> alas not very much supported yet.
> As for me, I'm just a user and I'll try to participate if I can add
> some value.
>
> Thanks for your reply
> Vsevolod
I don't think it's possible to make one language (one dialect of Lisp)
that will satisfy such a heterogeneous audience. Different people
have different constraints and different preferences. If you gathered
a list of important desired language features and attributes from such
a wide audience, you'd find many conflict that could not be resolved
elegantly enough.