Dang. I did indeed have to read the fine print. Sequences vs. lists.
All look the same , don't they. Those macroexpanded things which
looked
like lists were actually sequences. This is because map and mapcat and
such return ... sequences! (list? seq) returns false on a sequence...
So.

(defn mkseq [item]
  (cond
    (symbol? item) (seq (list item))
    :default (seq item)))

(defn lassoc [item lst]
  (first (filter #(= (first (mkseq %)) item) lst)))
;;;CHANGING to symbol? works, or i could of used if-not (seq? ..) i
guess...
(defmacro llet [bind & body]
  `(let ~(vec
           (mapcat #(if (symbol? %) (list % nil) %) bind))
     ~...@body))

;;or you could use my new favorite test function for macros..
(defn aseq? [item] (or (vector? item) (list? item) (seq? item)))


Thanks for the help!


On Sep 8, 3:34 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Without digging into the implementation code:
>
> shouldn't the expansion for e.g. clojure.core/letfn return a vector and not
> a list for the binding ?
>
> ((G__1840 [a b c] (print a)))
> should be
> (vector (G__1840 [a b c] (print a)))
> or [(G__1840 [a b c] (print a))]
>
> ?
>
> Maybe clojure.core/letfn is currently permissive on this, but this is an
> undocumented implementation detail (the doc for letfn says : "Takes a vector
> of function specs and a body, and generates a set of bindings of functions
> to their names. All of the names are available in all of the definitions of
> the functions, as well as the body.")
>
> Your maybe doing a similar error in other parts of the code where the
> implementation detail are closer to the public API, and that may explain
> your error ?
>
> 2009/9/8 Gorsal <s...@tewebs.com>
>
>
>
> > #<CompilerException java.lang.Exception: Unsupported binding form:
> > (G__1852 2) (NO_SOURCE_FILE:1182)>
> > So, I'm porting Paul Grahm's condlet macro to clojure. I've done it
> > except when i evaluate it it gives me the above error. However, when I
> > macroexpand-1 it it evaluates fine.
>
> > The only difference between evaluating the macroexpansion vs the other
> > way is that the (gensym) vars are now regular variables in the
> > macroexpanded version. However, i don't see how this can affect it.
>
> > (condlet [((= 2 2) (a 2) (b 3))
> >             ((= 3 4) (a 1) (b 4) (c 34))]
> >  (print a)) --> throws error
>
> > macroexpanded version where lcond is equivalent to a lisp cond and
> > same for llet. This evaluates
> > just fine!
>
> > (clojure.core/letfn
> >  ((G__1840 [a b c] (print a)))
> >  (user/lcond
> >    ((= 2 2)
> >      (user/llet
> >        (G__1841 G__1842 G__1843)
> >        (user/llet ((G__1841 2) (G__1842 3)) (G__1840 G__1841 G__1842
> > G__1843))))
> >    ((= 3 4)
> >      (user/llet
> >        (G__1841 G__1842 G__1843)
> >        (user/llet
> >          ((G__1841 1) (G__1842 4) (G__1843 34))
> >          (G__1840 G__1841 G__1842 G__1843))))))
>
> > What am i missing here? I've heard of this same error with cond-let
> > and the guy changed it due to the 'new everything that lets must have
> > bracket regime'? What's this?
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to