Re: [fpc-pascal] case statement
Note that the same ambiguity exists in the syntax (and this
is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [ "ELSE" statement-list ] |
statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO"
statement .
as ends with a and the optional <"ELSE" statement-list> part start
with "ELSE". Sloppy language design, I assume by Borland.
Regards,
Adriaan van Os
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Note that the same ambiguity exists in the syntax (and
this is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [ "ELSE"
statement-list ] | statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO"
statement .
as ends with a and the optional <"ELSE"
statement-list> part start with "ELSE". Sloppy language design, I assume by
Borland.
What exactly do you consider "sloppy" ?
The fact that the semicolon before the else is optional ?
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Michael Van Canneyt via fpc-pascal wrote:
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Note that the same ambiguity exists in the syntax
(and this is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [
"ELSE" statement-list ] | statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO"
statement .
as ends with a and the optional
<"ELSE" statement-list> part start with "ELSE". Sloppy language
design, I assume by Borland.
What exactly do you consider "sloppy" ?
The ambiguity in the syntax whether ELSE belong to or to <"ELSE"
statement-list>.
The fact that the semicolon before the else is optional ?
I don't see a semicolon in the formal syntax.
Regards,
Adriaan van Os
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Michael Van Canneyt via fpc-pascal wrote:
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Note that the same ambiguity exists in the syntax (and
this is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [
"ELSE" statement-list ] | statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO"
statement .
as ends with a and the optional <"ELSE"
statement-list> part start with "ELSE". Sloppy language design, I assume
by Borland.
What exactly do you consider "sloppy" ?
The ambiguity in the syntax whether ELSE belong to or to <"ELSE"
statement-list>.
Why do you think this is ambiguous ? It always belongs to statement list.
If there is ambiguity, it is in the if then else construct.
This makes it difficult to read for humans.
The fact that the semicolon before the else is optional ?
I don't see a semicolon in the formal syntax.
This works:
---
{$mode objfpc}
uses sysutils;
begin
try
except
on E: EAccessViolation do
begin
end;
on E: EInoutError do
begin
end; // can be removed or not.
else
begin
Writeln('OK');
end;
end;
end.
---
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Le 15/12/2023 à 10:39, Adriaan van Os via fpc-pascal a écrit : I don't see a semicolon in the formal syntax. May be included in the ' "DO" statement ' ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Michael Van Canneyt via fpc-pascal wrote:
The fact that the semicolon before the else is optional ?
I don't see a semicolon in the formal syntax.
This works:
OK, than an optional semicolon must be added to the rule
exceptionhandlers = [ exception-handler { ";" exception-handler } [ ";" ] [ "ELSE" statement-list
] | statement-list ] .
Regards,
Adriaan van Os
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
Jean SUZINEAU via fpc-pascal wrote: Le 15/12/2023 à 10:39, Adriaan van Os via fpc-pascal a écrit : I don't see a semicolon in the formal syntax. May be included in the ' "DO" statement ' ? No, have a look at the syntax diagrams, statements never end with a semicolon. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] method-definition
I am puzzled by the syntax rule in Chapter 6. Classes of the FreePascal Language Reference (version 3.2.0) Section 6.1 Class definitions has method-definition = [ "CLASS" ] ( function-header | procedure-header | constructor-header | destructor-header ) ";" [ ( ( ( "virtual" | "dynamic" ) [ ";" "abstract" ] ) | "override" | "message" ( integer-constant | string-constant ) ) ";" ] [ call-modifiers ";" ] . Section 6.6.1 Declaration has: method-definition = ( function-header | procedure-header | constructor-header | destructor-header ) ";" method-directives . method-directives = ( ( "virtual" | "dynamic" ) [ ";" "abstract" ] | "reintroduce" ";" | "override" ";" | "message" constant-expression ) [ call-modifiers ";" ] . Is this supposed to be the same rule for ? Some notes: 1. I don't see a rule anywhere in the Language Reference 2. "reintroduce" is in just one of the two definitions. 3. the optional "CLASS" is in just one of the two definitions. What complicates things, is that many conflicting rules have the same name in the Language Reference. For example, conceptually we have object-methods, record-methods, class-methods, interface-methods and objcclass-methods. But only the record method rules are prefixed as such. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] method-definition
On 15/12/2023 14:56, Adriaan van Os via fpc-pascal wrote:
I am puzzled by the syntax rule in Chapter 6. Classes of
the FreePascal Language Reference (version 3.2.0)
Section 6.1 Class definitions has
method-definition = [ "CLASS" ] ( function-header |
procedure-header | constructor-header | destructor-header ) ";" [ ( (
( "virtual" | "dynamic" ) [ ";" "abstract" ] ) | "override" |
"message" ( integer-constant | string-constant ) ) ";" ] [
call-modifiers ";" ] .
Section 6.6.1 Declaration has:
method-definition = ( function-header | procedure-header |
constructor-header | destructor-header ) ";" method-directives .
method-directives = ( ( "virtual" | "dynamic" ) [ ";" "abstract" ]
| "reintroduce" ";" | "override" ";" | "message" constant-expression )
[ call-modifiers ";" ] .
2. "reintroduce" is in just one of the two definitions.
Another note: "reintroduce" is given as an alternative to "virtual;
[abstract;]".
However, a method can be reintroduced, and be virtual/abstract.
program Project1;{$Mode objfpc}
type
TFoo = class
procedure Bar; virtual; abstract;
end;
TFoo2 = class(TFoo)
procedure Bar; reintroduce; virtual; abstract;
end;
begin
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] method-definition
On 15.12.23 16:00, Martin Frb via fpc-pascal wrote: [...] However, a method can be reintroduced, and be virtual/abstract. type TFoo = class procedure Bar; virtual; abstract; end; TFoo2 = class(TFoo) procedure Bar; reintroduce; virtual; abstract; end; Can that make sense? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] method-definition
> On Dec 15, 2023, at 8:56 PM, Adriaan van Os via fpc-pascal > wrote: > > What complicates things, is that many conflicting rules have the same name in > the Language Reference. For example, conceptually we have object-methods, > record-methods, class-methods, interface-methods and objcclass-methods. But > only the record method rules are prefixed as such. You mean like why records require you to add "static" to class methods? Makes no sense to me either. I don't understand why record constructors must have parameters while static functions do not. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
