Re: TMQL: Direct (super|sub)types?
Robert Barta <[email protected]>
| Newsgroups | gmane.text.xml.xtm.general |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Mar 05, 2011 at 09:31:23AM +0000, Andrew S. Townley wrote: > I think this is one of the weakest use cases I could possibly > imagine for having the default pull all subtypes. If you don't > care, then you should defensively make that distinction on the areas > of the code, the ontology and the domain in which you have control. > If you do care (as I think most of the "mainstream" programming > community you mentioned later would), then I think "breaking" in > this case is exactly the right thing to do. If you didn't care, > then you should've indicated you didn't care at the implementation > time. I find the contention around that topic (implicit inference semantics on "subclass") somewhat surprising. Not only because that is effectively hardwired in the object-oriented class of mainstream programming languages, but also because subclass transitivity is effectively the only "semantics" in TM. If we make that the non-default, then TMs would no longer count as "_semantic_ network technology". > I think the biggest thing in my mind here is the context of use. To me: > > if (t isa x) then > ...do something if t is a direct or indirect subclass > end > > is a vastly different scenario than using > > for x in ( x // types ) do > ..do something for each match for the entire tree > end > Be that as it may. The bottomline is that TMQL will have to support both cases (actually also TMCL, but that is spilled milk). The matter is only how and what the default case is. > I'm not saying that TMQL shouldn't be based on a formal model with > consistent semantics, but I think I'm a bit confused from the use > case as to whether it's supposed to be a scripting language on its > own (supported by CTM and TMCL) or whether it is expected to be > mixed in or used from host languages. _That_ is actually a very good question (although I do not see the connection to the above ;-) \rho