"C-like" syntax for Lisp in less than 100 lines of code
in [Lisp]
|
From: Tamas K Papp on 21 Apr 2010 13:26 On Wed, 21 Apr 2010 09:59:34 -0700, Pillsy wrote: > On Apr 21, 10:51 am, Tamas K Papp <tkp...(a)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
From: Alessio Stalla on 21 Apr 2010 13:52 On 21 Apr, 08:02, Peter Keller <psil...(a)merlin.cs.wisc.edu> wrote: > Alessio Stalla <alessiosta...(a)gmail.com> wrote: > > 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. 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
From: Mario S. Mommer on 21 Apr 2010 14:23 Alessio Stalla <alessiostalla(a)gmail.com> writes: > On 21 Apr, 08:02, Peter Keller <psil...(a)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. :) > 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; }; [...] 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.
From: Pascal J. Bourguignon on 21 Apr 2010 18:27 Pillsy <pillsbury(a)gmail.com> writes: > On Apr 20, 11:43�pm, G�nther Thomsen <guenth...(a)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__
From: Pascal J. Bourguignon on 24 Apr 2010 05:07
Tamas K Papp <tkpapp(a)gmail.com> writes: > On Fri, 23 Apr 2010 11:09:43 +0200, Nicolas Neuss wrote: > >> Tamas K Papp <tkpapp(a)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. 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__ |