Quote from Dave Voorhis on July 26, 2020, 9:57 am

Quote from Erwin on July 26, 2020, 9:51 am

Quote from Dave Voorhis on July 25, 2020, 8:13 am

Though there is perhaps an argument for not having WITH at all, either in expression or statement form. Instead, provide CONST as an alternative to VAR, with precisely the same syntax and rules, only immutable.

FWIW, those semantics might clash with those intuitively expected by people who are familiar with CONST keyword in other languages, where it can be used only for compile-time constants, not for "immutable vars that can be initialized only at run-time because some other variable is needed to do so".

Good point. I was thinking of semantics similar to Java 'final' or C# 'const', which must be assigned once and only once at run-time.

I wasn't thinking of C's #define.

Quote from dandl on July 26, 2020, 10:16 am

Quote from Erwin on July 26, 2020, 9:51 am

Quote from Dave Voorhis on July 25, 2020, 8:13 am

Though there is perhaps an argument for not having WITH at all, either in expression or statement form. Instead, provide CONST as an alternative to VAR, with precisely the same syntax and rules, only immutable.

FWIW, those semantics might clash with those intuitively expected by people who are familiar with CONST keyword in other languages, where it can be used only for compile-time constants, not for "immutable vars that can be initialized only at run-time because some other variable is needed to do so".

I'm quite relaxed about the idea that people who expect things to work a particular way in one language find things work differently in another. I suspect that's a case of 'welcome to the real world'.

Having an expression scoped declaration such as WITH is unusual, as languages go. I can't think of another language that does it, but I suspect it's a nice feature. Block-structured var declarations are nice too (they go back to Algol), and the const modifier is another good one. I don't think you want block-structured WITH too, unless it opens up some other useful feature (like using in C# or with in Pascal).

 

Quote from Hugh on July 26, 2020, 1:06 pm

Quote from Erwin on July 26, 2020, 9:54 am

Quote from Dave Voorhis on July 25, 2020, 3:29 pm

A benefit of CONST is that you can define a global CONST that applies to the whole database. Indeed, as was already mentioned in this thread, that's what DEE and DUM are.

WITH is definitely handy for avoiding repetition in a complex expression or in a given operator definition, but although WITH and CONST both define constants, CONST can replace WITH but WITH can't really replace CONST.  That's because WITH can only apply to code within a given operator definition or expression, but can't apply to multiple -- or all -- operator definitions and expressions, whilst a given CONST can.

WITH limits the lifetime of the constant/immutable var to the expression/statement itself, CONST as I understand it would most likely extend that lifetime to "end of the enclosing block".  Not that it's likely a big deal, but it's a difference.

WITH on a compound statement would also define a constant with such a lifetime.

Hugh

 

Quote from Hugh on July 26, 2020, 1:10 pm

Quote from dandl on July 26, 2020, 10:16 am

Quote from Erwin on July 26, 2020, 9:51 am

Quote from Dave Voorhis on July 25, 2020, 8:13 am

Though there is perhaps an argument for not having WITH at all, either in expression or statement form. Instead, provide CONST as an alternative to VAR, with precisely the same syntax and rules, only immutable.

FWIW, those semantics might clash with those intuitively expected by people who are familiar with CONST keyword in other languages, where it can be used only for compile-time constants, not for "immutable vars that can be initialized only at run-time because some other variable is needed to do so".

I'm quite relaxed about the idea that people who expect things to work a particular way in one language find things work differently in another. I suspect that's a case of 'welcome to the real world'.

Having an expression scoped declaration such as WITH is unusual, as languages go. I can't think of another language that does it, but I suspect it's a nice feature. Block-structured var declarations are nice too (they go back to Algol), and the const modifier is another good one. I don't think you want block-structured WITH too, unless it opens up some other useful feature (like using in C# or with in Pascal).

 

I plead guilty, having proposed the construct for both the SQL standard and Tutorial D back in the 1990s.   For SQL my company had asked me to come up with something to do that job and a colleague had pointed me to Pascal for a precedent using WITH.  I don't remember actually looking at Pascal, a language I had never used.  I might just have taken his word for it.

