What if Clojure had an alternate "surface" syntax that was translated
into standard Clojure syntax by a kind of preprocessor?
Many people that don't like Lisp dialects don't like them because of
the parentheses. I'm trying to address that.
Here's a simple example of valid Clojure code.
(defn pig-latin [word]
(let [first-letter (first word)]
(if (.contains "aeiou" (str first-letter))
(str word "ay")
(str (subs word 1) first-letter "ay"))))
(println (pig-latin "red"))
(println (pig-latin "orange"))
Here's what that same code would look like in my alternate syntax.
defn pig-latin [word]
let [first-letter (first word)]
if .contains "aeiou" (str first-letter)
str word "ay"
str (subs word 1) first-letter "ay"
println (pig-latin "red")
println (pig-latin "orange")
The rules for turning this into standard Clojure syntax are pretty simple.
1) If a line is indented farther than the previous one, it is part of
the previous line.
2) If a line doesn't start with a (, then add one.
3) If the next line is indented less than this one, add the
appropriate number of )'s at the end.
4) If the first token on a line is "if" and the first non-whitespace
character after it is not (
then assume the rest of the line is the condition and wrap it in ( ).
A translation from standard Clojure syntax to this alternate form
should also be possible.
Is this a bad idea?
--
R. Mark Volkmann
Object Computing, Inc.
No. This would be a translation step before the code is fed to the
current Clojure reader.
>> Many people that don't like Lisp dialects don't like them because of
>> the parentheses. I'm trying to address that.
>
> How many of those have spend enough time with a lisp to form a valid
> opinion of the syntax?
The parens don't bother me. My concern though is that many people
won't take the time to learn Clojure primarily because of the parens.
The preprocessor would appease those people and not change anything
for those that like Clojure just fine as it is.
> Rule 4 is a special case that introduces inconsistency. I am against it.
>
> The syntax is basically introducing implicit parenthesis based on
> indentation.
That's correct. The preprocessor would be just like Python in that
regard. People that don't like Python won't like this either.
No. This would be a translation step before the code is fed to the
On Mon, Feb 23, 2009 at 10:55 AM, Christian Vest Hansen
<karma...@gmail.com> wrote:
>
> On Mon, Feb 23, 2009 at 4:42 PM, Mark Volkmann
> <r.mark....@gmail.com> wrote:
>>
>> I have an idea I'd like to float to see if there are reasons why it's
>> a bad idea.
>>
>> What if Clojure had an alternate "surface" syntax that was translated
>> into standard Clojure syntax by a kind of preprocessor?
>
> Do you by any chance mean "custom reader" when you say "preprocessor"? :)
current Clojure reader.
> The parens don't bother me. My concern though is that many people
> won't take the time to learn Clojure primarily because of the parens.
Rule one of programming: never code anything you're not going to use
yourself. Unless you're getting paid to do it. Or something.
> The preprocessor would appease those people and not change anything
> for those that like Clojure just fine as it is.
Not really. People who use this preprocessor would still have to learn
to read Clojure code. And presumably these people would be releasing
libraries, so this would affect the Real Clojure programmers as
well. Nothing happens in a vacuum.
This idea gets proposed to various segments of the Lisp community with
astonishing regularity[1]. AFAIK the only time it ever went anywhere (for
some value of "went anywhere" at least) was with Dylan[2]. Needless to
say, this did nothing to increase the appeal of Dylan to the language
community at large and really only alienated people who actually
understood Lisp.
I hate to sound like a Smug Lisp Weenie™, but if people want to learn
Clojure, they're going to have to get comfortable with its
syntax. Parentheses aren't some embarrassing historical accident;
they're part of the reason lisps are so powerful.
-Phil
[1] http://www.dwheeler.com/readable/sweet-expressions.html
http://www.lispin.org/
http://www.archub.org/noparen.arc
http://pschombe.wordpress.com/2006/04/16/lisp-without-parentheses/
... and many more.
The parens don't bother me. My concern though is that many people
won't take the time to learn Clojure primarily because of the parens.
The preprocessor would appease those people and not change anything
for those that like Clojure just fine as it is.
Am 23.02.2009 um 19:42 schrieb Dan Larkin:
> But.. but... macros? code is no longer data?
It still is. Macros don't work on the String "(foo bar)"
but on the data structure (list 'foo 'bar). Whether this
is represented as >foo bar<, (foo bar) or implicit via
indentation doesn't change this. Macros happen
after the reader....
Sincerely
Meikel
I'm opposed to this idea. I don't think we should pander to the
masses by creating a schism between new and experienced users. New
users should be introduced to the real thing immediately and it is up
to the tutorials and community to help them overcome the fear/
puzzlement of parentheses. Like many other people have mentioned,
parentheses are not there just to be different, they're an integral
part of Clojure's power and hiding that fact from users will just
prevent them from using Clojure the way it's meant to.
What's the problem with parentheses anyway? It's the same as in Java
except you move the opening parentheses to the left of the function
name (and with Clojure, you don't even need to remove the commas!):
foo(bar, baz) => (foo bar, baz)
Vincent.
The problem is (+ 1 2) which is unlike how you normally do maths
If the procedure application uses a nested expression to select the
procedure to apply, it looks like using your heuristics, the
parentheses cannot be omitted:
Clojure:
((if (< x 0) - +) x)
Haskell: (s-expression with optional parentheses and infix operators):
(if (x < 0) then (\x -> -x) else id) x
Using your proposed rules, this does not work
(if (< x 0) - +) x
as the line starts with parentheses, and so the parser will assume
parentheses do not need to be added
A Haskell-like parser would be kind of cool, though -- is it worth the hassle?
--
miʃel salim • http://hircus.jaiku.com/
IUCS • msa...@cs.indiana.edu
Fedora • sal...@fedoraproject.org
MacPorts • hir...@macports.org
As I said, it's not me that has a problem with parentheses. It's not
hard to find developers that say that don't like Lisp because of the
parens. I think the question is whether we should make an effort to
appease those people. Clearly the majority of the people on this list
feel the answer is "no".
> 2.) If you think it's a good idea why bother to ask for permission?
I didn't ask for permission. I asked if others thought it was a good
idea. Most said "no".
> Create your RMVClojure and release it to the world. If people think
> it's a good idea they'll adopt it. If not . . . well, they won't.
> There are, of course, downsides to forks but if you really feel that
> this would help adoption of Clojure, why ask for the permission of
> others?
It wouldn't be a fork. It would be a simple preprocessor that would
use standard Clojure after the preprocessor runs.
Yes, I like that idea. If I get time to work on this, I'll do that.
I have a feeling that developers who use the "too many parentheses"
reason for avoiding Clojure (or other lisps) will just find another
reason when you remove the parentheses.
--
Michael Wood <esio...@gmail.com>