Sometimes I feel like I'm the only person who actually prefers parentheses. They just seem so much more useful than having to mentally parse indentation, or what kind of parens are there, or whether there's a space between the function name and its arg list.
Some of these suggestions are to get people to kneejerk less when they see Lisp code, but some parts are presented as being better for existing Lisp coders.
I can relate with wanting to be more accessible to non-lispers, but I primarily want to search for better ways to write programs. I'm not in the education business. I'm in the invention business.
Parsing indentation is a muscle just like parsing parentheses. Some programmers have experience with one, some have trained their visual cortex with the other. Whichever side you're on, it's good to leave one's comfort zone. Otherwise we risk being ruled by our languages and tools.
---
Checking for the space between function name and its arglist is a (minor) burden for the writer, but it seems painless for the reader. I think that's the right kind of decision. I'm happy to put the writer through some hoops if it makes reading easier.
The primary problem with Java's verbosity isn't that it's too much trouble to type. It is that it leaves readers to sip at the codebase through a straw.
Again, I'm not a fan of readable's specific approach. But I am totally on board with the general idea of looking to improve on s-expressions. I'm sure there can be new features out there that are better for existing Lisp coders.
I do agree that s-expressions shouldn't be set in stone. But I'm not sure that these specific suggestions are useful. Maybe I'm being a Luddite in regards to change.
I guess I'm on board with the curly-infix expressions for math. Maybe. I do hate having to mentally parse through lines like
{{1 * 2} + {3 / 4}}
To get "oh, this is adding two things together". But ok. Maybe. But the minute I have to distinguish between the form
... fun(arg1 arg2 arg3) ...
and
... fun (arg1 arg2 arg3) ...
I'm done. Granted, I haven't actually used neoteric expressions -- and I should try them -- but until I do, this style looks much less readable to me. I disagree that it's painless; it seems actually quite painful to me. It sure is closer to Algol-style coding, but it's just asking you to confuse the two. And that's easily done.
Fair enough. You don't typically see the no space style in lisp, so it stands out for me. But you're right that it's not as cut and dried as I thought.
Whenever I see things like the linked presentation (turns out I've seen it before), I can't help but think it's a solution in search of a problem. Simple parsing & evaluation models lead to expressive languages, and (I intuit) that's why their notations stick around despite people's efforts. For time immemorial, projects like these try to take a simple, consistent notation and pile on an abominable number of special cases with line noise more offensive than just parentheses [1]. It's not only unfitting for Lisps, but it's limiting for language design. There's only so much you can do with abbreviations, but soon enough there's feature-creep. I see that in his estimation (http://sourceforge.net/p/readable/wiki/Retort/), the special cases are sparing. But really? He needs three kaleidoscoping levels of syntax, knee-jerks to using the different brace types to supply soothing Algol-isms, introduces an indentation scheme that needs clarification regarding edge-cases with traditional syntax, and still finds a way to need special characters with special rules for "advanced" features. I guess we can agree to disagree...
In the end, I think it's a mistake trying to make Lisp notation something it's not. Much better is trying to improve what you've got within the structure of the language, like Arc turning
(let ((a 1) (b 2))
(+ a b))
into
(with (a 1 b 2)
(+ a b))
People are drawn to the idea of finally making Lisp "accessible" (I guess fixing society's use of infix notation is harder :P) while still retaining homoiconicity. Yet most seem to forget that homoiconicity requires simplicity, not Lisp syntax. People get stuck thinking inside the Lisp box, but again, simple parsing & evaluation models lead to expressive languages. For instance, combine a stack machine model (http://docs.factorcode.org/content/article-evaluator.html) with a simple parsing algorithm (http://docs.factorcode.org/content/article-parser-algorithm....) and you get a homoiconic language. Of course, it's a postfix language, so its math is unparsable to mere mortals...
[1] I admit he has a point about existing abbreviations that I'm simply used to, like quote/quasiquote/comma/splice and dotted lists. I think where those notations have stood the test of time is that they're subtle. I can use the quote family and the code still looks like Lisp, instead of looking like Lisp trying to look like C.
shader, fallintothis, will you email me? Email in profile. I'm going to post my solution to infix :) in a few days or weeks, and I would like to ping y'all to make sure I can get your criticisms.
(I'm not sure if you come here often or go periods without visiting.)
I think some moderate use of parentheses is okay, but I don't really like using them everywhere. Though, I wouldn't really mind an Arc dialect that had good syntax for functions and a Nulan-style type system, even if it did use parens.
Yeah, I'm sure a lot of you have seen this already. I'm really more interested on what your current opinions are concerning the various M-expression styles vs. traditional S-exprs.
The readable/sweetexpr project is probably the most comprehensive place to see the state of the art. I'm not actually eager to use it, though; I think you can do better if you don't care about supporting existing lisps.
