"C-like" syntax for Lisp in less than 100 lines of code
Alessio Stalla
syntax for Lisp, part as a proof of concept, part with the intention
of actually using it in a library. It's not meant to replace sexps but
just to be less scary for newbies AND to show that the syntax argument
against Lisp is just dumb. I'd never use it myself of course ;)
The syntax is based on the Lisp reader, with these simple rules:
, (comma) is considered whitespace.
expressions are separated by ;
( ) still delimit lists.
expressions consisting of multiple tokens are automatically wrapped in
a list. Expressions consisting of a single token are not listified, so
foo is read as a symbol while (foo) as a list.
foo { ... } is roughly like `(foo ,@(list ...)) i.e. the expressions
inside the braces are inserted in the outer expression.
That's pretty much all, and it turns out - surprisingly - to cover
many common expressions you can find in Lisp. Plus, reader macros
still work (though of course they don't understand the "C-like"
syntax).
An example:
with-output-to-string (str) {
print #\c str;
if (> foo 45) {
progn { print 3; print 4; }
print 5;
}
}
If anyone's interested, the code is here:
http://alessiostalla.altervista.org/software/c-like-lisp/cll.lisp
it's far from perfect; for example, braces inside lists are read as
literal characters. But, as a quick hack it came out pretty good,
imho.
Cheers,
Alessio
Slobodan Blazeski
> I have coded some simple syntax sugar to provide a vaguely "C-like"
> syntax for Lisp, part as a proof of concept, part with the intention
> of actually using it in a library.
Burn the witch.
grucidipo
Perhaps you should find interesting Maxima, it is based in Lisp and
use a C-like syntax, you can define operators and obtain the desired
preference using left and right binding power. It also has a way of
declaring the type of the arguments in order to translate to lisp with
optimize for speed setting.
I have been doing google code-jam problems for improving my Lisp
skills and project euler, but I still find it easier to use python.
Emacs is better than idle, you can redefine functions on the fly with
alt-e ctr-e, in python you must copy and paste the function definition
in the shell (python repl).
I also think that the current thread about improving asdf could be
better used if used with maxima.
o.ja...@gmail.com
once too(http://www.lispforum.com/viewtopic.php?
f=20&t=300&p=2044&hilit=unlisp#p2044, just ftr, it sucks), i don't
think it is all that bad an idea, if it gets nubs to use lisp.. But we
don't want them using a dozen different ones.. Perhaps try emulate
something like Python closely..(Or just be plain compatible with
it :).)
> I also think that the current thread about improving asdf could be better used if used with maxima.
What do you mean? You mean Maxima should use (the newer)asdf? I don't
get why maxima isn't asdf-installable at this point.. (And multiple
asd files please.. for instance the alternate syntax should probably
be a separate package & system..
Peter Keller
> An example:
>
> with-output-to-string (str) {
> print #\c str;
> if (> foo 45) {
> progn { print 3; print 4; }
> print 5;
> }
> }
How would you write a macro to do a non-trivial code transformation in the
above syntax?
-pete
Alessio Stalla
As I said, it's not intended to replace S-expressions: what I meant is
that you cannot use it to write macros cleanly. I believe that if you
know macros then usually you are also convinced that sexp-based syntax
is the most powerful one possible (to write macros). The main use I
intend to do of this syntax is to provide it to end-users of a library/
DSL who potentially don't care about Lisp and macros at all. Of course
the advanced users, or those who already know Lisp, won't have any
reason to use the dumbed-down syntax.
And, since the syntax outputs Lisp forms, you can more-or-less
trivially convert from "C-like" to Lisp by means of reading and then
printing the forms.
Again, if it's not clear, the sense of my post was not to promote the
syntax to lispers (which is stupid), but to show how, with relatively
few lines of code, you can build a "C-like" mock syntax on top of the
Lisp reader. Of course to be really C-like it should be more polished
and feature-rich - say, infix operators, [] to access arrays and hash
tables, other corner cases I'm not aware of, ...
Cheers,
Alessio
Alessio Stalla
> Alessio Stalla wasn't be the first and won't be the last :), i did it
> once too(http://www.lispforum.com/viewtopic.php?
> f=20&t=300&p=2044&hilit=unlisp#p2044, just ftr, it sucks), i don't
> think it is all that bad an idea, if it gets nubs to use lisp..
I know I'm not the first ;) but I got struck by how simple it is to
pervert the reader :D and I wanted to share my impression.
> But we
> don't want them using a dozen different ones.. Perhaps try emulate
> something like Python closely..(Or just be plain compatible with
> it :).)
Python is harder to emulate using the Lisp reader because of
whitespace significance: I purposedly added the braces as an easy
device to form bodies of expressions, like often happens with macros.
Doing the same by parsing whitespace and keeping track of the
indentation level was overkill, considering I didn't really want to
cook up a full-blown parser but simply to use the reader by adding as
few parsing rules as possible. For the same reason, my syntax is not
really C-like because, for example, foo() is not a function invocation
with zero arguments but rather gets read to the form (foo nil).
Cheers,
Alessio
Peter Keller
> Again, if it's not clear, the sense of my post was not to promote the
> syntax to lispers (which is stupid), but to show how, with relatively
> few lines of code, you can build a "C-like" mock syntax on top of the
> Lisp reader. Of course to be really C-like it should be more polished
> and feature-rich - say, infix operators, [] to access arrays and hash
> tables, other corner cases I'm not aware of, ...
Ah, I understand the intention more fully now.
It really is a neat piece of code you wrote.
-pete
Tamas K Papp
> Alessio Stalla wasn't be the first and won't be the last :), i did it
> once too(http://www.lispforum.com/viewtopic.php?
> f=20&t=300&p=2044&hilit=unlisp#p2044, just ftr, it sucks), i don't think
> it is all that bad an idea, if it gets nubs to use lisp.. But we don't
I think that the intention of helping newbies may be laudable, but I
don't see the practical advantage. S-expressions (and macros) are
what makes Lisp powerful. With a C-like syntax, Lisp is not much
more powerful than a C-like language (with a few nice features thrown in,
eg Blub OO systems rarely ever come close to CLOS). The greatest help
one can give to newbies is help with learning CL as it is.
That said, it is a cool hack.
Tamas
Günther Thomsen
[..]
> I think that the intention of helping newbies may be laudable, but I
> don't see the practical advantage.
This comes up every now and then. I'm not sure whether this
parenthesis-paralysis is actually a real problem or an often-repeated
myth.
In any case, Dylan did away with the prefix-syntax and that wasn't
enough to make it popular (but of course, there might have been other
reasons or no reasons why it failed to gain popularity).
> S-expressions (and macros) are
> what makes Lisp powerful. With a C-like syntax, Lisp is not much
> more powerful than a C-like language (with a few nice features thrown in,
> eg Blub OO systems rarely ever come close to CLOS). The greatest help
> one can give to newbies is help with learning CL as it is.
Not sure about that. But why not start with a good book and classic
Scheme? Once through that, the student surely will be able to deal
with those parenthesis and can move on to CL, if so inclined.
>
> That said, it is a cool hack.
Sure. The Lisp world isn't lacking cool hacks though.
Tamas K Papp
> On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]
>
>> S-expressions (and macros) are
>> what makes Lisp powerful. With a C-like syntax, Lisp is not much more
>> powerful than a C-like language (with a few nice features thrown in, eg
>> Blub OO systems rarely ever come close to CLOS). The greatest help one
>> can give to newbies is help with learning CL as it is.
> Not sure about that. But why not start with a good book and classic
> Scheme? Once through that, the student surely will be able to deal with
> those parenthesis and can move on to CL, if so inclined.
I started with Scheme instead of CL, thinking that since it claims to
be "smaller", it would be easier to learn. The language seemed very
clever and abstract, but I felt that it required to force my thinking
into particular patterns/solutions, which were not natural to me (eg
the books I have used insisted on doing pretty much everything with
tail recursion). Based on Scheme, I formed the impression that Lisp
is a clever but impractical programming language (I didn't know much
about CL). Fortunately for me, a year later I decided to give CL a
chance, and I was hooked instantly.
Based on my experience, I would be wary of recommending Scheme to
newbies. Also, I think that the two communities are a bit different.
I have yet to encounter a book for Scheme that is comparable to PCL.
Most books for Scheme I have seen seem to care little about the
language per se, and try to expand on a particular theme instead (eg
how to do everything using recursion, the joys of call/cc). Macros
are not really emphasized (eg in the Dybvig book, they get a very thin
chapter towards the end, which is a puzzle).
Tamas
Peter Keller
> This comes up every now and then. I'm not sure whether this
> parenthesis-paralysis is actually a real problem or an often-repeated
> myth.
I've hacked scheme for a long time and lisp for a little while. I believe
there is such a thing as parenthesis-paralysis.
After some careful introspection upon it over the years, I've come to
a belief about how it arises and presents.
It appears to me to happen because of two concepts:
1. Indention style
2. Destructuring bind, as performed by a human reading code. :)
Indention style, especially in lisp, is _extremely_ important and
emacs/slime is the only thing that culturally "does it correctly out of
the box".
Most editor's notion of auto-indention is that when you hit return,
you align with the first non whitespace character on the previous line
OR you just indent X columns. Combine this with a regular joe's idea of
indention being <tab>, and you have a disasterous situation. For example
suppose my tab stops are set to 4 in the following example. Every place
you see a . is where I hit tab.
Like:
(let ((thing 42)
. (stuff 99)
. (qux 100))
. (format t "Hi~%"))
Looks like crap doesn't it?
In other block structured languages, a simple tab is sufficient for code
readability. E.G. C:
void foo(void)
{
. int thing = 42;
. int stuff = 99;
. int qux = 100
. printf("Hi\n");
}
Notice, from a mental model of indention, I did the *exact* same
behaviour. I indented the bindings, left a space, then indented
the body. People use the same mental model of indention for similar
languages. This realization is the key to why people entering lisp for
the first time have such a hard time about it.
Let's take a look at the original poster's precipitating example. If
your tab stop is set to 2, then this is _exactly_ how you would type it
using a regular editor's default notion of indention.
with-output-to-string (str) {
print #\c str;
if (> foo 45) {
progn { print 3; print 4; }
print 5;
}
}
We can hypothesize that the original author's mental model of code
indention appears to follow to the default behavior of their editor
and that they write in block structured imperative languages more often
than not. I believe they view this indention model as "correct".
In C, C++, PHP, perl, Java, python, fortran 90, etc, etc, etc, this is
just fine and leads to pretty readable code. Specifically in python,
it is enshrined.
In Lisp (and somewhat scheme), the default behavior of the editor and/or
the mental model of indention is completely wrong. Why? reason number 2.
Humans use visual whitespace and alignments of similar boundary markers to
block off semantically related entities. This helps them to "destructure"
the forms into meaningful sections or elements.
The correctly indented lisp form for the above let form:
(let ((thing 42)
(stuff 99)
(qux 100))
(format t "Hi~%"))
You can see how the parentheses of the binding forms are aligned with
each other. The ( which "sticks out" is the demarcation of the beginning
of the binding list. The fact the (format ...) is indented to the left
states the bindings are over and this tells you this is the body of the let.
Another one, more complex in lisp (done with bad indention):
(do ((x 0 (1+ x))
. (y 10 (1- y))
. (z 0 (1+ z)))
. ((zerop y) (+ x z))
. (format t "Hi!~%"))
That is terrible, since the test condition vanishes into the step
forms. Get rid of the newline in the middle and it is a train wreck. The
problem is, this is how editors want to do it by default! I've seen the
modern generation of programmers lately. They use pico, notepad, gedit,
or kde/gnome whatever to write their code. The editors all do this ham
fisted autoindent behavior and can't really be taught otherwise. I can't
imagine that while writing lisp. I would go insane.
The correct do form:
(do ((x 0 (1+ x))
(y 10 (1- y))
(z 0 (1+ z)))
((zerop y) (+ x z))
(format t "Hi~%"))
The main problem is that culturally, lisp doesn't indent at the same
quanta of indention as other languages over the various semantic forms of
the language. Sometimes you need 1/4 of an indention, or 1/2 of one, or
a one space difference. Programmers, when presented with such a problem,
spend their time laboriously aligning parenthesis so everything looks
right--because their editor doesn't do it for them! If they don't
know what looks right to begin with, they simply self converge to a
self-consistent form of indention and write all their code in it.
The paralysis continues when, not having been grounded in the cultural
indention style of lisp or not having an editor that performs it
automatically, you start reading other people's code. If you get unlucky
and read a collection of people's code that never learned the correct
cultural style (each having their own style), then the destructuring
process gets amazingly difficult to do. You end up reading character
by character, parenthesis by parenthesis, trying to figure out where
semantic forms start and end. The most powerful visual/spatial recognizer
in your head (like 1/4 of your brain matter is devoted to it!) sits
completely idle!
I hacked my emacs/slime syntax coloring to be very detailed and show many
different classes of semantic ideas: comments, ANSI functions, macros,
special forms, type names, special variables, constants, etc, etc, etc to
all be color coordinated with each other using color theory to give me
insight into what I've written--and whether I'm writing it correctly!
The most important change I did was to make the parenthsis color nearly
the same as the background color. In a sense they vanish and I'm left
with the spatial blocks as an indention structure, which works just
fine. I can always resolve a specific parenthesis from the background if
I have to to disambiguate a form. Usually, if I screwed something up,
the indention level of my codebase goes wrong and it is pretty easy
to find where I missed a parenthsis.
Oddly, lisp is the only language for which I do this, all others are
just white text on a black background and I prefer it that way. Syntax
highlighting is distracting to me in non lisp languages. It is a
requirement for lisp!
After serious use of colorizing/indention system slime and my hacks
provided me, I occasionally find that looking at non-colorized, but
correctly indented Lisp, is hard. The parentheses make a visual heavyness
that is hard to ignore; I almost read it as ALL CAPS style yelling. If
I'm looking at non-colorized and non-culturally indented lisp, I revert
to the "hunt and peck" method of trying to destructure the semantic
forms in my head. It gets frustrating very quickly.
I honestly believe parenthesis-paralysis is real. The right editor will make
the paralysis completely disappear, the wrong editor will accentuate it.
Later,
-pete
Peter Keller
> with-output-to-string (str) {
> print #\c str;
> if (> foo 45) {
> progn { print 3; print 4; }
> print 5;
> }
> }
After really studying this piece of code. I would say that you should not
use it for newbies, or really at all.
Here is my reasoning:
In Bourne shell:
if [ x -gt y ]; then
echo "hi"
else
echo "bye"
fi
In C:
if (x > y) {
printf("hi\n");
} else {
printf("bye\n");
}
In perl
if (x > y) {
print "hi\n";
} else {
print "bye\n";
}
In python:
if x > y:
print("hi\n");
else:
print("bye\n");
in your dialect:
if (> x y) {
format t "hi~%";
format t "bye~%";
}
That would be the source of so many conceptual and concrete errors in
a piece of code as to make someone axe their computer into pieces and
regret the day they ever started programming. You'd be lucky if they
don't hunt you down with a dull sledgehammer to teach you a lesson. :)
Don't suggest a conventional meaning with your grouping symbols which
is totally inconsistent with the actual meaning in many other popular
languages.
Later,
-pete
Tim Bradshaw
> This comes up every now and then. I'm not sure whether this
> parenthesis-paralysis is actually a real problem or an often-repeated
> myth.
I think, though, that there are places where you want other syntaxes.
I'm very happy programming in Lisp's native syntax, but I'd find an
algebra system which required that (and I have used such) a pain to use.
Rupert Swarbrick
<snip... the real point of the post: sorry!>
> I hacked my emacs/slime syntax coloring to be very detailed and show many
> different classes of semantic ideas: comments, ANSI functions, macros,
> special forms, type names, special variables, constants, etc, etc, etc to
> all be color coordinated with each other using color theory to give me
> insight into what I've written--and whether I'm writing it correctly!
>
> The most important change I did was to make the parenthsis color nearly
> the same as the background color. In a sense they vanish and I'm left
> with the spatial blocks as an indention structure, which works just
> fine. I can always resolve a specific parenthesis from the background if
> I have to to disambiguate a form. Usually, if I screwed something up,
> the indention level of my codebase goes wrong and it is pretty easy
> to find where I missed a parenthsis.
Hi,
This sounds interesting to play with: did you stick the theming changes
you made into a file you could pass around? I've been lazy and tend to
stick with either the default emacs theme or a low contrast one called
zenburn. But it would be really interesting to have a look at one
designed by someone for use writing lisp!
About the actual point of your post, it's unfortunate that "modern" text
editors (gedit, kate, notepad++ etc.) lack the extensibility to turn
them into useful platforms for writing lisp. And your point about
indentation is exactly what's required (and difficult!). Fluffy brown
ubuntu theming and emacs don't really look beautiful together (yes, even
with emacs23) and emacs is _hard_ to get started with, which means that
even your average 1st year compsci student ain't gonna be using
emacs. Of course, that dooms them to a lifetime writing java for
ecommerce, but I guess they don't know that at the time.
Unfortunately, you're unlikely to convince a dedicated emacs user to
spend hours a week trying to make something like gedit better for lisp
because, well, there's emacs to use instead... Oh and, no, I don't know
a solution!
Rupert
Pillsy
[...]
> This comes up every now and then. I'm not sure whether this
> parenthesis-paralysis is actually a real problem or an often-repeated
> myth.
I'm increasingly convinced that parentheses are the fundamental reason
that Lisp isn't a lot more popular than it is. Syntax really matters
to people, and the reasons it matters are rooted in subjective
judgements about "prettiness" or "ease of reading". It so happens that
a lot of programmers hate the parentheses for subjective reasons that
simply don't apply to Lisp users because if they applied, we wouldn't
be Lisp users.
> In any case, Dylan did away with the prefix-syntax and that wasn't
> enough to make it popular (but of course, there might have been other
> reasons or no reasons why it failed to gain popularity).
Sure, but it was pretty much not marketed. Counterfactuals are tough,
but I've always thought that if Dylan, rather than Java, had been the
language that Sun decided to throw all that weight behind, today
everybody would be complaining about it because their boss makes them
use it.
[...]
> Not sure about that. But why not start with a good book and classic
> Scheme?
I think Common Lisp is an easier language to learn than Scheme, with
its richer set of imperative constructs and much better support for IO
and object orientation. Learning Scheme involves drinking a bunch of
Kool-Aid, and the good Scheme books are at least as much about selling
you that Kool-Aid as they are about teaching you a new language.
Cheers,
Pillsy
Tamas K Papp
> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote: [...]
>> This comes up every now and then. I'm not sure whether this
>> parenthesis-paralysis is actually a real problem or an often-repeated
>> myth.
>
> I'm increasingly convinced that parentheses are the fundamental reason
> that Lisp isn't a lot more popular than it is. Syntax really matters to
That's like saying that the requirement to engage in abstract thinking
is the fundamental reason that makes (serious) mathematics unpopular.
Maybe. But there is nothing you can do about it: you can't make it
"easier" without making it uninteresting.
Likewise, it does not really make much sense to talk about how popular
Lisp would be without parentheses. Speculations on how fundamental
the SEXP syntax is to Lisp (and why Dylan failed etc) aside, no one
has demonstrated the existence of an equally powerful Lisp with a more
"conventional" syntax, so what the experiment/counterfactual would be
is not clear.
If someone invented a Lisp without parenthesis that is as powerful as
eg CL, we would be able to talk about whether the parens make Lisp
unpopular. Naturally, I am not holding my breath :-)
Personally, I grew to like Lisp syntax. But maybe this is a
preference that is heterogeneous in the population: people who like the
syntax or are willing to tolerate it for the extra power become Lisp
programmers, the rest don't. Not much we can do about this.
> I think Common Lisp is an easier language to learn than Scheme, with its
> richer set of imperative constructs and much better support for IO and
> object orientation. Learning Scheme involves drinking a bunch of
> Kool-Aid, and the good Scheme books are at least as much about selling
> you that Kool-Aid as they are about teaching you a new language.
Agreed. I almost gave up on Lisp because I started with books on
Scheme. It was years later when I learned that there are people who
write practical programs in (heavily extended dialects of) Scheme.
Tamas
Pillsy
> On Wed, 21 Apr 2010 07:04:14 -0700, Pillsy wrote:
> > I'm increasingly convinced that parentheses are the fundamental reason
> > that Lisp isn't a lot more popular than it is.
> That's like saying that the requirement to engage in abstract thinking
> is the fundamental reason that makes (serious) mathematics unpopular.
> Maybe.
I don't think this is a good analogy. Programming languages provide
specialized notations, and Lisp, by specializing its notation to make
metaprogramming convenient, forgoes some other possibilities that make
doing other things particularly convenient.
> But there is nothing you can do about it: you can't make it "easier"
> without making it uninteresting.
I think there's an engineering trade-off between ease of
metaprogramming and provision of syntactic sugar. A smallish number of
languages and users gravitate towards the Lisp end of the spectrum and
a much larger group of languages users gravitate towards the
everything-else end of the spectrum, and there's virtually nothing in
the middle. There are only a few attempts, and if you only have a few
attempts, the whole class of languages is a lot more likely to get
wiped out for unrelated economic reasons (like Dylan) or unrelated
technical blunders (like Mathematica).
[...]
> If someone invented a Lisp without parenthesis that is as powerful as
> eg CL, we would be able to talk about whether the parens make Lisp
> unpopular. Naturally, I am not holding my breath :-)
I think this sells CL short, because it has a lot of things beyond
parenthesized syntax that make it a worthwhile language. Any idiot can
write a Lisp---writing toy Lisp interpreters is a common exercise in
undergraduate CS classes---but writing a *decent* Lisp is much
harder.
Someone can break new and interesting ground in terms of allowing more
syntax while enabling structured manipulation of source code, but that
doesn't mean that they won't totally botch the rest of their language.
The cool syntactical possibilities are only going to go so far if your
IO and error handling mechanisms are completely busted and your only
implementation is a slow-like-molasses-on-Quaaludes interpreter.
> Personally, I grew to like Lisp syntax.
I did too. Actually, I discovered that I liked it almost immediately.
OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
the reason I'm so convinced of the role that personal preference plays
in this is that my own preferences seem to be so radically different
from most other programmers.
Cheers,
Pillsy
Tim Bradshaw
> I think there's an engineering trade-off between ease of
> metaprogramming and provision of syntactic sugar.
I think that's a good summary.
Tamas K Papp
> On Apr 21, 10:51 am, Tamas K Papp <tkp...@gmail.com> wrote:
>> But there is nothing you can do about it: you can't make it "easier"
>> without making it uninteresting.
>
> I think there's an engineering trade-off between ease of metaprogramming
> and provision of syntactic sugar. A smallish number of languages and
Good point.
>> If someone invented a Lisp without parenthesis that is as powerful as
>> eg CL, we would be able to talk about whether the parens make Lisp
>> unpopular. Naturally, I am not holding my breath :-)
>
> I think this sells CL short, because it has a lot of things beyond
> parenthesized syntax that make it a worthwhile language. Any idiot can
> write a Lisp---writing toy Lisp interpreters is a common exercise in
> undergraduate CS classes---but writing a *decent* Lisp is much harder.
>
> Someone can break new and interesting ground in terms of allowing more
> syntax while enabling structured manipulation of source code, but that
> doesn't mean that they won't totally botch the rest of their language.
> The cool syntactical possibilities are only going to go so far if your
> IO and error handling mechanisms are completely busted and your only
> implementation is a slow-like-molasses-on-Quaaludes interpreter.
I agree. But I would argue that the other nice features of CL also
owe their existence and polished state to CL's extensibility, which
stems from SEXPS that you can easily manipulate with macros.
AFAIK in the beginning, Lisp was rather a crude language by today's
standards. But the very extensibility of the language made it an
extremely fertile ground for experimentation: different dialects
emerged, and people came up with nice solutions to common problems.
When CL was formed, it could just incorporate many of these - the
designers of CL had a lot to build on.
I am not aware of any other language family that would incorporate
facilities for experimentation with new features to the extent that
Lisp does. So I don't think that it is a mere coincidence that CL is
so well-polished: it all comes from Lisp's fundamental
extensibility/flexibility. Which has a lot to do with SEXPs+macros.
Best,
Tamas
Alessio Stalla
Very good point! I hadn't noticed it because I'm accustomed to the
Lisp way, i.e., that most macros have one and only one body. In C and
similar languages, this is not the case; there are constructs with
multiple bodies, often separated by keywords.
I could try to work around this limitation - for example, having
{ ... } translate to (progn ...) and allowing multiple {}-bodies per
expression, as in
if foo { then-part; } { else-part; };
but I don't really want to do that; the syntax would become more
complicated, move further away from the underlying representation as a
Lisp form, and still not be surprise-proof (where's the else keyword,
for example?).
I guess the only way to solve the dilemma is to expose the syntax to a
number of C or Java programmers and see what they think. If the
majority thinks it's garbage, then better forget it and stick to
sexps. If they still find some value in it, it could be saved, maybe
with some modifications.
Thanks for your insight.
Cheers,
Alessio
Mario S. Mommer
Alessio Stalla <alessi...@gmail.com> writes:
> On 21 Apr, 08:02, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
>> in your dialect:
>>
>> if (> x y) {
>> format t "hi~%";
>> format t "bye~%";
>> }
>>
>> That would be the source of so many conceptual and concrete errors in
>> a piece of code as to make someone axe their computer into pieces and
>> regret the day they ever started programming. You'd be lucky if they
>> don't hunt you down with a dull sledgehammer to teach you a lesson. :)
> Lisp way, i.e., that most macros have one and only one body. In C and
> similar languages, this is not the case; there are constructs with
> multiple bodies, often separated by keywords.
> I could try to work around this limitation - for example, having
> { ... } translate to (progn ...) and allowing multiple {}-bodies per
> expression, as in
>
> if foo { then-part; } { else-part; };
How about a Algol/Pascal/Ada parser? I mean, conceptually everything can
be expressed as prefix, and Pascal has a failry sane notation, is
reasonably small, and the bnf grammar as well as a bnf parser for lisp
can be had for 0 cost.
The real advantage of such a notation is to not have that to be the
showstopper. People sometimes look at S-exprs and say "no way", and that
was it. Having one with a good canonical syntax is nice to avoid bad
karma. I.e. if that little syntax of yours becomes official policy at
some big customer's shop, then at least it is not too braindamaged.
Pascal J. Bourguignon
> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
> [...]
>> This comes up every now and then. I'm not sure whether this
>> parenthesis-paralysis is actually a real problem or an often-repeated
>> myth.
>
> I'm increasingly convinced that parentheses are the fundamental reason
> that Lisp isn't a lot more popular than it is. Syntax really matters
> to people, and the reasons it matters are rooted in subjective
> judgements about "prettiness" or "ease of reading". It so happens that
> a lot of programmers hate the parentheses for subjective reasons that
> simply don't apply to Lisp users because if they applied, we wouldn't
> be Lisp users.
We should tag "(this is a list)" in front of each primary school of the
world! :-)
--
__Pascal Bourguignon__
Peter Keller
> [-- text/plain, encoding 7bit, charset: US-ASCII, 44 lines --]
>
> Peter Keller <psi...@merlin.cs.wisc.edu> writes:
>
> <snip... the real point of the post: sorry!>
>
>> I hacked my emacs/slime syntax coloring to be very detailed and show many
>> different classes of semantic ideas: comments, ANSI functions, macros,
>> special forms, type names, special variables, constants, etc, etc, etc to
>> all be color coordinated with each other using color theory to give me
>> insight into what I've written--and whether I'm writing it correctly!
>>
>> The most important change I did was to make the parenthsis color nearly
>> the same as the background color. In a sense they vanish and I'm left
>> with the spatial blocks as an indention structure, which works just
>> fine. I can always resolve a specific parenthesis from the background if
>> I have to to disambiguate a form. Usually, if I screwed something up,
>> the indention level of my codebase goes wrong and it is pretty easy
>> to find where I missed a parenthsis.
>
> you made into a file you could pass around? I've been lazy and tend to
> stick with either the default emacs theme or a low contrast one called
> zenburn. But it would be really interesting to have a look at one
> designed by someone for use writing lisp!
I wrote up an extended blog post of the usenet post I wrote about
indention at:
http://pages.cs.wisc.edu/~psilord/blog/28.html
That post includes the color reasoning and emacs lisp which implements the
highlighter. I have a couple screenshots you can see of it. The emacs
lisp, is um, special, and by that I mean terrible. I don't know emacs
lisp and I'm surprised the Earth didn't implode from the sucking sound
of my .emacs file.
I have some other lisp related stuff in the lisp category on my blog,
but I don't have too many posts in that category yet. I just started
writing lisp seriously 6 months ago or so.
> About the actual point of your post, it's unfortunate that "modern" text
> editors (gedit, kate, notepad++ etc.) lack the extensibility to turn
> them into useful platforms for writing lisp. And your point about
> indentation is exactly what's required (and difficult!).
I am a staunch vim user, to say the least. However, after patches I
was giving back to various lisp projects were rejected with the reason
"format it in SLIME or else". I bit the bullet and simply learned emacs
for my Lisp IDE. I'm happy I did this.
Later,
-pete
Thibault Langlois
> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
> [...]
>
> > This comes up every now and then. I'm not sure whether this
> > parenthesis-paralysis is actually a real problem or an often-repeated
> > myth.
>
> I'm increasingly convinced that parentheses are the fundamental reason
> that Lisp isn't a lot more popular than it is. Syntax really matters
I'm on the opposite side. I wish I had a sexp based syntax language
with the semantics of ANSIC.
If it was implemented in CL I would be able to mix them. A function
defined in the ANSIC package would obey the C semantics. When
compiling the CL compiler would automatically generate C syntax
equivalent, call gcc and generate the binding code.
If this approach was available for other languages (Java, javascript,
shell etc), I would have solved the syntax "problem" once for all. I
would never have to learn a different syntax for a new language. Sexp
is no-syntax it is so better than syntax A, B or C. What matters is
the semantic of the langugage. I am convinced that the ideal situation
described here would be actually better to teach programming. The
instructor could actually focus on the semantics of the language not
on the syntax.
Let's be crazy ! If I was a dictator I would require that every
programming language should offer a CL-compatible sexp based
syntax :-)
Tamas K Papp
> On Apr 21, 3:04 pm, Pillsy <pillsb...@gmail.com> wrote:
>> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote: [...]
>>
>> > This comes up every now and then. I'm not sure whether this
>> > parenthesis-paralysis is actually a real problem or an often-repeated
>> > myth.
>>
>> I'm increasingly convinced that parentheses are the fundamental reason
>> that Lisp isn't a lot more popular than it is. Syntax really matters
>
> I'm on the opposite side. I wish I had a sexp based syntax language with
> the semantics of ANSIC.
> If it was implemented in CL I would be able to mix them. A function
> defined in the ANSIC package would obey the C semantics. When compiling
> the CL compiler would automatically generate C syntax equivalent, call
> gcc and generate the binding code. If this approach was available for
Maybe you could try writing it and post here. It should not be too hard
I guess, C is a small language.
I had similar intentions with a subset of Fortran, but never got
around to it.
Tamas
Nick Keighley
> On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:
> > On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]
> >> S-expressions (and macros) are
> >> what makes Lisp powerful. With a C-like syntax, Lisp is not much more
> >> powerful than a C-like language (with a few nice features thrown in, eg
> >> Blub OO systems rarely ever come close to CLOS). The greatest help one
> >> can give to newbies is help with learning CL as it is.
I genuinely think the parentheses *are* a barrier. I was put off Lisp
for years by the Lots of Irritating Silly Parentheses. (and then cam
back to lisp-like languages because I kept reading what a great
language it was and how it would change the way you thunk). OTH I
don't think hiding them helps. You've just got to grasp the nettle. An
editor that can count helps a /lot/.
> > Not sure about that. But why not start with a good book and classic
> > Scheme? Once through that, the student surely will be able to deal with
> > those parenthesis and can move on to CL, if so inclined.
>
> I started with Scheme instead of CL, thinking that since it claims to
> be "smaller",
me too. I was also hoping to embed scheme.
> it would be easier to learn. The language seemed very
> clever and abstract, but I felt that it required to force my thinking
> into particular patterns/solutions, which were not natural to me (eg
> the books I have used insisted on doing pretty much everything with
> tail recursion).
I persevered. I think being more comfortable with recursion has been a
help. Though scheme's named-let doesn't really look like recursion...
> Based on Scheme, I formed the impression that Lisp
> is a clever but impractical programming language (I didn't know much
> about CL). Fortunately for me, a year later I decided to give CL a
> chance, and I was hooked instantly.
>
> Based on my experience, I would be wary of recommending Scheme to
> newbies. Also, I think that the two communities are a bit different.
> I have yet to encounter a book for Scheme that is comparable to PCL.
> Most books for Scheme I have seen seem to care little about the
> language per se, and try to expand on a particular theme instead (eg
> how to do everything using recursion, the joys of call/cc).
which book is that! "The Joy Of call/cc" is exactly what I've been
looking for (that and "So Which Bloody Macro Scheme Should I Use
Then?". Is there a "Hygenic Macros For Dummies"?)
> Macros
> are not really emphasized (eg in the Dybvig book, they get a very thin
> chapter towards the end, which is a puzzle).
AOL
--
Scheme wanting to be considered a Lisp is like Robert E. Lee wanting
to
keep his commission in the United States Army.
Nick Keighley
> On Wed, 21 Apr 2010 07:04:14 -0700, Pillsy wrote:
> > On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote: [...]
> >> This comes up every now and then. I'm not sure whether this
> >> parenthesis-paralysis is actually a real problem or an often-repeated
> >> myth.
in my experience it's real
> > I'm increasingly convinced that parentheses are the fundamental reason
> > that Lisp isn't a lot more popular than it is. Syntax really matters to
> > [people]
>
> That's like saying that the requirement to engage in abstract thinking
> is the fundamental reason that makes (serious) mathematics unpopular.
> Maybe. But there is nothing you can do about it: you can't make it
> "easier" without making it uninteresting.
I think my problem is never understood *why* I had to tolerate the
pain. I don't know if they didn't say or if I didn't listen but Lisp
just seemed perverse to me. I've never been good at learning things
"because I say so" (I was a late reader as a child for similar
reasons).
> Likewise, it does not really make much sense to talk about how popular
> Lisp would be without parentheses.
I see that now.
> Speculations on how fundamental
> the SEXP syntax is to Lisp (and why Dylan failed etc) aside, no one
> has demonstrated the existence of an equally powerful Lisp with a more
> "conventional" syntax, so what the experiment/counterfactual would be
> is not clear.
is it even possible to do something like Lisp's macros without SEXPs?
> If someone invented a Lisp without parenthesis that is as powerful as
> eg CL, we would be able to talk about whether the parens make Lisp
> unpopular. Naturally, I am not holding my breath :-)
>
> Personally, I grew to like Lisp syntax.
it's growing on me
> But maybe this is a
> preference that is heterogeneous in the population: people who like the
> syntax or are willing to tolerate it for the extra power become Lisp
> programmers, the rest don't. Not much we can do about this.
try to explain the reason for the wierd syntax?
Look at the syntax the C++ template programmers live with to get
certain things done...
> > I think Common Lisp is an easier language to learn than Scheme, with its
> > richer set of imperative constructs and much better support for IO and
> > object orientation. Learning Scheme involves drinking a bunch of
> > Kool-Aid, and the good Scheme books are at least as much about selling
> > you that Kool-Aid as they are about teaching you a new language.
>
> Agreed. I almost gave up on Lisp because I started with books on
> Scheme. It was years later when I learned that there are people who
> write practical programs in (heavily extended dialects of) Scheme.
I'm still plodding the stoney scheme road...
CL always looked a bit of monster to me...
--
"Een schip op het strand is een baken in zee.
[A ship on the beach is a lighthouse to the sea.]"
- Dutch Proverb
[apparently very bad dutch]
Nick Keighley
wrote:
oddly I used to (when writing english (as a teenager)) deeply nest
parentheses,
I was much more tolerant of nested structures (than most people),
combining
this with my "lite" (never start an (unnecessary) new paragraph (a
stop (will do))
never start an (unnecessary) new sentence (a comma (will do))), I'm
surprised my
english teacher isn't now confined to some (padded) room drawing ()'s
on the walls
(with crayons). I also taught myself to stop doing this. perhaps if
I'd continued
Lisp would have made me less unhappy.
Nick Keighley
wrote:
> On 21 Apr, 23:27, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>
>
>
>
> > Pillsy <pillsb...@gmail.com> writes:
> > > On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
> > >> This comes up every now and then. I'm not sure whether this
> > >> parenthesis-paralysis is actually a real problem or an often-repeated
> > >> myth.
>
> > > I'm increasingly convinced that parentheses are the fundamental reason
> > > that Lisp isn't a lot more popular than it is. Syntax really matters
> > > to people, and the reasons it matters are rooted in subjective
> > > judgements about "prettiness" or "ease of reading". It so happens that
> > > a lot of programmers hate the parentheses for subjective reasons that
> > > simply don't apply to Lisp users because if they applied, we wouldn't
> > > be Lisp users.
>
> > We should tag "(this is a list)" in front of each primary school of the
> > world! :-)
>
[layout de-googled]
Tim Bradshaw
> I also taught myself to stop doing this. perhaps if
> I'd continued
> Lisp would have made me less unhappy.
I don't think so, because the parenthesis in Lisp serve a very
different purpose (in "(if (< x 1) ... ...)", "(< x 1)" is not a
parenthetical remark which can be skipped on first reading).
Joshua Taylor
> I persevered. I think being more comfortable with recursion has been a
> help. Though scheme's named-let doesn't really look like recursion...
I spent time with CL before Scheme, and I've always found that
named-lets seemed like a nice abbreviation for CL's LABELS, and it so it
did have the nice recursive feel to it. Since CL doesn't guarantee
tail-call optimization I end up writing an iterative version in CL.
I've found that writing the named-let or LABELS version first can help:
the DO-loop usually just falls right out of the named-let version. //JT
Raffael Cavallaro
I think it should be qualified:
there's an engineering trade-off between ease of metaprogramming and
provision of built-in syntactic sugar.
I think the problem lisp faces with its parenthesized syntax is that
one needs to become fairly advanced at the language before one can
start *adding* the syntactic sugar one wants. As a result, newcomers
think they'll be doing the equivalent of manual inlining of dozens of
sets of parentheses forever if they use lisp.
The language needs to be sold macros-first if it is to have any chance
of convincing newcomers that fully parenthesized syntax is a good
thing. That means intro texts should start with examples of extremely
short, macro based code in lisp, the equivalent very long
c/c++/java/python/ruby, etc. version, and the fully macroexpanded lisp,
compared side by side.
--
Raffael Cavallaro
His kennyness
What makes you think most other programmers would not have the same
result as yourself, viz. discover they like it almost immediately?
What I see is a conflation of opinion from a distance with actual
appreciation derived from experience. Talk about apples and orangutans!
kt
His kennyness
> On 21 Apr, 05:47, Tamas K Papp <tkp...@gmail.com> wrote:
>> On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:
>>> On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]
>
>
>>>> S-expressions (and macros) are
>>>> what makes Lisp powerful. With a C-like syntax, Lisp is not much more
>>>> powerful than a C-like language (with a few nice features thrown in, eg
>>>> Blub OO systems rarely ever come close to CLOS). The greatest help one
>>>> can give to newbies is help with learning CL as it is.
>
> I genuinely think the parentheses *are* a barrier. I was put off Lisp
> for years by the Lots of Irritating Silly Parentheses. (and then cam
> back to lisp-like languages because I kept reading what a great
> language it was and how it would change the way you thunk).
...and thennnnnnnnnn? What was your, um, parensification curve (short,
long, asymptopic?) and where did it end (their invisible? you hate them?)?
kt
roland....@ruag.com
>>>>> "Nick" == Nick Keighley <nick_keigh...@hotmail.com> writes:
Nick> On 21 Apr, 05:47, Tamas K Papp <tkp...@gmail.com> wrote:
>> On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:
>> > On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]
[snip]
>> Most books for Scheme I have seen seem to care little about the
>> language per se, and try to expand on a particular theme instead (eg
>> how to do everything using recursion, the joys of call/cc).
Nick> which book is that! "The Joy Of call/cc" is exactly what I've been
Nick> looking for (that and "So Which Bloody Macro Scheme Should I Use
Nick> Then?". Is there a "Hygenic Macros For Dummies"?)
The closest I came understanding call/cc was after reading Dorai Sitaram's
"Teach Yourself Scheme in Fixnum Days".
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html
As for macros, you might find something useful at
http://library.readscheme.org/
hope this helps
Roland
Duane Rettig
If you're looking for a computer language that feels like natural
language, Lisp is definitely not for you. Other programming languages
go to great lengths to provide the shortcuts and ambiguities that
natural languages provide, and with those ambiguities come
misunderstandings, where the speaker or writer says one thing and the
listener/reader hears another. This ambiguous communication is not
acceptable in a computer language, though many programmers search for
the ultimate language that can be "natural" and yet unambiguous.
Lisp's parens remove several major causes of syntactic ambiguity.
There are often several reasons why ambiguities work in natural
languages. The ideal reason, especially for spoken language, is
because there is interaction to disambiguate when communication occurs
(though often courses taught to perform "active listening" can get
very expensive). Sometimes correct communication is not the highest
priority; often the listener hears what he wants to hear, and so it
wouldn't have mattered what the speaker had said anyway. Also,
speaking in a precise way often causes the listener to lose focus or
interest, and that defeats the purpose of the communication anyway,
even if the listener wanted to understand what the speaker was saying.
It's good that you learned not to be so precise in your writing,
because that way you would lose your readers less often. It was
likely a process of feedback anyway, where you asked yourself "Why
aren't they listening to me?" and finally figured out the answer. But
a computer always listens to exactly what you have to say (or else is
considered broken) so that natural aversion you learn to speaking or
writing precisely doesn't apply in a computer language.
Use the right tool for the job. Natural language is not the right
tool for talking to a computer at the lowest level.
Duane
Alan Malloy
Certainly it is *possible*. It wouldn't be nearly as concise or pretty,
but it could be done. In, for example, Java the compiler could:
1) Lex/parse everything into a syntax tree
2) Encode that tress as a hierarchical Java object
3) Compile all "macro methods", which take as their argument a reference
to the AST of the code they're being run on
4) Execute the macros, recursing as necessary
5) Recurse to step 3 if necessary; some macros may expand into further
macro definitions
6) Finally compile the macro-expanded code into a class file
This is so awkward as to be unusable, but it is hardly impossible.
--
Cheers,
Alan (San Jose, California, USA)
Alan Malloy
Sure it is. It expands on the meaning of the if statement. Try writing
it as "If some condition (in this case, x < 1) holds, I'll do something
(this time, evaluate a sub-form); otherwise I'll do something else (as
it happens, evaluate a different sub-form)".
If your reader didn't care about the details, and just wanted to
understand that you were doing something conditionally, the sentence
above could be stripped of all parenthetical clauses without harm: "If
some condition holds, I'll do something; otherwise I'll do something else".
Pillsy
> Pillsy wrote:
[...]
> > I did too. Actually, I discovered that I liked it almost immediately.
> > OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
> > the reason I'm so convinced of the role that personal preference plays
> > in this is that my own preferences seem to be so radically different
> > from most other programmers.
> What makes you think most other programmers would not have the same
> result as yourself, viz. discover they like it almost immediately?
If that were the case, wouldn't we see Lispy syntaxes everywhere? Lots
of people are exposed to Lisp through intro CS courses or editing
Emacs configuration files, and writing a Lisp reader is pretty damned
easy. Even if people hate the dynamic typing or garbage collection,
they could still give their new languages all the parentheses you
could ever want.
Add to that people's #1 superficial complaint about Lisp is the
Legions of Irritating Stupid Parentheses, and I'm pretty sure I'm
right about this.
Cheers,
Pillsy
Tim Bradshaw
> If your reader didn't care about the details
Sorry, that's just silly. There are no cases where that form could
somehow be omitted without changing the meaning of the program (in fact
making it syntactically invalid). However the previous parenthetical
remark can be so omitted - and parenthetical remarks in written English
(such as this one) very often can.
Tamas K Papp
> On Apr 22, 11:45 am, His kennyness <kentil...@gmail.com> wrote:
>> Pillsy wrote:
> [...]
>> > I did too. Actually, I discovered that I liked it almost immediately.
>> > OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
>> > the reason I'm so convinced of the role that personal preference
>> > plays in this is that my own preferences seem to be so radically
>> > different from most other programmers.
>
>> What makes you think most other programmers would not have the same
>> result as yourself, viz. discover they like it almost immediately?
>
> If that were the case, wouldn't we see Lispy syntaxes everywhere? Lots
> of people are exposed to Lisp through intro CS courses or editing Emacs
> configuration files, and writing a Lisp reader is pretty damned easy.
> Even if people hate the dynamic typing or garbage collection, they could
> still give their new languages all the parentheses you could ever want.
The good old argument of relying on the rationality of people. If X
is so good, why doesn't everyone use it? And consequently, if the
vast majority doesn't use X, there must be something wrong with it.
The sad truth is that the majority of people do not devote a lot of time
to exploring alternatives, they just use whatever they were taught, or
what others are using. They will use every excuse they can come up with
to rationalize this behavior.
The fact that Lisp is taught in intro CS courses is a serious handicap
for it IMO. AFAIK the vast majority of these courses use Scheme, and
use it to introduce some particular style of programming or a constructs
which are interesting to theoretical CS people. I would not be surprised
if the vast majority of CS students failed to see the point of these, and
even end up hating (or at least dismissing) the language. These feelings
might just focus on the most apparent superficial distinguishing mark of
Lisp: the parentheses.
> Add to that people's #1 superficial complaint about Lisp is the Legions
> of Irritating Stupid Parentheses, and I'm pretty sure I'm right about
> this.
As I said above, I think that the hatred of parentheses is just the
superficial focus of a problem that runs deeper. If I had to take one of
the intro CS courses I mentioned above, I would probably feel that if I
was subjected to an alien syntax, there should be some advantage to the
language to justify that. But usually there isn't, not in these courses.
I was not a CS major, but I was very excited that I could take CS courses
when I started at the university. I am a self-taught programmer, and I
thought that finally I could learn how to do it better. So I took the
intro course that CS students had to take. The Lisp part went like this:
Lisp is about lists and recursion. The only atoms Lisp has are integers,
which we manipulate. No mention of macros, CLOS, symbols, or even frickin
arrays.
The prof put up a factorial on the blackboard. Then a recursive function
for the Fibonacci series. These we analyzed. I recently found my notes
from that course when I was moving: the factorial wasn't even tail-
recursive! And naively done recursion is probably the dumbest way to
calculate Fibonacci.
This was the last CS course I ever took. I left it with the feeling that
Lisp has no point, it is a toy language for teaching recursion. It took
me about 8 years to look at Lisp again. I think that the vast majority
of students feel this way. There should even be a T-shirt: "I put up
with all those silly parenthesis, and all I got was theoretical CS toys."
Best,
Tamas
Nicolas Neuss
> The prof put up a factorial on the blackboard. Then a recursive function
> for the Fibonacci series. These we analyzed. I recently found my notes
> from that course when I was moving: the factorial wasn't even tail-
> recursive! And naively done recursion is probably the dumbest way to
> calculate Fibonacci.
OTOH, if not done naively, it is mathematically beautiful and the best
way (via fast exponentiation of a matrix).
> This was the last CS course I ever took. I left it with the feeling
> that Lisp has no point, it is a toy language for teaching
> recursion. It took me about 8 years to look at Lisp again. I think
> that the vast majority of students feel this way. There should even
> be a T-shirt: "I put up with all those silly parenthesis, and all I
> got was theoretical CS toys."
:-) I am guilty of liking these toys as well. But at least, I don't
avoid syntax transformations and OO in my (currently running)
programming class.
Nicolas
Tamas K Papp
> Tamas K Papp <tkp...@gmail.com> writes:
>
>> The prof put up a factorial on the blackboard. Then a recursive
>> function for the Fibonacci series. These we analyzed. I recently
>> found my notes from that course when I was moving: the factorial wasn't
>> even tail- recursive! And naively done recursion is probably the
>> dumbest way to calculate Fibonacci.
>
> OTOH, if not done naively, it is mathematically beautiful and the best
> way (via fast exponentiation of a matrix).
Indeed - but that's a topic for a different course. One that uses
something like Concrete Mathematics as a textbook :-)
>> This was the last CS course I ever took. I left it with the feeling
>> that Lisp has no point, it is a toy language for teaching recursion. It
>> took me about 8 years to look at Lisp again. I think that the vast
>> majority of students feel this way. There should even be a T-shirt: "I
>> put up with all those silly parenthesis, and all I got was theoretical
>> CS toys."
>
> :-) I am guilty of liking these toys as well. But at least, I don't
> avoid syntax transformations and OO in my (currently running)
> programming class.
Then you are probably not typical. BTW, do you have online notes for
your course? I am just curious.
If I had the resources, would love to conduct the following survey: among
undergrads exposed to some form Lisp, what fraction knows that
- Lisp has strings?
- ... and arrays?
- ... and macros?
- there are editors/IDEs that make working with Lisp extremely easy?
- Common Lisp exists?
- ... and has a lot of library function for List Manipulation 101?
- ... has loop and iterate?
- (tail) recursion doesn't come up very often for the average CL'er?
- CLOS exists?
- CLOS is far more advanced than the OO framework of some languages
that position themselves as object-oriented?
- that MOP exists (no need to know the details or use it, just what it
is)?
My prior would be that the percentage of people who answer "yes" to
these questions would be decreasing from 10% to 1e-5, in the order of
the questions above.
If my prior is more or less correct, I would not be surprised to learn
that most people who have been exposed to it dislike Lisp -- they
haven't been shown the good stuff. It's like giving a bicycle to a
kid, with the condition that he has to rebuild the wheel before each
ride.
Wishful thinking: the situation might improve if more intro courses
switch to Python or similar.
Best,
Tamas
Pillsy
> On Thu, 22 Apr 2010 14:17:41 -0700, Pillsy wrote:
> > On Apr 22, 11:45 am, His kennyness <kentil...@gmail.com> wrote:
[...]
> >> What makes you think most other programmers would not have the
> >> same result as yourself, viz. discover they like it almost
> >> immediately?
> > If that were the case, wouldn't we see Lispy syntaxes everywhere?
> > Lots of people are exposed to Lisp through intro CS courses or
> > editing Emacs configuration files, and writing a Lisp reader is
> > pretty damned easy. Even if people hate the dynamic typing or
> > garbage collection, they could still give their new languages all
> > the parentheses you could ever want.
> The good old argument of relying on the rationality of people. If X
> is so good, why doesn't everyone use it?
But the question wasn't whether X is good, the question is whether
people would *like* X more than Y if they had a chance to use X. My
answer is that people who have had a chance to use X usually still
keep on using Y with a great deal of enthusiasm.
[...]
> The fact that Lisp is taught in intro CS courses is a serious handicap
> for it IMO. AFAIK the vast majority of these courses use Scheme, and
> use it to introduce some particular style of programming or a constructs
> which are interesting to theoretical CS people.
That's another possibility, but even people who love the theoretical
bits seem to be looking for ways to abandon the parentheses in favor
of preposterous piles of syntactic sugar. Ever look at Haskell?
I dunno. I didn't even take CS courses; I mostly heard them described
second-hand by friends. I took some applied math classes and ended up
kinda liking Fortran, though.
Cheers,
Pillsy
Pillsy
wrote:[...]
> > Speculations on how fundamental
> > the SEXP syntax is to Lisp (and why Dylan failed etc) aside,
> > no one has demonstrated the existence of an equally powerful
> > Lisp with a more "conventional" syntax, so what the
> > experiment/counterfactual would be is not clear.
> is it even possible to do something like Lisp's macros without
> SEXPs?
Yes. The Dylan macro system[1] was a lot like the pattern-matching,
hygienic syntax-rules macro system for Scheme.
[...]
> > Agreed. I almost gave up on Lisp because I started with books on
> > Scheme. It was years later when I learned that there are people who
> > write practical programs in (heavily extended dialects of) Scheme.
> I'm still plodding the stoney scheme road...
> CL always looked a bit of monster to me...
CL looks a lot bigger than it is; a lot of the size is stuff that
might be in another language's "standard library", and some of the
rest is language constructs that provide more convenient (or familiar)
alternatives to relying on recursion or call/cc for everything.
Cheers,
Pillsy
Jorge Gajon
> I am a staunch vim user, to say the least. However, after patches I
> was giving back to various lisp projects were rejected with the reason
> "format it in SLIME or else". I bit the bullet and simply learned emacs
> for my Lisp IDE. I'm happy I did this.
>
Hi Peter,
I'm an avid Vim user as well, and I've been using "Limp" with a few
modificationsน. I've been playing a little bit with Emacs and SLIME, and
I can clearly see that the Emacs platform is much more powerful and that
there's nothing like SLIME available to VIM.
However, I've been hesitant to completely immerse myself into Emacs
mainly because I'm afraid that I will spend endless hours learning and
customizing it, without gaining a significant advantage over Vim.
/"But you said Emacs is more powerful."/
Yes but I don't need a tetris game, or GNUS, or a web browser, or an
ultra super duper grand unified debugger (as cool as it is.)
Vim, as a platform, may not be as powerful as Emacs, but it is powerful
nonetheless, and I wonder if is it worth the effort to start from
scratch with Emacs.
On the other hand, I truly believe the Vi editing model is superior.
Have you tried Vimpulse? I've tried viper-mode but it is not enough.
Peter, you say that you are happy you bit the bullet. Care to expand
that thought?.
Thank you.
น In this link you can see the modifications I've done to Limp:
http://stackoverflow.com/questions/2545893/turn-off-the-highlight-feature-in-the-limp/
Peter Keller
> On 2010-04-22, Peter Keller <psi...@merlin.cs.wisc.edu> wrote:
>> I am a staunch vim user, to say the least. However, after patches I
>> was giving back to various lisp projects were rejected with the reason
>> "format it in SLIME or else". I bit the bullet and simply learned emacs
>> for my Lisp IDE. I'm happy I did this.
>>
>
> I can clearly see that the Emacs platform is much more powerful and that
> there's nothing like SLIME available to VIM.
I used Limp for a couple months, but it had some very crappy bugs for me.
I spoke to the very personable maintainer, but we couldn't figure it out.
The bugs were hjkl would work, but then sometimes also act as if CTRL-Y/E
were performed. That was the most annoying bug ever and is what made
me stop using it. Another nasty bug was if I cut and pasted a chunk of
lisp into limp, and then hit 'u' for undo, it would leave detritus in
the buffer. And a third bug being whenever I created/destroyed tabs,
I'd disconnect from the lisp listener. These three bugs, combined with
Limp not formatting identically to SLIME, made be stop using it. The
maintainer and I really tried to figure it out, and Limp worked fine
for lots of other people. I guess my mileage varied. :)
> However, I've been hesitant to completely immerse myself into Emacs
> mainly because I'm afraid that I will spend endless hours learning and
> customizing it, without gaining a significant advantage over Vim.
I spent probably 3 weeks solid learning (doing the tutorial every day) and
then customizing emacs before I was happy with it and maybe 3 more weeks
before my "finger macros" functioned without me seriously concentrating
on it. I don't use viper mode, I use the nominal method emacs prefers,
with a couple major exceptions I hacked into the emacs lisp. Now that
I've been using it, I'll say that it was worth it and I'd do it again.
> Vim, as a platform, may not be as powerful as Emacs, but it is powerful
> nonetheless, and I wonder if is it worth the effort to start from
> scratch with Emacs.
I found that emacs was worth learning emacs as a Lisp IDE.
I found that vim and emacs basically have the same functionality.
I found that I vastly prefer vim's navigation system to emacs' nav system.
I found that I vastly prefer emacs' configuration system (elisp and the
raw interface to the editor itself) to vim's.
> On the other hand, I truly believe the Vi editing model is superior.
> Have you tried Vimpulse? I've tried viper-mode but it is not enough.
Nah, I hadn't tried it. It is simply because, as a vim user, if I were
going to drink the kool-aid of emacs, I'd better drink long and deep.
However, I said there were a couple major exceptions. These exist because
I couldn't make myself stop wanting certain text manipulation behavior that
vim gave me, and emacs didn't. After some hacking, emacs gave it to me.
These examples is emacs lisp that I found on the emacs wiki (which is a great
resource), on some page lost to memory, or wrote, I forgot which.
It is fair to say that I took the shortest route to customizing emacs that
a serious vim user would tolerate. :)
An explanation of my .emacs file.
I use tabs and split screens a lot in vim, adjusting their sizes is fast
in vim's command mode, in emacs it sucks, this rebinds to a better key
distribution.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; make more accessable the bindings to shrink and enlarge buffers
;; The regular keybindings suck.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(global-set-key (kbd "S-C-<left>") 'shrink-window-horizontally)
(global-set-key (kbd "S-C-<right>") 'enlarge-window-horizontally)
(global-set-key (kbd "S-C-<down>") 'shrink-window)
(global-set-key (kbd "S-C-<up>") 'enlarge-window)
These next two are because I want emacs to start up like vim starts up and
have as little stuff as possible except for the text I'm writing taking up
screen real estate.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Get rid of the scroll bars, I don't need them.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(scroll-bar-mode -1)
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; I don't like the spash screen
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(setq inhibit-splash-screen t)
Emacs' C-k is a bit dumb from my point of view, this makes it better, more
like dd, but later I reimplemented dd.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; I like more of a vim-like behavior when killing a whole line with C-k.
;; When the point is C-a, then C-k will act like dd.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(setq kill-whole-line t)
This is one reason why I use emacs.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Auto newline and indent when I hit return
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(global-set-key "\C-m" 'newline-and-indent)
This is a usability thing. actually typing 'yes' or 'no' is dumb.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Change the annoying 'yes'/'no' query to just 'y'/'n'
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(fset 'yes-or-no-p 'y-or-n-p)
The default scrolling method of emacs (when you reach the bottom of
the screen you pan the text and center it to the center of the screen)
is very different than vim's (scroll up by one line when reaching the
bottom of the screen), and this makes it act 99% like vim's.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; When I come to the top/bottom of the screen with C-n/p, scroll one line only
;; This is different than "(setq scroll-step 1)" because the latter will have
;; bad boundary behavior at the end of the buffer.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(setq scroll-conservatively most-positive-fixnum)
This is the reason why I love SLIME. I simply hit one key, and everything
is formatted like how it is supposed to be. It isn't as good as Lisp's
pretty printer, it doesn't actually go that far, but it goes far enough
that it is worth it weight in gold. I realize that Limp has the exact same
functionality, but the actual indention Limp performs is not what I want.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; When [f12] is hit, indentify the whole buffer. Very useful for Common Lisp
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun iwb ()
"indent whole buffer"
(interactive)
(delete-trailing-whitespace)
(indent-region (point-min) (point-max) nil)
(untabify (point-min) (point-max)))
(global-set-key [f12] 'iwb)
I absolutely hated that emacs didn't have vim's dd, so I wrote it. This binds
shift-alt-m to something which for all intents and purposes, is vim's dd.
I may need to hack it to accept a prefix argument so you can do things like
C-u 10 M-k, I haven't even tested that yet since I needed the raw functionality
so badly.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; This is my attempt and making a reliable vim dd and binding it to M-K
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun vim-dd ()
"Act like Vim's dd command."
(interactive)
(let ((col (current-column)))
(move-beginning-of-line 1)
(kill-line)
(move-to-column col)))
(global-set-key (kbd "M-K") 'vim-dd)
Yay. Bounce the parenthesis. An old vim habit, I still like it.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; If my point is on a ( or ), then bounce it like % in vim
;; This may be annoying if I actually wish to start or end a variable with
;; this character.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun bounce-paren (arg)
"Go to the matching paren if on a paren; otherwise insert %."
(interactive "p")
(cond ((looking-at "\\s\(") (forward-list 1) (backward-char 1))
((looking-at "\\s\)") (forward-char 1) (backward-list 1))
(t (self-insert-command (or arg 1)))))
(global-set-key "%" 'bounce-paren)
I miss this feature from vim and use it a lot. I got it from the emacs wiki
but it needs more hacking to make it reliable for all values of integers.
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Increment decimal a number under the point
;; doesn't exactly work with negative numbers. :(
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun increment-number-at-point ()
(interactive)
(skip-chars-backward "0123456789")
(or (looking-at "[0123456789]+")
(error "No number at point"))
(replace-match (number-to-string (1+ (string-to-number (match-string 0))))))
(global-set-key (kbd "C-c +") 'increment-number-at-point)
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Decrement decimal a number under the point
;; doesn't exactly work with negative numbers. :(
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun decrement-number-at-point ()
(interactive)
(skip-chars-backward "0123456789")
(or (looking-at "[0123456789]+")
(error "No number at point"))
(replace-match (number-to-string (1- (string-to-number (match-string 0))))))
(global-set-key (kbd "C-c -") 'decrement-number-at-point)
And then in the customization of emacs, I:
turned on column number mode
turned on save my place in files
turned on size indication mode
turned off the tool bar.
Combined with the above stuff, emacs looks basically like vim when it starts
up.
The one thing I haven't done is gotten an acceptable implementation of
vim's J command. I can do the awkward sequence in emacs: C-e C-d M-SPC
but I need to figure out a good mapping for it. A lot of useful keys
are already taken...
> Peter, you say that you are happy you bit the bullet. Care to expand
> that thought?.
I was happy because SLIME indented my lisp in accordance to cultural
norms. This was the main reason I was happy.
I found that I enjoyed emacs' configuration language as well. I wish it was
pure common lisp, but hey, you buy the ticket, you ride the ride.
The one thing I really, really miss is vim's command mode. I find it
depressing (no pun intended) that I have to hold down ctrl all the time
to do any command-like operations. I felt much more free in vim's command
mode. Then again, I figured out and wrote the customizations I needed
much faster in emacs lisp than I ever did in vim.
I like both editors, for different reasons. :)
Later,
-pete
Teemu Likonen
> /"But you said Emacs is more powerful."/
>
> Yes but I don't need a tetris game, or GNUS, or a web browser, or an
> ultra super duper grand unified debugger (as cool as it is.)
I believe this is just "psychological bloat". Those parts of Emacs you
don't use are only *.elc files on your hard disks. They are loaded only
when you actually use them. Bot Vim and Emacs are very light-weight
applications compared to other applications.
Jorge Gajon
> Jorge Gajon <ga...@gajon.org> wrote:
>> On 2010-04-22, Peter Keller <psi...@merlin.cs.wisc.edu> wrote:
>>> I am a staunch vim user, to say the least. However, after patches I
>>> was giving back to various lisp projects were rejected with the reason
>>> "format it in SLIME or else". I bit the bullet and simply learned emacs
>>> for my Lisp IDE. I'm happy I did this.
>>>
>>
>> I'm an avid Vim user as well, and I've been using "Limp" with a few
>> modifications. I've been playing a little bit with Emacs and SLIME, and
>> I can clearly see that the Emacs platform is much more powerful and that
>> there's nothing like SLIME available to VIM.
>
> I used Limp for a couple months, but it had some very crappy bugs for me.
> I spoke to the very personable maintainer, but we couldn't figure it out.
> The bugs were hjkl would work, but then sometimes also act as if CTRL-Y/E
> were performed. That was the most annoying bug ever and is what made
> me stop using it. Another nasty bug was if I cut and pasted a chunk of
> lisp into limp, and then hit 'u' for undo, it would leave detritus in
> the buffer. And a third bug being whenever I created/destroyed tabs,
> I'd disconnect from the lisp listener. These three bugs, combined with
> Limp not formatting identically to SLIME, made be stop using it. The
> maintainer and I really tried to figure it out, and Limp worked fine
> for lots of other people. I guess my mileage varied. :)
At first I found the exact same bugs you mention, but with the
modifications that I linked to in the previous message they are fixed.
The indentation is because Limp by default sets to the old Vi
indentation mode, I modified that too and now I get decent
indentation, not perfect but good enough.
>> However, I've been hesitant to completely immerse myself into Emacs
>> mainly because I'm afraid that I will spend endless hours learning and
>> customizing it, without gaining a significant advantage over Vim.
>
> I spent probably 3 weeks solid learning (doing the tutorial every day) and
> then customizing emacs before I was happy with it and maybe 3 more weeks
> before my "finger macros" functioned without me seriously concentrating
> on it. I don't use viper mode, I use the nominal method emacs prefers,
> with a couple major exceptions I hacked into the emacs lisp. Now that
> I've been using it, I'll say that it was worth it and I'd do it again.
>
>> Vim, as a platform, may not be as powerful as Emacs, but it is powerful
>> nonetheless, and I wonder if is it worth the effort to start from
>> scratch with Emacs.
>
> I found that emacs was worth learning emacs as a Lisp IDE.
> I found that vim and emacs basically have the same functionality.
> I found that I vastly prefer vim's navigation system to emacs' nav system.
> I found that I vastly prefer emacs' configuration system (elisp and the
> raw interface to the editor itself) to vim's.
>
>> On the other hand, I truly believe the Vi editing model is superior.
>> Have you tried Vimpulse? I've tried viper-mode but it is not enough.
>
> Nah, I hadn't tried it. It is simply because, as a vim user, if I were
> going to drink the kool-aid of emacs, I'd better drink long and deep.
>
Well, one thing is drinking the kool-aid, and other is using what's
best. I believe Vim's editing model is a big deal to just let it go.
I do see myself transitioning to Emacs in the near future, but only if
Vimpulse (or something else) gives me enough of the commands present in
Vim. Most of the text object movements, visual selection, and jumping
(g; g, are way too useful for me). And CTRL-[ must work.
And one thing that I *must* really be able to use is C-X C-N and C-X C-P
in insert mode.
Anyway, I have not been able to spend more time with Emacs recently, but
it is definitely in my to-do list. The problem is that there's not
enough time available, which is also my concern on walking down this
path.
> The one thing I really, really miss is vim's command mode. I find it
> depressing (no pun intended) that I have to hold down ctrl all the time
> to do any command-like operations.
Exactly :)
Thank you for sharing your impressions and the customizations that you
have done in your .emacs file.
His kennyness
> On Apr 22, 11:45 am, His kennyness <kentil...@gmail.com> wrote:
>> Pillsy wrote:
> [...]
>>> I did too. Actually, I discovered that I liked it almost immediately.
>>> OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
>>> the reason I'm so convinced of the role that personal preference plays
>>> in this is that my own preferences seem to be so radically different
>>> from most other programmers.
>
>> What makes you think most other programmers would not have the same
>> result as yourself, viz. discover they like it almost immediately?
>
> If that were the case, wouldn't we see Lispy syntaxes everywhere?
Why on Earth would that follow? The acid test is what you see in the
Road to Lisp: someone who really evaluated Lisp as a potential language,
not students dying to learn Java or Python or even C++ forced to do some
Scheme in a language survey (who would end up writing about 50 lines of
code over a week).
> Lots
> of people are exposed to Lisp through intro CS courses or editing
> Emacs configuration files, and writing a Lisp reader is pretty damned
> easy. Even if people hate the dynamic typing or garbage collection,
Sorry? People who hate dynamic typing or GC? You are just inventing
people now! :) What about all the straight men who would not want to
date Anna Kournikova?
> they could still give their new languages all the parentheses you
> could ever want.
Thank god the HTML and XML folks did not use a nested list format!!!
>
> Add to that people's #1 superficial complaint about Lisp is the
> Legions of Irritating Stupid Parentheses, and
...you just went OT back to the irrelevant opinion-at-a-distance if we
are talking about actual-inability-to-handle-parens.
> I'm pretty sure I'm
> right about this.
No problem. :)
kt
Peter Keller
> At first I found the exact same bugs you mention, but with the
> modifications that I linked to in the previous message they are fixed.
Oh, I have the maintainer's email address, maybe I'll forward to him your
link so he can see what's up.
> Well, one thing is drinking the kool-aid, and other is using what's
> best. I believe Vim's editing model is a big deal to just let it go.
I thought the same way, but in the end, I realized that both tools
allow me to "do the same things" with the text, so in essence the only
difference was what I was actually typing.
After a while, I was able to remap quite effectively the higher order text
manipulations my brain wanted to do into different concrete finger movements.
I thought it'd be horrible to do, and for the first 3 weeks, it was. :)
> And one thing that I *must* really be able to use is C-X C-N and C-X C-P
> in insert mode.
Turns out that M-/ is a good enough completion for me that I'm perfectly
happy with it. There are various method of tab completion I haven't all
figured out, but they can provide you with the choices and whatnot.
As for tags, M-. (if I recall) does something intelligent. SLIME itself
has some acceptable methods to go to a caller or a callee of a function
or identify other entities and their definitions. I've only used it in Lisp
and it worked well for me.
> Anyway, I have not been able to spend more time with Emacs recently, but
> it is definitely in my to-do list. The problem is that there's not
> enough time available, which is also my concern on walking down this
> path.
Eh, I say simply start writing code in it and only figure out the things
you absolutely need to figure out because it prevents you from writing
code. 99% of the time whatever I googled had like 4 pages devoted to
how to make emacs do it. Everything else can be put off. :)
I was annoyed that I had to learn another tool, but my brain surprised
me and remapped everything. I bashed emacs with a stick when I just couldn't
change my behavior. It worked out.
> Thank you for sharing your impressions and the customizations that you
> have done in your .emacs file.
No problem.
Have a nice day.
Later,
-pete
Pascal J. Bourguignon
Yes. After all, we all know that the only thing Python has is
significant indentation and colons (both of which are despicable), and
nothing else, not even list processing primitives.
blah
blah
blah:
blah:
blah
blah
blah:
blah
blah
blah
Useless.
--
__Pascal Bourguignon__
Pascal J. Bourguignon
> On 2010-04-22, Peter Keller <psi...@merlin.cs.wisc.edu> wrote:
>> I am a staunch vim user, to say the least. However, after patches I
>> was giving back to various lisp projects were rejected with the reason
>> "format it in SLIME or else". I bit the bullet and simply learned emacs
>> for my Lisp IDE. I'm happy I did this.
>>
>
> Hi Peter,
>
> I'm an avid Vim user as well, and I've been using "Limp" with a few
> modifications¹. I've been playing a little bit with Emacs and SLIME, and
> I can clearly see that the Emacs platform is much more powerful and that
> there's nothing like SLIME available to VIM.
>
> However, I've been hesitant to completely immerse myself into Emacs
> mainly because I'm afraid that I will spend endless hours learning and
> customizing it, without gaining a significant advantage over Vim.
You could. But you wouldn't have to, to benefit from emacs lisp.
Really, I usually don't spend any time on emacs customization, in the
course of a project. On the other hand, I may spend a few minutes to
write project specific emacs lisp functions, to help editing or
generating project specific stuff.
And you can customize emacs a lot without even programming in emacs
lisp. There are almost orthogonal matters.
--
__Pascal Bourguignon__
Frank Buss
> Yes. After all, we all know that the only thing Python has is
> significant indentation and colons (both of which are despicable), and
> nothing else, not even list processing primitives.
Python has some list processing primitives:
(car x) = x[0]
(cdr x) = x[1:]
(cons x y) = [x] + y
etc.
Of course, the functions are not the same as in Common Lisp, e.g. x[0]
gives an IndexError, if the list is empty and the primitives are not
functions, so you need to define your own functions for using it with
higher order functions.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Pascal J. Bourguignon
> Pascal J. Bourguignon wrote:
>
>> Yes. After all, we all know that the only thing Python has is
>> significant indentation and colons (both of which are despicable), and
>> nothing else, not even list processing primitives.
>
> Python has some list processing primitives:
Yes. And lisp has arrays. That was my point ;-)
We could develop the memes that
python is PainfullY THpace Overloaded Nuttiness
ruby is Rabid UBject Yoke
java is Just Another Vaunted Avoidance
etc.
(The TH in python is for the x[0],x[1:] you mentioned).
--
__Pascal Bourguignon__
Peter Keller
Just Another Vapid Attempt
-pete
Nicolas Neuss
> Then you are probably not typical. BTW, do you have online notes for
> your course? I am just curious.
I have notes for a previous version of the course which was a 2h/week
lecture. It mostly follows the first three chapters of SICP with
add-ons on syntax transformations, the lambda calculus, and OO. The
notes are in German, but not under a published link. If you want to
take a look, drop me an email.
> If I had the resources, would love to conduct the following survey:
> among undergrads exposed to some form Lisp, what fraction knows that
>
> - Lisp has strings?
> - ... and arrays?
> - ... and macros?
> - there are editors/IDEs that make working with Lisp extremely easy?
> - Common Lisp exists?
I guess that my students (from the previous course) would answer "yes"
to those questions.
> - ... and has a lot of library function for List Manipulation 101?
> - ... has loop and iterate?
> - (tail) recursion doesn't come up very often for the average CL'er?
For these questions, their answer would be "no", because I used DrScheme
and the focus was not on CL.
> - CLOS exists?
> - CLOS is far more advanced than the OO framework of some languages
> that position themselves as object-oriented?
> - that MOP exists (no need to know the details or use it, just what it
> is)?
"Yes" for those questions.
Nicolas
Tim Bradshaw
> Python has some list processing primitives:
But aren't its lists actually dynamically-resized arrays rather than
linked lists? Those are very different things.
Jorge Gajon
What I'm actually afraid is getting lured into "this new plugin", and
then this "other cool plugin", oh! and there's this other one!.
It's like reading a wikipedia article and then you read other related
article, and then another, and another, and before you realize it, you
have 20 tabs open with articles to read.
Dangerous stuff.
But yes, maybe it's just in mind.
Jorge Gajon
Peter, thank you for your comments, I definitely have to spend more time
with trying Emacs. Although SLIME is not indispensable for Common Lisp
programming, it sure is a significant advantage.
Best regards.
Jorge Gajon
> Jorge Gajon <ga...@gajon.org> writes:
>
>> On 2010-04-22, Peter Keller <psi...@merlin.cs.wisc.edu> wrote:
>>> I am a staunch vim user, to say the least. However, after patches I
>>> was giving back to various lisp projects were rejected with the reason
>>> "format it in SLIME or else". I bit the bullet and simply learned emacs
>>> for my Lisp IDE. I'm happy I did this.
>>>
>>
>> Hi Peter,
>>
>> I'm an avid Vim user as well, and I've been using "Limp" with a few
>> modifications¹. I've been playing a little bit with Emacs and SLIME, and
>> I can clearly see that the Emacs platform is much more powerful and that
>> there's nothing like SLIME available to VIM.
>>
>> However, I've been hesitant to completely immerse myself into Emacs
>> mainly because I'm afraid that I will spend endless hours learning and
>> customizing it, without gaining a significant advantage over Vim.
>
> You could. But you wouldn't have to, to benefit from emacs lisp.
> Really, I usually don't spend any time on emacs customization, in the
> course of a project. On the other hand, I may spend a few minutes to
> write project specific emacs lisp functions, to help editing or
> generating project specific stuff.
>
Pascal, when you say "...help editing or generating project specific
stuff", do you mean text templates that are expanded in place and you
fill the blanks, or do you mean something similar to keyboard macros to
avoid repetition, or a combination of them.
Or (more exciting), you mean something like CL macros where you call
it with some arguments and depending on the arguments it will 'expand'
into different source code.
Thank you.
Pascal J. Bourguignon
The former. I don't use keyboard macros, since I'm totally at ease with
emacs lisp programming, I do what users would do with keyboard macros
writing emacs functions.
Here are some typical example.
- The first would be a command to set different faces to different log
level in an application specific log file (which application issued a
lot of logs in debugging mode, so that it was really important to be
able to distinguish them by color to make sense of them).
(defun xxxxxx-log-fontify-buffer ()
(interactive)
(remove-all-properties)
(dolines (lstart lend)
(goto-char lstart)
(when (looking-at "\\(DEBUG\\|INFO\\|NOTICE\\|WARNING\\|ERROR\\) ")
(let* ((level (match-string 1))
(face (cond
((string= level "DEBUG") 'xxxxxx-message-level-debug)
((string= level "INFO") 'xxxxxx-message-level-info)
((string= level "NOTICE") 'xxxxxx-message-level-notice)
((string= level "WARNING") 'xxxxxx-message-level-warning)
((string= level "ERROR") 'xxxxxx-message-level-error))))
;; (message "%S %S %S %S" level face lstart lend)
(when face (facemenu-set-face face lstart lend))))))
(This could have been done with normal font-lock keywords, but it was
too slow given the size of the log files).
Also there's a function that set as an emacs attribute attached to
each log line, a log object, identifying the log message in the
sources (since there was no identification of the log message other
than its pattern, not to affraid the users). So that I could easily
jump from the log line to the corresponding source line.
- a function that would take a C++ message sending ("member function
call"), and transform it into sending a message to a scheduler object
with a boost::bind wrapping the original message send. (Transforming
the original message send into an asynchronous one). Of course, such
a feature would be implemented at the programming language level (ie.
with lisp macros), instead of inlining it in the source, but we can
use emacs lisp function to "macro expand" the target language.
- a funnier set of emacs commands were used to switch between two
representations of a function definition in a language where there was
no function definition available. Only eval(string) was availble, so
that I defined a syntax to define a function, and the function
parameters were passed thru global variables like in BASIC, and the
function body was stored into a string named by the function. The
commands switched between the two forms:
function f(input a,inout b,output c){
b=b+1;
c=a*2;
}
<->
a=null; // input of f
b=null; // inout of f
c=null; // output of f
f="b=b+1;c=a*2";
to try to recover some mental sanity...
I didn't write the switch for function calls, (ie between f(i,j,k) and
a=i;b=j;eval(f);k=c;) but it could have been done with some more
syntactic analysis of this dumb language.
- finally, one can also quite easily interface with underlying programs,
such as debuggers, writing emacs commands to drive the debugger or
other programs with a single key. For example, I have:
(defun clisp-debug-keys ()
"Binds locally some keys to send clisp debugger commands to the inferior-lisp
<f5> step into
<f6> next
<f7> step over
<f8> continue
"
(interactive)
(macrolet ((cmd (string)
`(lambda ()
(interactive)
(comint-send-string (inferior-lisp-proc)
,(format "%s\n" string)))))
(local-set-key (kbd "<f5>") (cmd ":s"))
(local-set-key (kbd "<f6>") (cmd ":n"))
(local-set-key (kbd "<f7>") (cmd ":o"))
(local-set-key (kbd "<f8>") (cmd ":c"))))
(defun sbcl-debug-keys ()
"Binds locally some keys to send clisp debugger commands to the inferior-lisp
<f5> step into
<f6> next
<f7> step over
<f8> continue
"
(interactive)
(macrolet ((cmd (string)
`(lambda ()
(interactive)
(comint-send-string (inferior-lisp-proc)
,(format "%s\n" string)))))
(local-set-key (kbd "<f5>") (cmd "step"))
(local-set-key (kbd "<f6>") (cmd "next"))
(local-set-key (kbd "<f7>") (cmd "over"))
(local-set-key (kbd "<f8>") (cmd "out"))))
(defun allegro-debug-keys ()
"Binds locally some keys to send allegro debugger commands to the inferior-lisp
<f5> step into
<f7> step over
<f8> continue
"
(interactive)
(macrolet ((cmd (string)
`(lambda ()
(interactive)
(comint-send-string (inferior-lisp-proc)
,(format "%s\n" string)))))
(local-set-key (kbd "<f5>") (cmd ":scont 1"))
;; (local-set-key (kbd "<f6>") (cmd ))
(local-set-key (kbd "<f7>") (cmd ":sover"))
(local-set-key (kbd "<f8>") (cmd ":continue"))))
In this specific case of Common Lisp, of course SLIME does it for you
already. When I started programming in Lisp, SLIME didn't exist yet.
> Or (more exciting), you mean something like CL macros where you call
> it with some arguments and depending on the arguments it will 'expand'
> into different source code.
Also this. For example, you may find in my sources in inferior
programming languages, emacs lisp code in comments, that will generate
the following inferior language code. Typically for repeatitive stuff.
For example:
/*
(insert-fields '(visible color width height))
*/
private $visible=null;
public function setVisible($aValue){ $this->visible=$aValue; return($this); }
public function getVisible(){ return($this->visible); }
private $color=null;
public function setColor($aValue){ $this->color=$aValue; return($this); }
public function getColor(){ return($this->color); }
private $width=null;
public function setWidth($aValue){ $this->width=$aValue; return($this); }
public function getWidth(){ return($this->width); }
private $height=null;
public function setHeight($aValue){ $this->height=$aValue; return($this); }
public function getHeight(){ return($this->height); }
But I may also use the same technique to generate more complex code, for
example optimized decision trees (embedded ifs).
Notice there's an emacs lisp pre-processor:
http://www.xcf.berkeley.edu/~ali/elpp/cgen.el
http://www.xcf.berkeley.edu/~ali/elpp/elpp.el
http://www.xcf.berkeley.edu/~ali/elpp/elppc.el
Basically it allows you to insert elisp in your C code and to
autogenerate C code from elisp s-expressions. (I guess you could apply
it to other programming languages too).
But then your sources wouldn't be C sources, but C+emacs lisp, so it
would be harder to commit them in your employer's repositories.
Commiting comments with emacs lisp code is already hard enough...
--
__Pascal Bourguignon__
Mario S. Mommer
Jorge Gajon <ga...@gajon.org> writes:
> What I'm actually afraid is getting lured into "this new plugin", and
> then this "other cool plugin", oh! and there's this other one!.
> Dangerous stuff.
Look, it is fun, it makes you productive, and it doesn't hurt. It makes
your head spin, but not in a way you'll regret. Where's the problem? :-)
Tim Bradshaw
> Look, it is fun, it makes you productive, and it doesn't hurt.
It may be fun, but I can speak from some experience when I say that the
endless cycle of "let's just find another extension to play with" is
*not* productive. Indeed, if it wasn't for Emacs I'm reasonably
certain I would be in charge of the world by now.
Scott L. Burson
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
>
> The language needs to be sold macros-first if it is to have any chance
> of convincing newcomers that fully parenthesized syntax is a good
> thing.
Yes! An excellent point.
-- Scott
Jorge Gajon
Thank you Pascal, for these detailed examples. The first two examples
were specially interesting to me.
I've superficially used Emacs before, I know the basic commands, but I
will start learning it deeper now. I'm more convinced now that there it
can be worth the effort.
Best regards.
Jorge Gajon
I don't know. Without a proper context it would seem like you are trying
to convince me to smoke a joint :)
jurgen_defurne
> I have coded some simple syntax sugar to provide a vaguely "C-like"
> syntax for Lisp, part as a proof of concept, part with the intention
> of actually using it in a library. It's not meant to replace sexps but
> just to be less scary for newbies AND to show that the syntax argument
> against Lisp is just dumb. I'd never use it myself of course ;)
>
> The syntax is based on the Lisp reader, with these simple rules:
>
> , (comma) is considered whitespace.
> expressions are separated by ;
> ( ) still delimit lists.
> expressions consisting of multiple tokens are automatically wrapped in
> a list. Expressions consisting of a single token are not listified, so
> foo is read as a symbol while (foo) as a list.
> foo { ... } is roughly like `(foo ,@(list ...)) i.e. the expressions
> inside the braces are inserted in the outer expression.
>
> That's pretty much all, and it turns out - surprisingly - to cover
> many common expressions you can find in Lisp. Plus, reader macros
> still work (though of course they don't understand the "C-like"
> syntax).
>
> An example:
>
> with-output-to-string (str) {
> print #\c str;
> if (> foo 45) {
> progn { print 3; print 4; }
> print 5;
> }
>
> }
>
> If anyone's interested, the code is here:http://alessiostalla.altervista.org/software/c-like-lisp/cll.lisp
>
> it's far from perfect; for example, braces inside lists are read as
> literal characters. But, as a quick hack it came out pretty good,
> imho.
>
> Cheers,
> Alessio
I am doing the opposite : I am building a Lisp-like system programming
language to program a system for which I built the ISA, simulator and
assembler all in Common Lisp. Currently a little bit on hold due to a
very busy job, but hoping I can continue with it soon.
As someone who has programmed in Pascal, C, Clipper, FoxPro, COBOL (74
and 85), Perl, Scheme and Common Lisp, I think that Common Lisp offers
enough opportunities to be programmed by anybody. I have programmed in
C, but in the meantime I have come to really, really dislike its
cryptic syntax, and prefer the simple cleanliness of Lisp (any Lisp).
Regards,
Jurgen