implementations when
destructuring a lazy sequence known?
Also, why was the random number printed twice on the JVM side. I haven't
looked an the implementation, but I would guess this would be due to
chunking the sequence. Thanks.
-Frank Failla
--
You received this message because you
: 0.7005322422752974
return: 0.6929552277817549
nil
user
When run on the CLR with clojure-clr 1.4.0, the random number will be
printed from in-repeat infinitely, never to return.
Is this difference between the JVM and CLR implementations when
destructuring a lazy sequence known?
Also, why
I left it alone. (The history is
lost, but I can place the JVM version change between Nov 08 and Feb 09.)
Four years later, I've just discovered the reason. The bug only surfaces
in certain circumstances on infinite (lazy) sequences -- and specifically
it is triggered by destructuring
I can't find the documentation for this behaviour:
(let [{x :b :as y} '(:a 1 :b 2)] [x y])
;= [2 {:a 1, :b 2}]
It seems as if the list in the init-expr is converted first to an
associative structure and then destructured.
But that behaviour doesn't seems to be documented, the map destructuring
.
But that behaviour doesn't seems to be documented, the map destructuring
documentation only talks
about destructuring of associative structures, and also there is nothing
about binding the :as expression
to the resultant associative structure instead of the initial init-expr
to default values. So {x x-default y y-default}
* Bindings as a result of the destructuring. So [x x-default y boo!]
What I'm suggesting might be useful, is destructuring sugar to bind one
additional map: {:x x-default :y boo!}.
The clojure.core/destructure code is pretty hairy, so I may
In case you are primarily interested in clojure functions with keyword
arguments (or optional arguments), you might check if clojure.options
(https://github.com/guv/clojure.options/) suits you.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
On Fri, 2012-08-31 at 03:40 -0700, Peter Taoussanis wrote:
(foo) = {:x x-default :y y-default}
I.e. to merge the :or defaults over the :args binding?
Such behavior would be quite surprising; to see why, desugar :keys:
{x (expr-that-computes :x),
y (expr-that-computes :y),
z
Hey all,
As currently implemented:
(defn foo
[ {:keys [x y z] :or {x x-default y y-default} *:as* args}]
args)
(foo) = *nil*
Is there a way anyone can think of (macro, etc.) that'd allow for something
like this:
(defn foo
[ {:keys [x y z] :or {x x-default y y-default} *:merge-as*
Cheers, Justin - I'd forgotten that (and just thought that vector-as-map
destructuring was broken - but this would explain why it is different from
other seqables.)
Doug
On Tuesday, August 28, 2012 3:12:43 PM UTC+1, Justin Kramer wrote:
Vector-as-map destructuring makes sense when you
One possibly confusing titbit I came across recently relates to how Clojure
handles destructuring of variable-length argument lists. The essence is
that the destructuring form can appear to influence the 'shape' of the
collection of arguments. Here is what I mean:
take nothing off the head
Vector-as-map destructuring makes sense when you consider that vectors are
associative: they map index to value.
(let [{a 1 b 3 :as c} [:a 1 :b 2]] [a b c])
= [1 2 [:a 1 :b 2]]
Justin
On Tuesday, August 28, 2012 8:30:58 AM UTC-4, Douglas Orr wrote:
One possibly confusing titbit I came across
Sean Corfield seancorfi...@gmail.com writes:
user (map #(let [{x 0 y 1 :or {0 -1, 1 -2}} %1]
[x y])
[[] [10] [10 11]])
([nil nil] [10 nil] [10 11])
I had expected it to return ([-1 -2] [10 -2] [10 11]).
It needs to be this:
user= (map #(let [{x 0 y 1 :or {x -1 y
Jay Fields j...@jayfields.com writes:
right, I know it's possible to do what you guys are describing. What I
meant to ask is, should :or be allowed in destructuring vectors? I
can't see any reason for it not to be allowed.
Hm, yes, I could think of these semantics, i.e., fill missing indices
Is there any reason that (let [[x y :or {x 1 y 2}] nil] [x y]) can't work?
--
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
Jay Fields j...@jayfields.com writes:
Hi Jay,
Is there any reason that (let [[x y :or {x 1 y 2}] nil] [x y]) can't
work?
:or is only supported for map destructuring but you use sequence
destructuring.
user (map #(let [{x :x, y :y :or {x 1, y 2}} %1]
[x y])
[{} {:x 17
On Tue, Jun 12, 2012 at 12:28 PM, Tassilo Horn tass...@member.fsf.org wrote:
user (map #(let [{x 0 y 1 :or {0 -1, 1 -2}} %1]
[x y])
[[] [10] [10 11]])
([nil nil] [10 nil] [10 11])
I had expected it to return ([-1 -2] [10 -2] [10 11]).
It needs to be this:
user= (map
right, I know it's possible to do what you guys are describing. What I meant to
ask is, should :or be allowed in destructuring vectors? I can't see any reason
for it not to be allowed.
On Jun 12, 2012, at 7:10 PM, Sean Corfield wrote:
On Tue, Jun 12, 2012 at 12:28 PM, Tassilo Horn tass
Hi Everybody,
I was just wondering if the following behaviour is the right behaviour..
can somebody comment?
user (let [{{a :a b :b :as w} :c a1 :a b1 :b :as w} {:a 10 :b 20 :c {:a
30 :b 40}}] {:a a :b b :b1 b1 :a1 a1})
{:a 30, :b 40, :b1 40, :a1 30}
user (let [{{a :a b :b :as w} :c a1 :a b1
the behaviour seems to be the same in 1.4.0
Sunil.
On Thu, Apr 19, 2012 at 11:31 AM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
Hi Everybody,
I was just wondering if the following behaviour is the right behaviour..
can somebody comment?
user (let [{{a :a b :b :as w} :c a1 :a b1
Hi,
I think this is a bug. This is the expansion without any :as clause:
(let*
[map__4496
{:a 10, :b 20, :c {:a 30, :b 40}}
map__4496
(if (clojure.core/seq? map__4496)
(clojure.core/apply clojure.core/hash-map map__4496)
map__4496)
map__4497
(clojure.core/get map__4496
You think I should file a bug-report?
Sunil.
On Thu, Apr 19, 2012 at 11:53 AM, Meikel Brandmeyer (kotarak)
m...@kotka.dewrote:
Hi,
I think this is a bug. This is the expansion without any :as clause:
(let*
[map__4496
{:a 10, :b 20, :c {:a 30, :b 40}}
map__4496
(if
Hi,
yes, I think so. The destructuring should not depend on the presence or
absence of a (for a given key) unrelated option. So no matter what I do
with :as the :a, :b, etc. keys should be correctly destructured, even in
nested maps as in your example.
Kind regards
Meikel
--
You received
On 08/02/2012 03:05, Asim Jalis wrote:
I frequently find myself passing around maps that are basically structs.
I use this macro to destructure the fields into let variables.
; Macro.
(defmacro def-fields [struct-name fields]
(let [field-symbol-vector (- fields (map name) (map symbol) vec)
I've some questions about destructuring a seq of maps, like:
1. Is it possible?
2. If yes, does it have any sense?
3. And if it's possible and is reasonable, how can I do it?
For example, let's say that I have a list of maps like this:
(def something [{:a 1 :b 2
On Tue, Feb 7, 2012 at 3:28 PM, Manuel Paccagnella
manuel.paccagne...@gmail.com wrote:
I've some questions about destructuring a seq of maps, like:
1. Is it possible?
2. If yes, does it have any sense?
3. And if it's possible and is reasonable, how can I do it?
For example, let's say that I
On 02/07/2012 09:37 PM, Aaron Cohen wrote:
Well, destructuring requires a literal, so you have to know exactly
the structure you're wanting to pick apart. For your specific example,
I can write a destructuring usage that will work, but there's no way
to do it in a general way.
user=(defn do-sum
-coll)))
Not a big deal, but I wonder if there is a better way to do it.
One better way:
(defn do-sum [some-coll]
(reduce + (map :a some-coll)))
Keywords can be used as functions. That's probably tidy enough not to
feel the need to do something else, such as destructuring
On 02/07/2012 09:48 PM, Cedric Greevey wrote:
One better way:
(defn do-sum [some-coll]
(reduce + (map :a some-coll)))
Keywords can be used as functions.
Sure!
That's probably tidy enough not to
feel the need to do something else, such as destructuring.
Yes, I
I frequently find myself passing around maps that are basically structs. I
use this macro to destructure the fields into let variables.
; Macro.
(defmacro def-fields [struct-name fields]
(let [field-symbol-vector (- fields (map name) (map symbol) vec)
arg (gensym)
body
to occur only when I use object destructuring within deftype. A
small sample:
(ns test)
(defprotocol Test
(foo [this data]))
(deftype Foo []
Test
(foo [this {:keys [bar a b c] :as d}]
(.log js/console bar)))
This compiles down to:
// ...
/**
* @constructor
*/
test.Foo = (function
invalid JavaScript
and I get an exception when running it in the browser.
This seems to occur only when I use object destructuring within deftype. A
small sample:
Destructuring is not currently supported on protocol fns. That's not valid
in Clojure either.
David
--
You received this message
Hi,
it is:
Clojure 1.3.0
user= (defprotocol Test (foo [this data]))
Test
user= (deftype Foo []
Test
(foo [this {:keys [bar a b c] :as d}]
(println bar)))
user.Foo
user= (foo (Foo.) {:bar 123})
123
nil
Meikel
--
You received this message because you are subscribed to the Google
Groups
On Fri, Feb 3, 2012 at 10:29 AM, Meikel Brandmeyer (kotarak)
m...@kotka.dewrote:
Hi,
it is:
Clojure 1.3.0
user= (defprotocol Test (foo [this data]))
Test
user= (deftype Foo []
Test
(foo [this {:keys [bar a b c] :as d}]
(println bar)))
user.Foo
user= (foo (Foo.) {:bar 123})
Joy of Clojure adds a second reason for this:
The second reason is because it allows us to conjure up other
destructuring features by using forms that would otherwise make no sense.
Because the item on the left of each pair will be a new local name, it must
be a symbol or possibly a nested
One thing that seems weird is the way Clojure destructures a map
I have this map: {:last-name Vinge :first-name Vernor} which is passed
to this function: (defn greet-author-2 [{fname :first-name}] ... )
Wouldn't it be better doing: (defn greet-author-2 [{:first-name fname}] ...
)
You first
That does feel a bit more natural, but how would you handle :keys, :as, and :or?
On Wed, Jan 4, 2012 at 1:36 AM, Johnny Weng Luu
johnny.weng@gmail.com wrote:
One thing that seems weird is the way Clojure destructures a map
I have this map: {:last-name Vinge :first-name Vernor} which is
On Wed, Jan 4, 2012 at 07:36, Johnny Weng Luu johnny.weng@gmail.com wrote:
One thing that seems weird is the way Clojure destructures a map
I have this map: {:last-name Vinge :first-name Vernor} which is passed
to this function: (defn greet-author-2 [{fname :first-name}] ... )
Wouldn't
I had the same thought when I first started learning Clojure - I think
the idea is that there is some nice mental resonance when
destructuring matches up to your mental model of the data structure
(it's literal form). In sequential destructuring, that holds but in
maps it doesn't so things look
nice mental resonance when
destructuring matches up to your mental model of the data structure
(it's literal form). In sequential destructuring, that holds but in
maps it doesn't so things look backwards. I think the way I've come
to understand it is that when doing a let-style binding
Seems like a bug:
The following compiles:
(let [[^Double x ^Double y] [0.1 0.2]] (+ x y))
This does not:
(let [[^double x ^double y] [0.1 0.2]] (+ x y))
Unable to resolve classname: double
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to
tested under Clojure 1.3
--
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
On Nov 2, 11:40 am, Sergey Didenko sergey.dide...@gmail.com wrote:
Seems like a bug:
The following compiles:
(let [[^Double x ^Double y] [0.1 0.2]] (+ x y))
This does not:
(let [[^double x ^double y] [0.1 0.2]] (+ x y))
Unable to resolve classname: double
This is CLJ-852. Applying the
On Thu, Jun 16, 2011 at 9:51 AM, Tassilo Horn tass...@member.fsf.org wrote:
Hi all,
I have some functions that use destructuring on a map parameter, and it
seems I have a false assumption on the workings. Take for example this
one:
(defn foo
[{:keys [a b]
:or {a 1 b 2}
:as all
between the
two maps. But you shouldn't be relying on key order anyway with
unsorted maps.
I don't.
2. This bare-bones macro doesn't handle docstrings on the functions.
That's bad. But for my use-case, the docstrings are mandatory, so I can
easily add them to your macro.
3. Map destructuring
On Fri, Jun 17, 2011 at 2:31 PM, Tassilo Horn tass...@member.fsf.org wrote:
Ken Wesson kwess...@gmail.com writes:
Hi Ken!
(defmacro defnm [name argvec body]
`(defn ~name ~argvec
(let ~(vec
(apply concat
(for [a argvec :when (and (map? a) (:or a) (:as
Hi all,
I have some functions that use destructuring on a map parameter, and it
seems I have a false assumption on the workings. Take for example this
one:
(defn foo
[{:keys [a b]
:or {a 1 b 2}
:as all}]
[(hash-map :a a :b b) all])
I expected it to always return a vector of two
On Jan 22, 1:19 am, Mark Triggs mark.h.tri...@gmail.com wrote:
Daniel Werner daniel.d.wer...@googlemail.com writes:
After a few tries I've come up with the following algorithm to
transform :keys syntax into normal destructuring syntax, but am still
appalled by its complexity:
(let [vmap
Hi,
user= (let [vmap '{y :y z :z :keys [a b] :syms [e f] :strs [g h]}]
(- (dissoc vmap :keys :strs :syms)
(into (map #(vector % (keyword %)) (:keys vmap)))
(into (map #(vector % (name %))(:strs vmap)))
(into (map #(vector % %) (:syms vmap)
{y :y, z :z, a :a, b :b,
]}
Now this is not too difficult of a function to write from scratch. BUT
it really looks like I should be able to piggy-back off the existing
functionality in the destructuring-let macro. But I cannot figure out
how I can do that without using
I have a library called Evalive (http://github.com/fogus/evalive) that
could help. Specifically I added a macro named `destro` that will do
_mostly_ what you want. Basically, it looks like the following:
(destro [a b [c d e]] [1 2 [3 4 5 6 7 8]])
Which returns:
{vec__2183 [1 2 [3 4 5 6 7
Sorry, I wasn't being very clear about my needs.
I need this function to run at *run-time*.
So the following:
(def values [1 2 [3 4 5 6 7 8]])
(def form '(a b (c d e)))
(destructure form values)
Should return:
{:a 1 :b 2 :c 3 :d 4 :e [5 6 7 8]}
I was wondering whether the destructure function
Hi,
Am 07.02.2011 um 18:20 schrieb Justin Kramer:
Checking out clojure.core/destructure and clojure.core/let might be
helpful.
Here's a macro I hacked together. It doesn't work with :keys, :as,
or :or. I take no responsibility if you use it for anything real. But
maybe it will provide you
Hi,
Am 07.02.2011 um 20:26 schrieb CuppoJava:
I was wondering whether the destructure function can be written
using the existing let form. Thanks for your help.
Ah ok. Nevermind.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
Thanks for your answer Meikel.
Your answer isn't that ugly. It's very similar to what I have as
well.
I would like to know if you think it's possible to re-use let to do
this. I feel like I'm re-inventing the wheel somewhat.
-Patrick
On Feb 7, 2:44 pm, Meikel Brandmeyer m...@kotka.de wrote:
Hi,
Am 07.02.2011 um 20:51 schrieb CuppoJava:
Thanks for your answer Meikel.
Your answer isn't that ugly. It's very similar to what I have as
well.
I would like to know if you think it's possible to re-use let to do
this. I feel like I'm re-inventing the wheel somewhat.
I don't think
On Mon, Feb 7, 2011 at 3:01 PM, Meikel Brandmeyer m...@kotka.de wrote:
Hi,
Am 07.02.2011 um 20:51 schrieb CuppoJava:
Thanks for your answer Meikel.
Your answer isn't that ugly. It's very similar to what I have as
well.
I would like to know if you think it's possible to re-use let to do
Actually that would be fine as a solution as well. I'm stumped as to
how to avoid repeating the same thing twice (once in function world
and once in macro world).
ie. Let's assume that we have this destructuring function. How do we
use that do program a destructuring let macro?
-Patrick
twice (once in function world
and once in macro world).
ie. Let's assume that we have this destructuring function. How do we
use that do program a destructuring let macro?
-Patrick
On Feb 7, 3:32 pm, Ken Wesson kwess...@gmail.com wrote:
On Mon, Feb 7, 2011 at 3:01 PM, Meikel Brandmeyer
patrickli_2...@hotmail.com wrote:
Actually that would be fine as a solution as well. I'm stumped as to
how to avoid repeating the same thing twice (once in function world
and once in macro world).
ie. Let's assume that we have this destructuring function. How do we
use that do program
On Mon, Feb 7, 2011 at 10:06 PM, CuppoJava patrickli_2...@hotmail.comwrote:
I've thought about that actually. And it wouldn't work.
So (defn destructure [form value]
...magic...)
(defmacro let [forms body]
`(let* ~(vec (destructure forms body)) - at this point, body is
not known
On Mon, Feb 7, 2011 at 10:06 PM, CuppoJava patrickli_2...@hotmail.com wrote:
I've thought about that actually. And it wouldn't work.
So (defn destructure [form value]
...magic...)
(defmacro let [forms body]
`(let* ~(vec (destructure forms body)) - at this point, body is
not known
in the destructuring-let macro:
(def a [1 2 3])
(let ((x y z) a)
(println x y z))
body refers to the single symbol a.
Anyway, it seems like what I want is impossible, or at the very least,
difficult. I will just have to put up with re-implementing let.
Thanks for everyone's contribution
-Patrick
it falls apart. body is actually bound to a
single symbol.
For example in the destructuring-let macro:
(def a [1 2 3])
(let ((x y z) a)
(println x y z))
body refers to the single symbol a.
What?
No. The syntax for let is a vector, so it'd be something like
(def a [1 2 3])
(let [[x y z
Hi everyone,
let's play a round of golf. I am currently implementing associative
destructuring for ClojureJS while trying not to peek into clojure.core
too often -- which wouldn't make things much easier since the
'destructure fn is a huge beast.
After a few tries I've come up with the following
Daniel Werner daniel.d.wer...@googlemail.com writes:
After a few tries I've come up with the following algorithm to
transform :keys syntax into normal destructuring syntax, but am still
appalled by its complexity:
(let [vmap {'y :y, 'z :z :keys ['a 'b]}]
(- vmap
((juxt :keys :strs
Ah. But a new map is being created with the default :or operation. I
guess the ability to get this entire map with defaults is not
available directly from clojure destructuring binding.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
the ability to get this entire map with defaults is not
available directly from clojure destructuring binding.
--
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
Is there any way to get the entire map when destructuring plus the
defaults?
(let [{:keys [a] :or {a 4} :as b} {:b 3}] b)
returns {:b 3}
but i would like it to return {:b 3 :a 4}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group
The :as option in destructuring forms binds the original value being
destructured -- no entire map is being formed in the background ahead of time.
So, build that entire map as you require; e.g.:
= (let [{:keys [a] :as b} (merge {:b 3} {:a 4})] b)
{:a 4, :b 3}
- Chas
On Jan 4, 2011, at 7:38
Archive search nth seq hickey:
http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gstq=nth+seq+hickey#773b23a34e88acab
Stu
On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote:
That's totally different than nth for a set being
On Mon, Dec 6, 2010 at 8:24 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
Archive search nth seq hickey:
http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gstq=nth+seq+hickey#773b23a34e88acab
Interesting. But that was years ago, Hickey no
On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote:
Furthermore, the comment (not made by Hickey) that map order may be
unstable is more than a little puzzling in light of the fact that the
maps in question are immutable. :)
In general, Rich has been careful not to promise things that
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote:
Furthermore, the comment (not made by Hickey) that map order may be
unstable is more than a little puzzling in light of the fact that the
maps in question
On Mon, 6 Dec 2010 16:30:10 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote:
Furthermore, the comment (not made by Hickey) that map order may be
unstable is
On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
On Mon, 6 Dec 2010 16:30:10 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Dec 6, 8:36 am, Ken Wesson
On Mon, 6 Dec 2010 17:07:15 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
On Mon, 6 Dec 2010 16:30:10 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these things; if the implementation changed its
innards while you were walking the
On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner gardne...@gmail.com wrote:
On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these
sorry to jump in this weird conversation, but it seems to me that you are on
parallel discussion without acknowleding it.
To me, the only thing which makes sense is that saying that seq promises no
deterministic ordering on sets and maps is not about calling seq on the same
java instance of a set
On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote:
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
Ah, I misunderstood what you wrote. Obviously (seq) should hand you each item
in the collection exactly once, but that's at a
On Mon, Dec 6, 2010 at 7:10 PM, Michael Gardner gardne...@gmail.com wrote:
On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote:
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
Ah, I misunderstood what you wrote. Obviously (seq)
On Dec 6, 2010, at 9:02 PM, Ken Wesson wrote:
I'll try this one more time. You suggested the innards, and with them
the seq order of the elements, might get rearranged.
I suggested no such thing; perhaps you are confusing me with Mike Meyer? I
referred more generally to the possibility of two
On Mon, Dec 6, 2010 at 10:45 PM, Michael Gardner gardne...@gmail.com wrote:
On Dec 6, 2010, at 9:02 PM, Ken Wesson wrote:
I'll try this one more time. You suggested the innards, and with them
the seq order of the elements, might get rearranged.
I suggested no such thing; perhaps you are
Hello all
I have following question to Rich and other core developers of Clojure -
why parameters destructuring requires presence of 'nth' implementation for
destructuring of sequences?
The [[x more]] idiom is very popular and could make code more concise, but
it doesn't work for sets and some
Re
jweiss at Sun, 5 Dec 2010 10:29:41 -0800 (PST) wrote:
j I'm no expert on this, but i'll take a crack at it.
j I think it's because sets don't (necessarily) impose any order, so
j there's no concept of first or nth. So destructuring would
j essentially be assigning a random item to x
destructuring would
j essentially be assigning a random item to x, or for join, joining them
j in random order.
Sometimes, order doesn't matter, for example, I want to print data from set
(or any collection that is transformable into sequence), using some
separator between elements...
For some
On Sun, Dec 5, 2010 at 1:29 PM, jweiss jeffrey.m.we...@gmail.com wrote:
I'm no expert on this, but i'll take a crack at it.
I think it's because sets don't (necessarily) impose any order, so
there's no concept of first or nth. So destructuring would
essentially be assigning a random item
On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote:
That's totally different than nth for a set being undefined. It's undefined
on purpose.
Now, if you are using a sorted-set, then you have a point there, I
would expect that nth means something then. But yeah, clojure
+1 to what Ken said
Sunil
On Mon, Dec 6, 2010 at 4:04 AM, Ken Wesson kwess...@gmail.com wrote:
On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote:
That's totally different than nth for a set being undefined. It's
undefined
on purpose.
Now, if you are using a
If sets don't have a set ordering, then why should seq on a set always
return the same order for the same set?
If seq doesn't always return the a seq with the same order, then (nth
set 5) might be different than a future call to (nth set 5),
because the underlying sequence returned by the set
On Sun, Dec 5, 2010 at 8:26 PM, Robert McIntyre r...@mit.edu wrote:
If sets don't have a set ordering, then why should seq on a set always
return the same order for the same set?
If seq doesn't always return the a seq with the same order, then (nth
set 5) might be different than a future call
Hi All,
I'm currently ploughing my way through Michael Fogus and Chris Housers
The Joy of Clojure. I am currently reading up on destructuring. The
authors sum up the chapter by concluding that destructuring is the
idiomatic clojure replacement for accessor methods in OO languages.
Can someone
as for first and next:
You can do this
(let [fst (first [1 2 3 4 5 6])
rst (rest [1 2 3 4 5 6])]
(println first: fst)
(println rest: rst))
or
(let [[fst rst] [1 2 3 4 5 6]]
(println first: fst)
(println rest: rst))
both print this:
first: 1
rest: (2 3 4 5 6)
--
You
;
}
public void setName(String name) {
this.name = name;
}
public void setCount(int count) {
this.count = count;
}
}
clojure equivalent using destructuring:
(def foo {:count 2 :name billy})
(let [{:keys [count name]} foo]
(println count: count name
:a 3]] [a])
[nil]
user= (let [{a 2} [:b 7 :a 3]] [a])
[:a]
The map destructuring in the defn is a special case of defn, not
destructuring itself.
(defn foo [ {:keys [a b]}] ...)
is equivalent to
(defn foo [ options#] (let [{:keys [a b]} (apply hash-map
options#)] ...))
Now it should also
Hi,
On 2 Nov., 07:41, Meikel Brandmeyer m...@kotka.de wrote:
Hi,
On 2 Nov., 03:25, Mike K mbk.li...@gmail.com wrote:
The map destructuring in the defn is a special case of defn, not
destructuring itself.
(defn foo [ {:keys [a b]}] ...)
is equivalent to
(defn foo [ options#] (let
[{a :a} [:b 7 :a 3]] [a]) possibly work?
The same way this one works:
(defn foo [ {:keys [a b]}] ...)
is equivalent to
(defn foo [ options#] (let [{:keys [a b]} (apply hash-map
options#)] ...))
This only happens if the rest argument destructuring is a hash map -
if I use a vector or a symbol
Hi,
On 2 Nov., 08:14, Mike Meyer mwm-keyword-googlegroups.
620...@mired.org wrote:
This only happens if the rest argument destructuring is a hash map -
if I use a vector or a symbol there, then the values don't get turned
into a map. Can't that same mechanism be used in the case where some
This question is a bit abstruse, so please bear with me :-)
Here is an example of a function with named arguments and default
values from the book The Joy of Clojure. It uses optional arguments
(via ) and map destructuring.
(defn slope
[ {:keys [p1 p2] :or {p1 [0 0] p2 [1 1]}}]
(float
101 - 200 of 306 matches
Mail list logo
