Talking from a strong PHP and Java background and zero previous Lisp
experience -
All I can say is, keep it simple. With the (f x) form, there's zero
syntactical ambiguity. There are bigger problems in the world besides
where the paren goes. Move along. :)
On Dec 28, 12:26 am, Gert Verhoog
I can't imagine what benefits M-expressions in Clojure would give us.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
There's a very nice summary of previous attempts at this on David Wheeler's
web page: http://www.dwheeler.com/readable/index.html
I think these ideas have some merit. I would like to have the readability
and conciseness of Python with the features and performance of Clojure.
--
You received
On Fri, Dec 30, 2011 at 9:19 AM, PC pca...@gmail.com wrote:
There's a very nice summary of previous attempts at this on David Wheeler's
web page: http://www.dwheeler.com/readable/index.html
I think these ideas have some merit. I would like to have the readability
and conciseness of Python
True, lack of conciseness may not be the first thing that comes to mind
when speaking about Lisps :-)
What I should have said is that I think equivalent Python code has fewer
'noise' symbols than S-expressions. Of course, that depends greatly on how
the programs are structured.
And, that
How about using a and b instead of ( ) so we could have faab which would be the
equivalent of (f a) so it would rule out symbolnames with an a in any place but
the first it, also we could go for less used characters as I don't know ¥ and µ
for example so that would not be half as fun I think.
Lisp experts don't quite understand
It's certainly possible. It wouldn't be the first time that Lispers
missed the forest for the trees. However, let's turn it around for a
moment and ask another question: why is it that some newcommers year after
year think that the choice of this syntax is
I am a polyglot programmer and never insisted to change the look of any
language.
I used them as is assuming that many people worked on their design for
several man years, more that I could spend myself on any of these design
decisions
and their impacts.
I worked with at least a dozen of these
However, let's turn it around for a
moment and ask another question: why is it that some newcommers year after
year think that the choice of this syntax is arbitrary?
Some people come with lots of baggage from other languages they like.
That's why various complaints and proposals are so
+1 Luc,
You have to let go. There was something I read once from Alistair and said
that people prefer familiarity over comfort, this is a real problem,
because when people get used to something it's really hard to show them
something more comfortable. I was shocked when I found myself choosing
The thing about lisps, though, is that code and data are represented
with the same structure. Adding sugar that makes them appear to be
different things would not help anyone, especially the beginner. It
will make grasping macros, among other things, much more difficult
down the road. Getting
Agree on looking from the angle of data structure and their internal
presentation. But conceptually, [] and {} are just syntax sugars:
[x y] - (vector x y)
{x y} - (hash-map x y)
#{x y} - (hash-set x y)
The 2 element structures are all become 3 element lists.
Louis
On Dec 29, 7:03 am,
On 29 December 2011 16:35, Louis Yu Lu louisy...@gmail.com wrote:
Agree on looking from the angle of data structure and their internal
presentation. But conceptually, [] and {} are just syntax sugars:
[x y] - (vector x y)
{x y} - (hash-map x y)
#{x y} - (hash-set x y)
Well, no, not
On 29 December 2011 04:49, Louis Yu Lu louisy...@gmail.com wrote:
Instead of using overloaded (), may be f[x] will cause less trouble,
and more inline with clojure's syntax as [ ] already being used for
defining the arguments of the function.
I think you need to look at this from a slightly
How about using a and b instead of ( ) so we could have faab which would be the
equivalent of (f a) so it would rule out symbolnames with an a in any place but
the first it, also we could go for less used characters as I don't know ¥ and µ
for example so that would not be half as fun I think.
do you mean syntax sugar = macro ?
On Thu, Dec 29, 2011 at 12:48 PM, James Reeves jree...@weavejester.comwrote:
On 29 December 2011 16:35, Louis Yu Lu louisy...@gmail.com wrote:
Agree on looking from the angle of data structure and their internal
presentation. But conceptually, [] and {}
Why not create a klingon version ?
How about using a and b instead of ( ) so we could have faab which would be
the equivalent of (f a) so it would rule out symbolnames with an a in any
place but the first it, also we could go for less used characters as I don't
know ¥ and µ for example
Better yet we can say that function calls and forms always start with a
symbol and end with punctuation or some natural delimiter. So we could
write things like:
defn f [x]
println hi!
42;
.
doseq [e range 10 20]
f e;
.
map fn [x] Math/pow x 2.0, range 10.
if even 3?
:even
:odd.
I suggest the Klingon downward triangle Natural delimiter you said ? :)
http://www.evertype.com/standards/csur/klingon.html
Luc
Better yet we can say that function calls and forms always start with a
symbol and end with punctuation or some natural delimiter. So we could
write things
Am 30.12.2011 um 00:19 schrieb Softaddicts:
I suggest the Klingon downward triangle Natural delimiter you said ? :)
And the irony that it is only used in latin transliteration…
Meikel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to
Quoth Louis Yu Lu on Boomtime, the 70th of The Aftermath:
The proposed syntax sugar apparently pleases my eyes and fingers
from conventional languages. With some experiments, I found the code
is more readable for me to use f(x) notation for function call, and
(op x) for operator.
It sounds
Instead of using overloaded (), may be f[x] will cause less trouble,
and more inline with clojure's syntax as [ ] already being used for
defining the arguments of the function.
Louis
On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote:
On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote:
My
Why not use fx ?
On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote:
Instead of using overloaded (), may be f[x] will cause less trouble,
and more inline with clojure's syntax as [ ] already being used for
defining the arguments of the function.
Louis
On Dec 27, 5:26
f%x% would probably work outside of #() forms. % is a symbol delimiter.
Ambrose
On Thu, Dec 29, 2011 at 12:56 PM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Why not use fx ?
On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote:
Instead of using
Since square brackets have been usurped by vectors, angle brackets
could be used to approximate M-expressions.
Quoth Ambrose Bonnaire-Sergeant on Boomtime, the 70th of The Aftermath:
Why not use fx ?
On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote:
Instead of using
On further thought, it will be a breaking change
(def fx 1)
(let [x 1]
fx)
% would work better.
Ambrose
On Thu, Dec 29, 2011 at 2:00 PM, Peter Danenberg p...@roxygen.org wrote:
Since square brackets have been usurped by vectors, angle brackets
could be used to approximate M-expressions.
% would work even worse because it doesn't nest. I still think the
whole idea ia a dreadful one, but would cause problems less often
than other suggestions.
On Dec 28, 10:06 pm, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
On further thought, it will be a breaking change
(def
On 12/26/2011 07:09 PM, Louis Yu Lu wrote:
With some experiments, I found the code is
more readable for me to use f(x) notation for function call, and (op
x) for operator.
Operator? It's all function calls!
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
The proposed syntax sugar does not break the existing code, it make it
easier to read and more fun for programmer from other language on the
ramping up stage. Even with mixed notation, I don’t see issue of
usability; the modified reader will handle it.
I sense the objection is that the f(x)
On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu louisy...@gmail.com wrote:
The proposed syntax sugar does not break the existing code
clojure.core= map(first [[1] [2]])
#core$map clojure.core$map@5ec3d2
[1]
Ambrose
--
You received this message because you are subscribed to the Google
Groups
Louis, obviously there's a problem here, the REPL should return
user= (map first [[1] [2]])
(1 2)
As for my point about macros, it's not about the calls, it's about macro
processing before
spitting out the code that will be compiled, what would this return ?
user= (defmacro mymac [func]
(let
I don't see the point of your proposed syntactic change, and I just
can't imagine it gaining traction. In my view, there are more pressing
and important issues than trying to cater to the needs of people that
are scared by (f x) as opposed to f(x). Since programming languages
are artificial
On Mon, 2011-12-26 at 10:09 -0800, Louis Yu Lu wrote:
Recently, I found freedom of coding playing with Clojure with over 20
years’ experience on other program languages, Previously, I had
several trials of learning Lisp, but never got traction.
However there are two syntax notations always
I don't see a reason for f(x) sugar, but if I had to do some complex
formulas I'd consider looking into a macro to enable infix math.
On Dec 27, 2011 2:44 PM, daly d...@axiom-developer.org wrote:
On Mon, 2011-12-26 at 10:09 -0800, Louis Yu Lu wrote:
Recently, I found freedom of coding playing
Luc,
I see you and other people put great points on this subject, that is
exactly what I wanted to know about the 'dark corner' in my initial
post.
Just for your info, I have tried on the modified reader, the following
alternatives all works:
Clojure 1.4.0-master-SNAPSHOT
user= (map first [[1]
So if I understand correctly, your proposal makes the absence/presence of space
pivotal
in making the decision about parsing infix/postfix notation ?
Luc
Luc,
I see you and other people put great points on this subject, that is
exactly what I wanted to know about the 'dark corner' in my
Yes, to be exactly, the simple change in the reader is after parsing a
symbol, if the following char separating the symbol is '(', the symbol
become the leading item of the following list, otherwise it is a
regular item in the current list context.
Louis
On Dec 27, 4:16 pm, Softaddicts
Do you support this?
classic: ((foo bar) baz)
your syntax: foo(bar)(baz)
Scott
On Mon, Dec 26, 2011 at 1:09 PM, Louis Yu Lu louisy...@gmail.com wrote:
Recently, I found freedom of coding playing with Clojure with over 20
years’ experience on other program languages, Previously, I had
Using the absence/presence of a space to influence parsing bugs me a lot...
No idea about using an explicit delimiter ?
My main concern is how can the reader report a decent error message
if there's an input mistake in this context ? I feel that a mistake
can have far reaching side effects
I am not suggesting switching the whole Lisp syntax, just provide a
'sugar'
((foo bar) baz) can written as (foo(bar) baz)
On Dec 27, 4:35 pm, Scott Jaderholm jaderh...@gmail.com wrote:
Do you support this?
classic: ((foo bar) baz)
your syntax: foo(bar)(baz)
Scott
On Mon, Dec 26, 2011 at
The modified reader will report no more, no less parsing error than
the current Clojure reader.
On Dec 27, 4:40 pm, Softaddicts lprefonta...@softaddicts.ca wrote:
Using the absence/presence of a space to influence parsing bugs me a lot...
No idea about using an explicit delimiter ?
My main
I don't usually reply to this sort of thread, but I'll toss in two
cents worth anyway. Speaking as a PHP programmer wading his way
through the beginning-to-intermediate stages of Clojure, I have to say
that I do not like the proposed sugar. If I wanted to write PHP in
Clojure, I'd just write PHP,
On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote:
My proposition is enhance Clojure to accept both (f x) and f(x)
Fortunately, I don't see that happening, for several reasons (many of which
have been mentioned). It adds complexity, causes confusion and inconsistent
coding styles and it will break
On 26 December 2011 18:09, Louis Yu Lu louisy...@gmail.com wrote:
My proposition is enhance Clojure to accept both (f x) and f(x), the
leading item can appear either after ‘(‘ as usual with classic Lisp
notion:
(println Hello, world!)
or with conventional function call notation:
Overall, it's a lot of effort (not the patch but the tests)
and there's a significant potential to cripple future additions
more in line with the current syntax.
Infix notation to be safe implies the use of a lot more delimiters to avoid
ambiguities.
Clojure is not going at all in this
Recently, I found freedom of coding playing with Clojure with over 20
years’ experience on other program languages, Previously, I had
several trials of learning Lisp, but never got traction.
However there are two syntax notations always bother me, it feels
unnatural with my experience on other
Recently, I found freedom of coding playing with Clojure with over 20
years’ experience on other program languages, Previously, I had
several trials of learning Lisp, but never got traction.
However there are two syntax notations always bother me, it feels
unnatural with my experience on other
Hi,
I have more than 30 years of dev under my belt dated back to Fortran, Cobol,...
never had a problem with Lisp syntax
Far more bothering to me were immutability and laziness, it took me three
months to get used to it,
not in a home project but laying out production code.
Clojure is a
48 matches
Mail list logo
