Really, this should be

(with-bindings-from-map var-map (+ *v1* 100)) ; -> 200,  does what we
expect
(with-bindings-from-map wrong-map (+ *v1* 100)) ; -> 110,  does the
wrong thing entirely, silently

Anyway, you may want to think about why common-lisp does not have a
with-all-slots macro for use with CLOS objects.  It is similar
reasoning which requires you name the slots you want to access when
using with-slots.





On Aug 10, 3:10 pm, jvt <vincent.to...@gmail.com> wrote:
> Meikel,
>
> What concerns me is that this macro lets you write code which depends
> on names which are not present at compile time (someplace).  Coming
> from scheme, not only would you _not_ do this, but you _can't_ do it
> without using eval in your macro body, which is considered bad form.
> That we can do it in clojure appears to be a consequence of the fact
> that 1) clojure uses maps internally for binding and 2) that thread-
> local binding requires you declare the vars somewhere before using
> them someplace else.
>
> Be this as it may, you can still get weird run-time behavior from this
> kind of macro in the following situation:
>
> (def *v1* 10)
> (def var-map {:*v1* 100})
> (def wrong-map {:*v2* 10})
>
> (with-bindings-from-map var-map (+ v1 100)) ; -> 200,  does what we
> expect
> (with-bindings-from-map wrong-map (+ v1 100)) ; -> 110,  does the
> wrong thing entirely, silently
>
> Writing a separate macro for each kind of binding may be slightly less
> convenient, but it also gives us a smarter error message.
>
> we could write instead
>
> (defmacro binding-v1 [ mp & body ] `(binding [{*v1* :*v1*} ~mp]
> ~...@body))
>
> (binding-v1 var-map (+ *v1* 10)) ; works
> (binding-v1 wrong-map (+ *v1* 10)) ; this gives the error we expect,
> that there is no *v1* in wrong-map.  (ok, it gives an error when we
> try to add 10 to nil, but error checking in binding-v1 would give a
> better error).
>
> Plus, this doesn't depend on a how the compiler implements or
> optimizes names.  It could be that in the future clojure will want to
> use a different representation internally than maps for symbol->value
> translation.
>
> -V
>
> On Aug 9, 11:58 pm, Niels Mayer <nielsma...@gmail.com> wrote:
>
> > On Thu, Aug 6, 2009 at 10:12 PM, samppi <rbysam...@gmail.com> wrote:
>
> > > I have about six variables that are often rebound together using
> > > binding; these variables are used to access and set data in a state
> > > object (whose type is of the user's choice). These variables' values
> > > (the accessors and setters) are often used together.
>
> > I'd like to be able to bundle these values into a map, and using a
>
> > function or macro called with-bundle, automatically bind the map's
>
> > vals to their respective variables:
>
> > (def my-bundle
>
> > {'*variable-1* :something1, '*variable-2* :something2})
>
> > If you don't get too religious about the curlyness of your brackets or the
> > inelegance of the syntax (which is basically common-lisp keywords, using
> > "infix notation," with the entailed loss of elegance caused by that
> > choice)...  What about using JSON, which seems to be close to the syntax
> > you're already using. Because JSON is ultimately a matter of calling a Java
> > class,all the work has already been done in terms of going back and forrth
> > between a "map" datastructure and the text-representation, both for JSON and
> > XML.
>
> > For example (cut/paste fromhttp://www.javapassion.com/ajax/JSON.pdf)
>
> > JSON looks like:
> >  var myJSONObject = {"bindings": [
> > {"ircEvent": "PRIVMSG", "method": "newURI", "regex": "^http://.*"},
> > {"ircEvent": "PRIVMSG", "method": "deleteURI", "regex": "^delete.*"},
> > {"ircEvent": "PRIVMSG", "method": "randomURI", "regex": "^random.*"}
> > ]
>
> > };
>
> > • Members can be retrieved using dot or subscript operators
> > myJSONObject.bindings[0].method // "newURI
>
> > In Java, the same "dot notation" can be used for set/get, but use JSONObject
> > Java Class
> > • A JSONObject is an unordered collection of name/value pairs
> > • The put methods adds a name/value pair to an object
> > • The texts produced by the toString methods strictly conform to the JSON
> > syntax rules
>
> > Output:
>
> > > myString = new JSONObject().put("JSON", "Hello, World!").toString();
>
> > // myString is {"JSON": "Hello, World"}
>
> > Parsing:
>
> > > try {
>
> > jsonObject = new JSONObject(myString);
>
> > }
>
> > catch(ParseException pe) {
>
> > }
>
> > .....
>
> > Similarly you could probably also use whatever combination of XML libraries
> > that'll turn XML structures into
> > data structures that can easily be accessed in Java, for example, here's a
> > little script you can throw into Xwiki to grab a RSS feed and turn it into
> > something that can easily be accessed in Java, Groovy, or Clojure:
>
> > Takes URL param ?zip=ZIPCODE and gets associated weather report for that
> > zipcode:
>
> > {{script language=groovy}}
>
> >   def rss = new XmlSlurper().parseText(("
>
> > >http://weather.yahooapis.com/forecastrss?p=";
>
> >                                         +
>
> > > xcontext.macro.params.zip).toURL().text)
>
> >   println rss.channel.title
>
> >   println "Sunrise: ${rss.channel.astrono...@sunrise}"
>
> >   println "Sunset: ${rss.channel.astrono...@sunset}"
>
> >   println "Currently:"
>
> >   println "\t" + rss.channel.item.conditi...@date
>
> >   println "\t" + rss.channel.item.conditi...@temp
>
> >   println "\t" + rss.channel.item.conditi...@text
>
> > {{/script}}
>
> > Nielshttp://nielsmayer.com
>
> > PS: what are people's favorite JSON or XML Java classes for doing this out
> > of scripting languages like Groovy or Clojure? Basically, going back and
> > forth between a structured textual representation and a map data structure
> > that can be accessed by variables like "rss.channel.item.condition.text" .
--~--~---------~--~----~------------~-------~--~----~
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