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