On Wed, Oct 14, 2009 at 4:07 AM, Meikel Brandmeyer <m...@kotka.de> wrote:
> > Hi, > > On Oct 14, 9:45 am, Garth Sheldon-Coulson <g...@mit.edu> wrote: > > > (In this parser I also have a non-stack-blowing version of the parser for > > deep data structures, which you Meikel suggested a couple weeks/months > ago, > > Huh? I did? > Yes, but I didn't explain what it was for at the time. http://groups.google.com/group/clojure/browse_thread/thread/b3b184bc59100379 > > > Is bound-fn less efficient because it has to make a full copy of all > > dynamically bound variables on each call? > > Don't nail me down on the details, but it creates a map containing all > dynamically bound variables. On every call on the boundfn this map is > installed and afterwards removed. So there is some overhead involved. > > Another possible approach is to return specialised functions. > Something like (def my-parser (make-parser options go here)), which > would get you a special function which does what you specified: (parse > stuff). No options involved anymore. > > From your description it's still not obvious what your options > actually influence. Could give some simple example of one of the low- > level functions where the behaviour of the parser is changed via an > option? > So, the options change numerous things about what the low-level parser functions do. The code in question is the Mathematica expression parser in Clojuratica. One example of an option is whether Mathematica lists (which earlier I called expression-sequences) will be parsed into Clojure seqs or Clojure vectors. Another example is whether or not Mathematica first-class functions, whenever encountered, will be made callable from Clojure by wrapping them in a Clojure first-class function. A third example is whether Mathematica hash-maps, whenever encountered, will be converted into Clojure hash-maps or left as simple colls of pairs. There are 10-15 options, most of which the defaults are fine for, but all of which I want the user to be able to set. There are options not only for the parser but for every function in the application, and the functions are interconnected. The options have to be propagated pretty much anywhere the call stack goes, through an arbitrary number of recursive calls. I'm pretty sure my choice is between (1) explicit arguments on nearly all my functions (not so bad, really) and (2) dynamic binding + bound-fn for lazyseqs. But if you can think of anything else... Is bound-fn in one of the clojure github branches? Or for the time being is the best way to get it simply to download it from assembla and stick it in my project library? I'll give it a shot, though at this point I think I may be leaning toward explicit arguments. I'm probably not understanding what's involved in dynamic binding, but why would the overhead on "installing" the function-local bindings of bound-fn be worse than mapping an argument symbol (i.e. the "options" symbol in (defn foo [expression options] ...) to the data structure passed as that argument? In both cases the data structure is immutable, so no copy should have to be made... ? > > Sincerely > Meikel > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
