alternate syntax
Mark Volkmann
a bad idea.
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.
David Nolen
Christian Vest Hansen
<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?
>
> Many people that don't like Lisp dialects don't like them because of
> the parentheses. I'm trying to address that.
opinion of the syntax?
There are many programming languages who's syntax looks ugly to the
eye that do not understand its meaning.
The syntax is basically introducing implicit parenthesis based on
indentation. I have been pondering this idea as well, but decided that
Clojure already goes so easy on the parenthesis, that it wasn't worth
my time to persue it any further.
>
> A translation from standard Clojure syntax to this alternate form
> should also be possible.
>
> Is this a bad idea?
prefer it as their primary reader over the standard Clojure reader.
It could, on the other hand, find a nice niche in DSLs, for programs
that need some level of scriptability by people who cannot be expected
to be lisp savvy.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Dan
Kevin Downey
http://github.com/hiredman/odds-and-ends/blob/8a84e6ddbad9d71f714ba16c3e1239633228a7eb/functional.clj#L94
it does transformations on code using zippers.
for example:
(pl inc $ inc $ 0) expands to (inc (inc 2))
pl is just a toy but it might be worth looking at.
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
Mark Volkmann
<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"? :)
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.
Cosmin Stejerean
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.
--
Cosmin Stejerean
http://offbytwo.com
Phil Hagelberg
> 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.
Laurent PETIT
Indeed, it's something I've also kept in mind when clojure-dev has waaay more functionalities than now (so this day is not coming very soon ;-).
That is, experimenting with an optional thin layer between the user and the real source file.
In order for that to work, though, I think the rules must allow for real bi-directional translation from the 2 forms.
And concerning the rule for if, there may be another more general pattern to find.
Certainly something along the lines of how Haskell does things.
--
Laurent
.Bill Smith
> 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.
want to expand the Clojure community by helping parentheses-adverse
people out. It seems to me that introducing a second syntax may help
beginners but will make things worse the longer they use it. For
example, if a second-syntax user has a problem, where should they go
for help? Should there be two Clojure forums, one for the Lisp syntax
and one for the second syntax? Should there be two versions of the
documentation, one written in the second syntax? Which syntax should
libraries be written in? Of course as long as there aren't any bugs
in the preprocessor, code written in the two syntaxes should be
compatible, but if I use the second syntax because I don't want to
adjust to parentheses, what happens if I need to read library code
that's been written using Lisp syntax?
Bill Smith
Dudley Flanders
> 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.
:dudley
[0] http://en.wikipedia.org/wiki/M-expression
David Nolen
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.
Laurent PETIT
... and was very surprised to feel a little "losts" without the parenthesis on the examples ! :-)
Anyway, since clojure-dev colorizes parenthesis depending on how deep they are in the hierarchy, I think it's not even painfull at all to live with parenthesis.
See this snapshot for an example : http://code.google.com/p/clojure-dev/wiki/ScreenShots#Source_code_Editor
I know also of gorilla (vim plugin), and certainly emacs (not sure about enclojure, though) that offer parens colorizing (also named rainbow parens).
Concerning the debate : should this be "just an IDE trick" to remove parens, or "a preprocessor", I'm very very against the idea of a preprocessor, for all the reasons other people have said about it : because it will inevitably lock beginners into something that is not really clojure, they won't be able to easily share libraries, they will feel bad when reading "real clojure" libraries code.
In the other end, I think a bidirectional translator could be interesting in an IDE to visually help people, from time to time.
My 0,02 €,
--
Laurent
MarkH
And anybody that brings up Dylan as a counter-example doesn't know
what they're talking about. Dylan died because Apple killed it.
Dan Larkin
Matt Revelle
are handy and not baggage.
Something like coffeemug's post on the subject: http://www.defmacro.org/ramblings/lisp.html
>
> >
Meikel Brandmeyer
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
Vincent Foley
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.
Dan
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.
Even though it shouldn't be included in clojure and I'm skeptical about its usefulness, it's a bad idea to tell people what they can or can't code.
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 and that parens determine scope and flow while you need braces in java to do that. You are saying that parens are what makes Clojure powerful and then you say they are just like Java's. Sorry, you can't have it both ways.
Tom Ayerst
Stuart Sierra
> 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.
The original Lisp had something called "M-expressions", a surface
syntax without parentheses. But no one ever bothered to implement it.
About once a month someone brings up "Lisp without parentheses" on
comp.lang.lisp. It's never caught on. For one thing, it's harder
than you think when you get into all the edge-cases. For another, it
usually doesn't offer any compelling advantages over the standard
syntax.
-Stuart Sierra
Joshua Fox
Can you do this without reader macros? Can you keep it homoiconic? (Apparently so, given the transformation rules, but I wonder if there are any corner cases.)
Cosmin Stejerean
The problem is (+ 1 2) which is unlike how you normally do maths
Fogus
> formulas a macro that allows infix notation would be useful (and I'm pretty
> sure I've seen at least one).
into now, wanted to distribute a modified version of CLIPS to its
customers that did not resemble LISP syntax.
Taking care of things like (printout t "foo") was a simple matter of
forcing the parser to recognize it as printout(t "foo"). Piece of
cake. The harder problem of course was that (+ 1 2 3) became +(1 2 3)
which was even more unacceptable to the customer. Therefore, we added
a special null function to the parser that took a bunch of symbols
representing an infix mathematical expression and converted it to
function calls:
(1 + 2 + 3) => +(1 +(2 3))
or
(1 + (6 / 3) + 3) => +(1 /(6 3) 3)
and so on...
It required every math expression to be enclosed in parens, but they
didn't care; it was a hit. Weird. I am not encouraging an alternate
syntax for Clojure (or Lisp), only stating that turning an s-expr
based language into something that vaguely resembles a c-syntax
language is not that difficult, even for math expressions.
-m
Rayne
On Feb 23, 12:01 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> I know also of gorilla (vim plugin), and certainly emacs (not sure about
> enclojure, though) that offer parens colorizing (also named rainbow parens).
Michel Salim
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
Onorio Catenacci
> should also be possible.
>
> Is this a bad idea?
>
like to share:
1.) What's so hard about using parentheses? I mean really it's just a
different syntax to learn. Is this really that much more difficult to
understand than using curly braces in C-based languages or IF/ ENDIF
(and similar constructs) in VB and VB-like languages? What I
personally find confusing is _inconsistent_ syntax. If I live to be
100 I don't think I'll ever be able to remember the rule about when a
person uses parentheses behind a subroutine or function call in VB.
This is one reason I don't much care for VB.
2.) If you think it's a good idea why bother to ask for permission?
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?
--
Onorio Catenacci III
Mark Volkmann
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.
Laurent PETIT
If you have not been discouraged by the crowd of people having answered 'no' to your question :-), and still have the idea of exploring this area, would you consider designing a "surface language" that allows bidirectional flow to and from clojure code ?
If you do so, then you would well provide two functions, one from your langage to clojure, and one from clojure to your language.
And then, it could be easy to :
* translate back and forth between your language and clojure
* use your work in IDEs (see what I mean :-) as just an alternate visualisation/editing option (and potentially still let the IDE use straight clojure format persistence ).
:-)
--
Laurent
Mark Volkmann
> Mark,
>
> If you have not been discouraged by the crowd of people having answered 'no'
> to your question :-), and still have the idea of exploring this area, would
> you consider designing a "surface language" that allows bidirectional flow
> to and from clojure code ?
>
> If you do so, then you would well provide two functions, one from your
>
> And then, it could be easy to :
> * translate back and forth between your language and clojure
> * use your work in IDEs (see what I mean :-) as just an alternate
> visualisation/editing option (and potentially still let the IDE use straight
> clojure format persistence ).
>
> :-)
Yes, I like that idea. If I get time to work on this, I'll do that.
Michael Wood
<r.mark....@gmail.com> wrote:
[...]
> 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".
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>
Onorio Catenacci
name. :-)
--
Onorio Catenacci III
jwhitlark
Clojure anymore.
Personally I'm opposed to watering something down just because it's
tricky.
~Jason