Re: defrecord with "inheritance"
> > Have you actually looked at the data structure implementations in > ClojureScript? The work is done. It's all protocols. > Hi David, I just have. This is a nice work. There is a lot of repetitions though. For example: - IEquiv (-equiv [coll other] (equiv-sequential coll other)) - IHash (-hash [coll] (caching-hash coll hash-coll __hash)) (where caching-hash has to be a macro) - ICounted (-count [coll] count) - ILookup (-lookup [coll k] (-nth coll k nil)) (-lookup [coll k not-found] (-nth coll k not-found)) All these appears multiple times in the file, each time for the same underlying reason. Each occurance is a missed opportunity for code reuse. (There must be other repetitions, that just those I found in a 2 minutes search) Add 4 more types of Vectors and you will have 4 more copies of those. And, I am not sure of that, but I think that in Clojurescript, the extend family has the same performance characteristics than deftype. Which makes things easier. Of course, deftype is sufficient for writing any class system, but you have to repeat yourself. And that is annoying. I don't advocate inheritance, which I think is a wrong answer to a good question, but someone needs to think of a way to reuse code in deftype. If you look at the big picture, multimethods are wonderful, protocols are great, reify is amazing, the extend family is top notch, but deftype lacks far behind in expressivity. (It is a very low-level construct, which the other are not.) And if deftype is in the language is because it is sometimes useful. And if it is useful, it should be made a pleasure to use as is the rest of the language. My first idea would be to add a macro (deftype-something body) that executes (or reduces) body at compile time in order to build a data structure containing the fields and the protocol/interface instances to be included in the resulting deftype. And then build a small library of functions to build classes. (extend-protocol, add-field, an so on...). It would solve one of the main problem of deftype: neither FP nor macros can help you much to build a type. Best, Nicolas. -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 1:53 AM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > I just have. This is a nice work. There is a lot of repetitions though. > Thanks Nicolas for putting together these examples. This is exactly what I've been talking about. Whenever someone talks about the issue of developing reusable partial implementation of protocols, the answer is always, "You can do that easily in Clojure by merging mappings." But in practice, I haven't seen many examples of anyone actually doing that. If people who are writing big systems (e.g., Clojurescript) aren't actually providing mergeable mappings, then writing new implementations for these protocols becomes a big copy-paste hackjob. I think part of the problem is that defrecord doesn't directly support using mappings of functions. The construct that supports that is extend, and needs to be done outside of defrecord, possibly costing some efficiency. This encourages people to copy-paste and not write reusable partial implementations. We need to figure out a way to make reusable partial implementations the norm. Maybe the solution is a Clojure construct along the lines of: (get-protocol-implementation ) gives you back a mapping of the functions used by that type to implement that protocol. This would allow you to get at and reuse protocol implementations, even if the original author didn't think to separate out the mapping. Also, a way to use such mappings inside of defrecord would also be a good idea, I think. --Mark -- 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: algebra system & core.logic
Symbolic computation sounds like a really great project! For your specific problem of sorting the dependencies, you can do a "topological sort" of the dependency graph of your equations in linear time (given there are no cyclic dependencies, otherwise it would detect the failure). There are standard algorithms to do that. It would be interesting to compare to core.logic's performance. Modelling the dependencies in core.logic is straightforward, but ordering them in linear time is not obvious to me - but I would love to see the code if you do it. All the best, Martin On Saturday, May 19, 2012 2:31:51 AM UTC+2, Brent Millare wrote: > > Is there work towards building an algebra system with core.logic? So one > could analyze mathematical expressions: compute symbolic derivatives, > simplify expressions, determine undefined variables, and other forms of > analysis. > > If there isn't, I have a good starting problem that I need help on. > > Lets say I have a bunch of equations, with the left hand side a single > variable, and the right is some expression. They are not ordered in any way > but I would like to order them, (if possible, otherwise throw useful > error), such that there isn't any dependency problems. Is there a good way > to do this with core.logic? And is the performance comparable to a hand > coded solution. Or put another way, can it do this in seconds for 500 > equations? > -- 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: How do I set jvm options for a lein repl
Check the sample project.clj on Github: https://github.com/technomancy/leiningen/blob/master/sample.project.clj There's an entry for JVM options: ;; You can set JVM-level options here. :jvm-opts ["-Xmx1g"] In a quick test, that worked for me when lein repl was executed. - Raju -- 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: How do I set jvm options for a lein repl
Oh, sorry, misunderstood your question. I found this blog post, maybe this still works, although it's from 2010: http://www.clojurepla.net/2010/05/increase-jvm-memory-when-using-swank.html -- 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: How do I set jvm options for a lein repl
That blog post is pretty outdated. When using leiningen, you can pass arbitrary jvm opts via project.clj[1]: :jvm-opts ["-Xmx1g"] [1]: https://github.com/technomancy/leiningen/blob/master/sample.project.clj On Mon, May 21, 2012 at 1:37 PM, Raju Bitter wrote: > Oh, sorry, misunderstood your question. I found this blog post, maybe > this still works, although it's from 2010: > http://www.clojurepla.net/2010/05/increase-jvm-memory-when-using-swank.html > > -- > 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 -- Moritz Ulrich -- 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: How do I set jvm options for a lein repl
> How do I set jvm options for a lein repl initiated independently of a > project? In particular, I want the heap expansion that results from doing > "M-x clojure-jack-in" in an emacs project.clj buffer with ":jvm-opts [ > "-Xms4G" "-Xmx4G"]" in its defproject form. Larry is looking for a way to set that value across all projects, not just for one project. - Raju -- 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: How do I set jvm options for a lein repl
You could add the following evinroment variable to your OS: LEIN_JVM_OPTS=-Xms4G -Xmx4G On Windows for example, you could add at the top of "lein.bat" file the following line (under "@echo off"): SET LEIN_JVM_OPTS=-Xms4G -Xmx4G This should be enough to do the trick. On Mon, May 21, 2012 at 6:51 AM, Larry Travis wrote: > How do I set jvm options for a *lein repl* initiated independently of a > project? In particular, I want the heap expansion that results from doing > "M-x clojure-jack-in" in an emacs *project.clj* buffer with ":jvm-opts [ > "-Xms4G" "-Xmx4G"]" in its defproject form. > --Larry > > -- > 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 4:53 AM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > > > > Have you actually looked at the data structure implementations in > > ClojureScript? The work is done. It's all protocols. > > > Hi David, > > I just have. This is a nice work. There is a lot of repetitions though. > I actually like this repetition. When it's simple one-liners like this, I feel the explicitness is worth way more than any gains from re-use, particularly because re-use often becomes a game of trying to find which file defines the behavior you're interested in. If the repetition were more substantial, the explicitness vs reuse tradeoff would eventually crossover though. --Aaron -- 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: algebra system & core.logic
On Monday, May 21, 2012 7:11:01 AM UTC-4, Martin Jul wrote: > > Symbolic computation sounds like a really great project! > > For your specific problem of sorting the dependencies, you can do a > "topological sort" of the dependency graph of your equations in linear time > (given there are no cyclic dependencies, otherwise it would detect the > failure). There are standard algorithms to do that. > > I ended up coding my own hand solution but I started from the leaves and worked towards the root nodes. I'll try the topological sort + reverse list approach and then compare performances. The topological sort code looks much simpler. -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 4:53 AM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > > ClojureScript? The work is done. It's all protocols. > > > Hi David, > > I just have. This is a nice work. There is a lot of repetitions though. > For example: > - IEquiv > (-equiv [coll other] (equiv-sequential coll other)) > > - IHash > (-hash [coll] (caching-hash coll hash-coll __hash)) > (where caching-hash has to be a macro) > > - ICounted > (-count [coll] count) > > - ILookup > (-lookup [coll k] (-nth coll k nil)) > (-lookup [coll k not-found] (-nth coll k not-found)) > And now any of those implementations can easily change at anytime without any external considerations. So what's the problem? David -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 5:39 AM, Mark Engelberg wrote: > On Mon, May 21, 2012 at 1:53 AM, nicolas.o...@gmail.com < > nicolas.o...@gmail.com> wrote: > >> I just have. This is a nice work. There is a lot of repetitions though. >> > > Thanks Nicolas for putting together these examples. This is exactly what > I've been talking about. Whenever someone talks about the issue of > developing reusable partial implementation of protocols, the answer is > always, "You can do that easily in Clojure by merging mappings." But in > practice, I haven't seen many examples of anyone actually doing that. If > people who are writing big systems (e.g., Clojurescript) aren't actually > providing mergeable mappings, then writing new implementations for these > protocols becomes a big copy-paste hackjob. > Have you looked at systems that use protocols extensively? The two I'm familiar with, core.logic and ClojureScript, do not constitute a "copy-paste hackjob". In fact I'd be surprised if the amount of copy-paste in either isn't less than 1% of the entire code base and a 1% where the redundancy is innocuous (IHash, IPrintable). > We need to figure out a way to make reusable partial implementations the > norm. > Shared functions work today. None of this to suggest that there aren't more "convenient" ways to share defaults. But I think the benefit of having type definitions that can be understood with an entirely local reading without having to search a type hierarchy or consider "defaults" should not be underestimated. David -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 5:39 AM, Mark Engelberg wrote: > On Mon, May 21, 2012 at 1:53 AM, nicolas.o...@gmail.com < > nicolas.o...@gmail.com> wrote: > We need to figure out a way to make reusable partial implementations the > norm. Maybe the solution is a Clojure construct along the lines of: > (get-protocol-implementation ) gives you > back a mapping of the functions used by that type to implement that > protocol. > This would allow you to get at and reuse protocol implementations, even if > the original author didn't think to separate out the mapping. > It's possible to do very sophisticated types of code reuse for those that need it via delegation given we have the ability to specify extend-type Object/default. David -- 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: defrecord with "inheritance"
> > And now any of those implementations can easily change at anytime without > any external considerations. So what's the problem? Well if you want to amend all of them at the same time, you have to modify all of them. On your advice of using extend-type: maybe I am wrong but I think it has a performance cost. I am not sure for the 1%, but the good metric is to look at the percentage of deftypes, not the whole code base. I think in a typical program, deftype already amount at less than 10% of the code. I wrote some code with a lot of different types implementing the same interfaces and that are made by composing different parts. I ended up splitting aspects in different types and use composition and "fake" protocols to implement cross-cutting aspects. I would have loved to have traits to do that instead: would have been easier, more performant and more natural to read. I could also have copied and pasted a lot, but it is asking for problem if you modify things later. -- 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: algebra system & core.logic
Actually, after working through the algorithm presented in the wiki, I think my implementation is basically equivalent given the data structures I'm using. :| On Monday, May 21, 2012 9:27:01 AM UTC-4, Brent Millare wrote: > > > > On Monday, May 21, 2012 7:11:01 AM UTC-4, Martin Jul wrote: >> >> Symbolic computation sounds like a really great project! >> >> For your specific problem of sorting the dependencies, you can do a >> "topological sort" of the dependency graph of your equations in linear time >> (given there are no cyclic dependencies, otherwise it would detect the >> failure). There are standard algorithms to do that. >> >> > I ended up coding my own hand solution but I started from the leaves and > worked towards the root nodes. I'll try the topological sort + reverse list > approach and then compare performances. The topological sort code looks > much simpler. > -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 11:11 AM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > > > > And now any of those implementations can easily change at anytime without > > any external considerations. So what's the problem? > > Well if you want to amend all of them at the same time, you have to > modify all of them. > As they are trivially the same, search+replace works really well in my experience. > On your advice of using extend-type: maybe I am wrong but I think it > has a performance cost. > An extra function dispatch or two? Not something I would lose sleep over for anything non-trivial. > I am not sure for the 1%, but the good metric is to look at the > percentage of deftypes, not the whole code base. > I think in a typical program, deftype already amount at less than 10% > of the code. > Sure which just drives my point home even more. > I wrote some code with a lot of different types implementing the same > interfaces and that are made > by composing different parts. > I ended up splitting aspects in different types and use composition > and "fake" protocols to implement > cross-cutting aspects. Without seeing your code hard to say anything about this. > I would have loved to have traits to do that > instead: would have been easier, more performant > and more natural to read. > Again without seeing your approach hard to tack any meaning to "more performant" or "more natural" to read. I think ClojureScript is pretty compelling evidence to the soundness of a protocol oriented inheritance-less approach. We live with a little redundancy but we achieve a considerable amount of clarity and localized readability. We've compressed 30,000 (more?) lines of the Java+Clojure standard library into ~6500 lines of pure Clojure. David -- 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
"when" function
Hi all, I'm struggling with "when" code structures and my imperative mindset. What is the better approach (or functional approach) to work with a code like the below? (defn parse-group [group-identifier line] (when (= group-identifier "ID1") (handle-id1 line)) (when (= group-identifier "ID2") (handle-id2 line)) (when (= group-identifier "ID3") (handle-id3 line))) Thank you. -- christian -- 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: "when" function
On May 21, 2012, at 10:54 AM, Christian Guimaraes wrote: > I'm struggling with "when" code structures and my imperative mindset. > > What is the better approach (or functional approach) to work with a code like > the below? I think you're looking for cond (from memory, syntax might be wrong): (defn parse-group [group-identifier line] (cond (= group-identitifer "ID1") (handle-id1 line) ... :else (do-something))) etc (doc cond) will give you what you need I think bill > (defn parse-group [group-identifier line] > (when (= group-identifier "ID1") > (handle-id1 line)) > (when (= group-identifier "ID2") > (handle-id2 line)) > (when (= group-identifier "ID3") > (handle-id3 line))) -- 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: "when" function
In this case I prefer either: (cond (= group-identifier "ID1") (handle-id1 line) (= group-identifier "ID2") (handle-id2 line) (= group-identifier "ID3") (handle-id3 line)) Or just use core.match: (match [group-identifier] ["ID1"] (handle-id1 line) ["ID2"] (handle-id1 line) ["ID3"] (handle-id1 line)) But then again, I have this "thing" for pattern matching...it's so elegant. Timothy Baldridge On Mon, May 21, 2012 at 10:54 AM, Christian Guimaraes wrote: > Hi all, > > I'm struggling with "when" code structures and my imperative mindset. > > What is the better approach (or functional approach) to work with a code > like the below? > > (defn parse-group [group-identifier line] > (when (= group-identifier "ID1") > (handle-id1 line)) > (when (= group-identifier "ID2") > (handle-id2 line)) > (when (= group-identifier "ID3") > (handle-id3 line))) > > Thank you. > -- christian > > > -- > 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 -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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: "when" function
I'm surprised no one went for condp (defn parse-group [group-identifier line] (condp = group-identifier "ID1" (handle-id1 line) "ID2" (handle-id2 line) "ID3" (handle-id3 line) (handle-unknown-id line))) or something like that... On Mon, May 21, 2012 at 11:59 AM, Timothy Baldridge wrote: > In this case I prefer either: > > (cond (= group-identifier "ID1") >(handle-id1 line) > (= group-identifier "ID2") > (handle-id2 line) > (= group-identifier "ID3") >(handle-id3 line)) > > Or just use core.match: > > (match [group-identifier] > ["ID1"] (handle-id1 line) > ["ID2"] (handle-id1 line) > ["ID3"] (handle-id1 line)) > > But then again, I have this "thing" for pattern matching...it's so elegant. > > Timothy Baldridge > > On Mon, May 21, 2012 at 10:54 AM, Christian Guimaraes > wrote: > > Hi all, > > > > I'm struggling with "when" code structures and my imperative mindset. > > > > What is the better approach (or functional approach) to work with a code > > like the below? > > > > (defn parse-group [group-identifier line] > > (when (= group-identifier "ID1") > > (handle-id1 line)) > > (when (= group-identifier "ID2") > > (handle-id2 line)) > > (when (= group-identifier "ID3") > > (handle-id3 line))) > > > > Thank you. > > -- christian > > > > > > -- > > 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 > > > > -- > “One of the main causes of the fall of the Roman Empire was > that–lacking zero–they had no way to indicate successful termination > of their C programs.” > (Robert Firth) > > -- > 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: "when" function
On Mon, May 21, 2012 at 8:54 AM, Christian Guimaraes
wrote:
> What is the better approach (or functional approach) to work with a code
> like the below?
A simple translation to condp:
(defn parse-group [group-identifier line]
(condp = group-identifier
"ID1" (handle-id1 line)
"ID2" (handle-id2 line)
"ID3" (handle-id3 line)))
But you may want something more extensible:
(def group-handlers
{"ID1" handle-id1,
"ID2" handle-id2,
"ID3" handle-id3})
(defn parse-group [group-identifier line]
(if-let [handler (group-handlers group-identifier)]
(handler line)
(println "unknown group identifier")))
A multimethod might also be an appropriate way forward for you.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
--
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: "when" function
On Monday, May 21, 2012 6:54:28 PM UTC+3, Christian Guimaraes wrote:
>
> Hi all,
>
> I'm struggling with "when" code structures and my imperative mindset.
>
> What is the better approach (or functional approach) to work with a code
> like the below?
>
> (defn parse-group [group-identifier line]
> (when (= group-identifier "ID1")
> (handle-id1 line))
> (when (= group-identifier "ID2")
> (handle-id2 line))
> (when (= group-identifier "ID3")
> (handle-id3 line)))
>
> Thank you.
> -- christian
>
>
>
Hi
Maybe something like
(defn parse-group [group-identifier line]
(condp = group-identifier
"ID1" (handle-id1 line)
"ID2" (handle-id2 line)
"ID3" (handle-id3 line)))
or, if you want to leverage the fact that maps are functions:
(defn parse-group [group-identifier line]
(({"ID1" handle-id1
"ID2" handle-id2
"ID3" handle-id3} group-identifier) line))
but then you lose some readability IMO.
On Monday, May 21, 2012 6:54:28 PM UTC+3, Christian Guimaraes wrote:
>
> Hi all,
>
> I'm struggling with "when" code structures and my imperative mindset.
>
> What is the better approach (or functional approach) to work with a code
> like the below?
>
> (defn parse-group [group-identifier line]
> (when (= group-identifier "ID1")
> (handle-id1 line))
> (when (= group-identifier "ID2")
> (handle-id2 line))
> (when (= group-identifier "ID3")
> (handle-id3 line)))
>
> Thank you.
> -- christian
>
>
>
--
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: "when" function
or simply use `case` (case group-identifier "ID1" (handle-id1 line) "ID2" (handle-id2 line) "ID3" (handle-id3 line)) 2012/5/21 Timothy Baldridge > In this case I prefer either: > > (cond (= group-identifier "ID1") >(handle-id1 line) > (= group-identifier "ID2") > (handle-id2 line) > (= group-identifier "ID3") >(handle-id3 line)) > > Or just use core.match: > > (match [group-identifier] > ["ID1"] (handle-id1 line) > ["ID2"] (handle-id1 line) > ["ID3"] (handle-id1 line)) > > But then again, I have this "thing" for pattern matching...it's so elegant. > > Timothy Baldridge > > On Mon, May 21, 2012 at 10:54 AM, Christian Guimaraes > wrote: > > Hi all, > > > > I'm struggling with "when" code structures and my imperative mindset. > > > > What is the better approach (or functional approach) to work with a code > > like the below? > > > > (defn parse-group [group-identifier line] > > (when (= group-identifier "ID1") > > (handle-id1 line)) > > (when (= group-identifier "ID2") > > (handle-id2 line)) > > (when (= group-identifier "ID3") > > (handle-id3 line))) > > > > Thank you. > > -- christian > > > > > > -- > > 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 > > > > -- > “One of the main causes of the fall of the Roman Empire was > that–lacking zero–they had no way to indicate successful termination > of their C programs.” > (Robert Firth) > > -- > 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: How do I set jvm options for a lein repl
Also there is an environment variable _JAVA_OPTIONS (note the leading underscore) which is handled by the HotSpot JVM (OpenJDK or Oracle JDK) and can be used with any java application. -- Mikhail -- 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: "when" function
> A multimethod might also be an appropriate way forward for you. +1 For multimethods, don't hardcode it if you don'tt have to. Timothy -- 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: How do I set jvm options for a lein repl
On Mon, May 21, 2012 at 5:28 AM, Raju Bitter wrote: >> How do I set jvm options for a lein repl initiated independently of a >> project? In particular, I want the heap expansion that results from doing >> "M-x clojure-jack-in" in an emacs project.clj buffer with ":jvm-opts [ >> "-Xms4G" "-Xmx4G"]" in its defproject form. > > Larry is looking for a way to set that value across all projects, not > just for one project. You can set :jvm-opts in the user profile if you're using Leiningen 2. Otherwise set JVM_OPTS as an environment variable. -Phil -- 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: defrecord with "inheritance"
The following is not about the merits of your request (or its foolishness :), it maybe a taste issue. If I look at productivity/efficiency, I cannot see the interest of sticking to the tools and frameworks the majority is using presently. They are highly inefficients. Doing things the same way they are already done and only changing the label does not provide any gain whatsoever. The heart of the problem is getting people to think differently about the things they have been doing wrong for the last two decades. I get regular feedback from people working in Javaish environments, many criticize the methods and tools they use daily. They feel they are not efficient and that it reduces their throughput significantly. That uneasiness is a first important sign that something is wrong in the "natural" thinking process of a significant chunk of developers (Java ones). Tools and frameworks emerge from this "natural thinking". I don't buy this idea of pleasing the majority but that maybe a personality trait. It's not about selling Hygrade sausages, it's about questioning our "bad habits". I got stuck into Java from back to 2001, my customers did not really questioned this choice in all those years. They never realized the jail they were getting into. Now they know they have a problem, having tons of code lines to maintain and no easy escape route. Clojure is flexible enough to allow you to address the same problem in different ways within a short timeframe. You can then experiment other approaches without having to switch to a different language/platform. This is the door allowing you to escape the rut into which your mind may be stuck. OO being one of them. Personally, I stay away from deftype/defrecord most of the time. I do however use protocols to implement "traits" of my own to standard Clojure data structures. OO can easily be tossed away using protocols or high order fns and maps. No need to carry that luggage. IMHO :) Luc P. > I surely agree there is individual difference in thinking what is > natural. Mozart might thought writing a symphony was a very natural > thing to accomplish, which I would strongly disagree. But if the > language does not meet the natural thinking of the majority people > (which I do think exist), then the language won't be effective for > them. There is nothing wrong because the language may not target the > "majority" as the users. However it will be even better if the > language can make more people's coding more efficient without > sacrificing anybody's coding efficiency. I hope my original "feature > request" at the beginning falls into such category. After all, even an > niche or elite language will benefit from a broader participation and > users. > > > On May 20, 9:00 pm, "Peter Buckley" wrote: > > -> high-level languages are there to make coding more efficient and > > effective > > > > -> the whole point of high-level > > languages is to satisfy our need to express our ideas/logics in a more > > natural way > > > > I'd argue that you're in violent agreement with each other :-) > > > > If I can express my idea/logic in a more natural way, I would expect that > > to make my coding more efficient and effective. > > > > I don't think there is such a thing as one "natural" thinking or > > programming pattern. I think what each of us regard as "natural" has a lot > > to do with different individuals' giftings, background, and experience. > > > > I think it's valid to say that OO is a bad attempt to force a contrived and > > ill-fitting "physical" world model on computer programs, and it's totally > > unnatural. That's just a point of view on the "natural"-ness of the > > programming model for an individual. > > > > Even if most programmers think that OO is an ideal model, that still > > doesn't mean it's the "natural" one. > > > > > > > > > > > > > > > > -Original Message- > > From: Alex Baranosky > > > > Sender: clojure@googlegroups.com > > Date: Sun, 20 May 2012 17:42:10 > > To: > > Reply-To: clojure@googlegroups.com > > Subject: Re: defrecord with "inheritance" > > > > I'd argue with you over whether that is the whole point of high-level > > languages. I might say that high-level languages are there to make coding > > more efficient and effective. > > > > On Sun, May 20, 2012 at 5:16 PM, Warren Lynn wrote: > > > > > I agree "familiar" is often mixed with "natural". But nevertheless > > > that does not mean there is no such thing as "natural" thinking or > > > programming pattern. In a broader sense, the whole point of high-level > > > languages is to satisfy our need to express our ideas/logics in a more > > > natural way, hence the modular design, interface and etc. The > > > challenge of a language is how to be natural and powerful at the same > > > time, as human being's natural thinking often is not enough to model > > > the complexity of the world. > > > > > On May 20, 7:34 pm, David Nolen wrote: > > > > FWIW, the first thing
Re: defrecord with "inheritance"
On Sun, May 20, 2012 at 2:37 PM, Bill Caputo wrote: > I am not a clojure beginner (though far from feeling I know all there is to > learn about it). I have been using clojure for almost a year; my team has > rebuilt the central part of our system (which is relied on by just about > every other team where I work) out of clojure and have had it in production > for 6 months. > > I've yet to even learn *how* to use defrecord, deftype & defprotocol. Same here--I can count on one hand the number of times I've wanted to implement polymorphism in three and a half years. Every time multimethods have worked great for the task. If you had polymorphism in a tight loop they might not suffice, but the decision to abandon multimethods should only be made after thorough benchmarking. -Phil -- 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: docstrings of if-let and when-let incorrect
Wow, the discussion continued! I agree on what most people have said: AND-combined and none of the bindings available in the else. On Friday, May 18, 2012 7:20:06 AM UTC+2, FrankS wrote: > > Christophe Grand was "experimenting" with some extensions to if-let and > when-let that had implicit ANDs for the let-forms: > > > https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/util.clj > > It feels intuitive to me to allow multiple if-let-forms like cgrand > implements, and I can certainly remember situations where I could have used > such a feature. > > -FrankS. > > > > On May 16, 2012, at 11:26 AM, dgrnbrg wrote: > > > I too assumed that if/when-let would support multiple bindings, short- > > circuiting if one failed, when I started learning Clojure. It seems > > that short-circuiting multiple bindings isn't surprising. > > > > On May 16, 10:56 am, Jay Fields wrote: > >> I've also attempted to use if/when-let with multiple bindings in the > past. > >> I assumed that it would behave as 'AND' and that no bindings would be > >> available in 'else' > >> > >> Cheers, Jay > >> > >> > >> > >> > >> > >> > >> > >> On Wed, May 16, 2012 at 10:29 AM, Dan Cross wrote: > >>> On Wed, May 16, 2012 at 9:16 AM, Aaron Cohen > wrote: > On Wed, May 16, 2012 at 9:10 AM, Walter Tetzner < > >>> robot.ninja.saus...@gmail.com> wrote: > > To make the bindings work like let, where later bindings can see > >>> previous > > bindings, I think the most natural way to do it is to have the > bindings > > behave like the maybe monad. > > [...] > >> > Saying something is obvious and then using the word monad a paragraph > >>> later > is contradictory. ;) > >> > >>> Hypothetically, "this is obvious, unlike most monads." Zing! > >> > What should happen on the else branch of the if-let; which bindings > are > >>> in > scope and what would be their values? > >> > >>> None of the bindings should be in scope. > >> > >>>- Dan C. > >> > >>> -- > >>> 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 > > On Friday, May 18, 2012 7:20:06 AM UTC+2, FrankS wrote: > > Christophe Grand was "experimenting" with some extensions to if-let and > when-let that had implicit ANDs for the let-forms: > > > https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/util.clj > > It feels intuitive to me to allow multiple if-let-forms like cgrand > implements, and I can certainly remember situations where I could have used > such a feature. > > -FrankS. > > > > On May 16, 2012, at 11:26 AM, dgrnbrg wrote: > > > I too assumed that if/when-let would support multiple bindings, short- > > circuiting if one failed, when I started learning Clojure. It seems > > that short-circuiting multiple bindings isn't surprising. > > > > On May 16, 10:56 am, Jay Fields wrote: > >> I've also attempted to use if/when-let with multiple bindings in the > past. > >> I assumed that it would behave as 'AND' and that no bindings would be > >> available in 'else' > >> > >> Cheers, Jay > >> > >> > >> > >> > >> > >> > >> > >> On Wed, May 16, 2012 at 10:29 AM, Dan Cross wrote: > >>> On Wed, May 16, 2012 at 9:16 AM, Aaron Cohen > wrote: > On Wed, May 16, 2012 at 9:10 AM, Walter Tetzner < > >>> robot.ninja.saus...@gmail.com> wrote: > > To make the bindings work like let, where later bindings can see > >>> previous > > bindings, I think the most natural way to do it is to have the > bindings > > behave like the maybe monad. > > [...] > >> > Saying something is obvious and then using the word monad a paragraph > >>> later > is contradictory. ;) > >> > >>> Hypothetically, "this is obvious, unlike most monads." Zing! > >> > What should happen on the else branch of the if-let; which bindings > are > >>> in > scope and what would be their values? > >> > >>> None of the bindings should be in scope. > >> > >>>- Dan C. > >> > >>> -- > >>> You received this message because you are subscribed to the Google >
Re: docstrings of if-let and when-let incorrect
On Wed, May 16, 2012 at 9:53 AM, Walter Tetzner < robot.ninja.saus...@gmail.com> wrote: > On Wednesday, May 16, 2012 9:16:29 AM UTC-4, Aaron Cohen wrote: >> >> Saying something is obvious and then using the word monad a paragraph >> later is contradictory. ;) >> >> What should happen on the else branch of the if-let; which bindings are >> in scope and what would be their values? >> >> > None of the bindings should be available in the else branch, since there > would be no way to know which will succeed before run-time. > I actually think that having all the bindings available and just nil for everything past the first failure would be more useful, and also matches the intuition that it expands out to nested if-lets (if-let [a 1 b 2 c nil] [a b c]) (if-let [a 1] (if-let [b 2] (if-let [c nil] [a b c] [a b c]) [a b c]) [a b c]) => [1 2 nil] -- 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: defrecord with "inheritance"
> Same here--I can count on one hand the number of times I've wanted to > implement polymorphism in three and a half years. Every time > multimethods have worked great for the task. If you had polymorphism > in a tight loop they might not suffice, but the decision to abandon > multimethods should only be made after thorough benchmarking. I agree multimethods are great. But when in a tight loop, you don't like them so much. The point is not whether deftype is useful or not. It is in the language so it must be useful, even it it is rarely. The point is whether it is an expressive construct or not. And it is not expressive enough to my taste. -- 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: "when" function
Hi, I think that multimethods will fit better in my case, since I have more than three ID's to handle. Thank you all for the answers. -- christian. On Mon, May 21, 2012 at 5:04 PM, Timothy Baldridge wrote: > > A multimethod might also be an appropriate way forward for you. > > +1 For multimethods, don't hardcode it if you don'tt have to. > > Timothy > > -- > 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: docstrings of if-let and when-let incorrect
I guess it wouldn't hurt having them available in the else, even if people won't use them often. On Monday, May 21, 2012 7:11:05 PM UTC+2, Aaron Cohen wrote: > > On Wed, May 16, 2012 at 9:53 AM, Walter Tetzner < > robot.ninja.saus...@gmail.com> wrote: > >> On Wednesday, May 16, 2012 9:16:29 AM UTC-4, Aaron Cohen wrote: >>> >>> Saying something is obvious and then using the word monad a paragraph >>> later is contradictory. ;) >>> >>> What should happen on the else branch of the if-let; which bindings are >>> in scope and what would be their values? >>> >>> >> None of the bindings should be available in the else branch, since there >> would be no way to know which will succeed before run-time. >> > > I actually think that having all the bindings available and just nil for > everything past the first failure would be more useful, and also matches > the intuition that it expands out to nested if-lets > > (if-let [a 1 b 2 c nil] [a b c]) > > > (if-let [a 1] >(if-let [b 2] > (if-let [c nil] > [a b c] > [a b c]) > [a b c]) >[a b c]) > > => [1 2 nil] > -- 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: docstrings of if-let and when-let incorrect
There's a few issues there, first of which is that the code doesn't evaluate to what's shown: REPL started; server listening on localhost port 21867 user=> (if-let [a 1] (if-let [b 2] (if-let [c nil] [a b c] [a b c]) [a b c]) [a b c]) java.lang.Exception: Unable to resolve symbol: c in this context (NO_SOURCE_FILE:3) The c isn't nil in the else form, it's unbound. The same would be true if it failed at any of the other levels, if the original if fails, a, b, & c are all unbound. So, setting them to nil isn't consistent. It might be a good option, but it's not consistent with the code above. I can't imagine that you'd want the else statement to have a bunch of possibly nil vars for any reason other than printing - otherwise you'd end up putting a bunch of conditional logic in the else to know which vars are nil, in which case you're better off using nested if-lets anyway. But, maybe the printing (i.e. logging) scenario is reason enough to bind these variables. I'd probably lean towards keeping them all unbound, as it's clear that each var would be bound (if form) or unbound (else form), versus each var being possibly truthy or nil in the else form. But, I don't feel strongly either way. On Mon, May 21, 2012 at 1:32 PM, Borkdude wrote: > I guess it wouldn't hurt having them available in the else, even if people > won't use them often. > > On Monday, May 21, 2012 7:11:05 PM UTC+2, Aaron Cohen wrote: >> >> On Wed, May 16, 2012 at 9:53 AM, Walter Tetzner < >> robot.ninja.saus...@gmail.com**> wrote: >> >>> On Wednesday, May 16, 2012 9:16:29 AM UTC-4, Aaron Cohen wrote: Saying something is obvious and then using the word monad a paragraph later is contradictory. ;) What should happen on the else branch of the if-let; which bindings are in scope and what would be their values? >>> None of the bindings should be available in the else branch, since there >>> would be no way to know which will succeed before run-time. >>> >> >> I actually think that having all the bindings available and just nil for >> everything past the first failure would be more useful, and also matches >> the intuition that it expands out to nested if-lets >> >> (if-let [a 1 b 2 c nil] [a b c]) >> >> >> (if-let [a 1] >>(if-let [b 2] >> (if-let [c nil] >> [a b c] >> [a b c]) >> [a b c]) >>[a b c]) >> >> => [1 2 nil] >> > -- > 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: docstrings of if-let and when-let incorrect
On Mon, May 21, 2012 at 1:43 PM, Jay Fields wrote: > There's a few issues there, first of which is that the code doesn't > evaluate to what's shown: > REPL started; server listening on localhost port 21867 > user=> > (if-let [a 1] >(if-let [b 2] > (if-let [c nil] > [a b c] > [a b c]) > [a b c]) >[a b c]) > java.lang.Exception: Unable to resolve symbol: c in this context > (NO_SOURCE_FILE:3) > > The c isn't nil in the else form, it's unbound. The same would be true if > it failed at any of the other levels, if the original if fails, a, b, & c > are all unbound. So, setting them to nil isn't consistent. It might be a > good option, but it's not consistent with the code above. I can't imagine > that you'd want the else statement to have a bunch of possibly nil vars for > any reason other than printing - otherwise you'd end up putting a bunch of > conditional logic in the else to know which vars are nil, in which case > you're better off using nested if-lets anyway. But, maybe the printing > (i.e. logging) scenario is reason enough to bind these variables. I'd > probably lean towards keeping them all unbound, as it's clear that each var > would be bound (if form) or unbound (else form), versus each var being > possibly truthy or nil in the else form. > > Yeah, I was typing theory code. However, "none defined in the else" doesn't fully match the "nested if-lets" behavior either. In the second if-let stanza, "a" would be bound in the else case. In any event, this is all just bike-shedding and illustrating that what appears "obvious" isn't necessarily. -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 1:12 PM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > > Same here--I can count on one hand the number of times I've wanted to > > implement polymorphism in three and a half years. Every time > > multimethods have worked great for the task. If you had polymorphism > > in a tight loop they might not suffice, but the decision to abandon > > multimethods should only be made after thorough benchmarking. > > The point is not whether deftype is useful or not. It is in the > language so it must be useful, even it it is rarely. > The point is whether it is an expressive construct or not. > And it is not expressive enough to my taste. Why not build a trait system then if you want something more "expressive"? All the pieces are there. Basic benchmarking of delegation via extend-type Object on JVM Clojure shows that it's fast enough for many inner loops where the work is more substantial than arithmetic. David -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 10:12 AM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > The point is not whether deftype is useful or not. It is in the > language so it must be useful, even it it is rarely. > The point is whether it is an expressive construct or not. > And it is not expressive enough to my taste. > > I'd go further and say that an important benchmark for any new language construct designed to support modularity, composability, and reuse is the degree to which it can support reuse in contexts unforeseen by the original author of the code. The whole beauty of protocols, for example, is that unlike interfaces, you can graft it on to a type that wasn't originally designed to support it. This is good, and a step forward from other languages. On the other hand, defrecord/deftype encourage you to write your protocol implementation in a way that cannot be reused unless you very specifically plan for it (factoring the protocol implementation into a separate map) and use a coding style that (might?) be less efficient (i.e., adding the protocol implementation via extend rather than directly in defrecord). This is not so good and potentially limits the value of protocols for developing complex systems. There are a lot of bad things about inheritance, but the one good thing about it is that it provides a certain way to extend and modify the behavior of objects in ways that were not foreseen or planned for. It would be nice if we could find a tasteful way to get that back with protocols without opening the entire inheritance can of worms. -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 1:59 PM, Mark Engelberg wrote: > On the other hand, defrecord/deftype encourage you to write your protocol > implementation in a way that cannot be reused unless you very specifically > plan for it (factoring the protocol implementation into a separate map) and > use a coding style that (might?) be less efficient (i.e., adding the > protocol implementation via extend rather than directly in defrecord). > This is not so good and potentially limits the value of protocols for > developing complex systems. > One of most complex OO component systems that I'm aware of - Cocoa - doesn't rely on this kind of code reuse at all. Everything is done via delegation and protocols. Games are some of the most complex OO systems being built today and the common wisdom is that building these systems on inheritance is a recipe for failure: http://www.gamasutra.com/blogs/MeganFox/20101208/88590/Game_Engines_101_The_EntityComponent_Model.php Looks an awful like protocols, and if not protocols precisely - then extend-type Object + sugar will get you the rest of the way. So "real world" complex systems avoid inheritance like the plague. So remind me again why it's desirable? David -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 10:59 AM, Mark Engelberg wrote: > The whole beauty of protocols, for example, is that unlike interfaces, you > can graft it on to a type that wasn't originally designed to support it. > This is good, and a step forward from other languages. i know protocols != structural typing, but just for that excerpt, isn't structural/duck typing good enough as well? -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 2:12 PM, Raoul Duke wrote: > On Mon, May 21, 2012 at 10:59 AM, Mark Engelberg > wrote: > > The whole beauty of protocols, for example, is that unlike interfaces, > you > > can graft it on to a type that wasn't originally designed to support it. > > This is good, and a step forward from other languages. > > i know protocols != structural typing, but just for that excerpt, > isn't structural/duck typing good enough as well? How does duck typing support sensibly extending types you don't control? -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 11:14 AM, David Nolen wrote: > How does duck typing support sensibly extending types you don't control? ah, i missed the implicit part of the excerpt that was about extending rather than just use. catching up. thanks. -- 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: defrecord with "inheritance"
>> On the other hand, defrecord/deftype encourage you to write your protocol >> implementation in a way that cannot be reused unless you very specifically >> plan for it (factoring the protocol implementation into a separate map) and >> use a coding style that (might?) be less efficient (i.e., adding the >> protocol implementation via extend rather than directly in defrecord). This >> is not so good and potentially limits the value of protocols for developing >> complex systems. > Inheritance is bad because it ties code reuse to a (mostly) non-significant hierarchy. That is not a reason to prevent all code reuse from deftypes. (It is not because OO gets it wrong that we should not try) -- 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: defrecord with "inheritance"
Sometimes it seems to me"OO" and "inheritance" have become some kind of taboos. I don't believe OO is all that wrong. To me Clojure seems to have good potential to harness the good part of OO without carrying into the bad parts. So I am hoping. :-) On May 21, 2:25 pm, "nicolas.o...@gmail.com" wrote: > >> On the other hand, defrecord/deftype encourage you to write your protocol > >> implementation in a way that cannot be reused unless you very specifically > >> plan for it (factoring the protocol implementation into a separate map) and > >> use a coding style that (might?) be less efficient (i.e., adding the > >> protocol implementation via extend rather than directly in defrecord). > >> This > >> is not so good and potentially limits the value of protocols for developing > >> complex systems. > > Inheritance is bad because it ties code reuse to a (mostly) > non-significant hierarchy. > That is not a reason to prevent all code reuse from deftypes. > > (It is not because OO gets it wrong that we should not try) -- 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: How do I set jvm options for a lein repl
I should be switching over to Leiningen 2 shortly in any case, but I am curious. How does one "set JVM_OPTS as an environment variable"? --Larry On 5/21/12 11:42 AM, Phil Hagelberg wrote: On Mon, May 21, 2012 at 5:28 AM, Raju Bitter wrote: How do I set jvm options for a lein repl initiated independently of a project? In particular, I want the heap expansion that results from doing "M-x clojure-jack-in" in an emacs project.clj buffer with ":jvm-opts [ "-Xms4G" "-Xmx4G"]" in its defproject form. Larry is looking for a way to set that value across all projects, not just for one project. You can set :jvm-opts in the user profile if you're using Leiningen 2. Otherwise set JVM_OPTS as an environment variable. -Phil -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 11:12 AM, David Nolen wrote: > So "real world" complex systems avoid inheritance like the plague. So > remind me again why it's desirable? > > David > > > I never said I want inheritance. I want convenient reuse of partial implementations. Inheritance is one way to achieve it, but I'd like to think that Clojure can find a better way. I believe the current mechanisms are insufficient. Copy and paste is not good enough. Mergeable maps are a good idea, but the current way of doing things steers people away from that solution and requires too much forethought to actively plan for reuse. If I implement a protocol inside of defrecord, all that implementation is "locked inside" and no one can get at it or reuse it in other contexts. This flies in the face of so many design principles of Clojure which generally eschew unnecessary encapsulation and privacy to make it easy to get at, reuse, and extend data and functions. As I proposed in an earlier email, one brainstorm I have about this is: (get-protocol-implementation ) gives you back a mapping of the functions used by that type to implement that protocol. Also, we need a way to use mappings of functions inside of defrecord/deftype, not just extend, if that is technologically feasible. I am genuinely interested in further brainstorms on the topic of how to encourage reuse of protocol implementations *without* inheritance. -- 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: How do I set jvm options for a lein repl
If you are running in a unix shell, something like JVM_OPTS=-Xms4G ... Followed by export JVM_OPTS Bash allows you to combine the two as in: export JVM_OPTS-Xms4G ... In a windows Cmd shell, something like this should work: set JVM_OPTS=Xms4G ... before running lein from the command line. Luc > I should be switching over to Leiningen 2 shortly in any case, but I am > curious. How does one "set JVM_OPTS as an environment variable"? >--Larry > > > On 5/21/12 11:42 AM, Phil Hagelberg wrote: > > On Mon, May 21, 2012 at 5:28 AM, Raju Bitter > > wrote: > >>> How do I set jvm options for a lein repl initiated independently of a > >>> project? In particular, I want the heap expansion that results from > >>> doing > >>> "M-x clojure-jack-in" in an emacs project.clj buffer with ":jvm-opts [ > >>> "-Xms4G" "-Xmx4G"]" in its defproject form. > >> Larry is looking for a way to set that value across all projects, not > >> just for one project. > > You can set :jvm-opts in the user profile if you're using Leiningen 2. > > Otherwise set JVM_OPTS as an environment variable. > > > > -Phil > > > > -- > 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 > -- Softaddicts sent by ibisMail from my ipad! -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 6:08 PM, Mark Engelberg wrote: > As I proposed in an earlier email, one brainstorm I have about this is: > > (get-protocol-implementation ) gives you > back a mapping of the functions used by that type to implement that > protocol. > I think there's some assumptions here about what level of granularity protocols are intended to work at right? Most of protocols in ClojureScript are 1 or 2 fns. If you need to provide partial implementations perhaps it's a sign the protocol design needs further work? The only two protocols that involve specifying more than 2 fns is IWatchable (3) and MultiFn (5). It's not clear to me that they would benefit from partial specification. Do you have a more specific example in mind? David -- 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: How do I set jvm options for a lein repl
The bash example is export JVM_OPTS=-Xms4G ... missed the = ... Luc > If you are running in a unix shell, something like > > JVM_OPTS=-Xms4G ... > > Followed by > export JVM_OPTS > > Bash allows you to combine the two as in: > > export JVM_OPTS-Xms4G ... > > In a windows Cmd shell, something like this should work: > > set JVM_OPTS=Xms4G ... > > before running lein from the command line. > > Luc > > > > > > I should be switching over to Leiningen 2 shortly in any case, but I am > > curious. How does one "set JVM_OPTS as an environment variable"? > >--Larry > > > > > > On 5/21/12 11:42 AM, Phil Hagelberg wrote: > > > On Mon, May 21, 2012 at 5:28 AM, Raju Bitter > > > wrote: > > >>> How do I set jvm options for a lein repl initiated independently of a > > >>> project? In particular, I want the heap expansion that results from > > >>> doing > > >>> "M-x clojure-jack-in" in an emacs project.clj buffer with ":jvm-opts [ > > >>> "-Xms4G" "-Xmx4G"]" in its defproject form. > > >> Larry is looking for a way to set that value across all projects, not > > >> just for one project. > > > You can set :jvm-opts in the user profile if you're using Leiningen 2. > > > Otherwise set JVM_OPTS as an environment variable. > > > > > > -Phil > > > > > > > -- > > 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 > > > -- > Softaddicts sent by ibisMail from my ipad! > > -- > 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 > -- Softaddicts sent by ibisMail from my ipad! -- 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 6:08 PM, Mark Engelberg wrote: > I never said I want inheritance. I want convenient reuse of partial > implementations. Inheritance is one way to achieve it, but I'd like to > think that Clojure can find a better way. We also have macros. You can always make your own (defmytype TypeName ...) and make compile to a deftype that rolls in the protocol implementations you want to reuse. I believe the current mechanisms > are insufficient. Copy and paste is not good enough. Mergeable maps are a > good idea, but the current way of doing things steers people away from that > solution and requires too much forethought to actively plan for reuse. If I > implement a protocol inside of defrecord, all that implementation is "locked > inside" and no one can get at it or reuse it in other contexts. This flies > in the face of so many design principles of Clojure which generally eschew > unnecessary encapsulation and privacy to make it easy to get at, reuse, and > extend data and functions. > > As I proposed in an earlier email, one brainstorm I have about this is: > > (get-protocol-implementation ) gives you back > a mapping of the functions used by that type to implement that protocol. > Also, we need a way to use mappings of functions inside of > defrecord/deftype, not just extend, if that is technologically feasible. > > I am genuinely interested in further brainstorms on the topic of how to > encourage reuse of protocol implementations *without* inheritance. > > -- > 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 4:00 PM, David Nolen wrote: > The only two protocols that involve specifying more than 2 fns is > IWatchable (3) and MultiFn (5). It's not clear to me that they would > benefit from partial specification. > I don't think there's enough body of code using protocols to really know what is going to turn out to be the natural size for protocols but even if we talk about "total" reuse instead of "partial" reuse, the issue is still the same -- the implementation of protocols is generally locked up with no easy way to reuse. If I know I want to implement ILookup the same way it was implemented for some other data structure, I have to be able to see your code, and then copy and paste it. For some things, it is obvious how to reimplement, but for some it is not. When I implemented priority maps, I had a difficult time figuring out all the interfaces that needed to be implemented, and it was especially difficult to figure out the right way to implement the various notions of equivalence and equality. Basically, I just wanted it to behave like the built-in maps. I had to copy and paste, and shortly after I completed my implementation, a change was made to how these concepts were handled in the core. My notion of equality became out-of-sync with that of built-in maps because I had no convenient way to say, "Do it the way regular maps do it." I ended up having to rewrite that code. So there is a maintenance issue here too. When Nicolas pointed out the many repetitions of something like the implementation of, say, ILookup, your response was that it would never be a big deal to just do a search-replace if you wanted to make a change. But that assumes that the only copies occur in your own code. When map equality changed, no one automatically did a search and replace in my code to make sure it would stay consistent. This is why code reuse mechanisms that don't rely on copy/paste search/replace are valuable, especially in the core, where other people are trying hard to make structures that behave in a core-like 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: defrecord with "inheritance"
On Mon, May 21, 2012 at 4:23 PM, kovas boguta wrote: > On Mon, May 21, 2012 at 6:08 PM, Mark Engelberg > wrote: > > > I never said I want inheritance. I want convenient reuse of partial > > implementations. Inheritance is one way to achieve it, but I'd like to > > think that Clojure can find a better way. > > We also have macros. > > You can always make your own > > (defmytype TypeName ...) > > and make compile to a deftype that rolls in the protocol > implementations you want to reuse. > > Yes, I can make a macro, but that won't do any good in terms of my reusing other people's code that have not been written in this manner. If large bodies of code are written implementing protocols using the mechanism provided by defrecord, and then I can't conveniently reuse that implementation without seeing it and copying and pasting it, I still have a problem, macro 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 options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: defrecord with "inheritance"
I think it's misleading to use inheritance to reduce code duplication. Inheritance is about indicating function typing and creating typed contracts, both of which are fairly un-idiomatic in Clojure. However, there is another way to prevent code duplication: use composition instead. Instead of having the Employee class mirror the attributes of the Person (which if you really wanted, you could easily do via a "defperson" like macro that would slug on extra fields), why not have an Employee carry a Person as one of its attributes? This approach is more similar to the Haskell/functional way of working with record types (I think Haskell's newtype operator works similarly under the covers). There is also an analogue to the decorator pattern in Java. In this case, you would specify a Personable protocol, which both Person and Employee implement; for all the basic operations, Employee would just defer to its internal person. Example: (defrecord Person [name birthday]) (defrecord Employee [title person]) (defprotocol Personable (name [this]) (age [this)) (extend-protocol Personable Person (name [this] (:name this)) (age [this] (date-dif (java.util.Date.) (:birthday this)) ;;date diff defined elsewhere Employee (name [this] (name (:person this)) (age [this] (age (:person this))) Arguably, if we were deferring to the current Java best practices and encapsulation, one should be creating interfaces of getters and setters rather than directly accessing instance variables anyway, making the extra protocol definition no more work than doing it correctly in modern Java. Best, Mark On Sunday, May 20, 2012 10:22:55 AM UTC-7, Warren Lynn wrote: > > So from what I read the philosophy of Clojure discourages inheritance > on concrete data types. However, maybe I am too entrenched in my OO > thinking, how do I define a new record type that includes all the data > members of another record type? I am thinking about the classic > Employee/Person example. > > If I can define a record of Employee with Person's data members > included, even that is not true inheritance (as no protocols of > "Person" will be automatically extended to "Employee"), I need that > for function re-use (so a function working on Person will > automatically work on Employee because Employee is guaranteed to have > all the data members in Person). > > Also, again, maybe I am too OO minded, is there a way inherit another > record type's protocol implementation? That seems to give the best > combination of both worlds (OO and functional), so you can either have > you own very customized combination of data type/protocols, or use the > very common OO pattern. Just like we have both the single-typed > dispatching (which is more OO like and covers a large portion of use > cases), and more advanced multimethods. > > Thanks. -- 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: defrecord with "inheritance"
Le 22 mai 2012 à 04:19, Mark Engelberg a écrit : On Mon, May 21, 2012 at 4:00 PM, David Nolen wrote: > The only two protocols that involve specifying more than 2 fns is > IWatchable (3) and MultiFn (5). It's not clear to me that they would > benefit from partial specification. > I don't think there's enough body of code using protocols to really know what is going to turn out to be the natural size for protocols but even if we talk about "total" reuse instead of "partial" reuse, the issue is still the same -- the implementation of protocols is generally locked up with no easy way to reuse. If I know I want to implement ILookup the same way it was implemented for some other data structure, I have to be able to see your code, and then copy and paste it. For some things, it is obvious how to reimplement, but for some it is not. When I implemented priority maps, I had a difficult time figuring out all the interfaces that needed to be implemented, and it was especially difficult to figure out the right way to implement the various notions of equivalence and equality. Basically, I just wanted it to behave like the built-in maps. I had to copy and paste, and shortly after I completed my implementation, a change was made to how these concepts were handled in the core. My notion of equality became out-of-sync with that of built-in maps because I had no convenient way to say, "Do it the way regular maps do it." I ended up having to rewrite that code. Hello Mark, Yes this is unfortunate. It would be interesting to see what would porting your priority map to clojurescript bring to the table, IMHO. Because clojure internals being a mix of java/interfaces and clojure certainly didn't help ? So there is a maintenance issue here too. When Nicolas pointed out the many repetitions of something like the implementation of, say, ILookup, your response was that it would never be a big deal to just do a search-replace if you wanted to make a change. But that assumes that the only copies occur in your own code. When map equality changed, no one automatically did a search and replace in my code to make sure it would stay consistent. This is why code reuse mechanisms that don't rely on copy/paste search/replace are valuable, especially in the core, where other people are trying hard to make structures that behave in a core-like 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 -- 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: defrecord with "inheritance"
Interesting demonstration, except for one thing, defining getters is a waste of time :) When you need to define accessors, you start to run into inefficient use of your time. It still a bearable workload in Java because of all this heavy tooling that allows to select for which fields accessors will be generated. Without getters, you would also expose mutable stuff to the universe. However in Clojure the values are not mutable... Why bother defining an accessor to a read-only value ? A better way would be something like: (defprotocol Personable (person [this]) (age [this] ) (defprotocol CensusOperators (age [this])) (extend-protocol Personable Person (person [this] this) Employee (person [this] (:person this))) (extend-protocol CensusOperators Person (age [this] (date-dif (java.util.Date.) (:birthday this) Much more convenient to me. I can take anything and make it a person. Even from a Clojure map just by extending it and returning a Person instance. You expose the Person abstraction when available instead of hiding it. Computed values like the age ? This is something that could be computed for other entities like an animal. So you can write (age (person )) or (age (animal )). This is why I tell people to get out of their usual thinking process. Get lazy, playing hide and seek was fun at pre-school age but in your code and data structures ? Luc P. > I think it's misleading to use inheritance to reduce code duplication. > Inheritance is about indicating function typing and creating typed > contracts, both of which are fairly un-idiomatic in Clojure. > > However, there is another way to prevent code duplication: use composition > instead. Instead of having the Employee class mirror the attributes of the > Person (which if you really wanted, you could easily do via a "defperson" > like macro that would slug on extra fields), why not have an Employee carry > a Person as one of its attributes? This approach is more similar to the > Haskell/functional way of working with record types (I think Haskell's > newtype operator works similarly under the covers). There is also an > analogue to the decorator pattern in Java. > > In this case, you would specify a Personable protocol, which both Person > and Employee implement; for all the basic operations, Employee would just > defer to its internal person. Example: > > (defrecord Person [name birthday]) > > (defrecord Employee [title person]) > > (defprotocol Personable > (name [this]) > (age [this)) > > (extend-protocol Personable > Person > (name [this] (:name this)) > (age [this] (date-dif (java.util.Date.) (:birthday this)) ;;date diff > defined elsewhere > Employee > (name [this] (name (:person this)) > (age [this] (age (:person this))) > > Arguably, if we were deferring to the current Java best practices and > encapsulation, one should be creating interfaces of getters and setters > rather than directly accessing instance variables anyway, making the extra > protocol definition no more work than doing it correctly in modern Java. > > Best, > Mark > > On Sunday, May 20, 2012 10:22:55 AM UTC-7, Warren Lynn wrote: > > > > So from what I read the philosophy of Clojure discourages inheritance > > on concrete data types. However, maybe I am too entrenched in my OO > > thinking, how do I define a new record type that includes all the data > > members of another record type? I am thinking about the classic > > Employee/Person example. > > > > If I can define a record of Employee with Person's data members > > included, even that is not true inheritance (as no protocols of > > "Person" will be automatically extended to "Employee"), I need that > > for function re-use (so a function working on Person will > > automatically work on Employee because Employee is guaranteed to have > > all the data members in Person). > > > > Also, again, maybe I am too OO minded, is there a way inherit another > > record type's protocol implementation? That seems to give the best > > combination of both worlds (OO and functional), so you can either have > > you own very customized combination of data type/protocols, or use the > > very common OO pattern. Just like we have both the single-typed > > dispatching (which is more OO like and covers a large portion of use > > cases), and more advanced multimethods. > > > > Thanks. > > -- > 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 -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Goog
Re: How do I set jvm options for a lein repl
It took me a while to figure out how to put multiple entries into an environment variable (that is, settings for both min and max heap sizes, to wit, "export JVM_OPTS=\ -Xms4G\ -Xmx4G") but, once I did, Phil's and Luc's suggestions have worked well and things have gone swimmingly. They work for both bash and eshell. Thanks much to you all. --Larry On 5/21/12 6:16 PM, Softaddicts wrote: The bash example is export JVM_OPTS=-Xms4G ... missed the = ... Luc If you are running in a unix shell, something like JVM_OPTS=-Xms4G ... Followed by export JVM_OPTS Bash allows you to combine the two as in: export JVM_OPTS-Xms4G ... In a windows Cmd shell, something like this should work: set JVM_OPTS=Xms4G ... before running lein from the command line. Luc I should be switching over to Leiningen 2 shortly in any case, but I am curious. How does one "set JVM_OPTS as an environment variable"? --Larry On 5/21/12 11:42 AM, Phil Hagelberg wrote: On Mon, May 21, 2012 at 5:28 AM, Raju Bitter wrote: How do I set jvm options for a lein repl initiated independently of a project? In particular, I want the heap expansion that results from doing "M-x clojure-jack-in" in an emacs project.clj buffer with ":jvm-opts [ "-Xms4G" "-Xmx4G"]" in its defproject form. Larry is looking for a way to set that value across all projects, not just for one project. You can set :jvm-opts in the user profile if you're using Leiningen 2. Otherwise set JVM_OPTS as an environment variable. -Phil -- -- 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
[ANN] checkero 0.1.0 : A Clojure code similarity search tool
Checkero finds common Clojure source code inside a set of directories. It is primarily intended to study how Clojure learners write functions. As a side effect, you can find if students have honestly completed their homework. It could also be used to find commonly used patterns in code that require refactoring. The algorithm uses a state-of-the-art tree distance function that quickly finds common tree patterns. It analyzes the syntactical structure of Clojure programs and finds similar expressions. You can find more details here: https://github.com/amuller/checkero Suggestions and feedback are more than welcome! Arnoldo Muller -- 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: defrecord with "inheritance"
On May 22, 2012 7:09 AM, "Softaddicts" wrote: > A better way would be something like: > > (defprotocol Personable >(person [this]) > (age [this] ) > > (defprotocol CensusOperators >(age [this])) > > (extend-protocol Personable >Person >(person [this] this) >Employee >(person [this] (:person this))) > > (extend-protocol CensusOperators > Person > (age [this] (date-dif (java.util.Date.) (:birthday this) > > Much more convenient to me. I can take anything and make it a person. I really don't understand your example. Personable#age conflicts with CensusOperators#age if you define them in the same Namespace (and you'll get a warning telling you so) . If they're in separate namespaces , what's the point of Personable #age, given you never define an implementation? > Even from a Clojure map just by extending it and returning a Person instance. > You expose the Person abstraction when available instead of hiding it. > > Computed values like the age ? This is something that could be computed > for other entities like an animal. > > So you can write (age (person )) or (age (animal )). > > This is why I tell people to get out of their usual thinking process. Get lazy, > playing hide and seek was fun at pre-school age but in your code and data > structures ? > > Luc P. > > > > I think it's misleading to use inheritance to reduce code duplication. > > Inheritance is about indicating function typing and creating typed > > contracts, both of which are fairly un-idiomatic in Clojure. > > > > However, there is another way to prevent code duplication: use composition > > instead. Instead of having the Employee class mirror the attributes of the > > Person (which if you really wanted, you could easily do via a "defperson" > > like macro that would slug on extra fields), why not have an Employee carry > > a Person as one of its attributes? This approach is more similar to the > > Haskell/functional way of working with record types (I think Haskell's > > newtype operator works similarly under the covers). There is also an > > analogue to the decorator pattern in Java. > > > > In this case, you would specify a Personable protocol, which both Person > > and Employee implement; for all the basic operations, Employee would just > > defer to its internal person. Example: > > > > (defrecord Person [name birthday]) > > > > (defrecord Employee [title person]) > > > > (defprotocol Personable > > (name [this]) > > (age [this)) > > > > (extend-protocol Personable > > Person > > (name [this] (:name this)) > > (age [this] (date-dif (java.util.Date.) (:birthday this)) ;;date diff > > defined elsewhere > > Employee > > (name [this] (name (:person this)) > > (age [this] (age (:person this))) > > > > Arguably, if we were deferring to the current Java best practices and > > encapsulation, one should be creating interfaces of getters and setters > > rather than directly accessing instance variables anyway, making the extra > > protocol definition no more work than doing it correctly in modern Java. > > > > Best, > > Mark > > > > On Sunday, May 20, 2012 10:22:55 AM UTC-7, Warren Lynn wrote: > > > > > > So from what I read the philosophy of Clojure discourages inheritance > > > on concrete data types. However, maybe I am too entrenched in my OO > > > thinking, how do I define a new record type that includes all the data > > > members of another record type? I am thinking about the classic > > > Employee/Person example. > > > > > > If I can define a record of Employee with Person's data members > > > included, even that is not true inheritance (as no protocols of > > > "Person" will be automatically extended to "Employee"), I need that > > > for function re-use (so a function working on Person will > > > automatically work on Employee because Employee is guaranteed to have > > > all the data members in Person). > > > > > > Also, again, maybe I am too OO minded, is there a way inherit another > > > record type's protocol implementation? That seems to give the best > > > combination of both worlds (OO and functional), so you can either have > > > you own very customized combination of data type/protocols, or use the > > > very common OO pattern. Just like we have both the single-typed > > > dispatching (which is more OO like and covers a large portion of use > > > cases), and more advanced multimethods. > > > > > > Thanks. > > > > -- > > 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 > -- > Softaddicts sent by ibisMail from my ipad! > > -- > You received this message because you are subscribed to t
Re: defrecord with "inheritance"
Hi, Am Dienstag, 22. Mai 2012 00:08:52 UTC+2 schrieb puzzler: > Mergeable maps are a good idea, but the current way of doing things > steers people away from that solution and requires too much > forethought to actively plan for reuse. I wonder why the current way of doing things “steers away” people from using extend. extend is simply the default. Period. Implementing things directly in a deftype or a defrecord should be the last resort if performance requires it. You loose not only the code reuse part when implementing things directly in the types, you also welcome back name clashes. user=> (ns foo) nil foo=> (defprotocol Foo (foo [this])) Foo foo=> (ns bar) nil bar=> (defprotocol Bar (foo [this])) Bar bar=> (in-ns 'user) # user=> (defrecord Data [x] foo.Foo (foo [this] :foo) bar.Bar (foo [this] :bar)) CompilerException java.lang.ClassFormatError: Duplicate method name&signature in class file user/Data, compiling:(NO_SOURCE_PATH:6) Or take mutually recursive types. With extend this is no problem at all. With direct definition you have to introduce manual factories with declare to break the cycles. Everyone just reiterates the mantra “It's slower! It's slower! It's slower!”, but no one talks about the trade-offs. And I bet only a very small fraction ever checked what “slower” means in their specific use case. The problem is not the current implementation. That is perfectly fine. The problem is a questionable golden idol called “performance” paired with lack of sorrow research. Kind regards 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: defrecord with "inheritance"
Hey Luc, That's a cool casting strategy to cleanly build a standard way to get at the person piece of any type of applicable record. In the pure composition case, it's actually a nice solution to build functions know how to unpack the Person aspect of a subtype. However, I think which strategy is best depends very much on whether you plan to extensively change the protocol implementation between the the different related types. In the case where Employee simply carries extra information with regard to a person, I agree that it is nice simply to define a mechanism to extract the base type and just act on it directly. However if you wish to do something more complicated or override default behavior extensively, I think the encapsulated "newtyped" way is more convenient. For example, how about we build a little DSL to represent different types of Excel cells. In Excel, everything is represented as a float, so we have to keep track of the type separately. I think using a record type is a fairly natural way to encode this extra data on type of Cell, where I might have reached for inheritance in traditional OOP. (defprotocol Convertable (convert-cell [this])) (defrecord Cell [row col float-value]) (defrecord MoneyCell [cell]) (defrecord DateCell [cell]) (defrecord NumberCell [cell]) (extend-protocol Convertable NumberCell (convert-cell [this] (float (-> this :cell :float-value)) DateCell (convert-cell [this] (excel-date (-> this :cell :float-value)) ;; Translate an Excel datestamp to java.util.Date MoneyCell (convert-cell [this] (bigdec (convert-cell (Number (:cell this) ;;BigDecimals are for exact money handling. Blindly unpacking the Cell type (via a Cellable convention like in the Person example) would lose information we need to accurately describe the conversion process and call the best function. This strategy also leverages ones of the best aspects of protocols: how extensible they are to new types of data. If I ever decide to support a StringCell type or a BooleanCell, I would just be one extend-protocol away rather than having to rewrite some gnarly embedded cond to work with my new type of cell. Of course for operations that don't care about their type, creating a protocol to extract the cell and working directly with its attributes (such as manipulating row and position directly), makes a great deal of sense. Best, Mark On Monday, May 21, 2012 10:09:02 PM UTC-7, Luc wrote: > > Interesting demonstration, except for one thing, defining getters is a > waste of > time :) > > When you need to define accessors, you start to run into inefficient use > of > your time. It still a bearable workload in Java because of all this heavy > tooling that allows > to select for which fields accessors will be generated. > Without getters, you would also expose mutable stuff to the universe. > > However in Clojure the values are not mutable... Why bother defining > an accessor to a read-only value ? > > A better way would be something like: > > (defprotocol Personable > (person [this]) > (age [this] ) > > (defprotocol CensusOperators > (age [this])) > > (extend-protocol Personable > Person > (person [this] this) > Employee > (person [this] (:person this))) > > (extend-protocol CensusOperators > Person > (age [this] (date-dif (java.util.Date.) (:birthday this) > > Much more convenient to me. I can take anything and make it a person. > Even from a Clojure map just by extending it and returning a Person > instance. > You expose the Person abstraction when available instead of hiding it. > > Computed values like the age ? This is something that could be computed > for other entities like an animal. > > So you can write (age (person )) or (age (animal )). > > This is why I tell people to get out of their usual thinking process. Get > lazy, > playing hide and seek was fun at pre-school age but in your code and data > structures ? > > Luc P. > > > > I think it's misleading to use inheritance to reduce code duplication. > > Inheritance is about indicating function typing and creating typed > > contracts, both of which are fairly un-idiomatic in Clojure. > > > > However, there is another way to prevent code duplication: use > composition > > instead. Instead of having the Employee class mirror the attributes of > the > > Person (which if you really wanted, you could easily do via a > "defperson" > > like macro that would slug on extra fields), why not have an Employee > carry > > a Person as one of its attributes? This approach is more similar to the > > Haskell/functional way of working with record types (I think Haskell's > > newtype operator works similarly under the covers). There is also an > > analogue to the decorator pattern in Java. > > > > In this case, you would specify a Personable protocol, which both Person > > and Employee implement
