I was reading McCarthy's original paper,
http://www-formal.stanford.edu/jmc/recursive/recursive.html
among other things to take a look at those legendary
M-expressions. They seem a fairly reasonable starting point for a
"new" programming language. Does anybody know if this notation was
ever fully defined? Do there exist translators for M-expressions <-->
S-expressions?
My idea was that this would be a great way of making Lisp more
palatable to all those folks who barf at the notation. You could have
.lisp files written in S-expressions by those who dig that notation,
and .limp (probably not a good name) files written in M-expessions for
those who dislike it.
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> I was reading McCarthy's original paper,
>
> http://www-formal.stanford.edu/jmc/recursive/recursive.html
>
> among other things to take a look at those legendary
> M-expressions. They seem a fairly reasonable starting point for
> a "new" programming language. Does anybody know if this
> notation was ever fully defined?
You might want to look at
http://makeashorterlink.com/?U5A011972
> Do there exist translators for M-expressions <-->
> S-expressions?
Probably, but I don't think anybody would want to use it. As it
turned out, working with S-expressions directly is much easier.
> My idea was that this would be a great way of making Lisp more
> palatable to all those folks who barf at the notation.
Probably not. This has been tried before. Look where it got the
Dylan folks ;-)
> You could have .lisp files written in S-expressions by those
> who dig that notation, and .limp (probably not a good name)
> files written in M-expessions for those who dislike it.
They'd have a hard time with macros, though.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Nils Goesche <···@cartan.de> writes:
> Mario S. Mommer <········@yahoo.com> writes:
>
> You might want to look at
>
> http://makeashorterlink.com/?U5A011972
McCarthy says here
http://makeashorterlink.com/?P50112972
(last paragraph) that he never fully defined it.
> > Do there exist translators for M-expressions <-->
> > S-expressions?
>
> Probably, but I don't think anybody would want to use it. As it
> turned out, working with S-expressions directly is much easier.
Well, not me and not you, but maybe those who are shocked by the
paretheses could use this for their first steps.
> > You could have .lisp files written in S-expressions by those
> > who dig that notation, and .limp (probably not a good name)
> > files written in M-expessions for those who dislike it.
>
> They'd have a hard time with macros, though.
I know, I know. The use I have in mind is as a way to get newbies
hooked :^)
Mario.
In article <··············@cupid.igpm.rwth-aachen.de>,
Mario S. Mommer <········@yahoo.com> wrote:
> I was reading McCarthy's original paper,
>
> http://www-formal.stanford.edu/jmc/recursive/recursive.html
>
> among other things to take a look at those legendary
> M-expressions. They seem a fairly reasonable starting point for a
> "new" programming language. Does anybody know if this notation was
> ever fully defined? Do there exist translators for M-expressions <-->
> S-expressions?
>
> My idea was that this would be a great way of making Lisp more
> palatable to all those folks who barf at the notation. You could have
> .lisp files written in S-expressions by those who dig that notation,
> and .limp (probably not a good name) files written in M-expessions for
> those who dislike it.
The problem discovered in doing pretty much the M-expression thing with
Dylan was macros. Everything else works fine, but it's really really
hard (impossible, I suspect) to allow users to write custom macros in an
idiomatic way for S-expressions, OR an idiomatic way for Algol-like
syntax, and translate automatically and idiomatically between the two.
*Especially* when people don't even agree what is idiomatic in
S-expressions. e.g. note the differences in syntax between "do" and
"loop". "loop" in CL is very much what everything is like in Dylan, so
if an infix Dylan programmer makes up a new macro similar to "loop" [1],
should it be presented to an S-expr Dylan programmer in something
similar to "do" or something similar to "loop"??
The only solution I can see is to make the programmer explicitly specify
*both* syntaxes when they write the macro (effectively write two
different macros implementing the same abstraction). That seems
unlikely to fly.
-- Bruce
[1] which of course Dylan already has, in "for"
Bruce Hoult <·····@hoult.org> writes:
> The problem discovered in doing pretty much the M-expression thing with
> Dylan was macros. Everything else works fine, but it's really really
> hard (impossible, I suspect) to allow users to write custom macros in an
> idiomatic way for S-expressions, OR an idiomatic way for Algol-like
> syntax, and translate automatically and idiomatically between the two.
I was thinking on the lines of having some part of the language in two
notations. One for people that dig S-expressions and one for those
that don't. There are many things you can do in lisp without needing
to write a macro yourself.
The idea comes from reading in Grahams site that Python is Lisp minus
macros. If that flies so well, we could do it "natively". A lot of the
power of lisp would be there. Speed among other things. If someone
feels like using macros, then they have S-expressions just around the
corner.
Since the main problem with Lisp for a lot of people are the
parentheses, why not give them what they want? I mean, if it's nothing
else... After all it is true that it is hard to deal with the
parentheses if you do not have an editor that helps you.
> The only solution I can see is to make the programmer explicitly specify
> *both* syntaxes when they write the macro (effectively write two
> different macros implementing the same abstraction). That seems
> unlikely to fly.
And if it flew it would be rather ugly. But maybe one could leave that
as an option, so that this secondary lenguage remains extensible.
Another possibility would be to implement this in two layers: the
macro, and a syntactic interface on top of it.
Mario.
P.S : I think the complaint on makeashorterlink is legitimate and I
promise not to use that again.
Mario S. Mommer wrote:
> Since the main problem with Lisp for a lot of people are the
> parentheses, why not give them what they want?
I don't think you realize that we have parentheses precisely to drive
those people away.
> After all it is true that it is hard to deal with the
> parentheses if you do not have an editor that helps you.
But you do have an editor that helps you. And with that, editing ()s is
massively easier than editing non-() code.
btw, Lisp macros are way too cool to give up.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Mario S. Mommer wrote:
> > Since the main problem with Lisp for a lot of people are the
> > parentheses, why not give them what they want?
>
> I don't think you realize that we have parentheses precisely to drive
> those people away.
:-)) Now that's a well designed feature, then. Whose idea was it? ;)
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> The idea comes from reading in Grahams site that Python is Lisp minus
> macros.
[...]
> Since the main problem with Lisp for a lot of people are the
> parentheses, why not give them what they want?
I think people say that the parentheses are the problem, but I think
that might be a red herring. I think the problem is that you
(basically) have to learn by rote which forms are function calls and
which are statements, to use a term familiar to non-Lispy people.
(dolist (element list)
(incf a (+ element 10)))
Now, what on earth does that do? If `dolist' is a function, then
`(element list)' is also a function call, and, er, the non-intrepid
programmer just stops and says "but it's all parentheses. I give up."
But that's not the problem. Probably.
Python, on the other hand, is nothing like Lisp minus macros. It's
perfectly clear, even if you've never seen Python before, but have
seen either C, Perl, Java or Basic, what are variable assignments,
where loops happen, and where functions are called.
--
(domestic pets only, the antidote for overdose, milk.)
·····@gnus.org * Lars Magne Ingebrigtsen
In article <··············@quimbies.gnus.org>,
Lars Magne Ingebrigtsen <·····@gnus.org> wrote:
> I think people say that the parentheses are the problem, but I think
> that might be a red herring. I think the problem is that you
> (basically) have to learn by rote which forms are function calls and
> which are statements, to use a term familiar to non-Lispy people.
This is *precisely* the reason for my preference for Dylan syntax over
CL&Scheme. Things with non-standard evaluation orders are so different
to function calls that they should also in my opinion *look* different.
-- Bruce
Mario S. Mommer wrote:
> Bruce Hoult <·····@hoult.org> writes:
>> The problem discovered in doing pretty much the M-expression thing with
>> Dylan was macros. Everything else works fine, but it's really really
>> hard (impossible, I suspect) to allow users to write custom macros in
>> an idiomatic way for S-expressions, OR an idiomatic way for Algol-like
>> syntax, and translate automatically and idiomatically between the two.
>
> I was thinking on the lines of having some part of the language in two
> notations. One for people that dig S-expressions and one for those that
> don't. There are many things you can do in lisp without needing to write
> a macro yourself.
>
> The idea comes from reading in Grahams site that Python is Lisp minus
> macros. If that flies so well, we could do it "natively". A lot of the
> power of lisp would be there. Speed among other things. If someone feels
> like using macros, then they have S-expressions just around the corner.
Mario, I think the problem space where infix notation is more useful than
prefix notation is very small. It's basically where you have lots of
mathematics that you don't want to have to translate to prefix notation.
And for that the infix package is available:
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
> Since the main problem with Lisp for a lot of people are the
> parentheses, why not give them what they want? I mean, if it's nothing
> else... After all it is true that it is hard to deal with the
> parentheses if you do not have an editor that helps you.
I suspect it is also hard to deal with Python whitespace without an editor
that helps you.
People seem to be able to cope with XML syntax and that syntax is little
more than verbose s-expressions (where the closing bracket is replaced by
a repeat of the prefix name).
>> The only solution I can see is to make the programmer explicitly
>> specify *both* syntaxes when they write the macro (effectively write
>> two different macros implementing the same abstraction). That seems
>> unlikely to fly.
>
> And if it flew it would be rather ugly. But maybe one could leave that
> as an option, so that this secondary lenguage remains extensible.
>
> Another possibility would be to implement this in two layers: the macro,
> and a syntactic interface on top of it.
If you use the infix package for ideas you should be able to build your
own infix layer. And it could run at a similar speed as native code
depending upon the implementation you use.
Bruce is also a Dylan expert. Look at Dylan's history to see whether
providing infix notation is really the significant thing holding back
adoption of Lisp.
BTW I'm sure you realise but for the benefit of newbies not a single
parenthesis in Lisp is redundant.
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> writes:
> Mario S. Mommer wrote:
> > The idea comes from reading in Grahams site that Python is Lisp minus
> > macros. If that flies so well, we could do it "natively". A lot of the
> > power of lisp would be there. Speed among other things. If someone feels
> > like using macros, then they have S-expressions just around the corner.
>
> Mario, I think the problem space where infix notation is more useful than
> prefix notation is very small.
I agree. The only use for such a secondary toy language would be to
make a point, and that was what I had in mind. But this point does not
really have to be made. After sleeping over it, I don't think any
longer that this is a good idea.
> It's basically where you have lots of
> mathematics that you don't want to have to translate to prefix notation.
> And for that the infix package is available:
> http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
As a matter of fact, I think that even for mathematical expressions
S-expressions are superior because they leave no doubt about what is
meant. Mathematical notation is often crufty itself, a point well made
here :
http://www-swiss.ai.mit.edu/~gjs/6946/sicm-html/book-Z-H-4.html#%_chap_Temp_2
> People seem to be able to cope with XML syntax and that syntax is little
> more than verbose s-expressions (where the closing bracket is replaced by
> a repeat of the prefix name).
I would make that: people are able to cope with XML syntax,
period. People are dealing every day with fairly medieval notations
without complaining.
> BTW I'm sure you realise but for the benefit of newbies not a single
> parenthesis in Lisp is redundant.
right!
Regards,
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> I was thinking on the lines of having some part of the language in two
> notations. One for people that dig S-expressions and one for those
> that don't. There are many things you can do in lisp without needing
> to write a macro yourself.
Well, one of the main drawbacks of that is that anyone who wnated to use
M-expressions would need to learn two representations, namely the
M-expressions and S-expressions. Even if you always program in the
M-language, you still need to understand S-expressions in order to
understand how the ubiquitous list manipulation code works.
So, in a sense, what happens is that the only people for whom
M-expressions are presumably an advantage -- people converting to Lisp
from other languages -- have the additional burden of learning two
languages instead of one. I suspect that is why initial (and
subsequent) attempts to actually use M-expressions for lisp have largely
fallen by the wayside. Why make things more complicated for novices
than for experts?
That plus the fact that really using the power of the language means you
will eventually need to become intimately familiar with s-expressions
pretty much means that the time spent on m-expressions is really a
waste.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
Mario S. Mommer wrote:
> I was reading McCarthy's original paper,
>
> http://www-formal.stanford.edu/jmc/recursive/recursive.html
>
> among other things to take a look at those legendary
> M-expressions. They seem a fairly reasonable starting point for a
> "new" programming language. Does anybody know if this notation was
> ever fully defined? Do there exist translators for M-expressions <-->
> S-expressions?
>
There used to exist something called MLISP, which used M-expressions
(i.e., infix syntax) as a front end to Lisp. It was in use at Yale in
the mid-seventies. I believe it is the same as the MLISP referred to in
the following Stanford tech reports:
# [ENE68]Enea, H.: MLISP, Stanf. Univ., Comp. Science Dep., Techn. Rep.
CS 92, Stanford, March 14, 1968
# [SMi70]Smith, D.C.: MLISP, Stanf. Univ., A.I. Proj., AIM-135, CS Dep.,
Rep. CS-179, Stanford, Oct. 1970
# [SMI69]Smith, D.C.: MLISP User's Manual, Stanf. Univ., Stanf. Art.
Intel. Project, Memo AI-84, Stanford, January 1969
(gleaned from a bibliography I found through Google at
http://www8.informatik.uni-erlangen.de/html/lisp/HISTK6.html)
As others have commented, there is no good reason to prefer
M-expressions to S-expressions, and a very good reason not to --- infix
notation conceals the closeness of Lisp's abstract and concrete
syntaxes. (Or, put another way, it conceals the fact that Lisp programs
are also Lisp data structures with the same hierarchical structure.)
Hence MLISP died out. There may still be a lexer/parser out there, however.
-- Drew McDermott
In article <················@yale.edu>, Drew McDermott
<··············@yale.edu> wrote:
>There used to exist something called MLISP, which used M-expressions
>(i.e., infix syntax) as a front end to Lisp. It was in use at Yale in
>the mid-seventies. I believe it is the same as the MLISP referred to in
>the following Stanford tech reports:
>
># [ENE68]Enea, H.: MLISP, Stanf. Univ., Comp. Science Dep., Techn. Rep.
>CS 92, Stanford, March 14, 1968
>
># [SMi70]Smith, D.C.: MLISP, Stanf. Univ., A.I. Proj., AIM-135, CS Dep.,
>Rep. CS-179, Stanford, Oct. 1970
>
># [SMI69]Smith, D.C.: MLISP User's Manual, Stanf. Univ., Stanf. Art.
>Intel. Project, Memo AI-84, Stanford, January 1969
>
>(gleaned from a bibliography I found through Google at
>http://www8.informatik.uni-erlangen.de/html/lisp/HISTK6.html)
Yep. The parser (written in Lisp) came from Stanford.
Drew McDermott <··············@yale.edu> writes:
> Mario S. Mommer wrote:
> There used to exist something called MLISP, which used M-expressions
> (i.e., infix syntax) as a front end to Lisp. It was in use at Yale in
> the mid-seventies. I believe it is the same as the MLISP referred to
> in the following Stanford tech reports:
MLISP and M-LISP. Yes. These and google starts to speak!
> # [ENE68]Enea, H.: MLISP, Stanf. Univ., Comp. Science Dep.,
> Techn. Rep. CS 92, Stanford, March 14, 1968
>
> # [SMi70]Smith, D.C.: MLISP, Stanf. Univ., A.I. Proj., AIM-135, CS
> Dep., Rep. CS-179, Stanford, Oct. 1970
>
> # [SMI69]Smith, D.C.: MLISP User's Manual, Stanf. Univ.,
> Stanf. Art. Intel. Project, Memo AI-84, Stanford, January 1969
I'll look at them. Thanks for the references.
> As others have commented, there is no good reason to prefer
> M-expressions to S-expressions, and a very good reason not to ---
> infix notation conceals the closeness of Lisp's abstract and concrete
> syntaxes.
Yes, you are right. But I'm not saying that this is a good idea. I
think it has value at least as a historical item, since this is how
things were supposed to be, but they never happened that way. Btw, is
there any other example of a language deciding more or less by itself
what notation is right? :-)
It could also have avlue as something from which newcomers can learn a
couple of things. Among others, exactly the reason why there are "so
many" parens. We /could/ have a different notation. But after a while
it should be clear this is silly: This S-expression notation is in
fact the one that is natural.
Anyway, I don't plan anything but a very basic compiler. It should
compile to S-expressions, of course.
Mario
Mario S. Mommer wrote:
> I
> think it has value at least as a historical item, since this is how
> things were supposed to be, but they never happened that way. Btw, is
> there any other example of a language deciding more or less by itself
> what notation is right? :-)
In general, no, since most other languages do not expose an alternate syntax
to prefer. There have been additions and stylistic guidelines that have
eventually forced out older syntactic structures (e.g., Hollerith strings
in Fortran), but in general, these have been few, far between, and not
nearly as in-depth as the ones that show up in Lisp (CLOS vs. message
sending paradigms, introduction of new datatypes, etc.).
In addition, most languages do not allow the range for experimentation as
Lisp did - most new ones are tied to their creators via a "cult of
personality" and will not admit interesting change without the linguistic
ubermensch passing it through (e.g., Perl, Eiffel, C++, etc.). This forces
anyone who wishes to introduce any new feature (again, few and far between)
to re-invent the same semantic (and often syntactic) wheels so that they
can tweak it in only one small area.
All-in-all, the computing community owes a great debt to McCarthy for
"getting out of the way". But I guess it was inevitable -- I don't think
he ever saw Lisp, qua language, as all that interesting. Instead, he saw
it as a tool for accomplishing more interesting things. In fact, I
sometimes wonder if studying and designing languages as tools for general
computing has come to a useful end. Certainly, most of the interesting
work is being done in application-specific arenas these days and besides,
we all know that Lisp *is* the ultimate as far as "general purpose"
languages go anyway :-).
faa
> In addition, most languages do not allow the range for experimentation as
> Lisp did - most new ones are tied to their creators via a "cult of
> personality" and will not admit interesting change without the linguistic
> ubermensch passing it through (e.g., Perl, Eiffel, C++, etc.). This forces
> anyone who wishes to introduce any new feature (again, few and far between)
> to re-invent the same semantic (and often syntactic) wheels so that they
> can tweak it in only one small area.
>
> All-in-all, the computing community owes a great debt to McCarthy for
> "getting out of the way".
Hmm. It seems fairly clear to me that Perl and C++ would have
been (even) worse languages without the continued involvement
of their respective creators. Eiffel, I'm not so sure about.
Python, another language I'm familiar with that has a very
strong "authorial" input (Guido van Rossum is universally
known as the "Benevolent Dictator for Life" in Python circles),
has also clearly benefited overall from this. Most languages
are more in need of restraint than of innovation. It's actually
quite interesting that Lisp has managed to remain so beautiful
without a single presiding genius[1] at the helm.
[1] I mean this word in its original sense, though in fact
Wall, Meyer, Stroustrup and van Rossum are all very
clever indeed. Despite the deficiencies of the languages
they have created.
--
Gareth McCaughan ················@pobox.com
.sig under construc
"Frank A. Adrian" <·······@ancar.org> writes:
> I sometimes wonder if studying and designing languages as tools for
> general computing has come to a useful end. Certainly, most of the
> interesting work is being done in application-specific arenas these
> days and besides, we all know that Lisp *is* the ultimate as far as
> "general purpose" languages go anyway :-).
Possibly, seeing as ML and Prolog didn't take over the world or even
influence other types of languages very much. OTOH, I have this quote
from Alan Kay, that I sometimes use as a .sig: "The great problem with
Lisp is that it is just good enough to keep us from developing
something really good." I suppose the designers of Dylan felt that
way.
There is one more stage in the evolution of computer languages that I
can see: proof-carrying code. Such systems have existed for a while,
but perhaps there's a break-trough yet to be made to express the
theoretical unity of a program and its correctness proof in a notation
that makes it truly convenient to work with. Probably, like modern
Lisps, its true utility will be available only through a suite of
tools included in it or associated with it (INSPECT, MACROEXPAND,
Emacs, GC tuning, etc.).
--
Pekka P. Pirinen
(for .sig, see above)
Pekka P. Pirinen wrote:
> "Frank A. Adrian" <·······@ancar.org> writes:
>
>>I sometimes wonder if studying and designing languages as tools for
>>general computing has come to a useful end. Certainly, most of the
>>interesting work is being done in application-specific arenas these
>>days and besides, we all know that Lisp *is* the ultimate as far as
>>"general purpose" languages go anyway :-).
>
>
> Possibly, seeing as ML and Prolog didn't take over the world or even
> influence other types of languages very much.
This is slightly off topic, but logic programming has a little
renaissance over there in the AOSD community, in the form of logic meta
programming. I think that's very interesting stuff.
Pascal
--
Given any rule, however �fundamental� or �necessary� for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
On 16 Nov 2002 22:13:03 +0100, Mario S. Mommer <········@yahoo.com> wrote:
> ever fully defined? Do there exist translators for M-expressions <-->
> S-expressions?
Did a version of Interlisp (Interlisp-C?) have an M-expression-ish flavor?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README