Scope and lifetime
I've been revisiting some of the issues around scope and lifetime for Andl, and looked to Tutorial D for some hints or guidance. There isn't much to go on. There is one mention of "global variable", and scope is explicitly excluded.
But from context and various hints it would seem we might identify the following:
-
Name Scope Lifetime Expression the name of an attribute or component used in an expression (possibly nested) During expression evaluation Local Variable (not relvar) and parameters names defined inside an operator (1) During operator invocation Global Variable (not relvar) defined outside an operator (2) During program execution (3) Type, operator, constraint Global, shared Life of database (or DROP) Private application relvar Global During program execution Public application relvar Global, shared During program execution (4) Base or virtual relvar Global, shared Life of database (or DROP)
Questions:
- Do names at inner scope simply nest and override any outer usage of that name while in scope?
- Can there be a global variable, private relvar and public relvar of the same name? Do they nest?
- (1): only variables and parameters?
- (2): no global or local relvars?
- (3): global variables lost at program end?
- (4): application relvars life of program, so how are they public?
I've probably misunderstood private relvars, but otherwise is that about right? Feel free to correct.
Is that a good model to follow? Is there any compelling reason not to have persistent scalar and tuple variables? [Obviously they would be stored in the database as a relvar.]
In Muldis Data Language I streamlined things by making EVERYTHING lexical, in combination with representing variables fundamentally as their own data type whose values are references to containers whose current value can change. In this context, "the database" is just a reference value declared in the main program and passed as an explicit argument to any routines that want to work with it. Lexical scope is within each routine and there is just one lexical namespace per routine, so there would never be 2 things with the same name. And so on. Loosely speaking, managing "the database" (of which there can be more than one) is analogous to common practice of managing files, particularly memory-mapped ones.
Quote from dandl on September 15, 2019, 4:56 amQuestions:
- Do names at inner scope simply nest and override any outer usage of that name while in scope?
- Can there be a global variable, private relvar and public relvar of the same name? Do they nest?
- (1): only variables and parameters?
- (2): no global or local relvars?
- (3): global variables lost at program end?
- (4): application relvars life of program, so how are they public?
I've probably misunderstood private relvars, but otherwise is that about right? Feel free to correct.
Is that a good model to follow? Is there any compelling reason not to have persistent scalar and tuple variables? [Obviously they would be stored in the database as a relvar.]
These are largely not covered in the D&D writings due to presumably being secondary to the purpose of Tutorial D, so I can only speak for what I've done in Rel. As usual, you can do whatever you like that isn't otherwise pre/pro-scribed, as long as it adheres to RM Pre 26.
- Inner scopes override outer scopes of the same name. I vaguely recall having a specific set of conditions under which this is disallowed and an error message indicates an attempt to shadow an existing variable, but I can't recall what it is (and at the moment can't be bothered to look). If it's important, I'll look for it.
- There can be a global relvar and a private relvar of the same name. The private relvar shadows the global relvar. A relvar declared with the PUBLIC keyword is notionally equivalent to 'extern' (and the like) in other languages. It asserts that a relvar of the given name and structure must already exist at the point of PUBLIC variable declaration.
- Not quite sure what you're asking with "only variables and parameters", but the only stateful constructs are variables and parameters.
- There are global and local (i.e., PRIVATE) relvars. Rel supports nested operators, so there can be relvars global to an inner operator that are PRIVATE in an outer operator.
- Global, non-persistent variables are lost at program end.
- There is no notion of an application scope or context, so there are no application relvars per se. There are database or REAL relvars and PRIVATE relvars.
You could certainly have persistent scalar and tuple variables, modulo the usual raised eyebrow over Codd's Information Rule. Treating persistent scalar and tuple variables as aliases for tuples in relations in real relvars would presumably get around that.
Quote from Dave Voorhis on September 15, 2019, 11:11 pmQuote from dandl on September 15, 2019, 4:56 amQuestions:
- Do names at inner scope simply nest and override any outer usage of that name while in scope?
- Can there be a global variable, private relvar and public relvar of the same name? Do they nest?
- (1): only variables and parameters?
- (2): no global or local relvars?
- (3): global variables lost at program end?
- (4): application relvars life of program, so how are they public?
I've probably misunderstood private relvars, but otherwise is that about right? Feel free to correct.
Is that a good model to follow? Is there any compelling reason not to have persistent scalar and tuple variables? [Obviously they would be stored in the database as a relvar.]
These are largely not covered in the D&D writings due to presumably being secondary to the purpose of Tutorial D, so I can only speak for what I've done in Rel. As usual, you can do whatever you like that isn't otherwise pre/pro-scribed, as long as it adheres to RM Pre 26.
- Inner scopes override outer scopes of the same name. I vaguely recall having a specific set of conditions under which this is disallowed and an error message indicates an attempt to shadow an existing variable, but I can't recall what it is (and at the moment can't be bothered to look). If it's important, I'll look for it.
Just remembered -- local variables may not shadow parameters.
Quote from Dave Voorhis on September 15, 2019, 11:11 pm
These are largely not covered in the D&D writings due to presumably being secondary to the purpose of Tutorial D, so I can only speak for what I've done in Rel. As usual, you can do whatever you like that isn't otherwise pre/pro-scribed, as long as it adheres to RM Pre 26.
Rather than just asking what you did in Rel, my intention was to infer a minimum set of plausible rules from the TD language spec and other hints scattered around. For example, TTM does not prescribe a local scope, but it does assume one in the body of text.
- Inner scopes override outer scopes of the same name. I vaguely recall having a specific set of conditions under which this is disallowed and an error message indicates an attempt to shadow an existing variable, but I can't recall what it is (and at the moment can't be bothered to look). If it's important, I'll look for it.
- There can be a global relvar and a private relvar of the same name. The private relvar shadows the global relvar. A relvar declared with the PUBLIC keyword is notionally equivalent to 'extern' (and the like) in other languages. It asserts that a relvar of the given name and structure must already exist at the point of PUBLIC variable declaration.
OK. One can infer that real/base, virtual and public relvars are all persistent (database lifetime), but the scope is unspecified. The obvious expectation would be global, but they could be local (in the program). It seems that private relvars are a completely different beast: scope and lifetime matching tuple and scalar variables. Just the word PRIVATE jars a bit.
- Not quite sure what you're asking with "only variables and parameters", but the only stateful constructs are variables and parameters.
Since I was talking about names, this was to distinguish from operators, types and constraints. It seems that those are always both global and persistent. I'm not sure I like that.
- There are global and local (i.e., PRIVATE) relvars. Rel supports nested operators, so there can be relvars global to an inner operator that are PRIVATE in an outer operator.
- Global, non-persistent variables are lost at program end.
- There is no notion of an application scope or context, so there are no application relvars per se. There are database or REAL relvars and PRIVATE relvars.
You could certainly have persistent scalar and tuple variables, modulo the usual raised eyebrow over Codd's Information Rule. Treating persistent scalar and tuple variables as aliases for tuples in relations in real relvars would presumably get around that.
Just so.
Quote from dandl on September 16, 2019, 1:11 pmQuote from Dave Voorhis on September 15, 2019, 11:11 pmThese are largely not covered in the D&D writings due to presumably being secondary to the purpose of Tutorial D, so I can only speak for what I've done in Rel. As usual, you can do whatever you like that isn't otherwise pre/pro-scribed, as long as it adheres to RM Pre 26.
Rather than just asking what you did in Rel, my intention was to infer a minimum set of plausible rules from the TD language spec and other hints scattered around.
That's what I did, sixteen years ago when I started developing the first version of Rel. But aren't those rules only relevant to Tutorial D?
Scope rules are well outside the remit of TTM and so will inevitably be specific to each D. Given andl is a very different language from Tutorial D, I should think what can be inferred about scoping and kinds of variables from Date & Darwen's illustrations of Tutorial D might not apply to andl, and would need to be different for other D's, and can differ between various Tutorial D implementations, and might even differ between Tutorial D examples in the various Date & Darwen books.
Quote from dandl on September 16, 2019, 1:11 pmIt seems that private relvars are a completely different beast: scope and lifetime matching tuple and scalar variables. Just the word PRIVATE jars a bit.
That is to say, their scope is the current program; unlike public relvars, they are not visible to other programs. I agree this is an unusual use of the term "private".
Quote from johnwcowan on September 16, 2019, 8:02 pmQuote from dandl on September 16, 2019, 1:11 pmIt seems that private relvars are a completely different beast: scope and lifetime matching tuple and scalar variables. Just the word PRIVATE jars a bit.
That is to say, their scope is the current program; unlike public relvars, they are not visible to other programs. I agree this is an unusual use of the term "private".
Unsurprisingly, discussion about PRIVATE relvars has come up before. I refer the interested reader to https://forum.thethirdmanifesto.com/forum/topic/clarification-sought-re-tutorial-d-private-relvars/#postid-948079 Note Hugh's responses, particularly the last post in the thread.
Quote from Dave Voorhis on September 16, 2019, 9:32 pmQuote from johnwcowan on September 16, 2019, 8:02 pmQuote from dandl on September 16, 2019, 1:11 pmIt seems that private relvars are a completely different beast: scope and lifetime matching tuple and scalar variables. Just the word PRIVATE jars a bit.
That is to say, their scope is the current program; unlike public relvars, they are not visible to other programs. I agree this is an unusual use of the term "private".
Unsurprisingly, discussion about PRIVATE relvars has come up before. I refer the interested reader to https://forum.thethirdmanifesto.com/forum/topic/clarification-sought-re-tutorial-d-private-relvars/#postid-948079 Note Hugh's responses, particularly the last post in the thread.
That's a very old and rather long discussion about not very much at all, but (I think) it agrees with what I was trying to say. The keyword PRIVATE is required, but only makes the declaration have the same meaning as if it were (a) allowed to be omitted and (b) consistent with scalar and tuple variable declarations. It doesn't mention that it really isn't a good use for a word that is widely used in other languages with a rather different meaning. My choice would have been to make it optional, and even deprecated (with apologies to D&D).
Quote from Dave Voorhis on September 16, 2019, 3:03 pmQuote from dandl on September 16, 2019, 1:11 pmQuote from Dave Voorhis on September 15, 2019, 11:11 pmThese are largely not covered in the D&D writings due to presumably being secondary to the purpose of Tutorial D, so I can only speak for what I've done in Rel. As usual, you can do whatever you like that isn't otherwise pre/pro-scribed, as long as it adheres to RM Pre 26.
Rather than just asking what you did in Rel, my intention was to infer a minimum set of plausible rules from the TD language spec and other hints scattered around.
That's what I did, sixteen years ago when I started developing the first version of Rel. But aren't those rules only relevant to Tutorial D?
Scope rules are well outside the remit of TTM and so will inevitably be specific to each D. Given andl is a very different language from Tutorial D, I should think what can be inferred about scoping and kinds of variables from Date & Darwen's illustrations of Tutorial D might not apply to andl, and would need to be different for other D's, and can differ between various Tutorial D implementations, and might even differ between Tutorial D examples in the various Date & Darwen books.
No, that's kind of the point. As I said at the outset, this started as a review of Andl, during which I noted that the issues I was facing are almost identical to those in TD/Rel, despite the very different syntax. I had thought that non-database relvars had slipped through the cracks (because the scalar-like syntax is prohibited), and didn't originally notice that PRIVATE plugs the gap. That points is now cleared up.
Expression, local and global scopes and the associated short lifetimes are easy enough to deal with, but the database is something else entirely. Several problems.
- If program contains a persistent declaration (relvar, operator, type or constraint), then running it twice produces a conflict.
- If the new declaration is identical (requires a test for equality), it could be silently allowed.
- If the new declaration is 'compatible' (for some definition of 'compatible'), it could be silently allowed.
- The simple solution is just make it a 'duplicate definition' error.
- Or we could combine VAR with DROP (overwrite)
- If the language includes DROP then there are a set of different problems.
- The DROP might break something because of a dependency
- We could track dependencies and prohibit the DROP
- Allow the DROP and wait for something to break.
- Before the DROP, between that and the new VAR, and after the VAR that name has 3 different meanings. The same code could do 3 different things.
- The DROP might break something because of a dependency
This stuff is messy, and I don't have any good answers right now. I lean towards overwriting prior declarations and informative diagnostic messages, rather than trying to be too smart.