Lisp without parentheses: Lisp INdented(genyris.com)
genyris.com
Lisp without parentheses: Lisp INdented
http://www.genyris.com/
10 comments
Yes, it has been a few months since the last person tried this.
Am i the only one who likes lisp because of the parenthesis and the lack of syntax? The parens are the perfect way of representing the syntax trees, and you dont have to be bothered with remembering all the syntax and operators etc like with the other languages.
Yes. But significant indentation does not destroy this lovely property.
No, definitely not. I agree with you 100%.
The claim that somehow this retains all qualities of Lisp is absolutely ridiculous. The single most important property of Lisp is that programs are lists, i.e., code==data. "Indented" lisp breaks this.
I'm not intending to troll when I say that people who don't like the parens just don't "get it."
The claim that somehow this retains all qualities of Lisp is absolutely ridiculous. The single most important property of Lisp is that programs are lists, i.e., code==data. "Indented" lisp breaks this.
I'm not intending to troll when I say that people who don't like the parens just don't "get it."
Not necessary that "indented" lisp breaks code==data property. Just like YAML can represent an arbitrary tree structure, indented syntax can be mapped to S-expr and vice versa.
I suspect the reason that alternative syntax for Lisp doesn't fly is that, once you use Lisp enough, you start feeling too comfortable with S-expr and the editor's support on it to switch to alternative syntax. It only appeals to those who are new to the language. And the downside is that the editor support can't be as good as S-expr (I suppose; is python-mode capable of various C-M-something tricks?).
I suspect the reason that alternative syntax for Lisp doesn't fly is that, once you use Lisp enough, you start feeling too comfortable with S-expr and the editor's support on it to switch to alternative syntax. It only appeals to those who are new to the language. And the downside is that the editor support can't be as good as S-expr (I suppose; is python-mode capable of various C-M-something tricks?).
No, you're not the only one. Often when writing code in other languages I think in Lisp, and then translate.
Nope, you're not :)
> the perfect way of representing the syntax trees
Humans don't think in syntax trees.
Humans don't think in syntax trees.
I do. When I think of algorithms I vaguely imagine DAG, which maps nicely to S-expr (the junction point maps to a tail function call).
In languages with syntax, I have to add syntactic fluff to satisfy the compiler, which is mostly an extra annoyance.
I don't say my way of thinking is the correct one. Some great programmers I respect have said they don't think in DAG (and naturally they choose languages other than Lisp as a primary tool).
In languages with syntax, I have to add syntactic fluff to satisfy the compiler, which is mostly an extra annoyance.
I don't say my way of thinking is the correct one. Some great programmers I respect have said they don't think in DAG (and naturally they choose languages other than Lisp as a primary tool).
Most humans don't. Some do.
Hm, this feels like comitting hara-kiri, but I actually found the eight queens sample:
http://www.genyris.com/wiki?page=default/eightqueenssource
A lot more readable than the 'regular' lisp version:
http://obereed.net/queens/algorithm.html
By automating the process of converting between 'indented' lisp and 'regular' lisp those that want it can have it and those that do not can simply ignore it.
http://www.genyris.com/wiki?page=default/eightqueenssource
A lot more readable than the 'regular' lisp version:
http://obereed.net/queens/algorithm.html
By automating the process of converting between 'indented' lisp and 'regular' lisp those that want it can have it and those that do not can simply ignore it.
I think that's partly because the way it's written is much more readable. Larger font probably doesn't hurt either (though the caps does).
True, having a round trip to Lisp's standardized format might make this usable. I have to wonder how much of Ruby's success is owed to being unable to trivially share Python code with strangers without most of our tools shredding the whitespace.
That's one of my pet peeves with python. Even sites like the django documentation suffer from this, cut&paste simply does not work in the python world and it is much poorer because of that.
It also can make debugging such a problem hell because you have to completely grok the code in order to spot the fact that the last line of a code block has somehow mysteriously jumped left 4 spaces.
And it makes refactoring code a major pain.
Braces rule compared to spaces.
It also can make debugging such a problem hell because you have to completely grok the code in order to spot the fact that the last line of a code block has somehow mysteriously jumped left 4 spaces.
And it makes refactoring code a major pain.
Braces rule compared to spaces.
cut&paste simply does not work in the python world and it is much poorer because of that.
I think that might have made it much better!
http://perldesignpatterns.com/?CutAndPasteProgramming
I think that might have made it much better!
http://perldesignpatterns.com/?CutAndPasteProgramming
Especially while learning a new language cut & paste is a pretty good way to get function definitions from the the tutorial into the interpreter.
Having to re-type a bunch of stuff that is already in a computer makes me feel like it is 1978 again.
Having to re-type a bunch of stuff that is already in a computer makes me feel like it is 1978 again.
Cut and paste is a good way to get the definitions from the tutorial into the interpreter without reading them.
Personally, I've only ever had a problem copy-pasting from the web. Even then, it is rare; a mild occasional annoyance well worth the price of the clutter free syntax.
Personally, I've only ever had a problem copy-pasting from the web. Even then, it is rare; a mild occasional annoyance well worth the price of the clutter free syntax.
There are other uses for cut/paste besides CutAndPasteProgramming; for example, one may want to post a snippet to a comment box that doesn't offer a preview function.
def foo(): if something: do_something_else print "bar"
What went wrong?
def foo(): if something: do_something_else print "bar"
What went wrong?
Set the highlight color of your () to white. Solved.
I set my editor to highlight my parens not de-emphasize so I can get a better picture of the structure of my code at a glance.
Why are people up-voting this? This is a recipe for bugs.
I think (hope) that it was meant to be funny as opposed to being a serious advice.
I've done this with Ruby and set the color to light gray. My co-workers wanted to have C/Java-style parens around damn near everything (except when they didn't; the reasoning to omit them was something along the lines of, "But, see, here it's a DSL." )
They strike me as line noise and make it harder to read many things, so I lightened up the color in my vim syntax files to give the appearance of more white space.
I had mixed results. Yes, it was far more readable to me, but there were times when a paren was missing or mistakenly added, or the spacing was off (another coding standard violation), and so on.
Now that I code on my own, the new coding standards say no parens unless required by the language. I also changed my syntax coloring back to more clearly show parens.
They strike me as line noise and make it harder to read many things, so I lightened up the color in my vim syntax files to give the appearance of more white space.
I had mixed results. Yes, it was far more readable to me, but there were times when a paren was missing or mistakenly added, or the spacing was off (another coding standard violation), and so on.
Now that I code on my own, the new coding standards say no parens unless required by the language. I also changed my syntax coloring back to more clearly show parens.
Heated debates amongst programmers (coworkers) about marginally important questions such as indenting styles, parenthesis usage, naming conventions, source code directory structure, etc. are always very amusing to observe. I usually sit back and just watch the show.
"I usually sit back and just watch the show."
Were that always an option. :)
Were that always an option. :)
Oh right. I get it now :-)
Light gray, then ;-P
Srsly, looking past the brackets is the least problem in reading lisp. The harder part is dealing with the lack of syntax, so you have to remember place structures instead of picking up hints from the punctuation. And in that regard, Pythonic indenting makes it harder.
Srsly, looking past the brackets is the least problem in reading lisp. The harder part is dealing with the lack of syntax, so you have to remember place structures instead of picking up hints from the punctuation. And in that regard, Pythonic indenting makes it harder.
Some IDEs (Alegro CL, cusp eclipse) display the arguments for all known forms and functions.
s/some/all/g
Nearly every Lisp development environment does that. SLIME, the poster child of excess does this as well. I don't think I matched parenthesis, indented or looked up a documentation since 2005.
Nearly every Lisp development environment does that. SLIME, the poster child of excess does this as well. I don't think I matched parenthesis, indented or looked up a documentation since 2005.
Doesn't help you if what you are trying to do is read code, rather than write it.
Perhaps we should go the Haskell route instead of the Python one?
is there a way to interchange ( to [ ? I have RSI.
P.S. Not keyboard mapping please.
P.S. Not keyboard mapping please.
(defun square-bracket-reader (stream char)
(declare (ignore char))
(read-delimited-list #\] stream t))
(defun use-square-bracket-readtable ()
(set-macro-character #\[ #'square-bracket-reader)
(set-macro-character #\] (get-macro-character #\) nil)))thanks!
DrScheme (PLT scheme's IDE) automatically translates [ and ] to ( and ) where appropriate. It's very handy.
Best attempt at this has got to be Dylan. Latest, plausible, attempt is probably David Moon's PLOT (Programming for Old Timers):
http://users.rcn.com/david-moon/PLOT/
See how he does macros for a syntax-full language :-)
http://users.rcn.com/david-moon/PLOT/Moon-ILC09.pdf
http://users.rcn.com/david-moon/PLOT/
See how he does macros for a syntax-full language :-)
http://users.rcn.com/david-moon/PLOT/Moon-ILC09.pdf
Either have parentheses and format by hand or use parentheses and have the editor format the text. Personally, I like the latter best. Easier to change stuff.
[deleted]
Oh no, I have no parenthesis. I am not a dataset nor a function, how do I compute?
Did you mean Python?
Well not really, Pythons' syntax isn't homoiconic.
http://en.wikipedia.org/wiki/Homoiconicity
http://en.wikipedia.org/wiki/Homoiconicity
At least most of it isn't.