On Apr 8, 11:08 am, David Nolen wrote:
> In my own code I only avoid the convenience of destructuring in the
> rare tight loops such as calculations intended to drive animations.
But when you write a function you would have to decide positional vs.
keyword. Would you then take a guess about usage
Yes, I meant that :-)
But I agree that some more sugar in general in map destructuring could
help (and be more DRY).
e.g.
(defn g [a b & {:keys [[c 1] [d 2]]}] [a b c d])
or
(defn g [a b & {c [:c 1] d [:d 2]]}] [a b c d])
in the general case
2010/4/8 Chris Perkins :
> On Apr 7, 5:41 am, La
On Apr 7, 5:41 am, Laurent PETIT wrote:
> I think defnk is deprecated by the new feature mentioned by Stuart.
Do you mean to say that this:
user=> (defnk f [a b :c 1 :d 2] [a b c d])
#'user/f
user=> (f 3 4 :d 7)
[3 4 1 7]
is deprecated in favor of this:
user=> (defn g [a b & {:keys [c d] :or {
In my own code I only avoid the convenience of destructuring in the
rare tight loops such as calculations intended to drive animations.
I've found it to have little effect elsewhere on program performance.
As an aside I personally prefer non positional keyword arguments. I
find positional ones qui
You can easily code positional keyword parameters yourself. It takes
only a few minutes for a basic version. Here's an admittedly not very
pretty example:
http://gist.github.com/360145
-Per
On Thu, Apr 8, 2010 at 9:13 PM, Sophie wrote:
> On Apr 7, 7:56 am, David Nolen wrote:
>> The runtime cos
On Apr 7, 12:37 pm, Armando Blancas wrote:
> in other languages they'd be annotations and maybe perceived
> as redundant, e.g. a call like: (circle x y radius) is readable
Ah, but what about:
(circle year population income)
vs.
(circle :x year :y population :r income)
> In Smtalltalk a single-ar
On Apr 7, 7:56 am, David Nolen wrote:
> The runtime cost of destructuring is not worth getting worked up
> about. It's easy to check this yourself with (time ...)
Results below:
user=> (defn fk [& {:keys [a b c]}] (+ a b c))
user=> (defn fp [a b c] (+ a b c))
user=> (time (dotimes [_ 100]
> I hereby cast my vote into the void: release often; release 1.2
> soon. :-)
(inc (fetch void))
--
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 modera
On Apr 6, 6:23 pm, Stuart Halloway wrote:
> Have you seen destructuring of rest args in the current master branch?
>
> (defn foo [& {:keys [a b c]}] [a b c])
>
> (foo :a 1 :c 3)
> => [1 nil 3]
... that's beautiful.
I hereby cast my vote into the void: release often; release 1.2
soon. :-)
--
> Just curious
> - what folks think of fixed-positional-keyword params
> - whether it was considered for Clojure
It's difficult to image that keyword params will be considered in
languages where they aren't folklore, as they are in Smalltalk,
Objective-C, and Self. Unlike Smtalltalk and Self,
The runtime cost of destructuring is not worth getting worked up
about. It's easy to check this yourself with (time ...)
David
On Wednesday, April 7, 2010, Sophie wrote:
> On Apr 6, 7:03 pm, ataggart wrote:
>> See:
>>
>> http://richhickey.github.com/clojure-contrib/def-api.html#clojure.con...
>
I think defnk is deprecated by the new feature mentioned by Stuart.
As far as I remember, positional arguments in defnk do not allow to be
used either prefixed by their name, either without, so I guess defnk
didn't solve your problem definition.
2010/4/7 Sophie :
> On Apr 6, 7:03 pm, ataggart wro
On Apr 6, 7:03 pm, ataggart wrote:
> See:
>
> http://richhickey.github.com/clojure-contrib/def-api.html#clojure.con...
Ah, thank you (all).
Will this be in 1.2? Is run-time cost expected to be minor, and will
passing unrecognized keys be an error?
--
You received this message because you are s
See:
http://richhickey.github.com/clojure-contrib/def-api.html#clojure.contrib.def/defnk
On Apr 6, 2:25 pm, Sophie wrote:
> Please don't misunderstand this post - it is not asking for a change
> of syntax, just trying to understand something.
>
> Clojure has chosen positional parameters (just li
On Apr 6, 2010, at 6:08 PM, Sophie wrote:
> Don't you think
> - fixed-order named parameters
> could (should?) be a separate issue from
> - optional, any-order, named parameters
> ?
I don't see the advantage of fixed-order named parameters over keyword
parameters. Note that you can require cer
Don't you think
- fixed-order named parameters
could (should?) be a separate issue from
- optional, any-order, named parameters
?
;; :x :y are fixed order, named, while :a :b are optional, named
(defn foo [:x :y & {:keys [a b]] [x, y, a, b])
(foo :x 1 :y 2)
=> [1 2 nil nil]
(foo :x 1 :a 2)
=
On Apr 6, 5:23 pm, Stuart Halloway wrote:
> Have you seen destructuring of rest args in the current master branch?
>
> (defn foo [& {:keys [a b c]}] [a b c])
>
> (foo :a 1 :c 3)
> => [1 nil 3]
>
> With this last bit of sugar in place I am extremely happy with
> Clojure's arg handling.
Hmmm. Loo
On Apr 6, 4:46 pm, Jarkko Oranen wrote:
> problem is that they also make some very common functional patterns
> cumbersome: most notably function application (ie. apply),
> composition, and higher-order functions.
I don't think it should be either-or (and positional would be needed
anyway to call
Have you seen destructuring of rest args in the current master branch?
(defn foo [& {:keys [a b c]}] [a b c])
(foo :a 1 :c 3)
=> [1 nil 3]
With this last bit of sugar in place I am extremely happy with
Clojure's arg handling.
Please don't misunderstand this post - it is not asking for a ch
On Apr 7, 12:25 am, Sophie wrote:
> Just curious
> - what folks think of fixed-positional-keyword params
> - whether it was considered for Clojure
I don't know for certain whether Rich ever considered smalltalk-style
parameters, but I doubt it.
I do like them, though; in Objective-C and Sma
Please don't misunderstand this post - it is not asking for a change
of syntax, just trying to understand something.
Clojure has chosen positional parameters (just like for Lisp, C, C++,
Java, Ruby, Python, Prolog, ...)
Smalltalk composes a full method name from a prefix-name + named
parameters.
21 matches
Mail list logo
