Finally, am I right that another reason to use explicit arguments, not dynamic binding, to pass the options is that if I ever convert my internal (map ...) calls to (pmap ...) calls the dynamic bindings would be lost on account of the function calls being handled by other threads?
On Wed, Oct 14, 2009 at 4:30 AM, Garth Sheldon-Coulson <[email protected]> wrote: > > > On Wed, Oct 14, 2009 at 4:07 AM, Meikel Brandmeyer <[email protected]> wrote: > >> >> Hi, >> >> On Oct 14, 9:45 am, Garth Sheldon-Coulson <[email protected]> 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. 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 -~----------~----~----~----~------~----~------~--~---
