4 ms·
I like fiddling around with weird languages... but... You find it. Then you start walking forward, looking for a closing parenthesis. This is the worst way to
by agentultra 14y ago
I like fiddling around with weird languages... but...
You find it. Then you start walking forward, looking for a closing parenthesis.
This is the worst way to work with Lisp code and is unfortunately the most naive way. It happens to be the way most people immediately jump to when editing Lisp code and hence how we end up with the pernicious "parenthesis" meme.
The way most Lisp programmers handle parenthesis is by using a smart editor. The "parens" structure the code very closely to the AST of the actual program. Computers love trees and editors can therefore readily manipulate them with little effort. You rarely edit the text of a Lisp program this way and instead edit it's tree.
Note: See the 'paredit' package in emacs for an example.
- chrisdone 14y agoI meant as _implementing_ an editor, like Paredit. If you're implementing Paredit, you need to find the parens in order to manipulate the current node. I just meant it's slightly easier to write such an editor. (∩▂∩) At least, I think it would be. I haven't tried!
- tych0 14y agoWouldn't it be easier to use some kind of formal grammar and a parser instead of the stack based thing you describe? In that case, lisp is probably one of the easiest languages to parse since it is all parenthesized s-expressions and not whitespace dependent at all.
- chrisdone 14y agoSure, it's fairly easy to parse. I think probably there is a speed hit (Emacs Lisp code is very slow—though you can call out to an external C library (I've tried it), for which ECL could be maybe used), but quite possibly it's just that, for Lisp, Paredit is mostly sufficient. I think the only case where it breaks down/has trouble is reader macros. I think it can consult SBCL somewhat upon encountering them, not entirely sure.
- hga 14y agoI have tried, and it's very easy (Goldhill's editor back in 1984); can't say for other languages, though.
- raverbashing 14y agoMy impression sometimes is that RPN (like in Forth) could be used as well and do with parenthesis altogether But of course, Forth has a stack, Lisp does not need one To write 5 * (2 + 3) Lisp: ( * 5 (+ 3 2)) Forth (ignore the dot): 2 3 + 5 * .
- akkartik 14y agoCheck out nokolisp for the opposite of your idea! http://koti.welho.com/tnoko/Nokolisp.htm http://koti.welho.com/tnoko/Nokolisp.htm
- RodgerTheGreat 14y agoForth actually has two stacks. Lisp has garbage-collected storage and environment structures, and Forth does not need them. :) Logo is a Lisp-like language which uses prefix notation but does not require parentheses surrounding every procedure invocation. Your example could be written as: product 5 sum 3 2 Parens are allowed for adding clarity and are only required for a vararg-style invocation. The main downside of this approach is that it is necessary to know the arity of every procedure in an expression to unambiguously parse it- Logo implementations typically either defer some safety checks to runtime or compile in two passes. Forth doesn't have this problem because it doesn't parse expressions per se- it compiles and interprets as it goes along.
- eru 14y agoLisp needs the parenthesis not because it lacks a stack, but because functions (like +) can take a variable number of arguments.
- darkf 14y agoI made a parentheses-less Lisp-inspired language a while back by using prefix (polish) notation with fixed-arity functions. You can find it here: https://github.com/darkf/possumv2 https://github.com/darkf/possumv2