sorry 'set' will convert from a coll to a set...use 'hash-set' ,
'sorted-set' etc etc...
Jim
On 12/11/12 13:22, Jim foo.bar wrote:
Yes, this has been discussed extensively in the pastI think the
convention is to use the ctor functions if you're passing data
dynamically, otherwise if deal
Yes, this has been discussed extensively in the pastI think the
convention is to use the ctor functions if you're passing data
dynamically, otherwise if dealing with constants the literals should be
just fine...In the case just replace the set literal with (hash-set ...)
or (set ...).
hop
I may arrive at the party a little late but just to mention I got bitten by
this too (while working on clojure-py, so I actually want to know about the
weird edge cases...)
user=> #{(rand-int 100) (rand-int 100)}
IllegalArgumentException Duplicate key: (rand-int 100)
clojure.lang.PersistentHas
I just wanted to mention to those interested in the issues raised by this
thread that a patch for CLJ-1065 was committed to Clojure master today, and is
part of release clojure-1.5.0-alpha5:
http://dev.clojure.org/jira/browse/CLJ-1065
All of the set and map constructor functions now explicitly
On Sep 8, 2012, at 7:38 PM, Andy Fingerhut wrote:
> Rich:
>
> I'm not sure what you mean by the not-fastest-path possible that exists in
> today's Clojure code, so if you get a chance, see if the below is what you
> mean.
>
> As far as I can tell (i.e. putting debug println's in the Java code
Rich:
I'm not sure what you mean by the not-fastest-path possible that exists in
today's Clojure code, so if you get a chance, see if the below is what you mean.
As far as I can tell (i.e. putting debug println's in the Java code of RT.map),
when someone enters a map literal in, say, a function
I understand your frustration.
But it is important to note that timeliness and feedback are a two-way street.
There was a time when changes to Clojure were tried immediately by users, and
I'd know within hours if not minutes if I'd introduced something that caused
problems for someone. That mat
I think I may have figured it out. New patch attached to ticket CLJ-1065 that
should eliminate run-time checks for duplicate map keys, for those maps whose
keys are all compile-time constants.
Andy
On Sep 8, 2012, at 4:38 PM, Andy Fingerhut wrote:
> Rich:
>
> I'm not sure what you mean by th
Thanks!
I'm still interested in patch for recommendation #3:
Restore the fastest path possible for those cases where the keys are
compile-time detectable unique constants
I'd like to see all three recommendations go into a release as a set.
On Sep 8, 2012, at 2:22 AM, Andy Fingerhut wrote:
The new ticket CLJ-1065 has a patch that I think implements the desired
behavior on the dev wiki page.
i.e. set/map literals with duplicates are invalid (status quo)
All constructor functions for sets and maps allow duplicates, and for maps,
always take the value associated with the last occurr
On the wiki page, Rich Hickey wrote:
* If you think a month is too long to get a response to your needs, from a
bunch of very busy volunteers, you need to chill out
* just because you decided to bring it up doesn't mean everyone else needs
to drop what they are doing
For the record, I don't really
On Sep 7, 2012, at 3:35 PM, Sean Corfield wrote:
> On Fri, Sep 7, 2012 at 10:49 AM, Rich Hickey wrote:
>> I've added my feedback there
>> (http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements)
>
> Thanx Rich! So the recommendation is:
>
> * set/map literals with du
On Fri, Sep 7, 2012 at 10:49 AM, Rich Hickey wrote:
> I've added my feedback there
> (http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements)
Thanx Rich! So the recommendation is:
* set/map literals with duplicates are invalid (status quo)
* hash-set/hash-map should c
Once again, thanks Andy!
I've added my feedback there
(http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements)
Patches implementing that are welcome.
Rich
On Sep 5, 2012, at 1:57 PM, Andy Fingerhut wrote:
> I've copied and pasted Mark's arguments to the Wiki page her
I've copied and pasted Mark's arguments to the Wiki page here:
http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements
Andy
On Sep 5, 2012, at 6:41 AM, Stuart Halloway wrote:
> Hi Mark,
>
> Thanks for extracting a summary of the conversation so far, and +1 for making
>
Hi Mark,
Thanks for extracting a summary of the conversation so far, and +1 for making
sure this is on the wiki.
Stu
> On Tue, Sep 4, 2012 at 9:30 AM, Andy Fingerhut
> wrote:
> I'm just trying to get the argument for change as clearly as possible.
>
> The major bullet points:
> 1. "It's a bu
I too approve of Mark's reasoning and solution. Probably that should be
moved into
http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements
On Wednesday, September 5, 2012 6:40:50 AM UTC+2, Peter Taoussanis wrote:
>
> +1 on Mark's most recent reply, that is:
>
> * Revert
+1 on Mark's most recent reply, that is:
* Revert to 1.2 behaviour.
* Consistency is good, but must be in favour of not throwing RTEs.
* No knobs.
It's clear that there's lots of directions that could be taken here, but
getting caught up on trying to find a solution that pleases everyone 100%
i
On Tue, Sep 4, 2012 at 9:30 AM, Andy Fingerhut wrote:
> I'm just trying to get the argument for change as clearly as possible.
>
The major bullet points:
1. "It's a bug that should be fixed." The change to throw-on-duplicate
behavior for sets in 1.3 was a breaking change that causes a runtime er
2012/9/5 Andy Fingerhut
> If someone types in the literal map {:a 5 :b 10 :c 13 :a -5}, what is the
> "correct thing"?
>
> Some people might be thinking the correct thing is "I want the last key
> :a's value, -5, to win always, no matter if the key :a occurs more than
> once. I never want an err
On Sep 4, 2012, at 4:53 PM, Jim - FooBar(); wrote:
> On 04/09/12 21:02, Andy Fingerhut wrote:
>>
>> Stuart Halloway mentioned the idea of having two kinds of set/map
>> constructor functions, one kind which quietly eliminates duplicates, another
>> which throws an exception on duplicates.
>
>
On 05/09/12 00:53, Jim - FooBar(); wrote:
of course not...this also goes against set/map semantics from a
mathematics point of view...the mathematical guarantees of set
('there will be no duplicates') are imposed by the set itself and not
by the person/program/whatever using it! the same with
On 04/09/12 21:02, Andy Fingerhut wrote:
But what if they all consistently throw exceptions when encountering
duplicates, including (set [5 5])? That doesn't sound like what you want.
of course not...this also goes against set/map semantics from a
mathematics point of view...the mathematical
+1 consistency, whether it throws an exception or not, removes complexity
from the language.
(because the programmer don't have to know the complex rules which literal
notation behaves which way
On Tue, Sep 4, 2012 at 10:02 PM, Andy Fingerhut wrote:
> But what if they all consistently throw excep
But what if they all consistently throw exceptions when encountering
duplicates, including (set [5 5])? That doesn't sound like what you want.
Also, it seems from this discussion that at least some people like the
error-catching aspects of the current behavior.
Stuart Halloway mentioned the id
the issue here is that behaviour should be *consistent* across all forms
of ctor functions, so programmers don't have to remember which one
allows what or don't thus limiting code breaks...the literal syntax is
just too elegant to give up! I don't think anyone is against consistency...
Jim
ps
I have created a dev page for this issue. It isn't a JIRA ticket because it
isn't clear to me yet exactly what the changes should be.
http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements
A couple of questions there for people that dislike the current behavior.
You ca
On 04/09/12 02:06, Mark Engelberg wrote:
This email is also my way of bumping the thread and bringing it again
to everyone's attention. This is something I'd very much like to see
resolved.
+1 ... this thread should not die!
Jim
--
You received this message because you are subscribed to the
On Mon, Sep 3, 2012 at 6:06 PM, Mark Engelberg wrote:
> I don't know what the path is now. I feel that in the past year, there have
> been several times where people have raised meaningful issues about Clojure
> and received no official response. It's hard to know whether this is an
> intentiona
In the early days of Clojure, it was clear that Rich was reading every post
on the Clojure mailing list. He didn't respond to every single thread, of
course, but when new issues were raised, he would frequently chime in,
"That's a good point, please create a patch for that" or "That's something
th
This issue best illustrates how imperative and functional thinking differ.
When I write code such as
(map not [true false])
, I implicitly think imperatively: "compiler, please traverse this
collection, applying 'not to each element...".
I could also word my thoughts functionally: "I desire the
I agree that the current throw-on-duplicates behavior is broken, because it
renders literals with variable keys useless.
> 1. Simplicity is partially about having orthogonal primitives. A
duplicate-removing collection factory cannot be sensibly used to implement
a throw-on-duplicates collection fa
+1
On Tuesday, August 7, 2012 3:20:44 AM UTC-4, abp wrote:
>
> I use literals for collection-construction from arbitrary values too. Just
> haven't run into that issue.
>
> So, please:
>
> Put hash maps and hash sets back to the way they were -- they worked
>>> perfectly fine. Use the duplicate
I'm more or less a newcomer to the language, but I generally feel that
having to deal with eventual exceptions, such as in
> [...] imagine some code that tried to construct a set literal from some
variables, catching IllegalArgumentException to deal with duplicate values.
is not very much in l
I use literals for collection-construction from arbitrary values too. Just
haven't run into that issue.
So, please:
Put hash maps and hash sets back to the way they were -- they worked
>> perfectly fine. Use the duplicate key check in ArrayMap to make ArrayMaps
>> behave like all the other ma
Fwiw, inc on what Marc said
Le 6 août 2012 à 10:39, Peter Taoussanis a écrit :
Just throwing in my vote here (assuming anyone's keeping count): I agree
with Mark that the current behavior is surprising and disagreeable.
And while there's clearly a practical argument to be made from both
persp
Just throwing in my vote here (assuming anyone's keeping count): I agree
with Mark that the current behavior is surprising and disagreeable.
And while there's clearly a practical argument to be made from both
perspectives, my own feeling is that throwing a hard runtime exception here
is excessi
On Sun, Aug 5, 2012 at 7:31 PM, Evan Gamble wrote:
> ...oh, and regarding the people who argue we should not use literal syntax
> with non-constants, I can only shake my head in wonder. Why on Earth would
> anyone seriously propose not using this elegant, concise syntax?
Just to be clear, I'm not
Throwing a runtime error for duplicates in set literals is, to me,
shockingly counterintuitive, regardless of whether constants or
non-constants are in the literal. Mathematical set notation has a long
history of admitting duplicates, for clarity in exposition, which are
understood to collapse
I don't think any of the 5 clojure books out there, mentions that
data-structure literals should not be used to generate vectors/maps/sets
dynamically at runtime...personally I've been doing this a lot
especially with vectors and maps ! never even suspected that it was
wrong simply because i do
On Aug 5, 2012, at 4:18 PM, Mark Engelberg wrote:
> Also, although it was a breaking change to add throw-on-duplicate behavior to
> many types of maps and sets, reverting back to 1.2 behavior could not
> possibly be a "breaking change" in the literal sense. Anyone whose code
> works right now
On Sat, Aug 4, 2012 at 11:45 PM, Mark Engelberg
wrote:
> My jaw is dropping here. I can't believe anyone would seriously propose
> that the only things that go between [], {}, or #{} should be constants.
For what it's worth, vectors behave this way in Emacs Lisp.
I couldn't believe it either wh
On Sun, Aug 5, 2012 at 1:42 PM, Mark Engelberg wrote:
> 3. People may differ about which flavor constructor the literals should
> use, but I don't see any arguments here warranting a breaking change.
Also, although it was a breaking change to add throw-on-duplicate behavior
to many types of maps
On Sun, Aug 5, 2012 at 1:18 PM, Stuart Halloway
wrote:
> 1. Simplicity is partially about having orthogonal primitives. A
> duplicate-removing collection factory cannot be sensibly used to implement
> a throw-on-duplicates collection factory, nor vice versa, so both seem
> equally primitive to me.
My 2c:
1. Simplicity is partially about having orthogonal primitives. A
duplicate-removing collection factory cannot be sensibly used to implement a
throw-on-duplicates collection factory, nor vice versa, so both seem equally
primitive to me.
2. Given that both flavors are useful, they should
After reading through the links that Chas provided, here's a summary of the
main points as I see them:
1. Looking through the history of this issue, no one was actually asking
to be protected from accidentally typing duplicate keys in a map or set.
2. People *were* asking to be protected from t
On Sun, Aug 5, 2012 at 7:33 AM, Chas Emerick wrote:
> Quoting Rich from the mailing list thread linked above:
>
> These are bugs in user code. Map literals are in fact read as maps, so
> a literal map with duplicate keys isn't going to produce an evaluated
> map with distinct keys. If you create
Oh, right; I've said something silly. What I had in mind is something like
(let [[x y] (if cond [(coll 0) (coll 1)] [default (first coll)]), which is
quite common in e.g. macros with optional arguments. Also, vectors
containing expressions can be used by functions returning multiple values,
or
On Sun, Aug 5, 2012 at 7:33 AM, Chas Emerick wrote:
> Note that the .createWithCheck variations of all of the collections in
> question are used by their "constructor" functions as well, e.g. hash-set,
> hash-map, and array-map:
>
I hadn't noticed that, but I think that is good evidence that thi
On Sun, Aug 5, 2012 at 3:33 AM, Vinzent wrote:
> Also, I have a huge number of literal vectors with expressions inside
> (typical example: (let [[x y] coll] ...) is an equvalent to [(coll 0) (coll
> 1)]).
A destructuring vector is not the same thing as is being discussed
here: (let [[x y] coll] .
On Aug 5, 2012, at 2:56 AM, Sean Corfield wrote:
> On Sat, Aug 4, 2012 at 11:45 PM, Mark Engelberg
> wrote:
>> In any case, Clojure is already able to detect when x and y are equal in
>> something like #{x y} and report it as an error.
>
> So do you think #{1 1} should not be an error? And {:a 1
I agree with puzzler and Alex.
Also, I have a huge number of literal vectors with expressions inside
(typical example: (let [[x y] coll] ...) is an equvalent to [(coll 0) (coll
1)]).
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this g
I'm on Mark's side. #{a b} potentially throwing a runtime exception is one
of those quirky Clojure-isms that would be considered bugs to anyone not
deeply entrenched in the Clojure world. Let's remove the Clojure-colored
glasses.
--
You received this message because you are subscribed to the Go
On Sat, Aug 4, 2012 at 11:56 PM, Sean Corfield wrote:
> On Sat, Aug 4, 2012 at 11:45 PM, Mark Engelberg
> wrote:
> > In any case, Clojure is already able to detect when x and y are equal in
> > something like #{x y} and report it as an error.
>
> So do you think #{1 1} should not be an error? And
On Sat, Aug 4, 2012 at 11:45 PM, Mark Engelberg
wrote:
> In any case, Clojure is already able to detect when x and y are equal in
> something like #{x y} and report it as an error.
So do you think #{1 1} should not be an error? And {:a 1 :a 2}? These
seem like "obvious" programmer errors that I'd
On Sat, Aug 4, 2012 at 11:05 PM, Baishampayan Ghose wrote:
> To add my two cents, IMHO the literal notation for sets, vectors &
> maps are just that---they are the "literal" representations of those
> data-structures and are not semantically equivalent to constructor
> functions. As such, the lite
On Sat, Aug 4, 2012 at 10:52 PM, Mark Engelberg
wrote:
> Yes, my first thought was, "I can just work around this by changing every
> occurrence of something like #{a b} to (set [a b])."
I guess my thinking is a literal doesn't contain variables :)
I'd have #{1 2 3} and #{:a :b :c} and #{'x 'y 'z
To add my two cents, IMHO the literal notation for sets, vectors &
maps are just that---they are the "literal" representations of those
data-structures and are not semantically equivalent to constructor
functions. As such, the literal notation should really be used with
constants; in every other ca
Perhaps you don't use sets as much as I do, so to help you put it in
perspective, imagine how you'd feel if I told you:
"Oh by the way, that nice vector notation you use to write things like [1 3
5 7 2]. Yeah, well, it's only reliable if there are constants inside.
That thing you've been doing wh
On Sat, Aug 4, 2012 at 7:23 PM, Sean Corfield wrote:
> I hadn't even thought of using the set literal syntax with variables
> that might not have unique value. I guess I'd ask: why not use the set
> function?
>
> (let [a :x b :x] (set [a b])) ;; #{:x}
>
>
Yes, my first thought was, "I can just wor
On Sat, Aug 4, 2012 at 6:43 PM, Mark Engelberg wrote:
> What is the reasoning behind the design decision that this generates an
> error:
> (let [a :x b :x] #{a b})
> rather than just returning #{:x} ?
My first reaction was that literals have to obey the rules of the
underlying type or else they a
61 matches
Mail list logo
