Re: Strange behaviour of a callable record

Thanks, Nicola! It solved it. When I looked at docs, I couldn't figure out the role of `applyTo`. Well, now I know. On Thursday, April 23, 2015 at 1:47:11 PM UTC+2, Nicola Mometto wrote: > > > You're not implementing IFn.applyTo, you should. > > Why applyTo is used in the second example while in

Re: Strange behaviour of a callable record

It would be great if the ticket has more of the original use case as motivation. On Thursday, April 23, 2015 at 7:00:51 AM UTC-5, Nicola Mometto wrote: > > > I've opened an enhancement ticket with a patch that changes this > behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 >

Re: Strange behaviour of a callable record

I've opened an enhancement ticket with a patch that changes this behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 Alexey Cherkaev writes: > Hi, > > I have encountered the problem with Clojure 1.6.0, when I create the record > that implements IFn. > > For example, > > (defrecord Foo [x]

Re: Strange behaviour of a callable record

You're not implementing IFn.applyTo, you should. Why applyTo is used in the second example while invoke is used in the other cases has to do with implementation details of how def expressions are compiled/evaluated. Alexey Cherkaev writes: > Hi, > > I have encountered the problem with Clojure 1

Strange behaviour of a callable record

Hi, I have encountered the problem with Clojure 1.6.0, when I create the record that implements IFn. For example, (defrecord Foo [x] clojure.lang.IFn (invoke [_ f] (f x))) Than create an instance of this record: (def f (->Foo 10)) And we can call it without a problem: user=> (f inc)

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Then all of them must be schizophrenic: forcing delay X while forcing delay X gives a stack overflow except if the delay happens to be the rest-part of a lazy seq, and then gives nil instead making the sequence seem to terminate early. That's very odd. How does it "know" whether the delay it's

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Clojure 1.6.0 user=> (def foo (delay (str @foo))) #'user/foo user=> @foo StackOverflowError clojure.lang.Delay.deref (Delay.java:37) user=> same with Clojure 1.7.0-master-SNAPSHOT, I don't see it returning nil as you said. On Fri, Feb 13, 2015 at 7:53 AM, Fluid Dynamics wrote: > On Friday, Feb

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Clojure 1.5.1 user=> (def bar (cons 1 (map #(do (println %) (+ (nth bar %) %)) (range #'user/bar user=> (take 10 bar) (0 1 IndexOutOfBoundsException clojure.lang.RT.nthFrom (RT.java:795) It is possible that it is lein/REPLy that's causing the output not to be print, I've seen it done a num

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

And here's some really crazy behavior from 1.5.1! => (def bar (cons 1 (map #(do (println %) (+ #_(nth bar %) %)) (range #'user/bar => (take 10 bar) (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 0 1 2 3 4 5 6 7 8) => (def bar (cons 1 (map #(do (println

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

On Friday, February 13, 2015 at 12:47:17 AM UTC-5, Justin Smith wrote: > > I don't want to sound too brusque in my defense of Clojure. I'm a huge > fan, so criticism of the language does get me a bit defensive. > I am a fan as well. Constructive criticism is useful as it can lead to improvements

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

To go into a bit more detail about what this code does: Here's the code formatted idiomatically - (defn divides? [x y] (zero? (mod x y))) (defn prime-ub [x] (/ x (if (even? x) 2 3))) (defn lower-primes [primes x] (let [ub (prime-ub x)] (take-while #(<= % ub) primes))) (defn prime? [prime

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

On Friday, February 13, 2015 at 12:05:24 AM UTC-5, Justin Smith wrote: > > it's an infinite lazy sequence with itself as a dependency. The first n > elements see a value of the initial non-lazy prefix. The alternative would > be a compilation error. Nope. Every component of the sequence should

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

it's an infinite lazy sequence with itself as a dependency. The first n elements see a value of the initial non-lazy prefix. The alternative would be a compilation error. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send em

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

it's an infinite lazy sequence with itself as a dependency. The first n elements see a value of the initial non-lazy prefix. The alternative would be a compilation error. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send em

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

On Thursday, February 12, 2015 at 11:24:03 PM UTC-5, Justin Smith wrote: > > Not unbound primes, primes as (cons 2 ...). If you look at my post above > where I added a print statement to prime? the first 32 inputs see (2) as > the value of primes. 32 is the chunking size of the range function.

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Oh, it's much worse than anyone has mentioned yet. The whole (def primes ...) bit is also a problem. What you are saying to the compiler is "create a var named primes and assign it this lazy-seq...", and then while defining that lazy seq you are creating closures that use "primes". That sort of cir

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Not unbound primes, primes as (cons 2 ...). If you look at my post above where I added a print statement to prime? the first 32 inputs see (2) as the value of primes. 32 is the chunking size of the range function. -- You received this message because you are subscribed to the Google Groups "Clo

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

I really fail to see how this can be related to chunking. So in: (def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3 (range)) *prime?* would be being called with unbound *primes*? And no exception would be raised and again no 4 or even numbers left to testify? Em sexta-feira,

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Clojure is quite elegant, but it's not always unsurprising. Even if one surprising behavior around lazy-seq realization is changed, others are likely to continue to occur. The solution to this is to not write code that implicitly relies on a specific timing of lazy realization. If you need resu

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Even THIS works now: (defn primes [] (let [primes' (atom nil)] (reset! primes' (cons 2 (filter #(prime? @primes' %) (iterate inc 3)) Em sexta-feira, 13 de fevereiro de 2015 01:28:13 UTC-2, Jorge Marques Pelizzoni escreveu: > > Anyway, I would be in awe that being Closure

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Anyway, I would be in awe that being Closure such an expressive and elegant language its user base is really ok with an state of affairs in which: (def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3 (range)) does not mean what it obviously should and above all means something

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

no, we have not moved past this, and the error is absolutely because you take too much for granted about lazy behavior (defn divides? [x y] (zero? (mod x y))) (defn prime-ub [x] (/ x (if (even? x) 2 3))) (defn lower-primes [primes x] (let [ub (prime-ub x)] (println "primes" primes "x" x) (tak

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

So why isn't 4 and any even numbers in the result list? Empty primes' allows everything to pass. We are already beyond this. I've already posted that even this does not work: (def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3 (range)) Em sexta-feira, 13 de fevereiro de 2015

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Considering for the sake of argument the possibility that it is a legitimate bug, and not a result of misusing the language features, it is a family of bug that will be more common than most, because it reflects a style of programming that is rare in real Clojure code. But it isn't a bug. Lazy

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Not even this works (in which I try to avoid state mutation): (def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3 (range)) Em quinta-feira, 12 de fevereiro de 2015 23:26:03 UTC-2, Fluid Dynamics escreveu: > > AFAICT the issue here is combining lazy evaluation with state mutat

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

AFAICT the issue here is combining lazy evaluation with state mutation. Don't do that. :) -- 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 - p

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Beautiful, Armando! Thanks for your the insight. Anyway, I really don't buy the "that's the way it is" argument. Totally looks like a bug and I don't find it a coincidence it is working differently in the development branch. Thank you all for your time :) Em quinta-feira, 12 de fevereiro de 20

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

This is excellent, I was just working out something similar myself. The version using an atom is not idiomatic Clojure, and isn't a translation of the Haskell version either. On Thursday, February 12, 2015 at 4:30:02 PM UTC-8, Armando Blancas wrote: > > Jorge, I tried this on 1.6 and seemed to w

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Jorge, I tried this on 1.6 and seemed to work: (def primes (cons 2 (for [n (iterate inc 3) :when (prime? primes n)] n))) On Thursday, February 12, 2015 at 4:21:45 PM UTC-8, Jorge Marques Pelizzoni wrote: > > Neither did delay help: > > (defn primes [] (let [primes' (atom nil)] >

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Laziness is pervasive in Haskell, for all computation (unless you force it off with special constructs). Laziness in Clojure is as pervasive as sequences, but it is not for all computation like in Haskell, and sequences have the previously-mentioned features of sometimes-more-eager-than-the-minimu

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Neither did delay help: (defn primes [] (let [primes' (atom nil)] (reset! primes' (delay (cons 2 (filter #(prime? (force (deref primes')) %) (drop 3 (range Serious this is not a bug? Em quinta-feira, 12 de fevereiro de 2015 22:14:46 UTC-2, Jorge Marques Pelizzoni esc

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Thanks, Michael, for your analysis and explanation. However not even this worked: (defn primes [] (let [primes' (atom nil)] (lazy-seq (reset! primes' (lazy-seq (cons 2 (lazy-seq (filter #(prime? (deref primes') %) (drop 3 (range)) And one thing we klnow for sure is th

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Hmm, upon further investigation I think I would not call this a bug in Clojure that got fixed, I think I'd call this an unspecified behavior in Clojure that happened to break your function and now happens to allow it to work. Your function depends heavily on Clojure's laziness, and laziness is an

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Or perhaps 1.7.0-alpha5 has a change vs. 1.6.0 that makes this code work by accident. Using lazy sequences to define later elements in terms of the prefix of the sequence up to that point has come up multiple times, usually with the example of generating primes (but different code each time). I d

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Well, that's a bug then :) And seems to have been fixed. Thanks! Em quinta-feira, 12 de fevereiro de 2015 17:51:13 UTC-2, Michael Blume escreveu: > > Oh, well this is fun -- with bleeding edge clojure I get the right answer, > but with 1.6.0 I see the same results you did. > > > -- You receive

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Oh, well this is fun -- with bleeding edge clojure I get the right answer, but with 1.6.0 I see the same results you did. On Thu Feb 12 2015 at 11:47:54 AM Michael Blume wrote: > Strange, when I run your code I don't get 9 or 15 > > On Thu Feb 12 2015 at 11:02:00 AM Jorge Marques Pelizzoni < > j

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Strange, when I run your code I don't get 9 or 15 On Thu Feb 12 2015 at 11:02:00 AM Jorge Marques Pelizzoni < jorge.pelizz...@gmail.com> wrote: > Hi, there! Please bear with me as I am very new to Closure (this is my > second program ever) but have a kind of solid Haskell background. > > I was tr

[newbie] strange behaviour in self-referential primes lazy-seq attempt

Hi, there! Please bear with me as I am very new to Closure (this is my second program ever) but have a kind of solid Haskell background. I was trying to get a version of this Haskell code: divides x y = mod x y == 0 primeub x = div x (if even x then 2 else 3) isprime primes x = all (not . divide

Re: bool with strange behaviour

Got it, thanks! *--* *Eduardo Aquiles Radanovitsck* ThoughtWorks Brasil On Tue, Feb 3, 2015 at 1:59 PM, Andy Fingerhut wrote: > Eduardo: > > This is due to the weirdness in Java, and Java's own documentation > recommends against using the Boolean class constructor. See the discussion > at this

Re: bool with strange behaviour

Eduardo: This is due to the weirdness in Java, and Java's own documentation recommends against using the Boolean class constructor. See the discussion at this link for more details: http://clojuredocs.org/clojure.core/if Andy On Tue, Feb 3, 2015 at 3:16 AM, Eduardo Aquiles Affonso Radanovitsck

bool with strange behaviour

Hello, we stepped into this on my team and we couldn't figure it out why the different behaviour of the first line. Could someone with deeper knowledge of the language explain us? (if (Boolean. false) 1 2) => 1 (if false 1 2) => 2 (if (Boolean/FALSE) 1 2) => 2 (if (= false (Boolean. false)) ​​ 1 2

Re: Strange behaviour for proxy when two abstract classes are passed in

Ah no wonder! I was looking at the wrong documentation for asm. On 02/04/2014, at 1:41, "A. Webb" wrote: > > > On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote: >> >> I know this is a silly example but I am curious to know what is happening >> with the proxy method. >> >> I have

Re: Strange behaviour for proxy when two abstract classes are passed in

On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote: > > I know this is a silly example but I am curious to know what is happening > with the proxy method. > > I have set up two calls to proxy: > > 1. > (def cp > (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] [])) > > 2. >

Strange behaviour for proxy when two abstract classes are passed in

I know this is a silly example but I am curious to know what is happening with the proxy method. I have set up two calls to proxy: 1. (def cp (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] [])) 2. (def cp (proxy [clojure.asm.ClassVisitor java.util.AbstractMap] [])) The fi

Re: core.cache strange behaviour for short ttl

It's definitely one of the less intuitive aspects of dealing with core.cache but it bites you once (or twice!) and you internalize it and kinda move on :) Sean On Mar 3, 2014, at 1:57 PM, dan.stone16...@gmail.com wrote: > In case anyone was wondering I worked out what was going on and it makes

Re: core.cache strange behaviour for short ttl

In case anyone was wondering I worked out what was going on and it makes perfect sense. I was being stupid :) If you ask for a value via 'lookup' expired values will not be returned at this point as 'has?' is called internally. I made a quick and dirty library to reflect the behaviour I want f

core.cache strange behaviour for short ttl

Taking the code below, if I repeatedly read from a cache I will occasionally get nil back from the cache. This seems to happen on my machine for ttl's under 5 ms. Although I'm sure I would never use such a short TTL in the wild, I would like to know why I am seeing this... Has anybody else notic

Re: Very strange behaviour in reducers

Ok, but apparently I'm not the only one to be puzzled by this behaviour, which we may regard as an inconsistency. Just to know, is it planned to be changed? (so that I can note it and remember it if I have an error that appears in this part of my code after a clojure upgrade) Le mardi 14 janvie

Re: Very strange behaviour in reducers

Similar threads are https://groups.google.com/forum/?hl=en#!topic/clojure/A1gW_BB_4MU https://groups.google.com/forum/?hl=en#!topic/clojure-dev/scvyi2Cwk7g Luca Il giorno martedì 14 gennaio 2014 16:43:10 UTC+1, Yves Parès ha scritto: > > Hello! > When mapping and reducing a map, it seems argume

Re: Very strange behaviour in reducers

Hi Yves, I guess it is because r/reduce calls r/reduce-kv (which is specific for map), while r/fold it does not have such special handling Filip On Tuesday, January 14, 2014 4:43:10 PM UTC+1, Yves Parès wrote: > > Hello! > When mapping and reducing a map, it seems arguments are passed different

Very strange behaviour in reducers

Hello! When mapping and reducing a map, it seems arguments are passed differently to the function that is mapped depending on whether you reduce with r/reduce or r/fold: (r/fold + (r/map (fn [k v] (inc v)) {:a 4 :b 5})) But: (r/reduce + (r/map (fn [[k v]] (inc v)) {:a 4 :b 5})) The func

Re: core.logic: Strange behaviour when using featurec with nested feature map (bug?).

Thanks for fixing it! Den måndagen den 6:e maj 2013 kl. 02:43:53 UTC+2 skrev David Nolen: > > Fixed in master, thanks for the report! > > > On Thu, Apr 25, 2013 at 5:53 PM, Martin Forsgren > > > wrote: > >> Hi! >> >> I noticed something strange when using featurec with a nested feature >> map(I

Re: core.logic: Strange behaviour when using featurec with nested feature map (bug?).

Fixed in master, thanks for the report! On Thu, Apr 25, 2013 at 5:53 PM, Martin Forsgren wrote: > Hi! > > I noticed something strange when using featurec with a nested feature map(I'm > using core.logic 0.8.3). > This works as expected: > (run* [x y] > (featurec x {:a {:b 1}}) > (== y {:b 1

Re: core.logic: Strange behaviour when using featurec with nested feature map (bug?).

Ok, ticket created: http://dev.clojure.org/jira/browse/LOGIC-132 - Martin Den torsdagen den 25:e april 2013 kl. 23:56:43 UTC+2 skrev David Nolen: > > Looks like a featurec bug, please file a ticket > http://dev.clojure.org/jira/browse/LOGIC > > Thanks! > David > > > On Thu, Apr 25, 2013 at 5:53

Re: core.logic: Strange behaviour when using featurec with nested feature map (bug?).

Looks like a featurec bug, please file a ticket http://dev.clojure.org/jira/browse/LOGIC Thanks! David On Thu, Apr 25, 2013 at 5:53 PM, Martin Forsgren wrote: > Hi! > > I noticed something strange when using featurec with a nested feature map(I'm > using core.logic 0.8.3). > This works as expe

Re: strange behaviour

ooo I found this: http://stackoverflow.com/questions/10565874/non-linear-slowdown-creating-a-lazy-seq-in-clojure I did not post this but this guy came up with the same solution... Jim ps: the 'partition' solution does seem much better... On 24/03/13 14:17, Jim - FooBar(); wrote: i'm getting s

Re: strange behaviour

i'm getting slightly paranoid now...let's forget about my code for a second...paste this into your repl: *;;using the original ngrams** (defrecord DUMMY [token tag]) (def Dpairs (doall (repeat 3 (DUMMY. "them" "PRO" ;them->pronoun (def Dtags (mapv :tag Dpairs)) (def tag-ngrams (doall (

Re: strange behaviour

wow! this is even stranger now!!! I removed the call to count from ngrams* and now the same thing happens but all 4 cpus are busy!!! I don't understand... Jim On 24/03/13 13:54, Marko Topolnik wrote: May or may not be related, but calling /count/ on a lazy sequence eagerly consumes the entir

Re: strange behaviour

May or may not be related, but calling *count* on a lazy sequence eagerly consumes the entire sequence. On Sunday, March 24, 2013 2:35:35 PM UTC+1, Jim foo.bar wrote: > > the operation is 'ngrams*' which doesn't care about what objects it > finds in the seq...Typically you'd have characters or

Re: strange behaviour

in other words, I can lose the 'doall' and do this: =>(def ntt-pairs (ngrams* tt-pairs 2)) #'hotel_nlp.algorithms.viterbi/ntt-pairs => (first ntt-pairs) (#hotel_nlp.algorithms.viterbi.TokenTagPair{:token "The", :tag "DET"} #hotel_nlp.algorithms.viterbi.TokenTagPair{:token "Fulton", :tag "NP"})

Re: strange behaviour

the operation is 'ngrams*' which doesn't care about what objects it finds in the seq...Typically you'd have characters or word ngrams but that doesn't mean you can't have any type of object...it simply doesn't care... (defn ngrams* "Create ngrams from a seq s. Pass a single string for chara

Re: strange behaviour

What do you mean by "performing the same operation"? How can you perform the same operation on completely different objects? Do you mean that you don't have the exact same *ngrams** in the first and second case? On Sunday, March 24, 2013 1:45:37 PM UTC+1, Jim foo.bar wrote: > > Hi everyone, > >

strange behaviour

Hi everyone, I'm experiencing some odd behaviour that I cannot justify so I thought someone smarter can help here... I'm reading in a file with 39,7226 lines, each one containing a token-tag pair (e.g. The/DET). This gives me 39,7226 fully-realized TokenTagPair objects (records-> TokenTagPai

Re: Strange behaviour: nested def in proxy method body

Ah, thanks for your reply, both of you! That's why I got confused: it seemed to work when I didn't use proxy. I'll stop using nested defs for now. But I will miss them: they allow me to evaluate them top-level in the REPL (using C-x C-e in emacs) and play around with them. K. On Thursday, D

Re: Strange behaviour: nested def in proxy method body

On Thursday, December 13, 2012 4:14:23 AM UTC-8, Marshall Bockrath-Vandegrift wrote: > kristianlm > writes: > > > I'm enjoying testing Java code with Clojure and it's been a lot of fun > > so far. Coming from Scheme, the transit is comfortable. However, I > > encountered a big surprise when I

Re: Strange behaviour: nested def in proxy method body

kristianlm writes: > I'm enjoying testing Java code with Clojure and it's been a lot of fun > so far. Coming from Scheme, the transit is comfortable. However, I > encountered a big surprise when I nested def's and used them with a > proxy: This is a common surprise for people with previous expos

Strange behaviour: nested def in proxy method body

Hello Clojurers! I'm enjoying testing Java code with Clojure and it's been a lot of fun so far. Coming from Scheme, the transit is comfortable. However, I encountered a big surprise when I nested def's and used them with a proxy: (defn new* [] (def i (atom 0)) (proxy [Object] [] (toSt

Re: Strange behaviour

On Nov 17, 2008, at 14:30, Rich Hickey wrote: > It's best to do this as generally as possible, building on something > like this: > > (defn map-same [f coll] > (let [ret (into (empty coll) (map f coll))] > (if (seq? coll) > (reverse ret) > ret))) OK, so I have as a minimal set

Re: Strange behaviour

On Nov 17, 7:56 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > On Nov 17, 2008, at 13:33, mb wrote: > > > vals returns a clojure.lang.APersistentMap$ValSeq, which > > is not a list. Hence list? returns false and you get the true > > branch, ie. the thing itself. > > A. It looks like a li

Re: Strange behaviour

On Nov 17, 2008, at 13:33, mb wrote: > vals returns a clojure.lang.APersistentMap$ValSeq, which > is not a list. Hence list? returns false and you get the true > branch, ie. the thing itself. A. It looks like a list, but it isn't a list. > I know. It doesn't help much, but it shows, tha

Re: Strange behaviour

Hi, On 17 Nov., 13:05, Konrad Hinsen <[EMAIL PROTECTED]> wrote: >         (defn replace-syms >            [sym-map expr] >            (let [replace #(replace-syms sym-map %)] >               (cond (contains? sym-map expr) (get sym-map expr) >                     (list? expr) (map #(replace-syms s

Strange behaviour

Given the function (defn replace-syms [sym-map expr] (let [replace #(replace-syms sym-map %)] (cond (contains? sym-map expr) (get sym-map expr) (list? expr) (map #(replace-syms sym-map %) expr) (vector? expr) (int