- From: Michael Dyck <jmdyck@ibiblio.org>
- Date: Fri, 11 Mar 2011 12:23:30 -0800
- To: Axel Polleres <axel.polleres@deri.org>
- CC: public-qt-comments@w3.org, Nuno Alexandre Lopes <nuno.lopes@deri.org>, Stefan Bischof <stefan.bischof@deri.org>
[Sorry for the delay -- I meant to reply last week, but it fell off my radar. Liam's reply reminded me.] Axel Polleres wrote: > > ... we would appreciate a small clarification (or pointers to earlier > discussions in this regard) on the "function" fs:new: > > First of all, fs:new appears in the document several times, before it is > actually explained (in acouple of normalization rule). Yes, it might have been better to explain it in Section 2.1 "Introduction to the Formal Semantics." > Then, the first time it is explained is within the normalization rule in > section 4.12.1. Here it says: > > "Note that the following normalization rule uses a variable $fs:new, > which is a newly created variable which must not conflict with any > variables already in scope." > > We are not entirely clear, what "scope" means here. I believe "variables already in scope" is a casual way of saying "in-scope variables", which refers to the 'varType' component of the static environment. > The term "scope" doesn't seem to be defined in the context of > normalization rules, it seems. Do you mean that normalization rules appear to be context-free, and so don't have access to a static environment? It's certainly true that most of them are context-free, but in fact, "normalization is always applied in the presence of a static context" (Section 3.2.2 "Normalization mapping rules"). E.g., normalization of function arguments is done with knowledge of the corresponding parameter types from the function signature, which is looked up in the static context. (Mind you, I think there are 'bugs' in the mechanism that conveys the static context to normalization rules, but I haven't looked too closely.) > What's particularly worrying us it, that this does not formally > seem to preclude that the newly generated variable is - for instance - > a variable which is actually used later on in a return clause. If a variable of the same name were introduced for an in inner scope, it would shadow the "$fs:new" variable, but I think that's okay, because the inner scope never needs to access the $fs:new variable. Do you have a specific example where this wouldn't work? -Michael
Received on Friday, 11 March 2011 20:24:04 UTC