Quote from Dave Voorhis on August 29, 2019, 7:15 am

Quote from AntC on August 29, 2019, 6:42 am

Pondering something else entirely, I bumped into this thought: This is a valid Tutorial D expression

• (RELATION {} {} {})

in which RELATION {} {} is a relation literal;

a) the first {} gives its heading (empty);

b) the second {} gives its content (empty).

c) And the final {} is a projection/attribute ref commalist (empty).

So the expression overall is DUM projected on no attributes, which evaluates to DUM. We might call this longhand DUMBER.

Ah, but the heading bit a) is optional, so we could omit it getting

• (RELATION {} {})

except that's ambiguous: does it omit the heading a) or does it omit the projection list c)? Come to think, the original expression suffers the same ambiguity; it could be

• (RELATION {}) {} {} // omitted heading, projected on an empty attribute list, projected again on an empty attribute list.

This is something like the syntactic ambiguity in ALGOL 60 nested if-then-else statements, where the else-part is optional:

• IF p THEN IF q THEN s1 ELSE s2;

Does the ELSE branch from the outer IF or the inner?

Any parsing of the expression that takes the heading a) as omitted must be semantically ambiguous(?) What is the type of the RELATION literal? OTOH it doesn't matter, because the expression projects away whatever attributes it might have had. So the result is always DUM.

What does Rel do?

Rel does this:

RELATION {} {}

RELATION {} {
}

RELATION {} {} {}

RELATION {} {
}

RELATION {} {} {} = DUM

true

Quote from Rene Hartmann on September 7, 2019, 9:47 pm

DuroDBMS does not allow empty content when no heading is given because it is not possible to infer a type unambiguously from empty content.

Thus, RELATION {} {} {} is not ambiguous.

The statement

IF p THEN IF q THEN s1 ELSE s2;

is not valid Tutorial D because END IF is required in IF statements.

Therefore, the 'dangling else problem' does not exist in TD because it has to be either

IF p THEN IF q THEN s1 ELSE s2; END IF; END IF;

or

IF p THEN IF q THEN s1; END IF; ELSE s2; END IF;

 

 

Quote from dandl on September 8, 2019, 12:19 am

Quote from Dave Voorhis on August 29, 2019, 7:15 am

Quote from AntC on August 29, 2019, 6:42 am

Pondering something else entirely, I bumped into this thought: This is a valid Tutorial D expression

• (RELATION {} {} {})

in which RELATION {} {} is a relation literal;

a) the first {} gives its heading (empty);

b) the second {} gives its content (empty).

c) And the final {} is a projection/attribute ref commalist (empty).

So the expression overall is DUM projected on no attributes, which evaluates to DUM. We might call this longhand DUMBER.

Ah, but the heading bit a) is optional, so we could omit it getting

• (RELATION {} {})

except that's ambiguous: does it omit the heading a) or does it omit the projection list c)? Come to think, the original expression suffers the same ambiguity; it could be

• (RELATION {}) {} {} // omitted heading, projected on an empty attribute list, projected again on an empty attribute list.

This is something like the syntactic ambiguity in ALGOL 60 nested if-then-else statements, where the else-part is optional:

• IF p THEN IF q THEN s1 ELSE s2;

Does the ELSE branch from the outer IF or the inner?

Any parsing of the expression that takes the heading a) as omitted must be semantically ambiguous(?) What is the type of the RELATION literal? OTOH it doesn't matter, because the expression projects away whatever attributes it might have had. So the result is always DUM.

What does Rel do?

Rel does this:

RELATION {} {}

RELATION {} {
}

RELATION {} {} {}

RELATION {} {
}

RELATION {} {} {} = DUM

true

But you would agree that it's ambiguous in the grammar. You've just answered how that ambiguity is resolved in Rel, but it's still there. Fortuitously there is no way it matters AFACIT.

Quote from AntC on September 8, 2019, 1:00 am

Quote from Rene Hartmann on September 7, 2019, 9:47 pm

DuroDBMS does not allow empty content when no heading is given because it is not possible to infer a type unambiguously from empty content.

Thus, RELATION {} {} {} is not ambiguous.

I'm looking at the formal syntax for Tutorial D. Presumably Rel and DuroDBMS have adapted that syntax slightly, or have some pragmatics such as the 'maximal munch' rule.

..., the 'dangling else problem' does not exist in TD ...

I didn't claim Tutorial D has a dangling else problem. I was referring to ALGOL 60, because its dangling else rule is a well-known example of how hard it is to define unambiguous syntax.

Every language since has learnt from that mistake; it's easy to avoid once it's pointed out. I guess Tutorial D is following PL/1.

 

Quote from Rene Hartmann on September 8, 2019, 8:59 am

Quote from AntC on September 8, 2019, 1:00 am

Quote from Rene Hartmann on September 7, 2019, 9:47 pm

DuroDBMS does not allow empty content when no heading is given because it is not possible to infer a type unambiguously from empty content.

Thus, RELATION {} {} {} is not ambiguous.

I'm looking at the formal syntax for Tutorial D. Presumably Rel and DuroDBMS have adapted that syntax slightly, or have some pragmatics such as the 'maximal munch' rule

Yes, the syntax used by DuroDBMS's interpreter Duro D/T is different from Tutorial D in a few places. For example, LEAVE is allowed without a statement name. The effect is to leave the innermost loop.

Quote from Dave Voorhis on September 8, 2019, 2:58 pm

Quote from dandl on September 8, 2019, 12:19 am

Quote from Dave Voorhis on August 29, 2019, 7:15 am

Quote from AntC on August 29, 2019, 6:42 am

Pondering something else entirely, I bumped into this thought: This is a valid Tutorial D expression

• (RELATION {} {} {})

in which RELATION {} {} is a relation literal;

a) the first {} gives its heading (empty);

b) the second {} gives its content (empty).

c) And the final {} is a projection/attribute ref commalist (empty).

So the expression overall is DUM projected on no attributes, which evaluates to DUM. We might call this longhand DUMBER.

Ah, but the heading bit a) is optional, so we could omit it getting

• (RELATION {} {})

except that's ambiguous: does it omit the heading a) or does it omit the projection list c)? Come to think, the original expression suffers the same ambiguity; it could be

• (RELATION {}) {} {} // omitted heading, projected on an empty attribute list, projected again on an empty attribute list.

This is something like the syntactic ambiguity in ALGOL 60 nested if-then-else statements, where the else-part is optional:

• IF p THEN IF q THEN s1 ELSE s2;

Does the ELSE branch from the outer IF or the inner?

Any parsing of the expression that takes the heading a) as omitted must be semantically ambiguous(?) What is the type of the RELATION literal? OTOH it doesn't matter, because the expression projects away whatever attributes it might have had. So the result is always DUM.

What does Rel do?

Rel does this:

RELATION {} {}

RELATION {} {
}

RELATION {} {} {}

RELATION {} {
}

RELATION {} {} {} = DUM

true

But you would agree that it's ambiguous in the grammar. You've just answered how that ambiguity is resolved in Rel, but it's still there. Fortuitously there is no way it matters AFACIT.

Yes, this one doesn't matter. I recall there are other grammar ambiguities too (including the potential for the classic IF ... ELSE issue noted elsewhere in this thread), but I can't recall the specifics off-hand.