On Tuesday 23 December 2008 07:27, Adam Harrison (Clojure) wrote: > Randall R Schulz wrote: > > ... > > Hi Randall, > > How do you envision read-table control to be useful in the context of > this particular problem - perhaps to redefine tokens beginning with > '?' as keywords? And is read-table control the same thing as reader > macros?
Loosely speaking, yes read-table control is about attaching your own code to particular input signifiers, usually (though in CL not necessarily) a specific character that appears following the "dispatching" macro character '#'. And I would strongly recommend _not_ trying to represent your query variables as keywords, but rather as entities that have the requisite properties or types of SPARQL query variables (as needed in your own design). That could be as simple as a metadata tag designating the symbol as a variable name or shunting them to an alternative namespace reserved for SPARQL query variables, e.g. Additionally or alternatively it could also handle entering the name into whatever indexing or table-of-contents required. Generally speaking, variables (whether the kind used in C / C++ / Java / etc. or the kind used in logic or the kind used in FP, the latter two being like each other than either is to the former) require lots of special treatment beyond their simple existence as a name of a something. As far as keywords relate to your problem, I recommend staying away from them for this purpose. The initial colon at the beginning of their names is ineluctable in Clojure and you shouldn't try to use them at cross purposes to their intended uses. Furthermore, you cannot attach metadata to keywords as you can to symbols. No, your logical variables should be represented by some other entity. Keep in mind that if you want to process SPARQL as a DSL based on the Clojure reader (assuming it's even readable by the Clojure reader (*) — not all languages are; even many Lisp-like languages are not), then you're going to have to control evaluation when you process it. That's true, anyway, if you're going to use an embedded DSL approach wherein the Clojure compiler will be the first thing to get its hands on your input S-Expressions after they're returned from the Reader. That's what macros are for. On the other hand, if you use an external DSL approach where you get the S-Expressions encoding SPARQL queries, then the whole issue of evaluation control and macros goes away. You just process those S-Exprs as data that encodes the queries. Evaluation and name resolution never enter the picture this way and you needn't worry about them (nor can you take advantage of them, whichever perspective suits you best...). Anyway, if SPARQL uses a leading question mark to signify a variable name, then you're going to have to check every symbol in your SPARQL input for that signifier and handle it appropriately. And I don't know if SPARQL has nested namespaces and rules about reusing variables (shadowing, e.g.), but if it does, you're going to need a symbol table design that accommodates that requirement (to state the obvious, I hope). Just don't try to press Clojure keywords into service for something they're not meant to be used for. > Best Regards, > > Adam. Randall Schulz -- Did I mention I'm wordy? --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
