> (let [keys "Chubb"]
> (println (clojure.core/keys {:foo :bar})))
Yes, I really like this aspect of Clojure.
> What does newLISP do for a query like
>
> SELECT p1.name, p2.name from people p1 JOIN people p2;
newLISP doesn't do anything, but sqlite3 will tell you that there are 2 columns
for the result set of that query, and each is named "name", and they both
happen to have the same value.
Now, if they came from different tables, you'd have a problem I think, but in
that case I wouldn't use my macro, which is just for convenience, it's not
designed to handle all queries perfectly. I'm sorry if I gave you the wrong
impression.
> The literature about hygienic macros disagrees with you.
I've read some of that literature and I don't think it does, but you're more
than welcome to elaborate. There are no variable capture issues here at least,
because the fexpr is inside of its own context (that's what define-smacro does,
the 's' is for 'safe').
- Greg
On Feb 4, 2010, at 8:05 PM, Richard Newman wrote:
>> 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.
>
> It matters in Clojure because symbols are interned in namespaces, or they
> have no namespace. Symbols from different namespaces denote different things:
> for example, this works just fine in Clojure, even though it's a Lisp-1,
> because the local `keys` has no namespace.
>
> (let [keys "Chubb"]
> (println (clojure.core/keys {:foo :bar})))
>
>>> 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.
>
> My point with that example is that it really is magic: the symbol name comes
> out of the DB, and isn't even mentioned in the syntax of the query. Against a
> different DB you'll get different results -- your code might even throw an
> error about a symbol not existing.
>
> What does newLISP do for a query like
>
> SELECT p1.name, p2.name from people p1 JOIN people p2;
>
> ?
>
>> 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.
>
> The literature about hygienic macros disagrees with you.
>
> --
> 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
