>> It's not clear in the case of multiple packages or namespaces. (In which >> package does "name" get interned? It depends on *when* the string is >> interned, because that decides the enclosing scope. Or does newLISP not have >> packages?) > > > NAME (not name) may be "interned" in the sense that it will exist somewhere > in the symbol tree, but that doesn't matter—at all. At least in newLISP. In > Clojure it may have some consequences and if so, that would be a valid > argument to make, I'd be interested to know what they are if that is the case.
Oh, I think I understand what you're asking. Are you worrying if the symbol won't be visible because the code could be run in a different namespace? That's actually an issue I ran into and so I had to pass in an additional argument to specify the namespace. I complained about it on newLISP's forums and luckily in the next version this won't be an issue because there will be a function that will give you the namespace that a given symbol belongs to. - Greg On Feb 4, 2010, at 6:18 PM, Greg wrote: >> It's not clear in the case of multiple packages or namespaces. (In which >> package does "name" get interned? It depends on *when* the string is >> interned, because that decides the enclosing scope. Or does newLISP not have >> packages?) > > > NAME (not name) may be "interned" in the sense that it will exist somewhere > in the symbol tree, but that doesn't matter—at all. At least in newLISP. In > Clojure it may have some consequences and if so, that would be a valid > argument to make, I'd be interested to know what they are if that is the case. > >> Neither are the names specified in a query such as "SELECT * FROM people". >> Who knows what'll happen when you do "SELECT p1.name ...". > > > This is incorrect. A query like "SELECT *" will not have any issues getting > the correct, expected names from the table definition. You can check the code > again, there's no string parsing going on with the query. > >> - Quietly and maybe accidentally shadows variables from enclosing scopes > > > If any shadowing happens, it's OK because you know it's going to happen. It's > also exceedingly unlikely it will happen due to naming convention and even if > it happens, it's *still OK* because nothing breaks because things are only > shadowed within the scope of the macro call and you're explicitly expecting > to use the NAME symbol, etc. There's zero confusion and zero ambiguity. > >> - Uses eval (which apparently is fine in newLISP, but as a Common Lisper and >> Clojurite strikes me as pointless) > > So, as I showed, the Clojure version seems to not require the use of eval. > >> c.c.sql also allows you to synthesize queries from Lisp forms > > This is a good point, and if I were to use Clojure I would use your version > instead. > > - Greg > > On Feb 4, 2010, at 5:53 PM, Richard Newman wrote: > >>> OK, I hope you can see the difference though between that and what I showed. >> >> Of course I can; I'm just illustrating a point by exaggeration. >> >>> They are not the same; in your example: >>> >>> - It's not clear what the magic symbols are >>> - The user does not specify the magic symbols (as they did in mine) >> >> It's not clear in the case of multiple packages or namespaces. (In which >> package does "name" get interned? It depends on *when* the string is >> interned, because that decides the enclosing scope. Or does newLISP not have >> packages?) >> >> Neither are the names specified in a query such as "SELECT * FROM people". >> Who knows what'll happen when you do "SELECT p1.name ...". >> >> You're about half-way to complete anaphora when you're starting to pull >> symbol names out of syntax-laden strings (or databases). That's magic, at >> least when compared to ordinary lexical symbol reference. >> >> Given that there's little to no advantage to doing this, I don't see the >> point. >> >>> This sort of programming style is easy to abuse and can sometimes lead to >>> confusion if handled incorrectly, but when applied in the appropriate >>> manner it can be extremely useful. >>> >>> The 'for-query-with-db' function is a good example of doing this correctly >>> because it: >>> >>> - Documents its behavior >>> - Creates symbols based on user input, not of its own accord as in your >>> example >>> - Clearly distinguishes them through a special naming convention >>> - Has advantages over other forms of solving the same problem >> >> ... and it's a bad example, because it: >> >> - Quietly and maybe accidentally shadows variables from enclosing scopes >> - Fails to nest queries which share names >> - Silently interns new variable names in your packages >> - Uses eval (which apparently is fine in newLISP, but as a Common Lisper and >> Clojurite strikes me as pointless) >> - etc. >> >> I see no point in doing this rather than going the conventional macro route. >> c.c.sql, for example, would do this: >> >> (with-query-results res >> ["SELECT name FROM people"] >> (println (:name res))) >> >> -- res is a map. You can pass it around, access its values, and your own >> function `name` doesn't get shadowed by your query. >> >> c.c.sql also allows you to synthesize queries from Lisp forms, which I think >> is more useful than trying to extract symbol names from a SQL string. >> >>>> The macroexpansion occurs at compile time. If you have all the knowledge >>>> at compile time, you can do the work then. If you don't, the macro has to >>>> expand into code that does the work at runtime. >>> >>> Thanks for the example and explanation! >> >> Sure thing! >> >> -- >> 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 > > -- > 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 -- 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