Hugh

Quote from Dave Voorhis on July 26, 2020, 3:08 pm

Quote from Erwin on July 26, 2020, 9:54 am

Quote from Dave Voorhis on July 25, 2020, 3:29 pm

A benefit of CONST is that you can define a global CONST that applies to the whole database. Indeed, as was already mentioned in this thread, that's what DEE and DUM are.

WITH is definitely handy for avoiding repetition in a complex expression or in a given operator definition, but although WITH and CONST both define constants, CONST can replace WITH but WITH can't really replace CONST.  That's because WITH can only apply to code within a given operator definition or expression, but can't apply to multiple -- or all -- operator definitions and expressions, whilst a given CONST can.

WITH limits the lifetime of the constant/immutable var to the expression/statement itself, CONST as I understand it would most likely extend that lifetime to "end of the enclosing block".  Not that it's likely a big deal, but it's a difference.

My thinking is this:

WITH on a single statement defines one or more constants whose scope is limited to the specified statement. This is equivalent to the existing WITH expression.

WITH on a compound statement aka block defines constants whose scope is limited to the specified block.

CONST is an immutable alternative to VAR, with the same scope and the same semantics as VAR bar mutability, and the same syntax but replace "VAR" with "CONST."

An alternative is to define "CONST" as a VAR modifier, but it seems rather jarring to declare semantic contradictions like CONST VAR x INIT(3) or VAR CONST x INIT(3).

A constant declared as CONST x INIT(3) seems more readable, but maybe that's just me.

Quote from dandl on July 27, 2020, 12:32 am

Quote from Dave Voorhis on July 26, 2020, 3:08 pm

Quote from Erwin on July 26, 2020, 9:54 am

Quote from Dave Voorhis on July 25, 2020, 3:29 pm

A benefit of CONST is that you can define a global CONST that applies to the whole database. Indeed, as was already mentioned in this thread, that's what DEE and DUM are.

WITH is definitely handy for avoiding repetition in a complex expression or in a given operator definition, but although WITH and CONST both define constants, CONST can replace WITH but WITH can't really replace CONST.  That's because WITH can only apply to code within a given operator definition or expression, but can't apply to multiple -- or all -- operator definitions and expressions, whilst a given CONST can.

WITH limits the lifetime of the constant/immutable var to the expression/statement itself, CONST as I understand it would most likely extend that lifetime to "end of the enclosing block".  Not that it's likely a big deal, but it's a difference.

My thinking is this:

WITH on a single statement defines one or more constants whose scope is limited to the specified statement. This is equivalent to the existing WITH expression.

WITH on a compound statement aka block defines constants whose scope is limited to the specified block.

CONST is an immutable alternative to VAR, with the same scope and the same semantics as VAR bar mutability, and the same syntax but replace "VAR" with "CONST."

Which makes WITH <block> redundant.

An alternative is to define "CONST" as a VAR modifier, but it seems rather jarring to declare semantic contradictions like

CONST VAR x INIT(3)

CONST VAR x INIT(3) or

VAR CONST x INIT(3)

VAR CONST x INIT(3).

A constant declared as

CONST x INIT(3)

CONST x INIT(3) seems more readable, but maybe that's just me.

It probably isn't just you, Pascal did something similar.

Quote from Hugh on July 27, 2020, 11:31 am

Quote from Dave Voorhis on July 26, 2020, 3:08 pm

Quote from Erwin on July 26, 2020, 9:54 am

Quote from Dave Voorhis on July 25, 2020, 3:29 pm

A benefit of CONST is that you can define a global CONST that applies to the whole database. Indeed, as was already mentioned in this thread, that's what DEE and DUM are.

WITH is definitely handy for avoiding repetition in a complex expression or in a given operator definition, but although WITH and CONST both define constants, CONST can replace WITH but WITH can't really replace CONST.  That's because WITH can only apply to code within a given operator definition or expression, but can't apply to multiple -- or all -- operator definitions and expressions, whilst a given CONST can.

