Re: lib integrated into clojure namespace
Hi, May I be the first to say: Thanks Steve and Rich! This is a great addition and really helps tie up the loose ends in the stuff I am currently working on--I didn't want to reimplement anything that I knew was coming into the language. Cheers, /mike. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: lib integrated into clojure namespace
On Aug 28, 2008, at 7:40 PM, Rich Hickey wrote: > I'm pleased to announce that Stephen C. Gilardi's lib code has been > integrated into the clojure namespace and is included in boot.clj, > as of SVN rev 1009. > > This means that use, require, and load-resources are now available > by default. That's great news, Rich. Thanks very much! > There is also a new macro, ns, which should be the preferred way to > use in-ns/import/use/require: I like what you've done with clojure/ns -- tying a lot of often-used functions neatly into one concise and powerful call. Nicely done! > Many thanks to Steve for his tireless work in defining and refining > lib, a very useful contribution! You're quite welcome! Working with Clojure makes it feel more like tireless fun. :-) Thanks! --Steve --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: updating nested structure
On Aug 28, 11:43 am, Parth Malwankar <[EMAIL PROTECTED]>
wrote:
> On Aug 28, 8:08 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Aug 27, 10:37 pm, Parth Malwankar <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > > > I posted a variant here:
>
> > > >http://paste.lisp.org/display/65964
>
> > > Rich,
>
> > > It works very nicely. Thanks.
>
> > > Just one thought in case the functions args are still being
> > > decided on. Could we consider taking access path as a
> > > vector rather than directly as function args.
>
> > > Here is the use case I have in mind.
>
> > > I think most access paths [:a :b :c] would be generated.
> > > Nested structures would be something like
>
> > > processor -> GPRs (general purpose regs) -> r0 r1 .. rN
> > > -> FPRs (floating point regs) -> f0 f1 .. fN
>
> > > fridge -> fruits -> apple mango ...
> > >-> veggies -> eggplant ...
> > >-> diary -> milk yoghurt ...
>
> > > So the developer may set up something like a
> > > (fridge-item-path (get-fruit)) => [:fruits :apple]
> > > (processor-reg-path (get-reg-arg-from-instruction)) => [:gpr-set :r0]
>
> > > With the current arg handling this is what we would need to do:
>
> > > user=> (item-path :mango)
> > > [:fruits :mango]
>
> > > user=> (apply mk-get my-fridge (conj (item-path :mango) :quantity))
> > > 30
>
> > > user=> (apply mk-assoc my-fridge (conj (item-path :mango) :quantity
> > > 40))
> > > {:fruits {:mango {:quantity 40, :color :yellow},
> > > :apple {:quantity 20, :color :red}},
> > > :diary-products {:milk {:quantity 1, :color :white,
> > > :type :low-fat},
> > >:yoghurt {:quantity 10, :color :pink,
> > > :type :strawberry}}}
>
> > > [formatting added above for readability]
>
> > > In case the access path were vectors the above could become:
>
> > > (mk-get my-fridge (item-path :mango) :quantity)
> > > (mk-assoc my-fridge (item-path :mango) :quantity new-quantity)
>
> > > Much less noise.
>
> > I don't see this (partial path + separate last key) as a general way
> > of doing things. The only other way I would consider is the entire
> > path as a sequence:
>
> > (defn mk-get [m ks]
> > (reduce get m ks))
>
> > (defn mk-assoc [m [k & ks] v]
> > (if ks
> > (assoc m k (mk-assoc (get m k) ks v))
> > (assoc m k v)))
>
> > ;usage
> > (def nx {:a {:b {:c {:content [1 10] :other 2)
>
> > (mk-get nx [:a :b :c :content])
> > -> [1 10]
>
> > (mk-assoc nx [:a :b :c :content 0] 42)
> > -> {:a {:b {:c {:other 2, :content [42 10]
>
> > (mk-assoc {} [:a :b :x] 42)
> > -> {:a {:b {:x 42}}}
>
> Thanks Rich.
> Sounds like a good idea to me. Works beautifully.
>
> user=> (load-file "fruits.clj")
> #'user/my-fridge
> user=> (mk-get my-fridge (item-quantity-path :mango))
> 30
> user=> (mk-assoc my-fridge (item-quantity-path :mango) 50)
> {:fruits {:mango {:quantity 50, :color :yellow}, :apple {:quantity
> 20, :color :red}}, :diary-products {:yoghurt {:quantity
> 10, :color :pink, :type :strawberry}, :milk {:quantity
> 1, :color :white, :type :low-fat}}}
> user=>
>
I've added get-in, assoc-in, and update-in to SVN rev 1010.
Rich
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
lib integrated into clojure namespace
I'm pleased to announce that Stephen C. Gilardi's lib code has been integrated into the clojure namespace and is included in boot.clj, as of SVN rev 1009. This means that use, require, and load-resources are now available by default. There is also a new macro, ns, which should be the preferred way to use in-ns/import/use/require: clojure/ns ([name & references]) Macro Sets *ns* to the namespace named by name (unevaluated), creating it if needed. If the ns didn't already exist, refers the clojure namespace. references can be zero or more of: (:requires ...) (:uses ...) (:imports ...) with the syntax of require/use/import respectively, except the arguments are unevaluated and need not be quoted. Use of ns is preferred to individual calls to in-ns/require/use/import: (ns foo (:requires [clojure.parallel :as par]) (:uses clojure.inspector) (:imports (java.util Date Timer Random) (java.sql Connection Statement))) load-resources should be preferred to load-file, and works relative to the classpath/namespace. Loading code from the classpath will become important for debugging. Note that ns automatically refers clojure unless the namespace already exists. To control/avoid the refer to clojure, create the ns first: (create-ns 'bar) (ns bar) ;no clojure names in bar Along the way, I also added Steve's format and printf, and added a new macro, defonce, which will define a var, but initialize it only the first time. This is especially useful for vars that hold data which you do not want to lose when you reload the file in order to get new/ fixed function defs. (defonce baz 42) (defonce baz 43) baz -> 42 There are extensive docs on the vars, so (doc require) etc. Many thanks to Steve for his tireless work in defining and refining lib, a very useful contribution! Rich --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: updating nested structure
On Aug 28, 8:08 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Aug 27, 10:37 pm, Parth Malwankar <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > > I posted a variant here:
>
> > >http://paste.lisp.org/display/65964
>
> > Rich,
>
> > It works very nicely. Thanks.
>
> > Just one thought in case the functions args are still being
> > decided on. Could we consider taking access path as a
> > vector rather than directly as function args.
>
> > Here is the use case I have in mind.
>
> > I think most access paths [:a :b :c] would be generated.
> > Nested structures would be something like
>
> > processor -> GPRs (general purpose regs) -> r0 r1 .. rN
> > -> FPRs (floating point regs) -> f0 f1 .. fN
>
> > fridge -> fruits -> apple mango ...
> > -> veggies -> eggplant ...
> > -> diary -> milk yoghurt ...
>
> > So the developer may set up something like a
> > (fridge-item-path (get-fruit)) => [:fruits :apple]
> > (processor-reg-path (get-reg-arg-from-instruction)) => [:gpr-set :r0]
>
> > With the current arg handling this is what we would need to do:
>
> > user=> (item-path :mango)
> > [:fruits :mango]
>
> > user=> (apply mk-get my-fridge (conj (item-path :mango) :quantity))
> > 30
>
> > user=> (apply mk-assoc my-fridge (conj (item-path :mango) :quantity
> > 40))
> > {:fruits {:mango {:quantity 40, :color :yellow},
> > :apple {:quantity 20, :color :red}},
> > :diary-products {:milk {:quantity 1, :color :white,
> > :type :low-fat},
> > :yoghurt {:quantity 10, :color :pink,
> > :type :strawberry}}}
>
> > [formatting added above for readability]
>
> > In case the access path were vectors the above could become:
>
> > (mk-get my-fridge (item-path :mango) :quantity)
> > (mk-assoc my-fridge (item-path :mango) :quantity new-quantity)
>
> > Much less noise.
>
> I don't see this (partial path + separate last key) as a general way
> of doing things. The only other way I would consider is the entire
> path as a sequence:
>
> (defn mk-get [m ks]
> (reduce get m ks))
>
> (defn mk-assoc [m [k & ks] v]
> (if ks
> (assoc m k (mk-assoc (get m k) ks v))
> (assoc m k v)))
>
> ;usage
> (def nx {:a {:b {:c {:content [1 10] :other 2)
>
> (mk-get nx [:a :b :c :content])
> -> [1 10]
>
> (mk-assoc nx [:a :b :c :content 0] 42)
> -> {:a {:b {:c {:other 2, :content [42 10]
>
> (mk-assoc {} [:a :b :x] 42)
> -> {:a {:b {:x 42}}}
>
Thanks Rich.
Sounds like a good idea to me. Works beautifully.
user=> (load-file "fruits.clj")
#'user/my-fridge
user=> (mk-get my-fridge (item-quantity-path :mango))
30
user=> (mk-assoc my-fridge (item-quantity-path :mango) 50)
{:fruits {:mango {:quantity 50, :color :yellow}, :apple {:quantity
20, :color :red}}, :diary-products {:yoghurt {:quantity
10, :color :pink, :type :strawberry}, :milk {:quantity
1, :color :white, :type :low-fat}}}
user=>
Parth
> Rich
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: updating nested structure
On Aug 27, 10:37 pm, Parth Malwankar <[EMAIL PROTECTED]>
wrote:
> On Aug 28, 12:10 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > I posted a variant here:
>
> >http://paste.lisp.org/display/65964
>
> Rich,
>
> It works very nicely. Thanks.
>
> Just one thought in case the functions args are still being
> decided on. Could we consider taking access path as a
> vector rather than directly as function args.
>
> Here is the use case I have in mind.
>
> I think most access paths [:a :b :c] would be generated.
> Nested structures would be something like
>
> processor -> GPRs (general purpose regs) -> r0 r1 .. rN
> -> FPRs (floating point regs) -> f0 f1 .. fN
>
> fridge -> fruits -> apple mango ...
>-> veggies -> eggplant ...
>-> diary -> milk yoghurt ...
>
> So the developer may set up something like a
> (fridge-item-path (get-fruit)) => [:fruits :apple]
> (processor-reg-path (get-reg-arg-from-instruction)) => [:gpr-set :r0]
>
> With the current arg handling this is what we would need to do:
>
> user=> (item-path :mango)
> [:fruits :mango]
>
> user=> (apply mk-get my-fridge (conj (item-path :mango) :quantity))
> 30
>
> user=> (apply mk-assoc my-fridge (conj (item-path :mango) :quantity
> 40))
> {:fruits {:mango {:quantity 40, :color :yellow},
> :apple {:quantity 20, :color :red}},
> :diary-products {:milk {:quantity 1, :color :white,
> :type :low-fat},
>:yoghurt {:quantity 10, :color :pink,
> :type :strawberry}}}
>
> [formatting added above for readability]
>
> In case the access path were vectors the above could become:
>
> (mk-get my-fridge (item-path :mango) :quantity)
> (mk-assoc my-fridge (item-path :mango) :quantity new-quantity)
>
> Much less noise.
>
I don't see this (partial path + separate last key) as a general way
of doing things. The only other way I would consider is the entire
path as a sequence:
(defn mk-get [m ks]
(reduce get m ks))
(defn mk-assoc [m [k & ks] v]
(if ks
(assoc m k (mk-assoc (get m k) ks v))
(assoc m k v)))
;usage
(def nx {:a {:b {:c {:content [1 10] :other 2)
(mk-get nx [:a :b :c :content])
-> [1 10]
(mk-assoc nx [:a :b :c :content 0] 42)
-> {:a {:b {:c {:other 2, :content [42 10]
(mk-assoc {} [:a :b :x] 42)
-> {:a {:b {:x 42}}}
Rich
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: updating nested structure
On Thu, Aug 28, 2008 at 2:01 AM, Parth Malwankar
<[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 8:13 am, Chouser <[EMAIL PROTECTED]> wrote:
>>
>> (apply mk-get my-fridge (item-path :mango) :quantity)
>
> I get an error with this.
>
> user=> (item-path :mango)
> [:fruits :mango]
> user=> (apply mk-get my-fridge (item-path :mango) :quantity)
> java.lang.IllegalArgumentException: Don't know how to create ISeq
> from: Keyword : :quantity
I'm sorry -- remind me not to post untested code after my bedtime.
You're right, that won't work. Apply does allow you to provide
non-seq arguments followed by the single seq at the end. This is what
I was thinking about:
user=> (apply + 1 2 3 [4 5 6])
21
But the apply expression I wrote above has a seq that you want to
expand early in the list, and non-seq at the end. As you already
discovered, that just throws an exception.
So let me start over -- you want a function that takes a mix of keys
and vectors of keys, right? You could of course wrap the ones Rich
provided for your own use cases. For example if you always have one
vector followed by one plain key, you could do:
user=> (defn mk-get-1 [m v k] (apply mk-get m (concat v [k])))
#'user/mk-get-1
user=> (mk-get-1 my-fridge (item-path :mango) :quantity)
10
Or if you want to allow any kind of mixed vectors, seqs, and plain keys:
user=> (defn mk-get-2 [m & a] (apply mk-get m (mapcat #(if (or
(vector? %) (seq? %)) % [%]) a)))
#'user/mk-get-2
user=> (mk-get-2 my-fridge (item-path :mango) :quantity)
10
user=> (mk-get-2 my-fridge :fruits [:mango :quantity])
10
user=> (mk-get-2 my-fridge :fruits (list :mango :quantity))
10
user=> (mk-get-2 my-fridge :fruits [:mango] :quantity)
10
Neither of these strike me as very general. I don't have my own use
cases (yet) for these functions, so I shouldn't speak too confidently,
but mk-get-1 seems like a pretty specific case (exactly one vector
followed by exactly one plain key). And since vectors are perfectly
valid map keys, it's possible to build nested maps that can't be
accessed using mk-get-2:
user=> (mk-get {[:a :b] :c} [:a :b])
:c
user=> (mk-get-2 {[:a :b] :c} [:a :b])
nil
--Chouser
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: gen-class for jar file
Thanks! On Wed, Aug 27, 2008 at 2:22 PM, Craig McDaniel <[EMAIL PROTECTED]> wrote: > > The "Hello Servlet" post from yesterday does that. > > On Aug 27, 4:56 pm, "Kevin Downey" <[EMAIL PROTECTED]> wrote: >> I am interested in using the gen-class related stuff to generate a >> class file to load and run my clojure code from a jar file. Does >> anyone have any example code for this they can share? >> >> -- >> The Mafia way is that we pursue larger goals under the guise of >> personal relationships. >> Fisheye > > > -- The Mafia way is that we pursue larger goals under the guise of personal relationships. Fisheye --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
