Re: Inheriting from IDeref - good idea or bad practise?
On Feb 8, 3:22 am, Stuart Halloway wrote: > IMO Anything that implements IDeref should adhere to Clojure's vision > for identity, e.g. reads need to be thread safe, cheap, require no > coordination, and block no one. Dereferencing futures or undelivered promises block the dereferencing thread though, so potentially blocking derefs should not be a problem. With side-effects in the deref operation, you would have to ensure that it's safe from multiple threads, though. -- 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: Clojure for system administration
On Feb 5, 12:33 am, Stuart Sierra wrote: > Clojure can certainly do these things; clojure-contrib contains many > file and io-related utilities. But remember that Clojure, like any > Java program, takes more time to start up than "scripting" languages > like Perl/Bash/Ruby/Python, so it may be less suitable for programs > that you intend to run at the command-line. Scripting languages also have very easy access to launch/use other utilities. What I did find clojure useful for back when I had time to look at it (a year ago), was presentation of data. For example, I had one script that scanned the maillog and made charts (Using Jfreechart) of sent/ received/rejected emails, another took patch data from all our servers and gave a historical view of how many servers were patched/unpatched/ had missing data. This is things where there is no advantage to scripting languages, and availability of java libraries is an advantage. -- -asbjxrn -- 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
groovy builders equivalent
Hello, Did anybody create a functionally equivalent clojure version of so-called Groovy Builders ? ( http://groovy.codehaus.org/Builders ) Not that it should be too difficult to come up with an equivalent, and also not that it would seem to you that it is interesting to do so given the power of clojure, but ... ... a friend of mine is investigating into groovy because he wants to leverage groovy builders power (does not want to write his application in groovy, just the builders parts). ... so I said to him: take a look at clojure, it really shines at mixing data and code, has very good support for writing data structure literals, and with the power of its macro system, you have unlimited power to customize a DSL. But he replied: * there is a lower cost for me to quickly get what I need: expressive builder expressions in a langage (groovy) that I can grasp very quickly And I also thought for myself: * power is good, but it would not be easy for my friend to *quickly* get the same as groovy builders provide, *because* they provide a "framework" which guides him. So, again, did anybody write something *functionally* similar to groovy builders already ? I would see such project a good way to have more java users become familiar to clojure "at a low cost", hopefully making them the switch less costly at firt. Cheers, -- Laurent -- 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: groovy builders equivalent
And I've found groovy builders not so well documented, very "magical" (as in "dark magic") where I think this should not be that way. So there is even room to make this simpler for the users, I guess, by correctly implementing a somewhat "verbose" purely functional (and macros-free) DSL, from whom anybody could understand how builders work, *and then* implement syntactic sugar over it via macros. 2010/2/8 Laurent PETIT : > Hello, > > Did anybody create a functionally equivalent clojure version of > so-called Groovy Builders ? > ( http://groovy.codehaus.org/Builders ) > > Not that it should be too difficult to come up with an equivalent, and > also not that it would seem to you that it is interesting to do so > given the power of clojure, but ... > > ... a friend of mine is investigating into groovy because he wants to > leverage groovy builders power (does not want to write his application > in groovy, just the builders parts). > > ... so I said to him: take a look at clojure, it really shines at > mixing data and code, has very good support for writing data structure > literals, and with the power of its macro system, you have unlimited > power to customize a DSL. > > But he replied: > * there is a lower cost for me to quickly get what I need: expressive > builder expressions in a langage (groovy) that I can grasp very > quickly > > And I also thought for myself: > * power is good, but it would not be easy for my friend to *quickly* > get the same as groovy builders provide, *because* they provide a > "framework" which guides him. > > > So, again, did anybody write something *functionally* similar to > groovy builders already ? > > I would see such project a good way to have more java users become > familiar to clojure "at a low cost", hopefully making them the switch > less costly at firt. > > Cheers, > > -- > Laurent > -- 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
Removing (gensym) in macro
Hi, just for practicing Clojure's macros I wrote the following create-java-list macro. (defmacro create-java-list [& forms] (let [prefixfn (fn [obj form] (cons (symbol ".") (cons obj form))) lname (gensym)] `(let [~lname (java.util.ArrayList.)] ~@(map (partial prefixfn lname) forms) ~lname))) The idea is that you can write (let [javalist (create-java-list (add "1") (add "2"))] (prn javalist)) instead of (let [javalist (java.util.ArrayList.)] (.add javalist "1") (.add javalist "2") (prn javalist)) Is it possible to create the macro without the (gensym) call? I wasn't able to use something like lname#. Cheers, Roman -- 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: Removing (gensym) in macro
Hi, On Feb 8, 11:45 am, Roman Roelofsen wrote: > just for practicing Clojure's macros I wrote the following > create-java-list macro. > > (defmacro create-java-list > [& forms] > (let [prefixfn (fn [obj form] (cons (symbol ".") (cons obj form))) > lname (gensym)] > `(let [~lname (java.util.ArrayList.)] > ~@(map (partial prefixfn lname) forms) > ~lname))) > > The idea is that you can write > > (let [javalist (create-java-list > (add "1") > (add "2"))] > (prn javalist)) > > instead of > > (let [javalist (java.util.ArrayList.)] > (.add javalist "1") > (.add javalist "2") > (prn javalist)) > > Is it possible to create the macro without the (gensym) call? I wasn't > able to use something like lname#. You can use ->. (defmacro create-java-list [& forms] (let [predot (fn [form] (cons (symbol ".") form))] `(let [lname# (java.util.ArrayList.)] (-> lname# ~@(map predot forms) which is maybe better written as (let [jl (-> (java.util.ArrayList.) (.add "1") (.add "2"))] (prn jl)) I don't see a compelling reason for such a macro. At least not in this simple case. 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 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: Removing (gensym) in macro
On 8 February 2010 12:45, Roman Roelofsen wrote: > Hi, > > just for practicing Clojure's macros I wrote the following > create-java-list macro. > > (defmacro create-java-list > [& forms] > (let [prefixfn (fn [obj form] (cons (symbol ".") (cons obj form))) > lname (gensym)] > `(let [~lname (java.util.ArrayList.)] > ~@(map (partial prefixfn lname) forms) > ~lname))) > > The idea is that you can write > > (let [javalist (create-java-list > (add "1") > (add "2"))] > (prn javalist)) > > instead of > > (let [javalist (java.util.ArrayList.)] > (.add javalist "1") > (.add javalist "2") > (prn javalist)) Try this: user=> (doto (java.util.ArrayList.) (.add "1") (.add "2")) # > Is it possible to create the macro without the (gensym) call? I wasn't > able to use something like lname#. Sorry, I'm not sure why that doesn't work. -- Michael Wood -- 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: Removing (gensym) in macro
Hi, On Feb 8, 12:14 pm, Michael Wood wrote: > user=> (doto (java.util.ArrayList.) > (.add "1") > (.add "2")) > # Oops. Yes. You need doto instead of ->. Sorry, my mistake. > > Is it possible to create the macro without the (gensym) call? I wasn't > > able to use something like lname#. > > Sorry, I'm not sure why that doesn't work. It doesn't work because the scope of lname# is limited to the `(). However lname is used in a ~@() which leaves the `() and enters the enclosing environment (in this case the macros). There the lname# is not valid. 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 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: Removing (gensym) in macro
> I don't see a compelling reason for such a macro. At least not in this > simple case. I agree. As I said, the purpose of this macro was purely for learning and understanding macros ;-) -- 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: Removing (gensym) in macro
> It doesn't work because the scope of lname# is limited to the `(). > However lname is used in a ~@() which leaves the `() and enters the > enclosing environment (in this case the macros). There the lname# is > not valid. Ah, that makes sense, thanks! Is using (gensym) the common solution here? So far I thought that (gensym) is more a internal function that I normally never need to call directly. -- 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: Parallel version of list comprehension
Do you have a specific example, some code you could paste? On Feb 7, 11:53 pm, Tim Snyder wrote: > Is there a straight-forward way to get parallelization when using list > comprehension? > The form of "for" syntax is much preferable to the closest I could > come up with using pmap. I also was having trouble getting the > correct level of nesting down when using pmap, though probably because > I'm tired. > > If there's nothing like a "pfor", is there a way to algorithmically > convert a list comp. into some nested pmaps? -- 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: groovy builders equivalent
On Mon, Feb 8, 2010 at 5:29 AM, Laurent PETIT wrote: > Hello, > > Did anybody create a functionally equivalent clojure version of > so-called Groovy Builders ? > ( http://groovy.codehaus.org/Builders ) > > Not that it should be too difficult to come up with an equivalent, and > also not that it would seem to you that it is interesting to do so > given the power of clojure, but ... > > ... a friend of mine is investigating into groovy because he wants to > leverage groovy builders power (does not want to write his application > in groovy, just the builders parts). > > ... so I said to him: take a look at clojure, it really shines at > mixing data and code, has very good support for writing data structure > literals, and with the power of its macro system, you have unlimited > power to customize a DSL. > > But he replied: > * there is a lower cost for me to quickly get what I need: expressive > builder expressions in a langage (groovy) that I can grasp very > quickly > > And I also thought for myself: > * power is good, but it would not be easy for my friend to *quickly* > get the same as groovy builders provide, *because* they provide a > "framework" which guides him. > > > So, again, did anybody write something *functionally* similar to > groovy builders already ? > > I would see such project a good way to have more java users become > familiar to clojure "at a low cost", hopefully making them the switch > less costly at firt. People choose languages for a project (myself included) for some of the oddest reasons sometimes... But it's interesting you mention builders -- I hadn't heard the term until reading a section Fogus wrote for our book. I guess I can't link to it here quite yet, but in essence he walks you through how to use normal Clojure literal map syntax in place of fluent builders. This of course requires essentially no framework code at all, either to support builders in general or for any specific application's builder needs. So perhaps what your friend needs is just an example or description of how to proceed in Clojure, not actually any library code at all. --Chouser http://joyofclojure.com/ -- 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: Removing (gensym) in macro
Hi, On Feb 8, 2:06 pm, Roman Roelofsen wrote: > Ah, that makes sense, thanks! Is using (gensym) the common solution > here? So far I thought that (gensym) is more a internal function that > I normally never need to call directly. In such a case using gensym is the normal solution. When you don't have the "escape" situation, using # is prefered since it removes the need for a surrounding let just containing gensym's. 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 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: Removing (gensym) in macro
2010/2/8 Meikel Brandmeyer : > Hi, > > On Feb 8, 2:06 pm, Roman Roelofsen > wrote: > >> Ah, that makes sense, thanks! Is using (gensym) the common solution >> here? So far I thought that (gensym) is more a internal function that >> I normally never need to call directly. > > In such a case using gensym is the normal solution. When you don't > have the "escape" situation, using # is prefered since it removes the > need for a surrounding let just containing gensym's. There's also just another (rather uncommon ?) situation when one would want to avoid using trailing #: if one wants to create bunchs of code in a loop, where one wants to generate different syms everytime. This does not work since sdfsdf# is generated once and for all at read-time, and not everytime the code will be executed. Example: user=> (map (fn [k] `(println k foo#)) [:a :b :c]) ((clojure.core/println user/k foo__6__auto__) (clojure.core/println user/k foo__6__auto__) (clojure.core/println user/k foo__6__auto__)) user=> (map (fn [k] (let [foo (gensym "foo")] `(println k ~foo))) [:a :b :c]) ((clojure.core/println user/k foo11) (clojure.core/println user/k foo12) (clojure.core/println user/k foo13)) HTH, -- Laurent -- 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
Clojure talk TODAY (Feb 8) Paris, France 19:00
Just a last minute reminder ... I'll be presenting "Clojure: Towards the Essence of Programming" on Monday Feb 8th at 19:00, in Paris. The event will be held at Zenika, SkillsMatter's partner in France. You must register for the talk ahead of time. http://skillsmatter.com/event/java-jee/clojure-towards-the-essence-of-programming I'm really excited about this talk; I've had a chance to "preview" it at CodeMash, and have used the feedback to make it even stronger. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- 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: groovy builders equivalent
2010/2/8 Chouser :
> On Mon, Feb 8, 2010 at 5:29 AM, Laurent PETIT wrote:
>> Hello,
>>
>> Did anybody create a functionally equivalent clojure version of
>> so-called Groovy Builders ?
>> ( http://groovy.codehaus.org/Builders )
>>
>> Not that it should be too difficult to come up with an equivalent, and
>> also not that it would seem to you that it is interesting to do so
>> given the power of clojure, but ...
>>
>> ... a friend of mine is investigating into groovy because he wants to
>> leverage groovy builders power (does not want to write his application
>> in groovy, just the builders parts).
>>
>> ... so I said to him: take a look at clojure, it really shines at
>> mixing data and code, has very good support for writing data structure
>> literals, and with the power of its macro system, you have unlimited
>> power to customize a DSL.
>>
>> But he replied:
>> * there is a lower cost for me to quickly get what I need: expressive
>> builder expressions in a langage (groovy) that I can grasp very
>> quickly
>>
>> And I also thought for myself:
>> * power is good, but it would not be easy for my friend to *quickly*
>> get the same as groovy builders provide, *because* they provide a
>> "framework" which guides him.
>>
>>
>> So, again, did anybody write something *functionally* similar to
>> groovy builders already ?
>>
>> I would see such project a good way to have more java users become
>> familiar to clojure "at a low cost", hopefully making them the switch
>> less costly at firt.
>
> People choose languages for a project (myself included) for some
> of the oddest reasons sometimes...
>
> But it's interesting you mention builders -- I hadn't heard the
> term until reading a section Fogus wrote for our book. I guess
> I can't link to it here quite yet, but in essence he walks you
> through how to use normal Clojure literal map syntax in place of
> fluent builders. This of course requires essentially no
> framework code at all, either to support builders in general or
> for any specific application's builder needs.
>
> So perhaps what your friend needs is just an example or
> description of how to proceed in Clojure, not actually any
> library code at all.
That's what I also thought first. And then I came to carefully look at
what Groovy builders are, and I think there may be more than just
"showing people how to do builders in clojure" (although for the
common cases having an article explaining that would certainly be
invaluable for newcomers).
Unless I'm thinking wrong, with plain function calls in clojure, you
presuppose that the construction of the final product is done as
persistent datastructures are built: from bottom to top.
With groovy builder, though, there is no such "hard-wired"
presupposition: the build functions are passed closures, and they call
the closure whenever they want, thus allowing the children to be
constructed before or after the parent (a lot of real-world builders
for java frameworks which use mutable datastructures require the
clients to be passed a reference to the parent).
Thus the "generic" builder framework offered by Groovy builders resembles this:
(make-foo-node nil {:prop1 val1 :prop2 val2 ... } (fn
make-foo-node-children [parent-instance] (make-bar-node
parent-instance {:prop3 val3 ...} (fn make-bar-node-children ...)) ;
I'm certainly missing parameters here
and not this:
(make-node-type-foo {:prop1 val1 :prop2 val2 ...} [
(make-node-type-bar ...) (make-node-type-bar ...) ])
So the groovy version hard-wires some convention over the signatures
of the "makers" methods, how things written in the DSL look like (good
when jumping from one project to another, "recognizable pattern" - at
least for common things).
I guess those things are important to make the barrier entry "low
enough" for people which do not feel "at home" with lisps yet.
OH YES, I also thing we could achieve an even more "type safe" version
than groovy builders, since I guess a lot of stuff is done at runtime
by groovy builders (especially reflection for setting java bean
properties from literal maps, finding the right method to call by
examining the method name in a generic unknown method handler) ... so
by leveraging the power of clojure macros, one could potentially mix
the beauty of synctactically elegant DSLs with compiler checks by
doing the reflection stuff at macro-compile time (and then get
feedback on "no such field exception" at compile time !! ! ! )
If nobody did too much investigation into "encapsulating" some common
pattern into a little lib of its own, maybe I'll investigate a little
bit in this area, to see by practice if it's interesting or not.
--
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
Re: Clojure talk TODAY (Feb 8) Paris, France 19:00
I wish I could be present ! I wish you the best, regards, -- Laurent 2010/2/8 Howard Lewis Ship : > Just a last minute reminder ... > > I'll be presenting "Clojure: Towards the Essence of Programming" on > Monday Feb 8th at 19:00, in Paris. The event will be held at Zenika, > SkillsMatter's partner in France. You must register for the talk ahead > of time. > > http://skillsmatter.com/event/java-jee/clojure-towards-the-essence-of-programming > > I'm really excited about this talk; I've had a chance to "preview" it > at CodeMash, and have used the feedback to make it even stronger. > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > -- > 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: groovy builders equivalent
Perhaps I have an incomplete grasp of the problem domain, but wouldn't
a map stored in a ref let you do this?
On Feb 8, 9:12 am, Laurent PETIT wrote:
> 2010/2/8 Chouser :
>
>
>
> > On Mon, Feb 8, 2010 at 5:29 AM, Laurent PETIT
> > wrote:
> >> Hello,
>
> >> Did anybody create a functionally equivalent clojure version of
> >> so-called Groovy Builders ?
> >> (http://groovy.codehaus.org/Builders)
>
> >> Not that it should be too difficult to come up with an equivalent, and
> >> also not that it would seem to you that it is interesting to do so
> >> given the power of clojure, but ...
>
> >> ... a friend of mine is investigating into groovy because he wants to
> >> leverage groovy builders power (does not want to write his application
> >> in groovy, just the builders parts).
>
> >> ... so I said to him: take a look at clojure, it really shines at
> >> mixing data and code, has very good support for writing data structure
> >> literals, and with the power of its macro system, you have unlimited
> >> power to customize a DSL.
>
> >> But he replied:
> >> * there is a lower cost for me to quickly get what I need: expressive
> >> builder expressions in a langage (groovy) that I can grasp very
> >> quickly
>
> >> And I also thought for myself:
> >> * power is good, but it would not be easy for my friend to *quickly*
> >> get the same as groovy builders provide, *because* they provide a
> >> "framework" which guides him.
>
> >> So, again, did anybody write something *functionally* similar to
> >> groovy builders already ?
>
> >> I would see such project a good way to have more java users become
> >> familiar to clojure "at a low cost", hopefully making them the switch
> >> less costly at firt.
>
> > People choose languages for a project (myself included) for some
> > of the oddest reasons sometimes...
>
> > But it's interesting you mention builders -- I hadn't heard the
> > term until reading a section Fogus wrote for our book. I guess
> > I can't link to it here quite yet, but in essence he walks you
> > through how to use normal Clojure literal map syntax in place of
> > fluent builders. This of course requires essentially no
> > framework code at all, either to support builders in general or
> > for any specific application's builder needs.
>
> > So perhaps what your friend needs is just an example or
> > description of how to proceed in Clojure, not actually any
> > library code at all.
>
> That's what I also thought first. And then I came to carefully look at
> what Groovy builders are, and I think there may be more than just
> "showing people how to do builders in clojure" (although for the
> common cases having an article explaining that would certainly be
> invaluable for newcomers).
>
> Unless I'm thinking wrong, with plain function calls in clojure, you
> presuppose that the construction of the final product is done as
> persistent datastructures are built: from bottom to top.
> With groovy builder, though, there is no such "hard-wired"
> presupposition: the build functions are passed closures, and they call
> the closure whenever they want, thus allowing the children to be
> constructed before or after the parent (a lot of real-world builders
> for java frameworks which use mutable datastructures require the
> clients to be passed a reference to the parent).
>
> Thus the "generic" builder framework offered by Groovy builders resembles
> this:
>
> (make-foo-node nil {:prop1 val1 :prop2 val2 ... } (fn
> make-foo-node-children [parent-instance] (make-bar-node
> parent-instance {:prop3 val3 ...} (fn make-bar-node-children ...)) ;
> I'm certainly missing parameters here
>
> and not this:
> (make-node-type-foo {:prop1 val1 :prop2 val2 ...} [
> (make-node-type-bar ...) (make-node-type-bar ...) ])
>
> So the groovy version hard-wires some convention over the signatures
> of the "makers" methods, how things written in the DSL look like (good
> when jumping from one project to another, "recognizable pattern" - at
> least for common things).
> I guess those things are important to make the barrier entry "low
> enough" for people which do not feel "at home" with lisps yet.
>
> OH YES, I also thing we could achieve an even more "type safe" version
> than groovy builders, since I guess a lot of stuff is done at runtime
> by groovy builders (especially reflection for setting java bean
> properties from literal maps, finding the right method to call by
> examining the method name in a generic unknown method handler) ... so
> by leveraging the power of clojure macros, one could potentially mix
> the beauty of synctactically elegant DSLs with compiler checks by
> doing the reflection stuff at macro-compile time (and then get
> feedback on "no such field exception" at compile time !! ! ! )
>
> If nobody did too much investigation into "encapsulating" some common
> pattern into a little lib of its own, maybe I'll investigate a little
> bit in this area, to see by practice if it's interesting or not.
--
You receive
Re: groovy builders equivalent
2010/2/8 Sean Devlin :
> Perhaps I have an incomplete grasp of the problem domain, but wouldn't
> a map stored in a ref let you do this?
I don't understand.
>
> On Feb 8, 9:12 am, Laurent PETIT wrote:
>> 2010/2/8 Chouser :
>>
>>
>>
>> > On Mon, Feb 8, 2010 at 5:29 AM, Laurent PETIT
>> > wrote:
>> >> Hello,
>>
>> >> Did anybody create a functionally equivalent clojure version of
>> >> so-called Groovy Builders ?
>> >> (http://groovy.codehaus.org/Builders)
>>
>> >> Not that it should be too difficult to come up with an equivalent, and
>> >> also not that it would seem to you that it is interesting to do so
>> >> given the power of clojure, but ...
>>
>> >> ... a friend of mine is investigating into groovy because he wants to
>> >> leverage groovy builders power (does not want to write his application
>> >> in groovy, just the builders parts).
>>
>> >> ... so I said to him: take a look at clojure, it really shines at
>> >> mixing data and code, has very good support for writing data structure
>> >> literals, and with the power of its macro system, you have unlimited
>> >> power to customize a DSL.
>>
>> >> But he replied:
>> >> * there is a lower cost for me to quickly get what I need: expressive
>> >> builder expressions in a langage (groovy) that I can grasp very
>> >> quickly
>>
>> >> And I also thought for myself:
>> >> * power is good, but it would not be easy for my friend to *quickly*
>> >> get the same as groovy builders provide, *because* they provide a
>> >> "framework" which guides him.
>>
>> >> So, again, did anybody write something *functionally* similar to
>> >> groovy builders already ?
>>
>> >> I would see such project a good way to have more java users become
>> >> familiar to clojure "at a low cost", hopefully making them the switch
>> >> less costly at firt.
>>
>> > People choose languages for a project (myself included) for some
>> > of the oddest reasons sometimes...
>>
>> > But it's interesting you mention builders -- I hadn't heard the
>> > term until reading a section Fogus wrote for our book. I guess
>> > I can't link to it here quite yet, but in essence he walks you
>> > through how to use normal Clojure literal map syntax in place of
>> > fluent builders. This of course requires essentially no
>> > framework code at all, either to support builders in general or
>> > for any specific application's builder needs.
>>
>> > So perhaps what your friend needs is just an example or
>> > description of how to proceed in Clojure, not actually any
>> > library code at all.
>>
>> That's what I also thought first. And then I came to carefully look at
>> what Groovy builders are, and I think there may be more than just
>> "showing people how to do builders in clojure" (although for the
>> common cases having an article explaining that would certainly be
>> invaluable for newcomers).
>>
>> Unless I'm thinking wrong, with plain function calls in clojure, you
>> presuppose that the construction of the final product is done as
>> persistent datastructures are built: from bottom to top.
>> With groovy builder, though, there is no such "hard-wired"
>> presupposition: the build functions are passed closures, and they call
>> the closure whenever they want, thus allowing the children to be
>> constructed before or after the parent (a lot of real-world builders
>> for java frameworks which use mutable datastructures require the
>> clients to be passed a reference to the parent).
>>
>> Thus the "generic" builder framework offered by Groovy builders resembles
>> this:
>>
>> (make-foo-node nil {:prop1 val1 :prop2 val2 ... } (fn
>> make-foo-node-children [parent-instance] (make-bar-node
>> parent-instance {:prop3 val3 ...} (fn make-bar-node-children ...)) ;
>> I'm certainly missing parameters here
>>
>> and not this:
>> (make-node-type-foo {:prop1 val1 :prop2 val2 ...} [
>> (make-node-type-bar ...) (make-node-type-bar ...) ])
>>
>> So the groovy version hard-wires some convention over the signatures
>> of the "makers" methods, how things written in the DSL look like (good
>> when jumping from one project to another, "recognizable pattern" - at
>> least for common things).
>> I guess those things are important to make the barrier entry "low
>> enough" for people which do not feel "at home" with lisps yet.
>>
>> OH YES, I also thing we could achieve an even more "type safe" version
>> than groovy builders, since I guess a lot of stuff is done at runtime
>> by groovy builders (especially reflection for setting java bean
>> properties from literal maps, finding the right method to call by
>> examining the method name in a generic unknown method handler) ... so
>> by leveraging the power of clojure macros, one could potentially mix
>> the beauty of synctactically elegant DSLs with compiler checks by
>> doing the reflection stuff at macro-compile time (and then get
>> feedback on "no such field exception" at compile time !! ! ! )
>>
>> If nobody did too much investigation into "encapsulating" some common
Re: Parallel version of list comprehension
Sure, I was going to add it last night, but brain had shut down for the night. The program I'm working on is a Communicating Sequential Processes toolbox, so you can write a process and collect the traces (along with other tools that simplify expressions and such). I've written a traces function that should return a lazy sequence of all the possible traces for a process. A process is actually a tree composed of c.c.types abstract data types, it can't do anything on its own. The event-set function returns a set of events in which the process can engage. The proc function takes one step forward in the process, based on the event passed. You can think of it more abstractly as getting a collection of values that are currently applicable, applying each value to the current state and in return getting a list of all the possible future values that could be applied down to a certain depth... like look-ahead in a game or puzzle solver. Each step back up through the call stack tacks the applied value onto the head of each of the lists of possible future steps. (defn traces [process depth] (if (zero? depth) [nil] (for [e (event-set process) t (traces (proc process e) (dec depth))] (cons e t I was playing around with nested pmap calls last night but I always got one extra layer of nesting for each depth I went. Any help is much appreciated, Tim On Feb 8, 8:22 am, Sean Devlin wrote: > Do you have a specific example, some code you could paste? > > On Feb 7, 11:53 pm, Tim Snyder wrote: > > > > > Is there a straight-forward way to get parallelization when using list > > comprehension? > > The form of "for" syntax is much preferable to the closest I could > > come up with using pmap. I also was having trouble getting the > > correct level of nesting down when using pmap, though probably because > > I'm tired. > > > If there's nothing like a "pfor", is there a way to algorithmically > > convert a list comp. into some nested pmaps? -- 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
scope of binding
Hi, I have a question about the scope of "binding" of a var. Let's say I have the following var: (def *v* 1) And I define a function that uses it: (defn f [n] (+ *v* n)) "binding" behaves as expected, establishing a thread-local binding to a new value in its scope: user=> (binding [*v* 2] (f 1)) 3 But if I pass it to "map", I expected it to pick up the new value, but it does not. user=> (binding [*v* 2] (map f [1 1 1])) (2 2 2) The output should be "(3 3 3)" if I understand it correctly. Where am I wrong? -- 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: Clojure talk TODAY (Feb 8) Paris, France 19:00
The talk will be in English or French? On Mon, Feb 8, 2010 at 2:13 PM, Laurent PETIT wrote: > I wish I could be present ! > > I wish you the best, > > regards, > > -- > Laurent > > 2010/2/8 Howard Lewis Ship : > > Just a last minute reminder ... > > > > I'll be presenting "Clojure: Towards the Essence of Programming" on > > Monday Feb 8th at 19:00, in Paris. The event will be held at Zenika, > > SkillsMatter's partner in France. You must register for the talk ahead > > of time. > > > > > http://skillsmatter.com/event/java-jee/clojure-towards-the-essence-of-programming > > > > I'm really excited about this talk; I've had a chance to "preview" it > > at CodeMash, and have used the feedback to make it even stronger. > > > > -- > > Howard M. Lewis Ship > > > > Creator of Apache Tapestry > > > > The source for Tapestry training, mentoring and support. Contact me to > > learn how I can get you up and productive in Tapestry fast! > > > > (971) 678-5210 > > http://howardlewisship.com > > > > -- > > 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: scope of binding
The problem is that map returns a lazy seq, and the lazy seq is evaluated outside of the binding by the REPL. If you add a doall inside the binding, it behaves as you expect. user=> (binding [*v* 2] (doall (map f [1 1 1]))) (3 3 3) Sean On Feb 8, 5:47 am, Alex wrote: > Hi, > > I have a question about the scope of "binding" of a var. > > Let's say I have the following var: > > (def *v* 1) > > And I define a function that uses it: > > (defn f [n] (+ *v* n)) > > "binding" behaves as expected, establishing a thread-local binding to > a new value in its scope: > > user=> (binding [*v* 2] (f 1)) > 3 > > But if I pass it to "map", I expected it to pick up the new value, but > it does not. > > user=> (binding [*v* 2] (map f [1 1 1])) > (2 2 2) > > The output should be "(3 3 3)" if I understand it correctly. Where am I wrong? -- 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: Inheriting from IDeref - good idea or bad practise?
James Reeves writes: > Would those more knowledgable about Clojure care to weigh in on > whether it be a good idea to create a custom class inheriting from > IDeref? That's how promise is implemented, but that's supposed to be an internal detail. -- Steven E. Harris -- 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: Inheriting from IDeref - good idea or bad practise?
I've got no clue, so I would just do the experiment. If it works out
well, tell us why. If it's a disaster, tell us what didn't work.
Sean
On Feb 7, 3:57 pm, James Reeves wrote:
> Hi folks,
>
> Would those more knowledgable about Clojure care to weigh in on
> whether it be a good idea to create a custom class inheriting from
> IDeref? I've been considering creating session proxy objects (to be
> later replaced with protocols) that would respond to deref calls, e.g.
>
> (def session
> (proxy [IDeref] []
> (deref [this]
> (read-session (.store this)))
> (store [this]
> {:type ::memory-store})))
>
> Is this a good idea, or is it considered bad practice to use IDeref in
> anything apart from core Clojure concurrently primitives?
>
> - James
--
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
Please share your thoughts on dependency injection
Hello all,
I am playing with the idea of a little library for dependency injection.
The idea is to declare injectable values as metadata-to-function map.
I started with a sketch of what the client code may look like.
Please let me know what you think.
Thank you,
Boris
Dependency declaration code:
;; -
;; declare lookup functions
(def-inject
#^{:type String :name "password"} password-lookup-fn
#^{:a 1 :b 2} a1-b2-lookup-fn
)
;; utility wrapper functions that allow for caching, lazy
initializations etc ...
(def-inject
#^{:type JDBC :kind "mysql"} (lazy (once-per-thread mysql-connect))
#^{:type JDBC :kind "oracle"} (lazy (once-per-thread oracle-connect)))
Client code:
;;-
;; a function that has access to password, foo and bar in it's lexical scope
;; dependencies are bound when the function is called
(inject
#^{:name "password" } password
#^{:a 1 :b 2} foo
#^{:type t2 :p1 v1 :p2 v2} bar
(defn fn-with-foo-bar-injected. ))
;; overriding injected values - e.g. for unit testing
(inject-bind
foo foo-val
bar bar-val
(fn-with-foo-bar-injected . ))
;; injecting a value inline
;; the name foo is provided for inject-bind
(defn . (... (inject #^{:type t :param1 v1 :param2 v2} foo) ...) ...)
;; local scope injections - works like let
(inject #^{:type t :param1 v1 :param2 v2} foo (...code that can use foo...))
--
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: Prepping clojure for packaging (was: Re: Clojure for system administration)
On 07.02.2010, at 03:25, Constantine Vetoshev wrote: > I stopped using Python and Ruby and Perl partly because the packaging > situation for all those languages is a horrible mess. For example, if I agree. It's not just packaging, even providing sufficiently general installation scripts is a difficult task. Even with the help of tools like autoconf, figuring out what is installed and what needs to be added is far from trivial. Add to this the unfortunate but undeniable existence of incorrect or incomplete software installations on many machines. It's a real pain. I distribute a couple of scientific computing software packages, mostly written in Python but all with some C code in them and some external dependencies. A large part of technical support questions is about installation problems. > In short, I think that the Java and Clojure way of packaging software > make life much easier for programmers, package maintainers, and > administrators, not harder. Making applications self-contained helps I have no experience with this yet, but one reason for looking into the JVM has been the hope for a simpler deployment scheme. Konrad. -- 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: Clojure talk TODAY (Feb 8) Paris, France 19:00
On 08.02.2010, at 15:10, Howard Lewis Ship wrote: > Just a last minute reminder ... > > I'll be presenting "Clojure: Towards the Essence of Programming" on > Monday Feb 8th at 19:00, in Paris. The event will be held at Zenika, If I had known this earlier, I might have been able to come :-( Konrad. -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
>> In short, I think that the Java and Clojure way of packaging software >> make life much easier for programmers, package maintainers, and >> administrators, not harder. Making applications self-contained helps > > I have no experience with this yet, but one reason for looking into the JVM > has been the hope for a simpler deployment scheme. Back in the day I used to write Java code, and indeed the concept of an "uber-jar" file made things nice, but if I remember correctly jar files cannot contain native code dependencies (I could be mistaken, let me know). That was the only area where distribution is a pain with Java, damned native libraries. - Greg On Feb 8, 2010, at 11:02 AM, Konrad Hinsen wrote: > On 07.02.2010, at 03:25, Constantine Vetoshev wrote: > >> I stopped using Python and Ruby and Perl partly because the packaging >> situation for all those languages is a horrible mess. For example, if > > I agree. It's not just packaging, even providing sufficiently general > installation scripts is a difficult task. Even with the help of tools like > autoconf, figuring out what is installed and what needs to be added is far > from trivial. Add to this the unfortunate but undeniable existence of > incorrect or incomplete software installations on many machines. It's a real > pain. I distribute a couple of scientific computing software packages, mostly > written in Python but all with some C code in them and some external > dependencies. A large part of technical support questions is about > installation problems. > >> In short, I think that the Java and Clojure way of packaging software >> make life much easier for programmers, package maintainers, and >> administrators, not harder. Making applications self-contained helps > > I have no experience with this yet, but one reason for looking into the JVM > has been the hope for a simpler deployment scheme. > > Konrad. > > -- > 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: return value of use, requires?
On Sat, Feb 6, 2010 at 2:08 AM, Timothy Pratley wrote: > Good point, I've updated the ticket patch to check options are valid > also, so the behavior is now: that is very cool, thank you! -- 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: scope of binding
You can also capture the binding. This looks a little ugly, but it works: it grabs the binding eagerly, and returns a closure that dynamically binds it when the function is invoked. (binding [*v* 2] (map (let [v *v*] (fn [n] (binding [*v* v] (f n [1 1 1])) Obviously you wouldn't use it in this instance -- use doall, or better yet rewrite your function to not use dynamic bindings -- but for larger jobs it works fine. -- 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
error reporting for macro expansion
The Clojure compiler is not very helpful when it comes to debugging exceptions that occur while macros are being expanded. As an example, consider this code: ;; macro-fail.clj (defmacro broken [] (/ 0 0)) (broken) Here's the stack trace I get when I compile this file: Exception in thread "main" java.lang.ArithmeticException: Divide by zero (macro-fail.clj:0) at clojure.lang.Compiler.eval(Compiler.java:5365) at clojure.lang.Compiler.load(Compiler.java:5759) at clojure.lang.Compiler.loadFile(Compiler.java:5722) at clojure.main$load_script__5893.invoke(main.clj:213) at clojure.main$script_opt__5922.invoke(main.clj:265) at clojure.main$main__5940.doInvoke(main.clj:346) at clojure.lang.RestFn.invoke(RestFn.java:409) at clojure.lang.Var.invoke(Var.java:365) at clojure.lang.AFn.applyToHelper(AFn.java:165) at clojure.lang.Var.applyTo(Var.java:482) at clojure.main.main(main.java:37) Caused by: java.lang.ArithmeticException: Divide by zero at clojure.lang.Numbers.divide(Numbers.java:138) at user$broken__1.invoke(macro-fail.clj:2) at clojure.lang.Var.invoke(Var.java:369) at clojure.lang.AFn.applyToHelper(AFn.java:167) at clojure.lang.Var.applyTo(Var.java:482) at clojure.lang.Compiler.macroexpand1(Compiler.java:5212) at clojure.lang.Compiler.macroexpand(Compiler.java:5267) at clojure.lang.Compiler.eval(Compiler.java:5335) ... 10 more As you can see, line 3, where the macro is used, appears nowhere in the stack trace. I've made some progress addressing this issue by adding an exception handler in Compiler.macroexpand1. I also discovered that, although the reader attaches line numbers to the forms it reads, it does not attach file names. I've added some code in LispReader.java that attaches the file name, but it does so by getting the value of Compiler.SOURCE_PATH. I suspect a less hackish fix would involve passing a filename to the reader some other way. -- 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: error reporting for macro expansion
On 8 February 2010 20:11, John R. Williams wrote: > ;; macro-fail.clj > (defmacro broken [] (/ 0 0)) > (broken) > [ ... ] > As you can see, line 3, where the macro is used, appears nowhere in > the stack trace. That's because execution never reaches this point, because the (/ 0 0) bit gets executed at macro expansion time. You'd have to syntax-quote it to fail at runtime: (defmacro broken [] `(/ 0 0)) (A regular quote would probably also do.) Also, note the user$broken ... line in your stack trace -- it does contain a useful indication of the source of the problem. Sincerely, Michał -- 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
Implicit style streams in Clojure
What is the Clojure best practice, if there is one, for writing a function like this: (defn integral [integrand initial-value dt] (def --integral (cons initial-value (lazy-seq (add-streams (scale- streams integrand dt) --integral --integral) integrand is a stream of values. I don't like the fact that --integral is visible outside of the integral function but I don't know how else to implement this efficiently. I am using -- here as a naming convention to identify vars that are defined within other functions. Also, what is general feeling about defs inside of functions? Brenton -- 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: Implicit style streams in Clojure
Use let: (defn foo [...] (let [helper (fn [...] ...)] (helper ...))) or letfn: (defn foo [...] (letfn [(helper [...] ...)] (helper ...))) The latter allows you to introduce mutually recursive functions. Sincerely, Michał -- 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: Implicit style streams in Clojure
don't use def inside functions, ever. in scheme define is lexically scoped, so you do that sort of thing. clojure is not scheme. if you want a lexically scoped function use a lexical scoping construct like let or letfn. On Mon, Feb 8, 2010 at 12:12 PM, Brenton wrote: > What is the Clojure best practice, if there is one, for writing a > function like this: > > > (defn integral [integrand initial-value dt] > (def --integral (cons initial-value > (lazy-seq (add-streams (scale- > streams integrand dt) > > --integral > --integral) > > > integrand is a stream of values. > > I don't like the fact that --integral is visible outside of the > integral function but I don't know how else to implement this > efficiently. I am using -- here as a naming convention to identify > vars that are defined within other functions. > > Also, what is general feeling about defs inside of functions? > > Brenton > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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: Implicit style streams in Clojure
letfn is exactly what I was looking for. Thank you. On Feb 8, 12:15 pm, Michał Marczyk wrote: > Use let: > > (defn foo [...] > (let [helper (fn [...] ...)] > (helper ...))) > > or letfn: > > (defn foo [...] > (letfn [(helper [...] ...)] > (helper ...))) > > The latter allows you to introduce mutually recursive functions. > > Sincerely, > Michał -- 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: Clojure talk TODAY (Feb 8) Paris, France 19:00
I've posted it at least once on this list! On Mon, Feb 8, 2010 at 9:35 AM, Konrad Hinsen wrote: > On 08.02.2010, at 15:10, Howard Lewis Ship wrote: > >> Just a last minute reminder ... >> >> I'll be presenting "Clojure: Towards the Essence of Programming" on >> Monday Feb 8th at 19:00, in Paris. The event will be held at Zenika, > > If I had known this earlier, I might have been able to come :-( > > Konrad. > > -- > 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 -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- 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
clojure pathnames library
Hi. Is there any clojure third-party library functionally similar to python's os.path? Using java.io.File is not so convenient as os.path. Regards Vadim Shender -- 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
Trait-like behavior with Protocols
Is it possible to have default implementations associated with functions in a protocol? This is most useful when some protocol functions are defined in terms of other. For instance, (defprotocol Span (start [self]) (stop [self]) (span-length [self])) Now I know I can just make span-length a function on Span as opposed to part of the protocol. Is that what one should do? -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
On 5 February 2010 18:47, Peter Schuller wrote: >> I've been wondering about this. The classpath issue seems like a >> major thorn in the side of the JVM, especially for Clojure and other > > It seems to be that there are two problems here. > > One problem is that there needs to be a convention for a clojure > "binary" that works consistently across platforms. I maintain the > clojure port in the FreeBSD port collection, and I install an > appropriate wrapper script such that you can in fact do: > > clojure myscript.clj > > And have it "just work" without further ado. > > This is something that I think needs to be made more consistent; > probably by having the clojure distribution ship with such a script > that works on all POSIX shells, and making it clear to packagers that > it is intended to be the standard way of invoking clojure. This is my biggest issue with Clojure, and something I spend far more time than I should handling. Clojure as a language is beautiful, terse and simple, yet I find managing the VM arguments and classpath tedious, and a real barrier to hacking in the language. Especially as Clojure adds the REPL as an additional environment to run code in. I have high hopes for Leiningen helping to tackle this issue, but it's by not quite there yet. I'd love for the clojure community to settle on a standard method of starting Clojure programs, repl's and swank-servers (with classpath and VM settings configured by a file). IMHO Ruby (and probably python) do this better than Clojure, though I'm not sure if we'll ever be able to find a solution we can all agree on. > The other issue is that of picking up libraries. Here scripting > languages like ruby/python/etc have a well-defined convention for > doing this, where you have certain system paths that are intended to > contain modules. The exact path will vary with platform (for example > as a function of whether you use pycentral, are on debian, freebsd, > redhat, etc). I personally don't put so much weight on this issue. In my experience when it comes to things like ruby, people only tend to install ruby,irb and rubygems from their package manager, and rely on using rubygems to get their packages. As the distro's tend to be very out of date when it comes to keeping these packages up to date, so I've found it's almost always better to gem install them. I also second the fears about having a system wide classpath. They're brittle and very error prone. R. -- 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: Trait-like behavior with Protocols
On Feb 8, 6:13 pm, aria42 wrote: > (defprotocol Span > (start [self]) > (stop [self]) > (span-length [self])) > > Now I know I can just make span-length a function on Span as opposed > to part of the protocol. Is that what one should do? Yes. -SS -- 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: clojure pathnames library
Look at clojure-contrib. In the 1.1 release, use duck-streams and java-utils. In the latest github sources, it's all in clojure.contrib.io. -SS On Feb 8, 5:43 pm, Vadim Shender wrote: > Hi. > > Is there any clojure third-party library functionally similar to python's > os.path? Using java.io.File is not so convenient as os.path. > > Regards > Vadim Shender -- 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
Detecting Number of Available CPU Threads
I'm wondering if there's anyway in Clojure, that one can detect the number of available processoring threads (ie. 4 core cpu with hyperthreading would equal 8 available threads). This will allow me to have a scalable processing app which can run on a single core CPU, or 250 core processor, without overwhelming the single core CPU with 250 threads (as an example). Cheers -- 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: Detecting Number of Available CPU Threads
On 9 February 2010 11:29, Wardrop wrote: > I'm wondering if there's anyway in Clojure, that one can detect the > number of available processoring threads (.availableProcessors (Runtime/getRuntime)) might be what you are after? -- 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: Detecting Number of Available CPU Threads
That seems like what I'm after, thanks. I assume this would be pretty reliable across all platforms running the JVM. By the way, I did google the Java API with various keywords but never cam across this object property. Thanks On Feb 9, 11:33 am, Timothy Pratley wrote: > On 9 February 2010 11:29, Wardrop wrote: > > > I'm wondering if there's anyway in Clojure, that one can detect the > > number of available processoring threads > > (.availableProcessors (Runtime/getRuntime)) might be what you are after? -- 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: Trait-like behavior with Protocols
On Feb 8, 2010, at 6:13 PM, aria42 wrote: > Is it possible to have default implementations associated with > functions in a protocol? This is most useful when some protocol > functions are defined in terms of other. For instance, > > (defprotocol Span > (start [self]) > (stop [self]) > (span-length [self])) > > Now I know I can just make span-length a function on Span as opposed > to part of the protocol. Is that what one should do? Can you show me what this looks like? Thanks, Dan -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
> > IMHO Ruby (and probably python) do this better than Clojure, though > I'm not sure if we'll ever be able to find a solution we can all agree > on. > Groovy has a very decent solution to the classpath issue for scripts. Details can be found at http://groovy.codehaus.org/Grape . It might be worthwhile for someone to investigate implementing something similar for Clojure. > I also second the fears about having a system wide classpath. They're > brittle and very error prone. > I third those fears... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
Hi, maybe I don't understand the problem. Why can't the system provide some kind of local repository? The package system (deb, rpm, ports, whatever) just installs the dependencies there. A wrapper script reads in the dependencies and adds them to the classpath on program start. Nothing is downloaded. There might be several versions of a library installed. No global classpath. I think that's what maven/ivy do right now. Why wouldn't this work together with a packaging system? (I think FreeBSD shows the way to go: cooperation between the system and the language.) 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 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: Trait-like behavior with Protocols
Hi,
On Feb 9, 12:13 am, aria42 wrote:
> Is it possible to have default implementations associated with
> functions in a protocol? This is most useful when some protocol
> functions are defined in terms of other. For instance,
>
> (defprotocol Span
> (start [self])
> (stop [self])
> (span-length [self]))
>
> Now I know I can just make span-length a function on Span as opposed
> to part of the protocol. Is that what one should do?
The last time I checked, it was my understanding the mix-ins are used
for this.
(defprotocol Thing (abc []) (xyz []))
(def AThing {:abc (fn [] ...) :xyz (fn [] )})
(deftype Banana ...)
(extend Thing Banana (merge AThing {:abc (fn []...)}))
This would effectively use the "default" implementation of xyz and
provide a custom one for xyz.
But I'm not up-to-date with the protocol stuff.
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 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
