Re: Clojure on top of ObjC?
On Tuesday, 23 April 2013 13:37:59 UTC-7, Steven Degutis wrote: While this is certainly neat, it doesn't allow Clojure to be used as an embedded scripting language inside an ObjC app. Since the Clojure/West talk I've been busy trying to get clojure-scheme self-hosted. I've been a week or so away from this working for a few weeks now :) But Clojure macros, the analysis pass, and the compiler are all self-hosted. There's a little bit more to do on the reader's interaction with syntax-quote, but once that's done we should have a real Clojure repl running on the iPhone. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ClojureScript allows fns to be called with too many arguments
ClojureScript doesn't complain when you supply too many arguments to a function, silently dropping the superfluous args. Is this a bug or feature? I'm not sure if I should replicate this behaviour in clojure-scheme, as it differs from Clojure. P.S. is there a separate group for ClojureScript bug discussions? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-scheme - Compiling Clojure to Scheme to C
ClojureScript has plenty of sharp edges, and this project is a bit rougher than even ClojureScript at the moment so you'll have to pardon the mess. The magic happens in the cljs.compiler namespace. Load up a clojure repl and do something along the lines of: (do (require 'cljs.compiler) (require 'cljs.core) (in-ns 'cljs.compiler) ) after that, you'll be able to compile .cljs files to .scm files via (compile-file /Users/nathansorenson/src/c-clojure/src/cljs/cljs/core.cljs) Note how I'm having to be real obvious about the filename right now. You should get an .scm file in the same directory. At that point you can compile it to an .o file with gambit, or just load it in the interpreter to play with $ gsc gsc-repl (load core.scm ;interpreted $ gsc core.scm ;outputs core.o gsc-repl (load core) ; loads the compiled .o -- 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
motivation behind laziness of apply in ClojureScript
When trawling the ClojureScript source, I was a little puzzled when I first noticed that cljs.core/apply respects the laziness of the seq its provided. Fogus mentioned this feature in his Clojure/west talk and it reminded me of my earlier puzzlement. This choice seems to contradict Clojure's eager argument evaluation semantics. Is the motivation of this choice described anywhere? I'm guessing I am missing an obvious use case. -- 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: motivation behind laziness of apply in ClojureScript
Your right the core apply is lazy too. The same question still remains: is there a use case behind apply being lazy when Clojure is otherwise a strictly evaluating language? Perhaps is this the intended mechanism to smuggle non-strictness into evaluation? -- 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: motivation behind laziness of apply in ClojureScript
Actually now that I've thought about it, you couldn't mimic non-strict evaluation with lazy apply, so that's not a use-case. All you could provide is left-to-right argument non-strictness which is not sufficient. W.r.t. your example, you can force evaluation the first 3 args, but you can't, say, force the evaluation of only the 3rd argument like in Haskell. I use apply to leverage list processing functions to massage input to functions that are generally non-seq-ey. If a function is intended to operate on lazy sequences, it seems to me that you would pass those sequences in as explicit arguments, in the same manner as all the Clojure seq operations. Again, we don't have the machinery to mimic non-strict evaluation so I don't think building functions that behave in this halfways-non-strict manner is obvious design. I'd like to see a function that depends on the left-to-right-non-strictness that lazy apply provides. -- 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: motivation behind laziness of apply in ClojureScript
I don't think it's possible to ever have apply not evaluate all its arguments? I think this is what Nathan was saying. Cedric is right that apply, itself, is strict and evaluates its arguments as one might expect. But I'm not referring to manual thunking/delaying your arguments to mimic laziness in a strict language. What I'm trying to understand is that one is able to write a polyvariadic function that *doesn't* completely realize the rest parameter (but only in the case that the fn is invoked via apply with a lazy seq argument). It's this combination of requirements that means apply should *not* construct a tuple (as in clojure-py) or cons arguments together into a list (as I'm currently doing in clojure-scheme) as these operations will cause the realization of the entire applied sequence. Given the above example, is there anyway to not have the side effects automatically run when invoking apply? Yes. If you bury an effect into the lazy-seq at some position n, it won't be realized unless the applied function is either fixed-arity up to n, or chooses to force the lazy-seq up to n (modulo chunked evaluation). My question is what would require this sort of function? Is there a use-case for a function that expects to be called via 'apply' to avoid evaluating some of its arguments? (Again, this isn't a question of thunking; The user of this hypothetical function can apply it with a strict list or a lazy list and no code needs to change--I, as a caller, don't need to explicitly thunk arguments for laziness and the fn doesn't need to explicitly force/dereference them). Put another way: why does apply need to promise not to realize its seq argument? -- 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: motivation behind laziness of apply in ClojureScript
An example of lazy apply, with your foo fn: (apply foo (iterate inc 0)) d -- 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: Polymorphic namespaces?
One example, in the frontend we wrap all the database calls in a caching
layer but we don't need that when the same code runs in the backend.
One option for something like this (a configuration option that doesn't
change much between function calls/expected to largely remain the same for
your program) is a dynamic var. You could just rebind eg *caching* to true,
and your database calls could dispatch accordingly.
Code loading is a first-order thing in Clojure as well, so you could do a
conditional require:
(if *caching* (require '[db.cached :as db]) (require '[db.uncached :as db]))
I'm not sure if this is often done, though?
I am also interested in the answer to your question. I wonder If anyone's
played with the idea of parameterized imports a la ML's functors:
(ns my-database-helpers
(require ...)
(args [ {:keys [db]}])
Then in the configuration code something like:
(require '[(my-database-helpers :db db.cached) :as helpers])
I know a big philosophy guiding Newspeak (http://newspeaklanguage.org/) is
that ALL imports should be done this way-- no code should explicitly
hard-code the libraries it uses.
--
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: motivation behind laziness of apply in ClojureScript
Put another way: why does apply need to promise not to realize its seq argument? (apply + some-lazy-seq-too-big-to-fit-in-main-memory) Not avoid evaluating some of its arguments but avoid holding onto the head in that case. I'd reach for 'reduce' in this case but that's still a valid point. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-scheme - Compiling Clojure to Scheme to C
I see the C code generation as an advantage, in that it becomes possible to target any platform with a C compiler. Can Clozure compile to iOS? Just a question, why Clojure-Scheme-C, instead of Clojure-Clozure? That way there would no be any C compiler dependency. -- 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] clojure-scheme - Compiling Clojure to Scheme to C
I've modified the output of the ClojureScript compiler to emit Scheme code. At this point the core library is successfully compiled by Gambit Scheme. A nice advantage of this is that Gambit compiles code via C, meaning that stand-alone Clojure executables are now available for any platform with a suitable gcc compiler! Gambit, notably, also compiles to iOS. Just recently I've confirmed that Clojure's core library runs on the iPad simulator. There is a ton of yak-shaving required at this point---compilation consists of a combination of shell commands, Clojure-interpreted commands and Gambit-interpreted commands. Hopefully this will soon be streamlined. https://github.com/takeoutweight/clojure-scheme -- 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: Quicksort
Couple of things to watch out for, Clojure doesn't pattern match on the args in the way you seem to be expecting, so this will blow the stack (i.e. calling qsort with the empty list won't call the 0-argument method you have there.) The error you're running into is that pop/peek isn't defined for lazy sequences. doall will force your lazy-sequence, but it's still of type LazySeq: (type (lazy-seq [1 2 3])) clojure.lang.LazySeq So putting the base-case into an if/else branch, and switching pop/peek for rest/first would look like so: (defn qsort ([list] (if (seq list) (let [piv (first list) f-half (filter (fn [n] (= n piv)) (rest list)) s-half (filter (fn [n] ( n piv)) (rest list))] (concat (qsort f-half) (cons piv (qsort s-half 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: Quicksort
Obviously the example of doall not being up to the task should read: scratch (type (doall (lazy-seq [1 2 3]))) clojure.lang.LazySeq -- 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: break-on-gaps - just curious if there is a more idiomatic way to do this
If you were feeling so inclined, you could structure this as a lazy sequence (like 'partition' does) (defn lazy-break [coll] (letfn [(break-paired [pairs] (lazy-seq (when-let [s (seq pairs)] (let [p (doall (take-while (fn [[a b]] (= (inc a) b)) pairs)) cutpoint (count p)] (cons (concat p [(nth pairs cutpoint)]) (break-paired (drop (inc cutpoint) pairs)))] (map #(map first %) (break-paired (map vector coll (rest coll)) user (take 2 (lazy-break (concat (range 4) (range 3) (range ((0 1 2 3) (0 1 2)) -- 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
defrecord and overriding empty
I'm using clojure.walk/postwalk to rewrite terms in nested data structures. However, I am unable to do this with types as defined by defrecord, because they specify that the function empty throw a not- implemented exception. If I were able to over-ride this default implementation of 'empty' I believe I could still use postwalk to rewrite my custom records (as they happily implement 'into' which works as expected.) This was my obvious first attempt: (defrecord TypeVar [guid name] clojure.lang.IPersistentCollection (empty [coll] (TypeVar. 0 nil))) Which fails due to: Duplicate method namesignature in class file types/TypeVar [Thrown class java.lang.ClassFormatError] I would prefer not to fall back on deftype as I do wish these objects to behave as maps. I also could write my own version of postwalk that doesn't call 'empty' on my custom-defined records, but it would be nice to make my types adhere to the contract of IPersistentCollection as much as possible. -- 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: advantage of dynamic typing
I am following the general strategy described in Sam Tobin-Hochstadt's work. He is the person behind typed-racket. His Phd dissertation[1] has an overview of the area of gradual/soft/refinement typing in dynamic languages. It's a good place to start, with a pretty gentle introduction to the motivations and issues involved (though I'd imagine you'd need a rough understanding of sequent calculus notation to follow his description of the semantics of his type system). [1] http://www.ccs.neu.edu/home/samth/ On Sep 27, 12:43 am, Paul Koerbitz paul.koerb...@gmail.com wrote: Hi Nathan! I am very intrigued by your approach. I would love to contribute, my problem is that I don't know the first thing about type inference systems (as in how they work on the inside). Do you have a good reference here? I'll take a look at what you've done, maybe bother you with some questions Thanks for the work! cheers Paul On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson n...@sfu.ca wrote: Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome day. -- 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 and overriding empty
You're right that my use isn't strictly returning a collection with a size of zero-- I'm treating empty more like 'default'. I'm thinking of its use in clojure.walk, which simply creates a blank version of an arbitrary collection in which to place the altered sub-forms. I can't find any other usages of 'empty' in the std lib. I agree it's a bit of a mismatch, as 'walk' won't be able to alter the built-in keys of a record, but you wouldn't expect that to happen if you were using records. Should IPersistentCollection even be defining 'empty', if one of the language's key data types doesn't support it? I think it would be better to either pull 'empty' into it's own protocol so clojure.walk doesn't match on IPersistentCollection when walking a data structure with the false expectation that it can create an empty version, or rename 'empty' it to something that records can implement, like 'default.' -- 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: iterate with side-effect function?
Because the fn is wrapped in a lazy sequence, the effects won't run if you ask for the same value again-- For instance: (def a (iterate (fn [cnt] (prn cnt) ;; save data to csv (inc cnt)) 0)) (nth a 5) ... all the effects are fired. (nth a 5) ... simply returns 5-- no effects are fired because the lazy sequence has already been realized up to this point. This may not be what you expect. Also, you shouldn't in general trust effects to be run the 'correct' amount of times. For instance, if we were operating on a chunked-sequence, if you asked for the 3rd element, you would get the side effects for the next 32 elements, which may not be what you'd expect. That doesn't happen to be the case here but it's something to keep in mind 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: iterate with side-effect function?
Quite often I convince myself I need state or some effectful trigger, but further thought reveals a simpler stateless approach. That being said--if you absolutely need to be doing something based on effects, something that absolutely can't be tracked via values in a purely functional way--like polling a queue once per second (functional-reactive programming notwithstanding), I personally prefer straight loop/recur to the list processing functions. In my mind, usings seq/filter/map suggests you are doing something lazy, referentially transparent, and composable. If you are not doing that, a loop recur signals to me you are manipulating the execution flow in a precise way. But again, I always try to find a way to avoid dealing with the messy stateful world until the last possible moment. Lots of application logic can be completely pure with one small write to file-type operation at the end. -- 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: Recursion/Algorithm Question
You're right on the doorstep again :) If you want to make a single, flat list out of two different lists, the function you're looking for is 'concat' You may find the cheat sheet helpful: http://clojure.org/cheatsheet. In this case you were looking for some operation on sequences which gave you a sequence back. There's a category for that on the sheet. It can save some time in narrowing down the docs you have to read through when you're just getting familiar with the core API. On Sep 22, 3:48 pm, ax2groin ax2gr...@gmail.com wrote: Thanks, Nathan, that did help. I'm still stuck, however, figuring out how to return the values as a flat sequence of vectors. Maybe I'm just missing the right function from the API. Here's where I'm at right now: (defn get-paths ([n] (get-paths n [0 0] '())) ([n point path] (cond (points-equal? (vector n n) point) (reverse (conj path point)) (out-of-bounds? n point) nil (blocked? point) nil :else (list (get-paths n (inc-y point) (conj path point)) (get-paths n (inc-x point) (conj path point)) So, right now when I call the function with nothing blocked (get-paths 1) it returns ((nil ([0 0] [0 1] [1 1])) (([0 0] [1 0] [1 1]) nil)) but what I want is (([0 0] [0 1] [1 1]) ([0 0] [1 0] [1 1])) so that a call to (count) would return the total number of paths. -- 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: advantage of dynamic typing
Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typinghttp://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logichttps://github.com/clojure/core.logicsome day. -- 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: using finger trees in two dimensions
What are your ideas? You can implement a balanced k-d tree on top a normal vector, so that would be my first thought. -- 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: Addition of new a priori distinct element to a vector
Just to clarify, you want to conj a vector to itself? i.e. [1 2 3 4] -- [1 2 3 4 [1 2 3 4]] I'm curious what the application of this is. Regarding the overhead of conj-ing to a vector: Clojure's data structures make use of structural sharing so conjoining an element to the end of a vector won't require any copying of entire vectors. It's a cheap, constant(ish) time operation. -- 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: Recursion/Algorithm Question
A recursive formulation is exactly the right idea. Also, you're right when you say it won't work with recur as you've set it up. In fact, you won't be able to use recur at all in this situation as a you are doing a depth-first search through possible paths--it's impossible to formulate a depth-first search as a tail-recursive function. You are definitely on the right track with your current idea. Though I would offer a hint: it's even simpler to return a sequence of all the paths (in a way very similar to how you've set it up) without using ANY of the state ref types. On Sep 21, 9:29 am, ax2groin ax2gr...@gmail.com wrote: I've been working through algorithm problems to learn the language a little better. I'm currently struggling with the question about a robot traversing a grid. If the grid is completely open, then the answer to how many possible ways to traverse the grid? is simply the math for combinations using factorials (see Project Euler #15). But if you suppose that some places in the grid are blocked or that you have to actually traverse the paths? I know that the code below doesn't work yet (recur is not at the tail). Think of it as pseudo-code to show my intent. I've left out the other methods to get at the heart of what I'm asking about. Essentially, each path leads to two more recursion points (at least the way I've formulated it in my else), until they finally run out of bounds or meet the goal. The input n represents the width of the square grid. I'm using a two-element vector to represent a point in the grid. (defn get-paths [n] (let [paths (agent '()) goal (vector n n)] (loop [point [0 0] path '()] (cond (points-equal? goal point) (send paths conj (conj path point)) (out-of-bounds? n point) nil (blocked? point) nil :else (recur (inc-x point) (conj path point)) (recur (inc-y point) (conj path point (deref paths))) Perhaps ultimately, the approach I've tried here is a dead-end? I'm not sure that this loop formulation would ever exit, or perhaps it would exit too quickly. -- 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: advantage of dynamic typing
These types of discussions seem to get very broad in their scope and not much is ever settled. That being said, it seems one place where dynamic typing is a huge advantage is for records--Clojure records are prevalent and extremely easy to use, and are an excellent substrate for where we would normally use objects. Now, it's possible to have records in statically typed languages, but there are many different ways to do it, and not all buy you the same properties you enjoy in a dynamic language (duck-typing a record if it contains the correct fields, adding additional fields the library designer didn't originally allow, etc.) Haskell has been trying for years to get a grip on it's record story. This isn't because it's impossible to have nice records in a static type system, it's simply because with a static type system you have to make a careful up-front choice about what your type system will allow. In a dynamic language you have none of these worries, and you are free to impose whatever invariants you like on your records. Great power/great responsibility, etc. On Sep 21, 12:09 pm, Dennis Haupt d.haup...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.09.2011 19:58, schrieb Ken Wesson: On Wed, Sep 21, 2011 at 3:00 AM, Dennis Haupt d.haup...@googlemail.com wrote: yes, but you magically need to know a) for which types does it work? if you give a byte to the function, will you get an error, or its first bit? or its first char after its been converted to a string? b) if i want my data structure to support this, how do i have to do that? I'm curious: in what world is API documentation considered to be magical? :) - -- good point. in my experience, public apis often are well documented (no problem with clojure standard lib) while in-team-code is rarely documented at all -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOejZrAAoJENRtux+h35aGZ8gP/0sKZAOSjMLYZgD0pFy9vs5v 54wUcP9/D+YEreM8hW67P1j0lNcRqFzEjPDvGX+dykdrZKOrfQ1xpFboiARusLSn XbtoO4vlkwxwwMv9kcB6DyWtTsP7vEc9M9jJkHRNEERynk6DKBrtAX0RHXz4Qfyj uHHovEG+a68vcbrY1C9GqRck/Qqhdn0JjoKwFXkZGEUaPVf6rLRfav/JY8wl5Mj2 AKYhj/0LTUCknqkMFYkflAdLLVFjYLWX+zAeac18E2/RtRFFT5kedhYzHe3CpPY4 x6BaT5hCS/fZkyYR2kzbar1F18RL4vixmg8HbjGceLLOobW2r5EVyNRxQMv8DIpi XkjZiW0jqC6XFpoK2KVCaMzJwM46SWNoY6xYglV9/prdQ0Jmf5Isa/FVL+T24Mrq uaI6AzlKMHk4NzfQNEvJYr22q/H9oT8waEPKDMtWgQsFkSwRFotCfkqu1L5T78MT BlPek1RIZLTPjxt4kXNwdTC0Q52hiLKNNJakIEakHxSdlwmeT+1i3b+v+luFfdw6 6mGb0H8x0pUJKnU/QHFzPA/hPhg0LMOhdwTdvUm+O/7cbFhAakvhLMdUZlEmj70Y 9DugBMLto6bHyMk4kXUyHzP4ProiFmTwNE5P5UFhtl60svAmkxYuQXFl6JeisxX/ zTIgie+GRZPuGSTtcKPy =pfvF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure type casting vs java type casting
long entails a call to RT/longCast, which dynamically dispatches on the type of the object passed to it. I haven't tested this, but i would imagine the java cast would compile directly to the single byte- code instruction i2l. Presumably, then, the java call would be a touch faster by a few instructions. Of course the standard disclaimer applies: you have to be wary of making performance decisions w/o benchmarking, especially with a good hotspot compiler under your feet. On Sep 17, 7:55 am, Brent Millare brent.mill...@gmail.com wrote: Is the following clojure code: (long (.some-method-that-returns-int this)) equivalent in semantics and performance to the following java code: (long)some-method-that-returns-int(); I need to make type casts in an inner loop (hot zone), and I was wondering if there was something implicit that makes writing it in java faster. -- 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: Spread work onto multiple threads (in pure Clojure)
Futures begin executing their contents immediately, you don't have to deref them to trigger the side effects. (perhaps you were thinking of delay?) I'm assuming you are using futures because email-request is an io- blocking operation? The thing to note is that the body of a future automatically runs in its own thread, so you could go ahead and just do a regular map: (doall (map #(future (email-request %)) approved)); all the emails would then be sent in parallel threads. On Sep 21, 4:06 pm, ronen nark...@gmail.com wrote: I was looking for a pure Clojure solution to run multiple non- dependant tasks on multiple threads, iv considered using Agent, Promises or Futures, yet the simplest cleanest succinct solution iv found is: (defn email-approved [approved] (doall (pmap deref (for [req approved] (future (email-request req)) The only thing that I don't like about it is the use of pmap, main since Im using the parallel mapping action just for side effects (triggering the consumptions of futures by derefing them). Iv seen solution that involve Java service executor and the Work project (https://github.com/getwoven/work), yet id rather achieve this in pure Clojure. Thanks Ronen -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure vs Scala - anecdote
I adore Clojure as well, but could this success not be partially due to the reimplementing for the second time phenomenon? i.e. if you re- wrote the entire thing in Scala again, perhaps you would see similar gains in brevity etc? On Sep 6, 10:32 pm, Sean Corfield seancorfi...@gmail.com wrote: I just wanted to share this experience from World Singles... Back in November 2009, we started developing with Scala. We needed a long-running process that published large volumes of changes from our member database as XML packets published to a custom search engine. The mapping from half a dozen tables in the database to a flat XML schema was pretty complex and the company had tried a number of solutions with mixed success in the past. I introduced Scala based on the promises of performance, concurrency and type safety - and conciseness (especially with XML being a native data type in Scala). We've been running the Scala publishing daemons in production for most of two years. Generally they work pretty well but, under stress, they tend to hit Out of Memory exceptions and, after a lot of poking around, we became fairly convinced it was due (at least in part) to the default actor implementation in Scala. Scala is going to fold in Akka soon and we had been considering migrating to Akka anyone... But having introduced Clojure this year (after experimenting with it since about May last year), we figured we'd have a short spike to create a Clojure version of the Scala code to see how it worked out. It took about 15 hours to recreate the publishing daemon in Clojure and get it to pass all our tests. Today we ran a soak test publishing nearly 300,000 profiles in one run. The Scala code would fail with OoM exceptions if we hit it with 50,000 profiles in one run (sometimes less). The Clojure code sailed thru and is still happily running - so we'll be replacing the Scala code during our next production build. The other aspect that's interesting is that the Scala code totaled about 1,000 lines (about 31k characters of code). The Clojure replacement is just under 260 lines (around 11.5k characters of code). Neither code base has much in the way of comments (*ahem* - I'm not proud of that, just pointing out that there's no noise offsetting the code comparison). That doesn't include unit tests either, it's just the raw production code. The form of the Clojure code mostly follows the form of the Scala code, most of the same functions - it was very functional Scala - with some refactoring to helper functions to make it more modular and more maintainable. The net result is (obviously) that we'll be taking the Clojure publishing daemon to production and we'll be dropping Scala completely. Kudos to Rich Hickey and the Clojure/core team for creating a great general purpose language that can solve big problems - thank you! -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Railo Technologies, Inc. --http://www.getrailo.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: 2D graphics options with Clojure?
Batik can serialize to both PNG and PDF. http://xmlgraphics.apache.org/batik/ I currently use Batik in a clojure project doing a lot of drawing of 2d vector-based images. It's a very extensive library but it suits my needs well. On Apr 29, 9:26 pm, stu stuart.hungerf...@gmail.com wrote: Hi, I'm developing a Clojure project that loads and creates a bunch of simple 2D geometry (lines, polygons, beziers, text etc). I need to create in a batch-style way high quality 2D renderings of that geometry, firstly as PNG files and secondly as PDF files. What are my options for doing this from Clojure? So far I can see it might be done with Java2D as I think this can be used server-side to create the PNG files, but not sure about the PDFs. I believe I can use Incanter's wrapping of the Processing libraries for the PNG and again I'm not sure about the PDF option. The Cairo toolkit is also an option via the Gnome Java bindings and Java interop? Are there other options that I'm missing that anyone would like to report on? Thanks in advance, Stu -- 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: SubVector's (via 'subvec') do not support 'transient'
I've read that, and the claim seems to be that Vectors support transience. Within Clojure's abstraction SubVectors are Vectores: (vector? (subvec [1 2 3] 0 2)) = true. On Apr 30, 8:27 am, Armando Blancas armando_blan...@yahoo.com wrote: Check this out:http://clojure.org/Transients On Apr 29, 10:54 am, Nathan Sorenson n...@sfu.ca wrote: (transient (subvec [1 2 3 4 5] 0 2)) fails with a class cast exception. Is this expected/unavoidable? How do I know whether the vectors I'm passed are regular vectors or come via subvec? I'm assuming I lose all the performance benefits of subvec if I defensively pour all vectors into a new vector before calling transient? I'm on clojure 1.3.0-alpha4 -- 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: SubVector's (via 'subvec') do not support 'transient'
Yes but the contract of subvec is that it returns a persistent vector and the resulting data structure returns true under the vector? predicate. I know that subvec returns a different type because I've looked at the Java source code but that's a leaky abstraction. On Apr 30, 10:57 am, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 30, 2011 at 11:27 AM, Armando Blancas armando_blan...@yahoo.com wrote: On Apr 29, 10:54 am, Nathan Sorenson n...@sfu.ca wrote: (transient (subvec [1 2 3 4 5] 0 2)) fails with a class cast exception. Is this expected/unavoidable? How do I know whether the vectors I'm passed are regular vectors or come via subvec? I'm assuming I lose all the performance benefits of subvec if I defensively pour all vectors into a new vector before calling transient? I'm on clojure 1.3.0-alpha4 Check this out:http://clojure.org/Transients There is no mention of subvec on that page. -- 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
SubVector's (via 'subvec') do not support 'transient'
(transient (subvec [1 2 3 4 5] 0 2)) fails with a class cast exception. Is this expected/unavoidable? How do I know whether the vectors I'm passed are regular vectors or come via subvec? I'm assuming I lose all the performance benefits of subvec if I defensively pour all vectors into a new vector before calling transient? I'm on clojure 1.3.0-alpha4 -- 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
*ns* unexpectedly changing on me, via SwingUtilities/invokeLater
I want to examine the namespace within a swing thread, as I want to see if a particular var is defined from another part of the program before operating on it. However, inside the do-swing macro (or just using SwingUtilities/invokeLater directly) *ns* will always refer to clojure.core, not the namespace of the file I'm working on. eg: (ns some-namespace) (javax.swing.SwingUtilities/invokeLater (fn [] (println *ns*))) will print: #Namespace clojure.core But if I'm defensive and copy *ns*: (ns other-namespace) (def this-namespace *ns*) (javax.swing.SwingUtilities/invokeLater (fn [] (println this- namespace))) will print: #Namespace other-namespace as expected. Interestingly, all DEF instructions are interned into the expected namespaces: other-namespace (javax.swing.SwingUtilities/invokeLater (fn [] (def somevar 1))) nil other-namespace somevar 1 other-namespace clojure.core/somevar ; Evaluation aborted. other-namespace other-namespace/somevar 1 Is this expected behaviour? -- 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
Emacs slime repl now printing carriage returns after Clojure 1.3.0-alpha5
In my clojure repl, i'm now seeing CTRL-M characters at the end of each line printed to the repl (println commands, doc commands etc...). If I launch the swank-repl from Cygwin I still see these ^M's. Am I to assume this relates to this added feature: Java's line.separator property for newline? I'm just wondering which program in the chain I should fix: clojure, swank-clojure, or emacs? -Nathan -- 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: Emacs slime repl now printing carriage returns after Clojure 1.3.0-alpha5
I'm using Windows 7, and again, I see this behaviour when using the regular windows shell or Cygwin to launch the swank-repl. On Mar 16, 12:10 pm, Nathan Sorenson n...@sfu.ca wrote: In my clojure repl, i'm now seeing CTRL-M characters at the end of each line printed to the repl (println commands, doc commands etc...). If I launch the swank-repl from Cygwin I still see these ^M's. Am I to assume this relates to this added feature: Java's line.separator property for newline? I'm just wondering which program in the chain I should fix: clojure, swank-clojure, or emacs? -Nathan -- 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: ANN: Textmash - another IDE for Clojure
I've always wanted to have an in-game scripting console that has
access to some of the functionality I'm used to in emacs, like
paredit. This would actually be really useful in achieving this, I
think!
On Jan 19, 1:44 am, Laurent PETIT laurent.pe...@gmail.com wrote:
Hello,
2011/1/18 Olek aleksander.nas...@gmail.com
Hi,
Here is a link:http://code.google.com/p/textmash/
Some time ago I have written it in order to help accomplish a task of
creating some paraller processing system written entirely in Clojure
(it was the map reduce framework from Google).
It was also used with success in other tasks, like editing PHP pages,
Clojure learning, writing small programs in Clojure and some simple
text processing.
Feel free to contribute in bug fixing and improving or maybe even
rewriting it in Clojure (there are not too much lines of code).
There's a task I have in my todo list since a long time, which is to
extract more of ccw structural editing and clojure source code grammar
parser into external projects.
Currently, structural editing in ccw is already totally decoupled from
Eclipse, or even any graphical toolkit (Swing / SWT). The only dependencies
of the clojure grammar definition+parsley parser+structural edition
a-la-paredit commands are clojure and clojure-contrib.
If you're interested, I could reprioritize this task and put it near the top
of my todo list.
As an example, calling a paredit.clj command looks like this: call a
multimethod named paredit.core/paredit:
* call the parser to get a parsetree. Note that the parsetree follows
clojure.xml format.
* give the parsetree to the paredit command, along with the command name
and the state of the editor (plain textual content, cursor position,
selection length). As a result you'll get a set of text changes to apply to
the source code in the form of a list of maps representing deltas: {:keys
[offset length text]} (in the original source code, replace the range
[offset (+ offset length)[ with text to effectively apply the paredit
command you invoked)
in code (pseudo-code, not my dev environment at hand), this would look like
with the current shape of the code/namespaces:
;; how would we invoke raise over sexp to get (spy foo) transformed into
foo with the cursor before f char and no current selection
(require '[paredit.parser :as p] '[paredit.core :as s])
(let [original-code (spy foo)
parsetree (p/parse original-code)
raise-over-delta (s/paredit :paredit-raise-sexp parsetree {:text
original-code :offset 5 :length 0})]
raise-over-delta)
= {:text (spy foo) :offset 5 :length 0 :modifs [ {:text foo :offset 0
:length 9} ]}
HTH,
--
Laurent
The main idea is to take what is best in Eclipse, NetBeans and
ergonomy of Mac OS and put into light tool.
I hope you will enjoy it.
Bye!
--
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.comclojure%2bunsubscr...@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
Tagless-final Interpretations in Clojure (can it be done better than this?)
After reading Oleg's lecture Typed tagless-final interpretations ( http://okmij.org/ftp/tagless-final/course/ ), I decided to see if this was possible, or made any sense, to follow this style in Clojure. The idea is that, instead of representing a DSL syntax as a data structure that you interpret, you represent syntax directly as functions, which dispatch (in the Haskell case, using type classes) depending on how you want to interpret the expressions. This approach lets you extend the syntax easily, as well as add new interpreters easily. Thus, you can avoid the expression problem when creating your DSLs. In Clojure, we can't dispatch on return types, so the best I came up is https://gist.github.com/782454 which dispatches on a dynamic var (also attached below). I would have liked to use protocols somehow, but it's not clear how this could be done. Clearly we have, at compile time, all the information regarding which specialized method to call -- we shouldn't have to use slow multimethods. Speed isn't important in this simple example, but it might become critical if we were to interpret huge expression trees. ;the gist: https://gist.github.com/782454 (def *interpreter* nil) (defmulti lit (fn [i] *interpreter*)) (defmulti neg (fn [i] *interpreter*)) (defmulti add (fn [a b] *interpreter*)) ;'eval' instance (defmethod lit :evaluate [x] x) (defmethod neg :evaluate [x] (- x)) (defmethod add :evaluate [x y] (+ x y)) ;'show' instance (defmethod lit :show [x] (str x)) (defmethod neg :show [x] (str (- x ))) (defmethod add :show [x y] (str ( x + y ))) (defmacro evaluate [expr] (binding [*interpreter* :evaluate] (eval expr))) (defmacro show [expr] (binding [*interpreter* :show] (eval expr))) ;(evaluate (add (lit 3) (neg (lit 2 ; 1 ;(show (add (lit 3) (neg (lit 2 ; (3 + (-2)) -- 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
Any clean way to avoid explicit recursion when creating nested loops?
I was discussing this on the clojure channel, and it seems as though avoiding explicit recursion is the idiomatic thing to do. Is there a better way to define a function that loops over an arbitrary number of sequences in a nested fashion, similar to the 'for' macro, without relying on recursion? This is the current approach, using recursion: (defn nested [ seqs] returns lazy 'for'-like nesting of a seq of seqs. (letfn [(nestrec [prefix [list deeper-lists]] (if deeper-lists (mapcat #(nestrec (conj prefix %) deeper-lists) list) (map #(conj prefix %) list)))] (nestrec [] seqs))) so (nested (range) [:a :b]) returns [[0 :a][0 :b] [1 :a] [1 :b] [2 :a] ... ] -- 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: Any clean way to avoid explicit recursion when creating nested loops?
That's perfect, thanks! On Sep 30, 4:55 pm, Mark Engelberg mark.engelb...@gmail.com wrote: clojure.contrib.cartesian-product does what your nested function does, but more efficiently, using iteration rather than recursion. -- 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: Macro closing over atom gives Can't embed object in code error.
I think I understand; the unquote operator is not providing a reference to the underlying object itself, but is rather a procedure that translates the object into a code representation. Thank-you for the explanation. On Sep 19, 6:53 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: A macro is a function which returns a data structure representing code to be compiled. All literals (String, Integer, symbol, etc.) and basic data structures (lists, maps, etc.) can be compiled, as can functions. Most other non-literal objects *cannot* be compiled. What you probably want is not a macro but a closure: (defn hidden-atom [] (let [a (atom :hello)] (fn [] (deref a (def x (hidden-atom)) (x) ;;= :hello -S On Sep 19, 12:32 am, Nathan Sorenson n...@sfu.ca wrote: I am playing around with a macro to define accessor functions for a closed-over atom. Here is a simplified example: (defmacro hidden-atom [] (let [a (atom :hello)] `(defn get-value [] (deref ~a When I evaluate this macro, I get the error: Can't embed object in code, maybe print-dup not defined: clojure.lang.a...@1a7693a I imagined this should work, as the above macro doesn't seem too different from the following macro, which does work: (defmacro hidden-function[] (let [a (fn [] :hello)] `(defn get-value [] (~a When using macroexpand-1, both macros return nearly identical forms: gdsl.proc (macroexpand '(hidden-atom)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (clojure.core/deref #a...@10a5e22: :hello))) (.meta (var gdsl.proc/get-value gdsl.proc (macroexpand '(hidden-function)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (#proc$hidden_function$a__15149 gdsl.proc$hidden_function $a__15...@bde2da))) (.meta (var gdsl.proc/get-value I'm afraid I don't know enough about macro expansion to understand what is wrong here. -- 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
Macro closing over atom gives Can't embed object in code error.
I am playing around with a macro to define accessor functions for a closed-over atom. Here is a simplified example: (defmacro hidden-atom [] (let [a (atom :hello)] `(defn get-value [] (deref ~a When I evaluate this macro, I get the error: Can't embed object in code, maybe print-dup not defined: clojure.lang.a...@1a7693a I imagined this should work, as the above macro doesn't seem too different from the following macro, which does work: (defmacro hidden-function[] (let [a (fn [] :hello)] `(defn get-value [] (~a When using macroexpand-1, both macros return nearly identical forms: gdsl.proc (macroexpand '(hidden-atom)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (clojure.core/deref #a...@10a5e22: :hello))) (.meta (var gdsl.proc/get-value gdsl.proc (macroexpand '(hidden-function)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (#proc$hidden_function$a__15149 gdsl.proc$hidden_function $a__15...@bde2da))) (.meta (var gdsl.proc/get-value I'm afraid I don't know enough about macro expansion to understand what is wrong here. -- 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: Reduce a function over more than one sequence (like map)
Thanks for the replies. Indeed, I have been approaching the issue with
destructuring, as suggested. It still seems to me that reduce* is
consistent with the behaviour of map, in that it is polyvariadic and
doesn't require packing arguments into and out of a single sequence.
However, its good to know the destructuring approach is more or less
the obvious way to go about things, and I am not overlooking an
idiomatic approach.
On Jun 12, 3:53 am, Jürgen Hötzel juer...@hoetzel.info wrote:
2010/6/11 Nathan Sorenson n...@sfu.ca:
Is there a way to fold over multiple sequences, in the same way that
'map' can apply a multi-parameter function over several seqs? In other
words, is there a function like this:
There is no need for a special purpose reduce* function.
Using destructing binding as Sean explains and creating an
intermediate lazy sequence of key/value pairs, this leads to short and
concise code:
(reduce (fn [m [k v]] (assoc m k v)) {} (map vector [:one :another]
(iterate inc 1)))
A good example of Alan J. Perlis quote and Clojure rationale:
It is better to have 100 functions operate on one data structure than
to have 10 functions operate on 10 data structures.
Jürgen
--
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
Reduce a function over more than one sequence (like map)
Is there a way to fold over multiple sequences, in the same way that
'map' can apply a multi-parameter function over several seqs? In other
words, is there a function like this:
(defn reduce*
[f val colls]
(reduce (fn [acc args] (apply f acc args))
val
(apply map vector colls)))
That behaves like this:
(reduce* assoc {} [:one :another] (iterate inc 1))
{:one 1, :another 2}
--
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
Parameter ordering on map/reduce
First of all, I would like to thank Rich and this community for producing such a pleasurable language, and for putting up with with all the unpleasant nit-picking of new users. That being said... I am curious as to why the function parameter is specified before the collection parameter in map/reduce. I have never used a lisp before, and may not be aware of idiomatic style, but it seems to be the convention elsewhere in Clojure (assoc, conj, .method calls, etc...) to have the altered data structure be the first parameter. Would this not allow mixing map into a threaded expression: (- [1 2 3] (map inc) (assoc 0 4) (reduce +) (conj :anotherthing)) Perhaps this style is rare in practice? Certainly it is easy enough to write a custom map/reduce which acts this way, so I suppose my question is mostly philosophical. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Parameter ordering on map/reduce
The let- macro looks very useful. Thank-you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