WITH limits the lifetime of the constant/immutable var to the expression/statement itself, CONST as I understand it would most likely extend that lifetime to "end of the enclosing block".  Not that it's likely a big deal, but it's a difference.

My thinking is this:

WITH on a single statement defines one or more constants whose scope is limited to the specified statement. This is equivalent to the existing WITH expression.

WITH on a compound statement aka block defines constants whose scope is limited to the specified block.

CONST is an immutable alternative to VAR, with the same scope and the same semantics as VAR bar mutability, and the same syntax but replace "VAR" with "CONST."

An alternative is to define "CONST" as a VAR modifier, but it seems rather jarring to declare semantic contradictions like

CONST VAR x INIT(3)

CONST VAR x INIT(3) or

VAR CONST x INIT(3)

VAR CONST x INIT(3).

A constant declared as

CONST x INIT(3)

CONST x INIT(3) seems more readable, but maybe that's just me.

Chris's main reason for wanting CONST is to allow relation constants to be defined in the database, just like relation variables.   Tutorial D already specifies two such constants, TABLE_DEE and TABLE_DUM.

As things are in Rel, I cheerfully use virtual relvars (views) for that purpose.  It could be argued that a "virtual variable" that references no real ones isn't really a variable (it doesn't vary in value from time to time) and such definitions shouldn't be allowed, but that wouldn't be my position.

Hugh

Quote from Dave Voorhis on July 28, 2020, 4:31 pm

Quote from dandl on July 27, 2020, 12:32 am

Quote from Dave Voorhis on July 26, 2020, 3:08 pm

Quote from Erwin on July 26, 2020, 9:54 am

Quote from Dave Voorhis on July 25, 2020, 3:29 pm

A benefit of CONST is that you can define a global CONST that applies to the whole database. Indeed, as was already mentioned in this thread, that's what DEE and DUM are.

WITH is definitely handy for avoiding repetition in a complex expression or in a given operator definition, but although WITH and CONST both define constants, CONST can replace WITH but WITH can't really replace CONST.  That's because WITH can only apply to code within a given operator definition or expression, but can't apply to multiple -- or all -- operator definitions and expressions, whilst a given CONST can.

WITH limits the lifetime of the constant/immutable var to the expression/statement itself, CONST as I understand it would most likely extend that lifetime to "end of the enclosing block".  Not that it's likely a big deal, but it's a difference.

My thinking is this:

WITH on a single statement defines one or more constants whose scope is limited to the specified statement. This is equivalent to the existing WITH expression.

WITH on a compound statement aka block defines constants whose scope is limited to the specified block.

CONST is an immutable alternative to VAR, with the same scope and the same semantics as VAR bar mutability, and the same syntax but replace "VAR" with "CONST."

Which makes WITH <block> redundant.

Yes, the addition of CONST as an alternative to VAR -- which I think is very worthwhile -- means this:

WITH (p := 1, q := 2): BEGIN 
  WRITELN p + q; 
  WRITELN p * q; 
END;

...is semantically identical to this:

BEGIN 
  CONST p INIT(1);
  CONST q INIT(2); 
  WRITELN p + q; 
  WRITELN p * q; 
END;

I have no objection to both existing, though in a pedagogical language, it probably makes sense to have just one.

For reasons already mentioned, then it makes sense for CONST to be the one.

If that were the case, for the sake of syntactic simplicity I'd be inclined to allow this (again, semantically identical to the previous example):

BEGIN 
  CONST p := 1;
  CONST q := 2; 
  WRITELN p + q; 
  WRITELN p * q; 
END;

And if that's allowed, this also should be allowed:

BEGIN 
  VAR p := 1;
  VAR q := 2; 
  WRITELN p + q; 
  WRITELN p * q; 
END;

 

Quote from dandl on July 29, 2020, 12:33 am

Yes, the simplified syntax would be preferable. I should point out that = is marginally preferable to := for constants, as it's not really assignment.

And why stop there? The whole language could benefit from this kind of streamlining.