Re: Alternate set literal syntax?
'(Devin Walters)
On Tuesday, March 27, 2012 at 8:54 PM, Cedric Greevey wrote:
On Tue, Mar 27, 2012 at 3:05 PM, Herwig Hochleitner
hhochleit...@gmail.com (mailto:hhochleit...@gmail.com) wrote:
2012/3/26 Cedric Greevey cgree...@gmail.com (mailto:cgree...@gmail.com):
(comp {:k1 5 :k2 6}), that is not used in production whereas (comp
{:k1 5 :k2 6}) (note spacing) is used in production but isn't broken.
(comp {:k1 5 :k2 6}) _is_ used in Production,
Without a space right after the ? Where? What is your evidence?
Without even showing a page of code using said new syntax, let alone
make an effort to enumerate cases where it would break.
I did in fact make such an effort, which should also have been clear
from an earlier post.
Not in your initial post and none of the latter ones, as far as I saw
while skimming.
If you're not very good at skimming without missing important points,
just set aside some time at some point and read it thoroughly.
Furthermore you don't seem to recognize the gravity of those issues
The only issue arguably possessing substantial gravity is the
oddly-spaced (comp {:k1 5 :k2 6}) and similar.
That statement is arguably wrong.
And I am arguably a butterfly dreaming I'm a man. But it's a
hypothesis of no real practical import.
- Hacking a second pass into the compiler (the single pass compiler is
a feature)
Avoided by {...} (or [...]).
- Breaking existing conventions
I disagree that adding a syntax (without removing #{}) is breaking a
convention. On the other hand, allowing sets to be specified with a
symmetric delimiter pair arguably is UNbreaking a convention.
- Dual end tokens (the reason i chose lisp is, that I don't want to
bother with foo.bar(); note the _);_ ). Yes, this makes a difference
when you edit your program.
But you don't mind dual start tokens, or you'd object to #{. Seems
you're being fairly arbitrary there.
Lisp is about prefix notation.
I don't see what bearing this has. Moreover, Lisp is many things to
many people. Others would say Lisp is about lambdas; still others,
that Lisp is about macros; and of course many would say Lisp is about
list processing.
- Adding duplicate reader syntax (the only other place we've done that
is #^, which is deprecated and where nobody liked the original syntax,
esp. in combo with type hinting) (the other examples you gave, e.g.
deref vs @ were the reader macro vs the form into which it gets
translated)
Duplicate syntax is duplicate syntax. Your reader vs. other
distinction is an artificial one.
- Introducing a new reader table (i.e. a prefix character that
switches the reader mode) for '{', '', or whichever you choose. right
now the '#' is the only reader table and it is an important visual
indicator for here, the reader inserts a datatype determined by the
next character [or few characters, since we have tagged literals])
And this is just plain wrong. There must be a reader table for the
default case as well as a secondary one activated for the next token
by #. Also, there's nothing inherently icky about adding one more.
Furthermore, the notion that # indicates here, the reader inserts a
datatype determined by what's next is ... a simplification, at best.
#^, though deprecated, still exists and attaches metadata rather than
deciding a datatype. #_ comments out the following form rather than
deciding a datatype (and can't really be interpreted as making what
follows some sort of do nothing datatype; (two-arg-fn 1 #_2 3) won't
throw bad arity). #' suppresses lookup of a var's contents, so the
form is the var itself instead of whatever's inside it. In fact, #{,
#, and arguably #( are the ones that do specify a datatype, and do
not outnumber the others.
I offer(ed) my ideas for free.
Yes you can _offer_ them for free. Which doesn't mean we can
_implement_ them for free.
Nobody claimed otherwise. You, on the other hand, erroneously implied
that I was charging or costing you money.
Also, getting your idea implemented is
valued very highly in this community, even if you get no money.
How is that relevant to the question of price? In fact by your own
admission (even if you get no money) it's orthogonal to the question
of price, and therefore *not* relevant.
Are you implying that you think I don't have a coherent view?
I only implied that you didn't _demonstrate_ it (please read)
Now you're implying that I lack reading comprehension skills. Please
stop being gratuitously insulting and rude. And please stop implying
things about me that are untrue.
Because such an implication would be both factually false and an insulting
public mischaracterization of me, perpetrated without provocation.
But the fact that you didn't even consider implementation complexity,
And
Re: Alternate set literal syntax?
Let's take a step back and look at this idea from a new user's view.
The way I see it, whatever we do, we'll have to explain to users how
to create sets. Hashmaps, and vectors follow (roughly) the JSON/Python
syntax:
vector = [1 2 3 4]
map = {1 2 3 4}
So how to these languages represent sets?
Python does it via extra syntax sugar:
set = {foo, bar}
map = {foo: bar, foo2 : bar2}
I think the thing we have to keep in mind is that I can't think of a
single other language that has set literals. So whatever we come up
with will be a bit bizzare to new users. So let's look at the options
given above:
{{foo}} ;; looks like a hash of a hash
{foo} ;; could work, but no other form in all of clojure has two
forms at the end.
#{foo} ;; not exactly pretty
My thoughts are this...who actually uses the literal hash set? In the
thousands of lines of Clojure code I've written a hash set once. So my
first reaction is why have a literal at all? Why not use:
On top of that, lets say we do want a literal syntax...if we have to
teach some bizarre syntax that people will rarely use...what's the big
difference between #{} and {} ?
If we want to actually go back to the original lisps, they didn't have
any special syntax at all, besides the quote literal. This isn't
ruby/python/C#. If something can be implemented without syntactic
sugar, most times it should be. So my question for Cedric is...why all
the fuss about set? Why not just use (set [foo, bar]) it's clean,
and makes plenty of sense to newbies.
Timothy
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Wednesday, March 28, 2012 at 12:58 PM, Timothy Baldridge wrote:
Let's take a step back and look at this idea from a new user's view.
The way I see it, whatever we do, we'll have to explain to users how
to create sets. Hashmaps, and vectors follow (roughly) the JSON/Python
syntax:
vector = [1 2 3 4]
map = {1 2 3 4}
So how to these languages represent sets?
Python does it via extra syntax sugar:
set = {foo, bar}
map = {foo: bar, foo2 : bar2}
I think the thing we have to keep in mind is that I can't think of a
single other language that has set literals.
Good point, but I disagree with the suggestion that because other languages
don't have a set literal we shouldn't have one either. I like having the
literal, FWIW. It makes sets feel like a more natural datastructure to use
throughout the language. I've seen people write all sorts of crazy methods and
functions to do what sets give you for free in other languages before they
realized oh right, this should probably be a set. Keeping sets front and
center with a literal promotes their use in general. I think that's a Good
Thing™. In other languages I sometimes feel like they're an afterthought, and
using them feels like they're somehow foreign. As in I often find myself
thinking: Where's my set literal? Why am I not writing this in Clojure? ;)
So whatever we come up
with will be a bit bizzare to new users. So let's look at the options
given above:
{{foo}} ;; looks like a hash of a hash
{foo} ;; could work, but no other form in all of clojure has two
forms at the end.
#{foo} ;; not exactly pretty
My thoughts are this...who actually uses the literal hash set? In the
thousands of lines of Clojure code I've written a hash set once. So my
first reaction is why have a literal at all? Why not use:
That's surprising to me. You never use something like this?
(map #{:fred :bob :ted} [:fred :bob])
Would you use:
(into (hash-set) [1 2 2 3])
(reduce conj (hash-set) [1 2 2 3])
Instead of:
(into #{} [1 2 2 3])
(reduce conj #{} [1 2 2 3])
To my eye, the empty set is a fairly common occurrence and that seems to be how
#{} gets used the most. The set literal also seem fairly abundant in test code.
Contrived example: (= (map inc #{1 2 3}) '(2 3 4)) This finding is based on a
rushed `ack -aui #{` of popular projects I'd consider to be idiomatic
clojure. So take my research with a grain of salt.
(sorted-set), (sorted-map), and (array-map) make more sense to me to call
without args (sorted-set) or with args (sorted-set 1 2 2 3) over introducing a
literal.
We have: '(), [], {}, #{}
No one seems to be dumbfounded by '(). I suppose one could imagine something
nasty like $1 2 3$ being proposed for a single character set wrapper, but
blech. No thank you. I rather like #{} and wouldn't be shy about introducing it
to a beginner.
On top of that, lets say we do want a literal syntax...if we have to
teach some bizarre syntax that people will rarely use...what's the big
difference between #{} and {} ?
If we want to actually go back to the original lisps, they didn't have
any special syntax at all, besides the quote literal. This isn't
ruby/python/C#. If something can be implemented without syntactic
sugar, most times it should be. So my question for Cedric is...why all
the fuss about set? Why not just use (set [foo, bar]) it's clean,
and makes plenty of sense to newbies.
Timothy
--
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
(mailto:clojure@googlegroups.com)
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
(mailto:clojure+unsubscr...@googlegroups.com)
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
That's surprising to me. You never use something like this?
(map #{:fred :bob :ted} [:fred :bob])
I think it's more that most of what I work with is either seq like,
vectors, or has some sort of key-value relationship. Most of the time
if I need a set of unique keys, I also need sets of data attached to
those keys.
To my eye, the empty set is a fairly common occurrence and that seems to be
how #{} gets used the most.
Agreed.
Timothy
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Wed, Mar 28, 2012 at 3:56 PM, Devin Walters dev...@gmail.com wrote:
We have: '(), [], {}, #{}
Not quite. '() isn't strictly analogous to #{}, because quote
suppresses evaluation of what's inside.
user= (def foo 42)
#'user/foo
user= (for [x ['(foo) [foo] {:a foo} #{foo}]]
(println x))
(foo)
[42]
{:a 42}
#{42}
(nil nil nil nil)
user=
There's no list literal. It's like array-map or sorted-set:
(array-map this)
(sorted-set that)
(list these things)
No one seems to be dumbfounded by '(). I suppose one could imagine something
nasty like $1 2 3$ being proposed for a single character set wrapper, but
blech. No thank you.
Indeed. Using the same symbol as both start and end delimiter fails
when there's nesting. It's fine for string literals; not so much for a
type of data structure that might contain the same type as an element.
On top of that, lets say we do want a literal syntax...if we have to
teach some bizarre syntax that people will rarely use...what's the big
difference between #{} and {} ?
Symmetry.
I'm not really sour on #{} or dead-set on having something else,
though. It was just a mostly idle idea I had. But it produced such a
strong attack in response to it, for whatever reason, that now I'm
stuck having to defend it as not-unreasonable because otherwise people
will acquire a negative opinion of me.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
not-unreasonable because otherwise people will acquire a negative opinion of me. On the contrary...I find that people who admit that their cool idea after further thought probably isn't so cool garner better respect from the community at large. Just my $0.02... Timothy -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Wed, Mar 28, 2012 at 7:36 PM, Timothy Baldridge tbaldri...@gmail.com wrote:
not-unreasonable because otherwise people
will acquire a negative opinion of me.
On the contrary...I find that people who admit that their cool idea
after further thought probably isn't so cool garner better respect
from the community at large.
But I never claimed it was a cool idea in the first place. I said,
and I quote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept ... it looks nicer, IMO ...
There's two statements of opinion -- X is somewhat ugly and Y looks
nicer than X -- and one statement of fact, that Y could be implemented
without it being a breaking change. The former two are somewhat
subjective and the latter was proved true.
So, I've been attacked for purportedly holding a much stronger
position on the matter than I really do.
In any event, the die is cast now. Either I successfully defend my
having made that original post as not having been a wrong/unreasonable
thing to do, or else people regard me as having done a
wrong/unreasonable thing. There's no alternative, by the law of the
excluded middle.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Wed, Mar 28, 2012 at 12:56 PM, Devin Walters dev...@gmail.com wrote:
The set literal also seem fairly abundant in test code.
Yup, I have a bunch of tests where success is to get back any of a
known set of values.
We have: '(), [], {}, #{}
Well... (), [], {}, #{} - the ' isn't needed on the empty list, right?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
2012/3/26 Cedric Greevey cgree...@gmail.com:
(comp {:k1 5 :k2 6}), that is not used in production whereas (comp
{:k1 5 :k2 6}) (note spacing) is used in production but isn't broken.
(comp {:k1 5 :k2 6}) _is_ used in Production, because it works and
somebody left it in.
Without even showing a page of code using said new syntax, let alone
make an effort to enumerate cases where it would break.
I did in fact make such an effort, which should also have been clear
from an earlier post.
Not in your initial post and none of the latter ones, as far as I saw
while skimming. And it should have been in the initial post (by my
definition of should)
Furthermore you don't seem to recognize the gravity of those issues
The only issue arguably possessing substantial gravity is the
oddly-spaced (comp {:k1 5 :k2 6}) and similar.
That statement is arguably wrong. Instead of arguing it, I'll present
my personal (descending) issue gravity list:
(Note that not all of those stem from your initial proposal, but there
are some from the various solutions you additionally proposed)
- Hacking a second pass into the compiler (the single pass compiler is
a feature)
- Breaking existing conventions
- Dual end tokens (the reason i chose lisp is, that I don't want to
bother with foo.bar(); note the _);_ ). Yes, this makes a difference
when you edit your program. Lisp is about prefix notation.
- Adding duplicate reader syntax (the only other place we've done that
is #^, which is deprecated and where nobody liked the original syntax,
esp. in combo with type hinting) (the other examples you gave, e.g.
deref vs @ were the reader macro vs the form into which it gets
translated)
- Introducing a new reader table (i.e. a prefix character that
switches the reader mode) for '{', '', or whichever you choose. right
now the '#' is the only reader table and it is an important visual
indicator for here, the reader inserts a datatype determined by the
next character [or few characters, since we have tagged literals])
I offer(ed) my ideas for free.
Yes you can _offer_ them for free. Which doesn't mean we can
_implement_ them for free. Also, getting your idea implemented is
valued very highly in this community, even if you get no money.
Are you implying that you think I don't have a coherent view?
I only implied that you didn't _demonstrate_ it (please read)
Because such an implication would be both factually false and an insulting
public mischaracterization of me, perpetrated without provocation.
But the fact that you didn't even consider implementation complexity,
language elegance, implications on existing code (in your initial
example anyway), ... while the biggest merits are some 0.7% of some
users, and an unverify_able_ claim of code beauty ... tells me your
grasp on the topic is not as complete as you might think. This is not
an insult, but a challange to prove otherwise, your two valid
responses are proving and denying the need to prove.
Since there are none, that would seem to be moot. On soliciting
feedback in general, what do you think this thread was for?
Looking at the initial post, it seems like it was for putting a
not-that-well thought out idea out there, and see if it sticks. Every
PL community has those a lot.
Unfortunately, the feedback I've gotten thus far seems to consist more
of knee-jerk hostility than of reasoned debate on the technical
matters.
You didn't credibly address the technical reasons that were given to
you (IMO, anyway)
At which point we can repeat the questions (reason), just tell you why
it's a bad idea anyway (emotion), or just ignore you (will do,
promise)
On the contrary, all decisions should be made from a weighing of costs
versus benefits rather than, as you seem to be suggesting, considering
just the costs alone.
Didn't intent to suggest that, otherwise: Exactly my view.
It's remarkable how emotional some people get in response not only to
merely words, but even to merely dry, technical words devoid of any
personal attacks, threats, unflattering public disclosures, or
implications of same.
Let me take the opportunity to apologize to you for where you feel I
overstepped my boundaries.
Too late. You already, by implication, called me incoherent,
half-blind, and other things.
Well, the name I was shooting for, doesn't actually fit, since you
seem to be interested in ongoing discussion involving you.
Meanwhile, I have refrained for the most part from like behavior, and
I have, contrary to one of your implications, made a good-faith effort
to address each objection that has been raised.
You seem to have done that, truth be told.
I get the distinct
impression that several here *first* concluded that my idea was
terrible, and only *then* tried to form an argument proving it so,
rather than examining the idea with an open mind first and then
drawing a logical conclusion based on reason and evidence.
A page of example code could remedy that, mostly.
However,
Re: Alternate set literal syntax?
On Tue, Mar 27, 2012 at 3:05 PM, Herwig Hochleitner
hhochleit...@gmail.com wrote:
2012/3/26 Cedric Greevey cgree...@gmail.com:
(comp {:k1 5 :k2 6}), that is not used in production whereas (comp
{:k1 5 :k2 6}) (note spacing) is used in production but isn't broken.
(comp {:k1 5 :k2 6}) _is_ used in Production,
Without a space right after the ? Where? What is your evidence?
Without even showing a page of code using said new syntax, let alone
make an effort to enumerate cases where it would break.
I did in fact make such an effort, which should also have been clear
from an earlier post.
Not in your initial post and none of the latter ones, as far as I saw
while skimming.
If you're not very good at skimming without missing important points,
just set aside some time at some point and read it thoroughly.
Furthermore you don't seem to recognize the gravity of those issues
The only issue arguably possessing substantial gravity is the
oddly-spaced (comp {:k1 5 :k2 6}) and similar.
That statement is arguably wrong.
And I am arguably a butterfly dreaming I'm a man. But it's a
hypothesis of no real practical import.
- Hacking a second pass into the compiler (the single pass compiler is
a feature)
Avoided by {...} (or [...]).
- Breaking existing conventions
I disagree that adding a syntax (without removing #{}) is breaking a
convention. On the other hand, allowing sets to be specified with a
symmetric delimiter pair arguably is UNbreaking a convention.
- Dual end tokens (the reason i chose lisp is, that I don't want to
bother with foo.bar(); note the _);_ ). Yes, this makes a difference
when you edit your program.
But you don't mind dual start tokens, or you'd object to #{. Seems
you're being fairly arbitrary there.
Lisp is about prefix notation.
I don't see what bearing this has. Moreover, Lisp is many things to
many people. Others would say Lisp is about lambdas; still others,
that Lisp is about macros; and of course many would say Lisp is about
list processing.
- Adding duplicate reader syntax (the only other place we've done that
is #^, which is deprecated and where nobody liked the original syntax,
esp. in combo with type hinting) (the other examples you gave, e.g.
deref vs @ were the reader macro vs the form into which it gets
translated)
Duplicate syntax is duplicate syntax. Your reader vs. other
distinction is an artificial one.
- Introducing a new reader table (i.e. a prefix character that
switches the reader mode) for '{', '', or whichever you choose. right
now the '#' is the only reader table and it is an important visual
indicator for here, the reader inserts a datatype determined by the
next character [or few characters, since we have tagged literals])
And this is just plain wrong. There must be a reader table for the
default case as well as a secondary one activated for the next token
by #. Also, there's nothing inherently icky about adding one more.
Furthermore, the notion that # indicates here, the reader inserts a
datatype determined by what's next is ... a simplification, at best.
#^, though deprecated, still exists and attaches metadata rather than
deciding a datatype. #_ comments out the following form rather than
deciding a datatype (and can't really be interpreted as making what
follows some sort of do nothing datatype; (two-arg-fn 1 #_2 3) won't
throw bad arity). #' suppresses lookup of a var's contents, so the
form is the var itself instead of whatever's inside it. In fact, #{,
#, and arguably #( are the ones that do specify a datatype, and do
not outnumber the others.
I offer(ed) my ideas for free.
Yes you can _offer_ them for free. Which doesn't mean we can
_implement_ them for free.
Nobody claimed otherwise. You, on the other hand, erroneously implied
that I was charging or costing you money.
Also, getting your idea implemented is
valued very highly in this community, even if you get no money.
How is that relevant to the question of price? In fact by your own
admission (even if you get no money) it's orthogonal to the question
of price, and therefore *not* relevant.
Are you implying that you think I don't have a coherent view?
I only implied that you didn't _demonstrate_ it (please read)
Now you're implying that I lack reading comprehension skills. Please
stop being gratuitously insulting and rude. And please stop implying
things about me that are untrue.
Because such an implication would be both factually false and an insulting
public mischaracterization of me, perpetrated without provocation.
But the fact that you didn't even consider implementation complexity,
And what, pray tell, is your evidence for this latest unflattering
claim about me?
Oh, that's right, you don't have any, because it's simply not true.
Indeed, my posts to this thread contain sketches of implementations of
both proposals, and neither description is especially complex.
language elegance,
You call #{...} elegant?
implications on existing
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 12:45 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On Mon, Mar 26, 2012 at 12:22 PM, Cedric Greevey cgree...@gmail.com wrote: Isn't this just another way of saying humans will have to read to the end to see what the form is? I provided a response to that objection already. Your response missed the point. I don't agree, and furthermore I consider responding to someone's reasoned debate with an accusation that they in any way failed to comprehend something to be insulting and rude. The onus is on you to communicate clearly. If you say X when you really meant Y, and then someone provides a reasonable counterargument to X, in particular, you missed the point is not a nice way to respond. If your actual point was Y, you should have said so in the first place. Attempting to place the blame on the other party for your own confusion, misstatement, or what-have-you is simply not very sporting. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 2:35 PM, Cedric Greevey cgree...@gmail.com wrote:
I don't agree, and furthermore I consider responding to someone's
reasoned debate with an accusation that they in any way failed to
comprehend something to be insulting and rude. The onus is on you to
communicate clearly. If you say X when you really meant Y, and then
someone provides a reasonable counterargument to X, in particular,
you missed the point is not a nice way to respond. If your actual
point was Y, you should have said so in the first place. Attempting to
place the blame on the other party for your own confusion,
misstatement, or what-have-you is simply not very sporting.
I apologise, there's no excuse for my response.
I will continue the debate with more class.
On Mon, Mar 26, 2012 at 12:45 AM, Ambrose Bonnaire-Sergeant
It breaks the uniformity of Clojure syntax.
On Mon, Mar 26, 2012 at 12:22 PM, Cedric Greevey cgree...@gmail.com
wrote:
Isn't this just another way of saying humans will have to read to the
end to see what the form is?
No, this is a way of saying the {{}} proposal is very unlikely to succeed
for reasons that include violating established, well thought out,
conventions. I consider success as approval by any Clojure/core members.
I provided a response to that objection already.
You addressed the merits of using syntax that complects human recognition
with reading entire forms, but did not address the merits of breaking an
important syntax convention.
To be fair, the question you were answering was addressing the former.
Of course, this suggests an alternative, too:
{set items go here}
- {} is a breaking change. Consider (comp {:a :b}).
- Both left and right sides now use 2 tokens, afaik no other syntax
needs this.
- Even {} and {} have similar problems to {}.
- White space issues, as outlined in your proposal
- Consider (:refer-clojure :exclude [ ]) and redefining them in the
module. The assumptions for avoiding the corner cases no longer hold.
- The implementation probably wouldn't be too much fun either, not that
I tried.
IMO this syntax would be an even bigger disaster than {{}}.
On Sun, Mar 25, 2012 at 5:24 PM, Evan Mezeske emeze...@gmail.com wrote:
Anyway, no matter how beautiful a new set notation might be (not that I
personally think {{}} is beautiful), it seems that having two notations
for
one concept would be more confusing than having one notation for one
concept. You *know* that this question would appear on a regular basis,
What is the difference between #{} and {{}}?
Exactly. There is *no* difference. At all.
On Mon, Mar 26, 2012 at 8:44 AM, Cedric Greevey cgree...@gmail.com wrote:
On Sun, Mar 25, 2012 at 8:36 PM, Cedric Greevey cgree...@gmail.com
wrote:
How often do we get What are the differences among 100, 0144, and
0x64, and which should I use when? ;)
Nevermind:
#^{:foo 42} thingy vs. ^{:foo 42} thingy;
(deref foo) vs. @foo;
#'bar vs. (var bar);
#(+ %2 (* 2 %1)) vs. (fn [a b] (+ b (* 2 a)));
'quux vs. (quote quux);
:user/baz vs. ::baz (in ns user);
(cons mumble some-seq) vs. (conj some-seq mumble);
and probably others. :)
cons vs. conj IMO is completely irrelevant to this discussion.
The only redundant syntax in that list #^{} vs. ^{}. A wart in the
language, but a clear improvement nonetheless. Thankfully Clojure is very
conservative with breaking changes.
All others serve a purpose, no matter how minor.
How is this proposal (on *any* alternative set syntax) different to
proposing :::user to be synonymous to ::user, wrt redundant syntax?
Alex hit the nail on the head with the 3rd post of this thread.
Thanks,
Ambrose
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
The only redundant syntax in that list #^{} vs. ^{}. A wart in the
language, but a clear improvement nonetheless. Thankfully Clojure is very
conservative with breaking changes.
All others serve a purpose, no matter how minor.
How is this proposal (on *any* alternative set syntax) different to
proposing :::user to be synonymous to ::user, wrt redundant syntax?
Alex hit the nail on the head with the 3rd post of this thread.
+100 and I think (and others may agree) that should conclude this thread
Thanks,
Ambrose
--
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 with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
László Török
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 5:29 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
I will continue the debate with more class.
Thank you.
Isn't this just another way of saying humans will have to read to the
end to see what the form is?
No, this is a way of saying the {{}} proposal is very unlikely to succeed
for reasons that include violating established, well thought out,
conventions.
Conventions whose goal is said readability.
I provided a response to that objection already.
You addressed the merits of using syntax that complects human recognition
with reading entire forms, but did not address the merits of breaking an
important syntax convention.
Since your own earlier post indicated that the convention exists to
make it easier for humans to recognize what forms they're dealing
with, addressing that directly obviates any issue with the convention.
Unless you're now claiming the convention has additional goals beyond
that one.
Of course, this suggests an alternative, too:
{set items go here}
{} is a breaking change.
No, it's not. Not really.
Consider (comp {:a :b}).
Anyone in their right mind would write that as (comp {:a :b} ). Or
rather, they wouldn't, since returns true or false, {:a :b} turns
that into nil, and then throws an exception. But they might write
(comp {false 0 true 1} ). :)
Both left and right sides now use 2 tokens, afaik no other syntax needs
this.
So?
White space issues, as outlined in your proposal
Not if white space is used per existing convention.
Consider (:refer-clojure :exclude [ ]) and redefining them in the module.
Should be rare, and again, spaces would be normal between and { and
between } and right now.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
So to summarize:
You suggest to
a) Break expressions like (comp {:k1 5 :k2 6}) or {{:foo 5} 4} which
are legal and therefore used in production; when challenged you
propose additional workarounds that take a whole page to even
informally describe
b) Introduce the completely new notational convention of requiring
multiple closing tokens for one form; a set
Without even showing a page of code using said new syntax, let alone
make an effort to enumerate cases where it would break.
Furthermore you don't seem to recognize the gravity of those issues
and just keep focusing on hypothetical benefits, like a salesman.
We won't buy ideas before you can make us accept them. You can only
make us even consider accepting your ideas by demonstrating a coherent
view of the involved issues.
You can also do that by soliciting feedback to points you haven't
fully thought out. Just ignoring or trying to outweigh them with
promised benefits certainly won't help.
/rant
Also this isn't bikeshedding, since syntax stability and orthogonality
of the language core aren't the proverbial bike shed but the very
power plant in lisp (and every usable language [by my definition of
usable])
So without calling any names, let me conclude with
*plonk*
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Agree with Herwig 100%. This conversation has been interesting to me only
insofar as I've discovered *more* problems with the initial proposal than I
think I would have found by myself.
'(Devin Walters)
On Monday, March 26, 2012 at 1:12 PM, Herwig Hochleitner wrote:
So to summarize:
You suggest to
a) Break expressions like (comp {:k1 5 :k2 6}) or {{:foo 5} 4} which
are legal and therefore used in production; when challenged you
propose additional workarounds that take a whole page to even
informally describe
b) Introduce the completely new notational convention of requiring
multiple closing tokens for one form; a set
Without even showing a page of code using said new syntax, let alone
make an effort to enumerate cases where it would break.
Furthermore you don't seem to recognize the gravity of those issues
and just keep focusing on hypothetical benefits, like a salesman.
We won't buy ideas before you can make us accept them. You can only
make us even consider accepting your ideas by demonstrating a coherent
view of the involved issues.
You can also do that by soliciting feedback to points you haven't
fully thought out. Just ignoring or trying to outweigh them with
promised benefits certainly won't help.
/rant
Also this isn't bikeshedding, since syntax stability and orthogonality
of the language core aren't the proverbial bike shed but the very
power plant in lisp (and every usable language [by my definition of
usable])
So without calling any names, let me conclude with
*plonk*
--
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
(mailto:clojure@googlegroups.com)
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
(mailto:clojure+unsubscr...@googlegroups.com)
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 2:12 PM, Herwig Hochleitner
hhochleit...@gmail.com wrote:
So to summarize:
You suggest to
a) Break expressions like (comp {:k1 5 :k2 6}) or {{:foo 5} 4} which
are legal and therefore used in production;
No. The first suggestion does not break {{:foo 5} 4}, which should
have been clear from an earlier post, and while the second breaks
(comp {:k1 5 :k2 6}), that is not used in production whereas (comp
{:k1 5 :k2 6}) (note spacing) is used in production but isn't broken.
Without even showing a page of code using said new syntax, let alone
make an effort to enumerate cases where it would break.
I did in fact make such an effort, which should also have been clear
from an earlier post.
Furthermore you don't seem to recognize the gravity of those issues
The only issue arguably possessing substantial gravity is the
oddly-spaced (comp {:k1 5 :k2 6}) and similar.
We won't buy ideas before you can make us accept them.
I offer(ed) my ideas for free.
You can only make us even consider accepting your ideas by demonstrating a
coherent
view of the involved issues.
Are you implying that you think I don't have a coherent view? Because
such an implication would be both factually false and an insulting
public mischaracterization of me, perpetrated without provocation.
You can also do that by soliciting feedback to points you haven't
fully thought out.
Since there are none, that would seem to be moot. On soliciting
feedback in general, what do you think this thread was for?
Unfortunately, the feedback I've gotten thus far seems to consist more
of knee-jerk hostility than of reasoned debate on the technical
matters.
Just ignoring or trying to outweigh them with
promised benefits certainly won't help.
On the contrary, all decisions should be made from a weighing of costs
versus benefits rather than, as you seem to be suggesting, considering
just the costs alone.
/rant
It's remarkable how emotional some people get in response not only to
merely words, but even to merely dry, technical words devoid of any
personal attacks, threats, unflattering public disclosures, or
implications of same.
So without calling any names,
Too late. You already, by implication, called me incoherent,
half-blind, and other things.
Meanwhile, I have refrained for the most part from like behavior, and
I have, contrary to one of your implications, made a good-faith effort
to address each objection that has been raised. I get the distinct
impression that several here *first* concluded that my idea was
terrible, and only *then* tried to form an argument proving it so,
rather than examining the idea with an open mind first and then
drawing a logical conclusion based on reason and evidence. However, an
inquiry in search of truth must needs start with the bare facts and
suggestions and ideas and follow, unbiasedly, wherever these may lead;
an inquiry that starts with coming to a conclusion and only afterwards
attempts to apply the tools of reason is not a search for truth but
rather a search for a rationalization for a decision already made,
and, in many such cases, made blindly.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 3:22 PM, Devin Walters dev...@gmail.com wrote: Agree with Herwig 100%. That's rather odd, seeing as how Herwig didn't even participate in any reasoned debate in this thread; instead, he just threw a drive-by flame at me out of the blue and without provocation. This conversation has been interesting to me only insofar as If it's not very interesting to you, nobody is forcing you to read it. This, by the way, being the second time in recent days that someone here has intimated incorrectly that I'm not interested in topic X implies I have the right to demand, at least by implication, that the people talking about topic X shut up, even if topic X is not off topic for the list. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
To all, please: - either the topic doesn't interest you, and then let the thread die by not answering to it. - either you want to participate, and then answer questions, ask new ones, period. Piece to all, Laurent Le 26 mars 2012 à 21:34, Cedric Greevey cgree...@gmail.com a écrit : On Mon, Mar 26, 2012 at 3:22 PM, Devin Walters dev...@gmail.com wrote: Agree with Herwig 100%. That's rather odd, seeing as how Herwig didn't even participate in any reasoned debate in this thread; instead, he just threw a drive-by flame at me out of the blue and without provocation. This conversation has been interesting to me only insofar as If it's not very interesting to you, nobody is forcing you to read it. This, by the way, being the second time in recent days that someone here has intimated incorrectly that I'm not interested in topic X implies I have the right to demand, at least by implication, that the people talking about topic X shut up, even if topic X is not off topic for the list. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
I follow this list mostly to avoid losing track of things as time passes and keep a record of significant things. I do not read every post, I filter at glance accoring to the subject and rarely by the initial poster. A jump in the number or replies in a thread also triggers my attention. I rarely intervene except when it can help someone with appropriate info and timing. It's not the first time that syntax preferences are brought forward. Every time the pattern is the same ... should with little or no supporting facts and most of the time no attempt by the poster to implement his idea. A personal taste is not a fact nor a need (a need would compromise your survival), it's a desire. Desires can or cannot be satisfied, it has no impact on your survival or on the syntax of an established language. Desires cannot by themselves change reality, work will. This thread is now more than a dozen replies long and at the end your desire will not get satisfied anyway. So why generating this kind of noise on tne list ? It's there to help prople solve problems (facts) not complaining about the color of the ceiling. Luc P. On Sat, Mar 24, 2012 at 3:46 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Hey, we all have our rough edges :) I'm 50, there's less life in front of me than behind. Debating about the sex of angels looks to me a bad way of using the not so many hours left in our lives on significant problems before the final exit. If this particular thread's topic does not interest you, and you feel reading, and debating in, it would waste your time, perhaps you should just ignore it. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this grou http://groups.google.com/group/clojure?hl=en -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail! -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On the contrary, discussing ideas relevant to Clojure is quite on topic here. Once again: if *you* find this thread useless or uninteresting, *you* can safely ignore it, but telling everyone else what to discuss and what not to discuss (when they're not straying from the list's official topic too much) seems out-of-bounds to me. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sat, Mar 24, 2012 at 04:44, Cedric Greevey cgree...@gmail.com wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
without breaking anything. It's not possible for it to be a valid map
literal, because the outer {...} pair has only one object inside it
and a map literal requires an even number of objects (zero, two, four
...), so right now {{foo bar baz}} will just throw a
CompilerException, and so will {{foo bar baz quux}} even though the
inner {...} pair then has an even number of objects. Making the reader
treat that as a set literal is therefore a purely additive change.
It's one character longer than #{foo bar baz} but it looks nicer, IMO,
and still shows the cousin-ship between sets and maps by using the
same choice among {}, [], ().
I'd encourage you to have a look at LispReader.java [1], paying
particular attention to how macros[] and dispatchMacros[] are used
internally. Basically, the reader dispatches to a specialized
sub-reader based on the first character of what it reads. This gives
the reader a nice modularity while also allowing the reader to convert
a characters to data in a single pass. This has real advantages, but
arbitrary syntax tricks like {{ foo bar }} don't fit well into this
world.
[1]
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java
I guess what I'm saying is that there is a deeper mechanism behind
what may seem to you like arbitrary syntactic noise. #{...} #(...)
etc. Your proposal is unlikely to garner much support if you're not
able to formulate an argument that appreciates the complexity
trade-offs it implies. (Say, a far more complex Reader.)
One of the nice things about Lisps is that their written
representation as data is uncomplicated to parse. Don't be too quick
to throw that away.
// Ben
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Doesn't this amount to arguing over what color the bike shed should be? [1]
Is there anything I could do with Clojure with an aesthetically different
(but functionally identical ) set notation that I cannot do with Clojure
right now?
Anyway, no matter how beautiful a new set notation might be (not that I
personally think {{}} is beautiful), it seems that having two notations for
one concept would be more confusing than having one notation for one
concept. You *know* that this question would appear on a regular basis,
What is the difference between #{} and {{}}?
[1] http://bikeshed.com/
On Friday, March 23, 2012 8:44:27 PM UTC-7, Cedric Greevey wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
without breaking anything. It's not possible for it to be a valid map
literal, because the outer {...} pair has only one object inside it
and a map literal requires an even number of objects (zero, two, four
...), so right now {{foo bar baz}} will just throw a
CompilerException, and so will {{foo bar baz quux}} even though the
inner {...} pair then has an even number of objects. Making the reader
treat that as a set literal is therefore a purely additive change.
It's one character longer than #{foo bar baz} but it looks nicer, IMO,
and still shows the cousin-ship between sets and maps by using the
same choice among {}, [], ().
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sun, Mar 25, 2012 at 5:24 PM, Evan Mezeske emeze...@gmail.com wrote:
Is there anything I could do with Clojure with an aesthetically different
(but functionally identical ) set notation that I cannot do with Clojure
right now?
Attract 0.7 more people per 1000 on average to adopt the language, perhaps. :)
Anyway, no matter how beautiful a new set notation might be (not that I
personally think {{}} is beautiful), it seems that having two notations for
one concept would be more confusing than having one notation for one
concept. You *know* that this question would appear on a regular basis,
What is the difference between #{} and {{}}?
How often do we get What are the differences among 100, 0144, and
0x64, and which should I use when? ;)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sun, Mar 25, 2012 at 8:36 PM, Cedric Greevey cgree...@gmail.com wrote:
How often do we get What are the differences among 100, 0144, and
0x64, and which should I use when? ;)
Nevermind:
#^{:foo 42} thingy vs. ^{:foo 42} thingy;
(deref foo) vs. @foo;
#'bar vs. (var bar);
#(+ %2 (* 2 %1)) vs. (fn [a b] (+ b (* 2 a)));
'quux vs. (quote quux);
:user/baz vs. ::baz (in ns user);
(cons mumble some-seq) vs. (conj some-seq mumble);
and probably others. :)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
I think one of the strengths of clojure (over at least CL certainly) is
it's a warm and helpful community. Please, let's not poison that.
I think this response was not only not helpful, it was also, in some small
way, damaging to the community. Please don't reply to legitimate questions
in this manor.
On Saturday, March 24, 2012 8:17:57 AM UTC-4, Luc wrote:
I would suggest that we introduced some klingon characters in the language,
we could then satisfy all these alien desires to change a syntax that has
been
established 4 years ago.
We have a product driving an hospital here, your esthetic considerations
do not
fit in my deployment plan. This is not a toy language anymore... That era
is behind
us since Jan. 2009.
With nearly 5 versions out since 2009, I think that we can say that the
language has
reached some maturity at least regarding the syntax.
Now we are in the framework selection phase to meet greater challenges and
improving internals and platform availability.
I suggest you clone the source code and create your custom reader version.
Then you will be free to apply any change you may feel appropriate.
vaj HabHa''a' je 'uSDu'lIj joj
Luc
On Sat, Mar 24, 2012 at 1:28 AM, Sean Corfield seancorfi...@gmail.com
wrote:
On Fri, Mar 23, 2012 at 8:44 PM, Cedric Greevey cgree...@gmail.com
wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
My concern is that {{1 2 3 4}5} is currently legal - a map with a map
as a key and 5 as the value. That means that the reader couldn't tell
if {{ introduced your set notation or the start of a nested map
without looking arbitrarily far ahead. And that problem gets worse if
you encounter {{{ or or... {{{ could introduce a nested map, a
map of your sets or one of your sets containing a map...
The other objections are fair enough -- matters of taste. But the
above is a technical problem with a simple fix: make one pass over the
source, converting it into a rudimentary AST whose nodes just look
like (thing thing thing), #(thing thing thing), [thing thing thing],
{thing thing thing}, and #{thing thing thing} (the file as a whole
be regarded as implicitly wrapped in (do ... )); then (assuming no
unbalanced delimiters) make a second pass doing the rest of the
reader's job. The second pass will see a {...} node with one direct
child that is also a {...} node in, and only in, the case of the
proposed set syntax. (It will also allow { {foo bar baz}} and
similarly as sets.)
As for the aesthetics, what I like about {{...}} is that the
delimiters are symmetrical, unlike #{...}, and it would allow one to
reserve use of the # mark to, mostly, closures, so # would stand out
more as typically indicating a lambda. (The #{...} syntax then remains
comparatively desirable in the specific case that the set literal is
being used as a predicate, as it's both a set and a lambda in that
context.)
--
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 with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
--
Softaddictslprefontaine@softaddicts.ca lprefonta...@softaddicts.ca
sent by ibisMail!
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Embarrassingly, it took this long for me to realize there's a much
tidier way to alter the reader:
Where the exception throw is for map literals with odd numbers of
key-or-value items, wrap the throw in a check that counts the number
of additional consecutive } tokens, stopping when it hits a non-}
token, the start of the corresponding form was the wrong delimiter
(not a {; throw a delimiter mismatch exception then), or the
corresponding from had more than one item.
Now, we have {{...{odd number of nested things}...}}, and know the
nesting depth of {}s. However, there's a special case: there's a
single nested thing and it's a map. In that case, we really had
{{...{{even number of things}}...}}. So we bump the nesting depth by 1
and replace the map with (interleave (keys map) (vals map)) as the
things-seq.
Finally, if the nesting depth is greater than 1, instead of throwing
the key-with-no-value exception we:
* If the nesting depth is odd, drop it by 1 and replace the things-seq
with [(apply hash-map things-seq)]. Throwing the key-with-no-value
exception anyway, if the things-seq was odd in length. Since
{{...{...}...}} with an odd number of enclosing {}s is a map nested in
single-element sets.
* Regardless, nest sets nesting-depth/2, each set containing the next
one except the last contains the items in things-seq.
The above requires only a localized change and not a massive redesign
or complication of the entire reader, such as adding a whole pass.
This addresses, satisfactorily IMO, the objection based on not wanting
to elevate the reader's complexity. The objection of multiple
representations being confusing is moot when so many other things in
Clojure also have multiple representations at a low level. That leaves
the objection that it may be harder for *people* to read, since they
have to reach the end of nested {{{s to figure out what the data
structure is.
I answer that by noting that it's possible to write poorly-readable
code in any language worth coding in, including the existing version
of Clojure. Someone who wants their {{...}} sets to be easily parsed
by humans is advised simply to a) not nest lots of single-element sets
(that ought to be damned rare anyway), b) not put spaces between the
braces in {{ and }}, and c) put spaces between {{ and adjacent {s and
between }} and adjacent }s. So, if you really had to nest a map in two
sets and wanted to not use #{...}, you'd want {{ {{ {k1 v1 k2 v2} }}
}}, so the delimiter units are easily separated. IDE support could
also help, parsing according to the stated rule and treating a
(balanced, with all internal delimiters also balanced) {{ ... }} pair
as two single delimiters that are {{ and }} rather than four that are
two {s and two }s for the purposes of highlight matching delimiter
functionality (the braces in {{ and }} would highlight together) and
rainbow parens (the paired {{ and }} would be a single color).
(Paredit would have to not change behavior, or if you typed {{
intending to add items and then }, more items, and }, it might not let
you break up the }} it made corresponding to the {{.) The pretty
printer would also benefit from putting spaces between paired braces
and adjacent braces that face the same way, keeping the grouping
clear.
So ... any further objections, other than it's unlikely anyone cares
enough to bother actually making such a change? :)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 11:46 AM, Cedric Greevey cgree...@gmail.com wrote:
So ... any further objections, other than it's unlikely anyone cares
enough to bother actually making such a change? :)
It breaks the uniformity of Clojure syntax.
Almost all sugar is prefix: you can identify syntax by looking to the left
of the form.
#{1}
(fn [a b c]) (variable arity, left of c)
#'var
'(1 2 3)
{:a 1}
I remember Rich Hickey explaining this in a discussion with Daniel Spiewak.
Ambrose
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sun, Mar 25, 2012 at 11:59 PM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
On Mon, Mar 26, 2012 at 11:46 AM, Cedric Greevey cgree...@gmail.com wrote:
So ... any further objections, other than it's unlikely anyone cares
enough to bother actually making such a change? :)
It breaks the uniformity of Clojure syntax.
Almost all sugar is prefix: you can identify syntax by looking to the left
of the form.
#{1}
(fn [a b c]) (variable arity, left of c)
#'var
'(1 2 3)
{:a 1}
I remember Rich Hickey explaining this in a discussion with Daniel Spiewak.
Isn't this just another way of saying humans will have to read to the
end to see what the form is? I provided a response to that objection
already.
Of course, this suggests an alternative, too:
{set items go here}
Maps aren't valid arguments to , so it should be rare that you'd have
a immediately followed by a {. And normally there'd be a space in
any remaining cases, e.g. (my-hof {:foo 1} other-stuff). We'd now
require that space, and treat a { without any space between as a
single delimiter matched by }. Note that this can immediately be
identified at the left, before reaching the far side. We would also
require a space in } if they are to be treated as separate tokens,
since otherwise (def eclectic-set {:keyword 42 'symbol {:k :v}}) is
tricky to parse. (The set's last two items would be a map and ;
requiring the space makes it a mismatched delimiter right after :v and
adding the space makes it easily parsed as a map and .)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Mon, Mar 26, 2012 at 12:22 PM, Cedric Greevey cgree...@gmail.com wrote:
On Sun, Mar 25, 2012 at 11:59 PM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
On Mon, Mar 26, 2012 at 11:46 AM, Cedric Greevey cgree...@gmail.com
wrote:
So ... any further objections, other than it's unlikely anyone cares
enough to bother actually making such a change? :)
It breaks the uniformity of Clojure syntax.
Almost all sugar is prefix: you can identify syntax by looking to the
left
of the form.
#{1}
(fn [a b c]) (variable arity, left of c)
#'var
'(1 2 3)
{:a 1}
I remember Rich Hickey explaining this in a discussion with Daniel
Spiewak.
Isn't this just another way of saying humans will have to read to the
end to see what the form is? I provided a response to that objection
already.
Your response missed the point.
is better, objectively, with respect to complecting recognizing syntax
and reading entire forms.
Thanks,
Ambrose
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sat, Mar 24, 2012 at 1:28 AM, Sean Corfield seancorfi...@gmail.com wrote:
On Fri, Mar 23, 2012 at 8:44 PM, Cedric Greevey cgree...@gmail.com wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
My concern is that {{1 2 3 4}5} is currently legal - a map with a map
as a key and 5 as the value. That means that the reader couldn't tell
if {{ introduced your set notation or the start of a nested map
without looking arbitrarily far ahead. And that problem gets worse if
you encounter {{{ or or... {{{ could introduce a nested map, a
map of your sets or one of your sets containing a map...
The other objections are fair enough -- matters of taste. But the
above is a technical problem with a simple fix: make one pass over the
source, converting it into a rudimentary AST whose nodes just look
like (thing thing thing), #(thing thing thing), [thing thing thing],
{thing thing thing}, and #{thing thing thing} (the file as a whole can
be regarded as implicitly wrapped in (do ... )); then (assuming no
unbalanced delimiters) make a second pass doing the rest of the
reader's job. The second pass will see a {...} node with one direct
child that is also a {...} node in, and only in, the case of the
proposed set syntax. (It will also allow { {foo bar baz}} and
similarly as sets.)
As for the aesthetics, what I like about {{...}} is that the
delimiters are symmetrical, unlike #{...}, and it would allow one to
reserve use of the # mark to, mostly, closures, so # would stand out
more as typically indicating a lambda. (The #{...} syntax then remains
comparatively desirable in the specific case that the set literal is
being used as a predicate, as it's both a set and a lambda in that
context.)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
I would suggest that we introduced some klingon characters in the language,
we could then satisfy all these alien desires to change a syntax that has been
established 4 years ago.
We have a product driving an hospital here, your esthetic considerations do
not
fit in my deployment plan. This is not a toy language anymore... That era is
behind
us since Jan. 2009.
With nearly 5 versions out since 2009, I think that we can say that the
language has
reached some maturity at least regarding the syntax.
Now we are in the framework selection phase to meet greater challenges and
improving internals and platform availability.
I suggest you clone the source code and create your custom reader version.
Then you will be free to apply any change you may feel appropriate.
vaj HabHa''a' je 'uSDu'lIj joj
Luc
On Sat, Mar 24, 2012 at 1:28 AM, Sean Corfield seancorfi...@gmail.com wrote:
On Fri, Mar 23, 2012 at 8:44 PM, Cedric Greevey cgree...@gmail.com wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
My concern is that {{1 2 3 4}5} is currently legal - a map with a map
as a key and 5 as the value. That means that the reader couldn't tell
if {{ introduced your set notation or the start of a nested map
without looking arbitrarily far ahead. And that problem gets worse if
you encounter {{{ or or... {{{ could introduce a nested map, a
map of your sets or one of your sets containing a map...
The other objections are fair enough -- matters of taste. But the
above is a technical problem with a simple fix: make one pass over the
source, converting it into a rudimentary AST whose nodes just look
like (thing thing thing), #(thing thing thing), [thing thing thing],
{thing thing thing}, and #{thing thing thing} (the file as a whole
be regarded as implicitly wrapped in (do ... )); then (assuming no
unbalanced delimiters) make a second pass doing the rest of the
reader's job. The second pass will see a {...} node with one direct
child that is also a {...} node in, and only in, the case of the
proposed set syntax. (It will also allow { {foo bar baz}} and
similarly as sets.)
As for the aesthetics, what I like about {{...}} is that the
delimiters are symmetrical, unlike #{...}, and it would allow one to
reserve use of the # mark to, mostly, closures, so # would stand out
more as typically indicating a lambda. (The #{...} syntax then remains
comparatively desirable in the specific case that the set literal is
being used as a predicate, as it's both a set and a lambda in that
context.)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail!
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Your point is clear and valid but isn't it a bit harsh to write the response in a tone like this? After all we are asking and answering questions here, it's not like something is going to change after one request. BTW it is nice to hear Clojure being reliable enough in people's eyes to be used in such a serious application. On Saturday, March 24, 2012 2:17:57 PM UTC+2, Luc wrote: I would suggest that we introduced some klingon characters in the language, we could then satisfy all these alien desires to change a syntax that has been established 4 years ago. We have a product driving an hospital here, your esthetic considerations do not fit in my deployment plan. This is not a toy language anymore... That era is behind us since Jan. 2009. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Hey, we all have our rough edges :) I'm 50, there's less life in front of me than behind. Debating about the sex of angels looks to me a bad way of using the not so many hours left in our lives on significant problems before the final exit. It's not the first time requests similar to this one pop out on this mailing list. The problem here is a timing issue, we left this phase of discussions a while ago (looks light years to me). Nobody is forced to use Clojure, if it this not appeals to your esthetic values, no problem, just use something else. You have what you think is a great idea, well, implement it, toy with it and then present your conclusions and hard facts here. This approach will yield at least two benefits: A) it will demonstrate that it's doable and will make limitations clear if any exists B) the effort required will make you realize if you get enough bang for your buck. There's so many existing projects to do out there to keep your entire life busy using Clojure, why spend time (even think time) re-inventing the wheel ? As for the Klingon stuff, I do not have bumps in my forehead or elsewhere :))) Luc Your point is clear and valid but isn't it a bit harsh to write the response in a tone like this? After all we are asking and answering questions here, it's not like something is going to change after one request. BTW it is nice to hear Clojure being reliable enough in people's eyes to be used in such a serious application. On Saturday, March 24, 2012 2:17:57 PM UTC+2, Luc wrote: I would suggest that we introduced some klingon characters in the language, we could then satisfy all these alien desires to change a syntax that has been established 4 years ago. We have a product driving an hospital here, your esthetic considerations do not fit in my deployment plan. This is not a toy language anymore... That era is behind us since Jan. 2009. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail! -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Forgot to add these: http://dev.clojure.org/display/community/Clojure+Success+Stories http://www.quora.com/Whos-using-Clojure-in-production Your point is clear and valid but isn't it a bit harsh to write the response in a tone like this? After all we are asking and answering questions here, it's not like something is going to change after one request. BTW it is nice to hear Clojure being reliable enough in people's eyes to be used in such a serious application. On Saturday, March 24, 2012 2:17:57 PM UTC+2, Luc wrote: I would suggest that we introduced some klingon characters in the language, we could then satisfy all these alien desires to change a syntax that has been established 4 years ago. We have a product driving an hospital here, your esthetic considerations do not fit in my deployment plan. This is not a toy language anymore... That era is behind us since Jan. 2009. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail! -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sat, Mar 24, 2012 at 1:44 AM, Cedric Greevey cgree...@gmail.com wrote:
On Sat, Mar 24, 2012 at 1:28 AM, Sean Corfield seancorfi...@gmail.com wrote:
On Fri, Mar 23, 2012 at 8:44 PM, Cedric Greevey cgree...@gmail.com wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
My concern is that {{1 2 3 4}5} is currently legal - a map with a map
as a key and 5 as the value. That means that the reader couldn't tell
if {{ introduced your set notation or the start of a nested map
without looking arbitrarily far ahead. And that problem gets worse if
you encounter {{{ or or... {{{ could introduce a nested map, a
map of your sets or one of your sets containing a map...
The other objections are fair enough -- matters of taste. But the
above is a technical problem with a simple fix: make one pass over the
source, converting it into a rudimentary AST whose nodes just look
I think the word reader above applies both to the human and computer
kinds. You've only addressed the problem for the computer. A user
would still have to look at the end of the collection to know if it is
a set or map (or use editor).
As for the aesthetics, what I like about {{...}} is that the
delimiters are symmetrical, unlike #{...}, and it would allow one to
reserve use of the # mark to, mostly, closures, so # would stand out
more as typically indicating a lambda.
Sorry to break it to you, but # is used in many places other than
lambdas, so even if you remove it from #{} you still have foo#, #^foo,
#^{foo bar}, #'foo, #foo, #_foo, #foo{1 2}, #foo[1 2], and others
I've probably forgotten.
One option you have is to use Emacs to replace #{} and #() with
something distinctive looking.
(dolist (mode '(clojure-mode slime-repl-mode))
(eval-after-load mode `(font-lock-add-keywords
',mode
(mapcar
(lambda (pair)
`(,(car pair)
(0 (progn (compose-region (match-beginning 1)
(match-end 1)
,(cadr pair))
nil
`((\\(#\\){ ∈)
(\\(#\\)(ƒ)
((\\(fn\\)[\[[:space:]] λ)
((\\(comp\\)[\[[:space:]] ∘)
((\\(range\\)[\[[:space:]] ℝ)
((\\(apply \+\\)[\[[:space:]] ∑)
((\\(Math/pi\\)[\[[:space:]] π)
((\\(-\\)[\[[:space:]] →)
((\\(partial\\)[\[[:space:]] þ)
((\\(complement\\)[\[[:space:]] ¬)
;; not working
;; (Math/pi[:space:] π)
;; ((\\(apply \+\\)[\[[:space:]] ∑)
)
Cheers,
Scott
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sat, Mar 24, 2012 at 6:38 PM, Scott Jaderholm jaderh...@gmail.com wrote:
On Sat, Mar 24, 2012 at 1:44 AM, Cedric Greevey cgree...@gmail.com wrote:
As for the aesthetics, what I like about {{...}} is that the
delimiters are symmetrical, unlike #{...}, and it would allow one to
reserve use of the # mark to, mostly, closures, so # would stand out
more as typically indicating a lambda.
Sorry to break it to you, but # is used in many places other than
lambdas, so even if you remove it from #{} you still have foo#, #^foo,
#^{foo bar}, #'foo, #foo, #_foo, #foo{1 2}, #foo[1 2], and others
I've probably forgotten.
Along those lines, the # character is the dispatch macro [which]
causes the reader to use a reader macro from another table, indexed by
the character following # So, it's a little more than just syntactic
sugar.
http://clojure.org/reader
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sat, Mar 24, 2012 at 3:46 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Hey, we all have our rough edges :) I'm 50, there's less life in front of me than behind. Debating about the sex of angels looks to me a bad way of using the not so many hours left in our lives on significant problems before the final exit. If this particular thread's topic does not interest you, and you feel reading, and debating in, it would waste your time, perhaps you should just ignore it. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Sat, Mar 24, 2012 at 6:38 PM, Scott Jaderholm jaderh...@gmail.com wrote:
Sorry to break it to you, but # is used in many places other than
lambdas, so even if you remove it from #{} you still have foo#, #^foo,
#^{foo bar}, #'foo, #foo, #_foo, #foo{1 2}, #foo[1 2], and others
I've probably forgotten.
I was not talking about the number of things it's used for, but rather
the frequency of the uses in production code; sorry if that wasn't
clear.
My experience is that the highest frequency of #s in production code
is at the starts of lambdas; the next highest is regexes, which as
programs of a sort are also quasi-lambda-like (though not usable
directly as operators). Autogensyms in macros are a distant third and
use the # as a suffix, not a prefix. The other uses of # are less
frequent still. At the bottom of the heap, #_ is only used temporarily
in debugging, for the most part.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
I don't mind the #{} syntax, however I feel that if alternate syntax
were to be introduced (for whatever datatype) it should be the unicode
parenthesis since they 1. Look nice, 2. No addition of extra
characters (I value succinctness), 3. They work in most common
existing structured editing environments- emacs/paredit supports
unicode parens right now, whereas a construct like {{}} would break
down pretty fast. The downside (however minor) is the user has to
remap some key-binding to support it.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Alternate set literal syntax?
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
without breaking anything. It's not possible for it to be a valid map
literal, because the outer {...} pair has only one object inside it
and a map literal requires an even number of objects (zero, two, four
...), so right now {{foo bar baz}} will just throw a
CompilerException, and so will {{foo bar baz quux}} even though the
inner {...} pair then has an even number of objects. Making the reader
treat that as a set literal is therefore a purely additive change.
It's one character longer than #{foo bar baz} but it looks nicer, IMO,
and still shows the cousin-ship between sets and maps by using the
same choice among {}, [], ().
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
I'm a fan of #{foo bar baz}.
Ambrose
On Sat, Mar 24, 2012 at 11:44 AM, Cedric Greevey cgree...@gmail.com wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
without breaking anything. It's not possible for it to be a valid map
literal, because the outer {...} pair has only one object inside it
and a map literal requires an even number of objects (zero, two, four
...), so right now {{foo bar baz}} will just throw a
CompilerException, and so will {{foo bar baz quux}} even though the
inner {...} pair then has an even number of objects. Making the reader
treat that as a set literal is therefore a purely additive change.
It's one character longer than #{foo bar baz} but it looks nicer, IMO,
and still shows the cousin-ship between sets and maps by using the
same choice among {}, [], ().
--
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 with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
Even if #{...} was ugly (which I don't feel one way or the other on),
having two special syntaxes for the same thing is even uglier than having
one ugly set literal notation :)
On Sat, Mar 24, 2012 at 12:19 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
I'm a fan of #{foo bar baz}.
Ambrose
On Sat, Mar 24, 2012 at 11:44 AM, Cedric Greevey cgree...@gmail.comwrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
without breaking anything. It's not possible for it to be a valid map
literal, because the outer {...} pair has only one object inside it
and a map literal requires an even number of objects (zero, two, four
...), so right now {{foo bar baz}} will just throw a
CompilerException, and so will {{foo bar baz quux}} even though the
inner {...} pair then has an even number of objects. Making the reader
treat that as a set literal is therefore a purely additive change.
It's one character longer than #{foo bar baz} but it looks nicer, IMO,
and still shows the cousin-ship between sets and maps by using the
same choice among {}, [], ().
--
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 with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Alternate set literal syntax?
On Fri, Mar 23, 2012 at 8:44 PM, Cedric Greevey cgree...@gmail.com wrote:
#{foo bar baz} is somewhat ugly. It occurs to me that one could modify
the reader to additionally accept
{{foo bar baz}}
My concern is that {{1 2 3 4}5} is currently legal - a map with a map
as a key and 5 as the value. That means that the reader couldn't tell
if {{ introduced your set notation or the start of a nested map
without looking arbitrarily far ahead. And that problem gets worse if
you encounter {{{ or or... {{{ could introduce a nested map, a
map of your sets or one of your sets containing a map...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
