Well, for now only the value s used by the parser macro is really needed. But then it will be less general, the parser macro will not be able to access the lexical scope. I'm still not sure if I really need that, but I like writing code that have some orthogonality.
Let's say I use only a simple combinator: user=> (defn result [v] #(list [v %])) user=> (parser (result "test")) java.lang.Exception: Unable to resolve symbol: s in this context But even if I'm able to fix that, this code will still not work: (let [z "test"] (parser (result z))). Like I already said I don't know if I really need it. Thanks On Aug 24, 2:49 pm, Chouser <[EMAIL PROTECTED]> wrote: > On Sun, Aug 24, 2008 at 1:33 PM, budu <[EMAIL PROTECTED]> wrote: > > > Here is the match-forms function: > > Thanks. Now that I can see some concrete examples, ... I'm stumped. > > Your binding form isn't computed until runtime, by which time the > macros are all expanded. There may be a way to have the binding form > evaluated later without using eval, but I'm failing to think of it. > > Perhaps if you could compute the list of symbols that will need to be > bound at compile time (in the macro instead of in the macro > expansion), that would be sufficient for us to work up a solution. > Would this be possible? > > --Chouser --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
