On Wed, Jul 13, 2011 at 10:33 AM, Andrea Tortorella wrote:
> I'm not an expert in macros, and maybe this is a stupid question but i
> think there should be a general pattern for this.
>
> I' ve a function:
>
> (defn choose* [f & choices]
> "Applies f to one of the choices"
> . .)
>
> And
(defmacro choose [[c choices] & body]
`(choose* (fn [~c] ~@body) ~choices)) <--- not ~@, just ~
~@ expects a sequence result
In your first example, [:a :b :c] is a sequence but in the second example, y is
not.
body is a sequence (& body), using ~@ there is ok there.
Luc P.
On Wed, 13 Jul 201
That'll do - Thank you both.
Tim
On Jul 13, 8:12 pm, Luc Prefontaine
wrote:
> By string I mean human readable...
>
> On Wed, 13 Jul 2011 21:56:58 -0400
>
>
>
>
>
>
>
>
>
> Luc Prefontaine wrote:
> > # is a string representation of
> > the fn object, not the object itself.
>
> > user=> (def a get
I'm not an expert in macros, and maybe this is a stupid question but i
think there should be a general pattern for this.
I' ve a function:
(defn choose* [f & choices]
"Applies f to one of the choices"
. .)
And this macro:
(defmacro choose [[c choices] & body]
`(choose* (fn [~c] ~@bod
The listing is nice...maybe would be nice to be able to limit the listing to
one artifact, or a match of artifacts with wildcards, not sure if the
feature would be used enough to justify the work though, but something like:
lein localrepo list "*ring*"
would output:
[ring]
ring-core (0.2.0, 0.
By string I mean human readable...
On Wed, 13 Jul 2011 21:56:58 -0400
Luc Prefontaine wrote:
> # is a string representation of
> the fn object, not the object itself.
>
> user=> (def a get)
> #'user/a
> user=> (meta a)
> {:ns #, :name get, :file
> "clojure/core.clj", :line 1154, :arglists ([map
On Wed, Jul 13, 2011 at 9:35 PM, Tim Robinson wrote:
> I know I can get the meta data using the following form:
>
> => (meta #'get)
> {:ns #, :name get, :file "clojure/
> core.clj"
>
> Is there a means to get the meta data from the stored function without
> using its identifier?
>
> ie. knowin
# is a string representation of the fn
object, not the object
itself.
user=> (def a get)
#'user/a
user=> (meta a)
{:ns #, :name get, :file "clojure/core.clj", :line
1154, :arglists ([map key] [map key not-found]), :added "1.0", :inline-arities
#{2 3}, :inline #, :doc
"Returns the value mapped
On Wed, Jul 13, 2011 at 7:49 PM, Mike Meyer wrote:
> On Tue, 12 Jul 2011 22:21:39 -0400
> Ken Wesson wrote:
>> >> Which means it's not really case 4 at all.
>> >
>> > Well, it's very clearly not cases 1, 2 or 3.
>>
>> No, it's case zero: standard multi-developer, multi-computer, single
>> canonic
I know I can get the meta data using the following form:
=> (meta #'get)
{:ns #, :name get, :file "clojure/
core.clj"
Is there a means to get the meta data from the stored function without
using its identifier?
ie. knowing this result:
=> get
#
Can I somehow do this:
=>(meta #)
java.lang.
On Wed, Jul 13, 2011 at 6:25 PM, Chas Emerick wrote:
>> True. Look at the results - the top five big wins are:
>> * Functional programming
>> * Platform (JVM) compatibility / interop
>> * The REPL
>> * Immutability
>>
> My phrasing may very well have gotten in the way. "Big wins" isn't exactly
>
On Jul 13, 2011, at 8:37 PM, Sean Corfield wrote:
> On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg wrote:
>> Or it could just be that some of the other things on that list were so
>> compelling that they overshadowed these.
>>
>> * The REPL
>> * Functional Programming
>> * Ease of development
That looks very interesting Dave - can you give a bit more information
on what sorts of things you can actually do once you have a REPL
connected? (in terms of how to access / explore things inside the
running Java application)
On Wed, Jul 13, 2011 at 4:06 PM, David Powell wrote:
> I wrote a tool
On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg wrote:
> Or it could just be that some of the other things on that list were so
> compelling that they overshadowed these.
>
> * The REPL
> * Functional Programming
> * Ease of development
True. Look at the results - the top five big wins are:
* Fu
On Wed, Jul 13, 2011 at 3:52 AM, Albert Cardona wrote:
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.
Well, those features are all in Clojure 1.2.0 so nothing is preventing
you using them.
That said, so far I haven't had much
We use 1.2 in prod with protocols... no need to wait for 1.3
Luc P.
On Wed, 13 Jul 2011 06:52:01 -0400
Albert Cardona wrote:
> Chas,
>
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and t
On Jul 13, 2011, at 6:03 AM, Ambrose Bonnaire-Sergeant wrote:
> I've found that (some of) Clojure's advanced features are best taught in
> terms of simpler ideas
> that most programmers would be familiar with.
+1
-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
On Tue, 12 Jul 2011 22:21:39 -0400
Ken Wesson wrote:
> >> Which means it's not really case 4 at all.
> >
> > Well, it's very clearly not cases 1, 2 or 3.
>
> No, it's case zero: standard multi-developer, multi-computer, single
> canonical master copy on one computer/cluster somewhere. The thing
>
I wrote a tool called liverepl a while ago:
https://github.com/djpowell/liverepl
It effectively lets you get a repl into a Java or Clojure process, but it
has the nice feature that it works with any Java processes without requiring
any modifications to the code. It uses the Java Attach API, whic
This is great !!!
But you should posting it in a blog and compare it with other
solutions.
On Jul 12, 2:31 am, Asim Jalis wrote:
> I have been using the Clojure REPL to debug a large Java server app.
> It's great for exploratory testing and for validating assumptions
> about how the system works.
Am glad it worked for you. I have updated the plugin to version 0.2
with "list" functionality. Will appreciate any feedback/suggestion.
https://github.com/kumarshantanu/lein-localrepo
Regards,
Shantanu
On Jul 12, 6:40 pm, Mark Rathwell wrote:
> Works great, Shantanu. Thanks!
>
> On Tue, Jul 12
On Wed, Jul 13, 2011 at 5:17 PM, Sam Ritchie wrote:
> Ken, that'll result in the original vector back out again.
> (vec (take 3 (cycle [1 2 3]))) => [1 2 3].
> I think you mean:
> (vec (take (* n (count xs)) (cycle xs
I wasn't using "n" to mean the number of repetitions of the xs but the
tota
Ken, that'll result in the original vector back out again.
(vec (take 3 (cycle [1 2 3]))) => [1 2 3].
I think you mean:
(vec (take (* n (count xs)) (cycle xs
On Wed, Jul 13, 2011 at 5:13 PM, Ken Wesson wrote:
> On Wed, Jul 13, 2011 at 11:21 AM, Bhinderwala, Shoeb
> wrote:
> > Thanks Tamr
On Wed, Jul 13, 2011 at 11:21 AM, Bhinderwala, Shoeb
wrote:
> Thanks Tamreen. Your solution will have to be wrapped in another vec call. I
> will use Miekel’s:
>
>
>
> (reduce into [] (repeat n xs)).
What about (vec (take n (cycle xs)))?
--
Protege: What is this seething mass of parentheses?
On Wed, Jul 13, 2011 at 2:41 PM, Phil Hagelberg wrote:
> Albert Cardona writes:
>
>> "It seems that relatively few people are taking advantage of some of
>> Clojure’s most sophisticated and unique features: metadata; protocols,
>> records, and types; and multimethods. These facilities are absolu
On Wed, Jul 13, 2011 at 1:37 PM, Raoul Duke wrote:
> On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson wrote:
>> Oh, I'm not saying my own is exploding -- just that macros can be
>> tough for some people to get their heads around, and monads even more
>> so, so combining the two ...
>
> maybe call them
Albert Cardona writes:
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods. These facilities are absolutely
> game-changers, at least IMO. Either most domains have
Indeed, all of these features were introduced in 1.2.0. Metadata has been
around since (roughly) the beginning.
It's true that metadata being available only for "Clojure types" (those that
implement clojure.lang.IObj) is unfortunate — but I wouldn't say that that's
reason to consider the mecha
On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson wrote:
> Oh, I'm not saying my own is exploding -- just that macros can be
> tough for some people to get their heads around, and monads even more
> so, so combining the two ...
maybe call them something else and it won't be so bad. when people see
the
I do think a simple String error message is all that the user of the
function should provide. From there, An AssertionError can throw up
something along the lines of what you said - Expected… , Found… , Message.
That would give enough information for reporting at least in a test
framework. To get m
Thanks Tamreen. Your solution will have to be wrapped in another vec
call. I will use Miekel's:
(reduce into [] (repeat n xs)).
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On
Behalf Of Tamreen Khan
Sent: Wednesday, July 13, 2011 11:0
Damn, Meikel's solution is better, I was thinking:
(apply concat (repeat n xs))
On Wed, Jul 13, 2011 at 10:54 AM, Bhinderwala, Shoeb <
sabhinderw...@wellington.com> wrote:
> **
>
> I have to write a function that will take a vector as input, repeat the
> elements multiple times and return back a
Hi,
you could use (reduce into [] (repeat n xs)).
Sincerely
Meikel
--
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
I have to write a function that will take a vector as input, repeat the
elements multiple times and return back a single vector of the repeated
items. I came up with the following but am wondering if there is a
better or simpler way to write this:
(def xs ["a" "b" "c"])
(defn repeat-vec-n
[xs
> At what point in time it realises the elements is mood in the end
Yes. Probably the whole point of (finite) lazy seqs is some sort of side
effect. Be it memory consumption, processing time, or other forms of
side-effect. But, shouldn't map, filter, reduce and others, with its
lazy-friendly be
Hi,
Am Mittwoch, 13. Juli 2011 16:15:28 UTC+2 schrieb Sebastián Galkin:
>
> > Making assumptions between the order of realization of seq elements and
> calls to the reducing functions seems crazy to me, really.
>
> May be, but it's not as much about the order as about the laziness. New
> reduce
> Making assumptions between the order of realization of seq elements and
calls to the reducing functions seems crazy to me, really.
May be, but it's not as much about the order as about the laziness. New
reduce is less lazy than previous, and maybe unnecessarily so. If you think
of a collecti
2011/7/13 Sebastián Galkin
> Oh I see it now, the call is inverted in 1.2.1 core.clj. Thanks, it was
> driving me crazy.
>
> Regarding Meikel comment on clojure-dev
>
> > I will open a ticket to either apply the shown fix, or modify the
> contract of reduce to require pureness of f.
>
> I think t
Oh I see it now, the call is inverted in 1.2.1 core.clj. Thanks, it was
driving me crazy.
Regarding Meikel comment on clojure-dev
> I will open a ticket to either apply the shown fix, or modify the contract
of reduce to require pureness of f.
I think that changing reduce contract, such a basic
On Jul 13, 1:16 am, Christian Marks <9fv...@gmail.com> wrote:
> Thank you. Based on this I've simplified the code further.
You could combine the test for a cycle leader
with the cycle length count--but your original
code, which calculates cycle lengths only if
a cycle leader is identified, is mo
I think for me at least leveraging the polymorphism that the seq
abstraction provides gets you such a long way compared to collection
libs in other languages that you don't have to reach for the other
features as quickly.
I think Rich even stated that as one of the reasons for delaying their
introd
On Wed, Jul 13, 2011 at 7:19 AM, Konrad Hinsen
wrote:
> On 13 Jul 2011, at 05:04, Ken Wesson wrote:
>
>>> One approach that has been proposed to improve composability of macros is
>>> to
>>> adopt a continuation-passing style. This would make macros a candidate
>>> for
>>> the continuation monad,
Hi,
On Wed, Jul 13, 2011 at 7:57 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:
>
> multimethods - since close to every mention of multimethods also involves
> telling how slow they are, these are most often shunned.
>
>
I don't get that impression. MM's seem to be pushed as a "first c
All those are available in 1.2, or am I missing something?
>From my own experience:
metadata, when I started to learn clojure, I thought "this is awesome". When
I realized that metadata only applies to clojure types, it felt unreliable
and I never got to using it.
protocols & records/types - they
On 13 Jul 2011, at 05:04, Ken Wesson wrote:
One approach that has been proposed to improve composability of
macros is to
adopt a continuation-passing style. This would make macros a
candidate for
the continuation monad, so perhaps monads may be of use in
implementing
complex macros.
That
I've found that (some of) Clojure's advanced features are best taught in
terms of simpler ideas
that most programmers would be familiar with.
For example, excuse the plug, I motivated multimethods by relating them to
simple conditionals
like "case". I think I succeeded in making MMs just look like
Chas,
"It seems that relatively few people are taking advantage of some of
Clojure’s most sophisticated and unique features: metadata; protocols,
records, and types; and multimethods. These facilities are absolutely
game-changers, at least IMO. Either most domains have no use for them
(I can’t b
Hi,
Am Mittwoch, 13. Juli 2011 11:02:40 UTC+2 schrieb bsmith.occs:
>
> On Wed, Jul 13, 2011 at 08:43, Meikel Brandmeyer wrote:
> > Hi,
> >
> > I think the culprit is here:
> >
> https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L6
On Wed, Jul 13, 2011 at 08:43, Meikel Brandmeyer wrote:
> Hi,
>
> I think the culprit is here:
> https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64
>
> The line "(recur cls (next s) f (f val (first s)))" must be written as
>
> (l
On 12 Jul 2011, at 23:18, Alan Malloy wrote:
On Jul 12, 12:01 pm, Konrad Hinsen wrote:
The composability issue with macros lies in writing them, not using
them.
Strongly disagree. Macros compose reasonably well when writing them
(eg, using let in the implementation of with-open is trivial);
50 matches
Mail list logo
