likely bug in variable definitions lazarus / 62-General ---------------------------------------------------------------------- 440bx · 2022-10-01 06:08 Hello, Consider the following program:Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program DefinitionBug; function A() : integer;var  Avar : qword - 0;  { is this supposed to compile ??? } begin  result := Avar + 1;end; begin  A();end.           the definition in line 5 doesn't make sense but the compiler accepts it. Comments and/or confirmation that it is a bug, welcome. ---------------------------------------------------------------------- Bogen85 · 2022-10-01 06:35 That is strange. (that FPC accepts that...) However JCF (Jedit Code Formatter) can't parse that... Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ./lazforum/60776/DefinitionBug.pas(5,20) Error Exception TEParseError  Unexpected token, expected ";"Near - And in my editor Line 5 Column 20 is the "-" in "qword - 0" Can you file a bug report on this against FPC? ---------------------------------------------------------------------- ASerge · 2022-10-01 07:07 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$LONGSTRINGS OFF} function Test: Integer;var  AVar: QWord - 0; { is this supposed to compile ??? }begin  Result := High(Char + 'This is also still supported'); // =255end; begin  Test;end. ---------------------------------------------------------------------- Bart · 2022-10-01 11:46 The latter one is already reported and I seem to remember it has been fixed in fpc main. Not sure though. Bart ---------------------------------------------------------------------- bytebites · 2022-10-01 11:58 High(Char + 'This is also still supported')  ->  Error: type identifier not allowed here ---------------------------------------------------------------------- Bart · 2022-10-01 12:25 fpc main of today compiles both examples (32/64-bit on windows). It'll emit an error on the second example in {$H+} mode, not in {$R-} mode. Bart ---------------------------------------------------------------------- Kays · 2022-10-01 12:46 The compiler eliminates arithmetically neutral operations (+0, -0, *1 and div 1). This elimination takes place at an unusual place, though. It’s weird that the issue only arises with qWord and int64. Quote from: Bart on October 01, 2022, 01:46:22 pmThe latter one is already reported and I seem to remember it has been fixed in fpc main.I did complain about it once, see #37547. It was marked as a duplicate of #32994 which is still open. ---------------------------------------------------------------------- Bogen85 · 2022-10-01 14:11 Still compiles and runs for me, I just now updated my git checkout of fpc and rebuilt and reinstalled... 3.3.1-11945-g0a9e1ede72 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program hellofpcworld; {$LONGSTRINGS OFF} function Test: Integer;var  AVar: QWord - 0; { is this supposed to compile ??? }begin  AVar := 0;  writeln('Avar = ', AVar);  Result := High(Char + 'This is also still supported'); // =255end; const boo = 'dogÜ'; begin  writeln ('Hello FPC world! ', boo);  writeln (Test);end.  compiles... Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Hint: Start of reading config file /home/shared- development/fpc_usr/lib/fpc/etc/fpc.cfgHint: End of reading config file /home/shared-development/fpc_usr/lib/fpc/etc/fpc.cfgFree Pascal Compiler version 3.3.1 [2022/10/01] for x86_64Copyright (c) 1993-2022 by Florian Klaempfl and othersTarget OS: Linux for x86-64Compiling lazforum/hellofpcworld.pasLinking /home/shared- development/sandbox/bin/hellofpcworld19 lines compiled, 0.1 sec, 156832 bytes code, 1139896 bytes data2 hint(s) issued  runs... Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Hello FPC world! dogÜAvar = 0255 ---------------------------------------------------------------------- Arioch · 2022-10-01 14:39 Quote from: 440bx on October 01, 2022, 08:08:39 amfunction A() : integer; var   Avar : qword - 0;  { is this supposed to compile ??? } it also works as a global variable Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; var a: qword + 0; however a different type won't work Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: word + 0; // project1.lpr(4,16) Error: Error in type definitionvar a: dword + 0; // project1.lpr(4,16) Error: Error in type definition  same with int64/int32 types My guess is this is because CPU register size. I am compiling in Win64, so int64/qword is okay I can not test Win32 compilation - the Win64 Lazarus installation does not permit it... Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: string + ''; // project1.lpr(4,15) Fatal: Syntax error, ";" expected but "+" found fails also so it is not just about "eliminating all the obvious no-ops", something more complex ---------------------------------------------------------------------- alpine · 2022-10-01 15:14 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1;var  a: qword + 0;  b: dword + 0;beginend. Compiles without error. Win32 target. Lazarus 2.2.2 (rev lazarus_2_2_2) FPC 3.2.2 i386-win32-win32/win64 ---------------------------------------------------------------------- Arioch · 2022-10-01 15:18 and then what about 16-bit "word + 0"  or "int16 + 0" or "smallint + 0"? ---------------------------------------------------------------------- alpine · 2022-10-01 15:35 Quote from: Arioch on October 01, 2022, 05:18:22 pmand then what about 16-bit "word + 0"  or "int16 + 0" or "smallint + 0"? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: word + 0; Gives an error. ---------------------------------------------------------------------- Arioch · 2022-10-01 15:40 Q.E.D. at least Intel back-end has thios error triggered on integer types sized in CPU general purpose register sizes ( 1x, 2x, ....) i think you can make a 6-bytes integer type, subrange, to try intermediate point, but... whatever :-D It is not really needed, just if you think it being funny something like Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program;type  a = 0 .. $ffFFffFFffFF;var b: a + 0;begin end.  But perhaps here SizeOf(a) and SizeOf(b) would be 8 not 6 ?  At least that is so on Win64 target ---------------------------------------------------------------------- alpine · 2022-10-01 16:00 Quote from: Arioch on October 01, 2022, 05:40:28 pmQ.E.D. Quote from: Arioch on October 01, 2022, 04:39:38 pmMy guess is this is because CPU register size. I am compiling in Win64, so int64/qword is okay And how that relates to the FPC parser? Because (AFAIK) it is an incorrect syntax at the first place. ---------------------------------------------------------------------- Arioch · 2022-10-01 16:05 i can only suspect, as vaguely as can be, that memory sizes shorter than GPR trigger a different code path, which includes typecasting, upsizing up to the GRP size multiple but i don';t know of course, i just observe the black box ---------------------------------------------------------------------- alpine · 2022-10-01 16:38 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var  a: 1 * dword; // ok  b: 1 * 0 + dword; // ok  c: 1 * 1 * 0 + dword; // ok  d: 1 * 1 * ( 1 - 1 ) + dword; // ok  e: 1 * 1 * ( 16 - 2 * 8 ) + dword; // ok  f: dword + #0; // Operator is not overloaded: "LongWord" + "Char"begin  writeln(a,b,c,d,e,f);end. It seems that an expression non-terminal can follow the : into the variable decl. despite the syntax diagrams https://www.freepascal.org/docs-html/current/ref/refse22.html As long it evaluates to zero and includes a suitable type identifier - it is OK ---------------------------------------------------------------------- Bogen85 · 2022-10-01 16:47 For me this would not compile, even the ones marked as ok by @y.ivanov Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program DefinitionBug2; var  a: 1 * dword;  b: 1 * 0 + dword;  c: 1 * 1 * 0 + dword;  d: 1 * 1 * ( 1 - 1 ) + dword;  e: 1 * 1 * ( 16 - 2 * 8 ) + dword;  f: dword + #0;begin  writeln(a,b,c,d,e,f);end. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ fpc ./lazforum/60776/DefinitionBug2.pasFree Pascal Compiler version 3.3.1 [2022/10/01] for x86_64Copyright (c) 1993-2022 by Florian Klaempfl and othersTarget OS: Linux for x86-64Compiling ./lazforum/60776/DefinitionBug2.pasDefinitionBug2.pas(4,15) Error: Error in type definitionDefinitionBug2.pas(5,19) Error: Error in type definitionDefinitionBug2.pas(6,23) Error: Error in type definitionDefinitionBug2.pas(7,31) Error: Error in type definitionDefinitionBug2.pas(8,36) Error: Error in type definitionDefinitionBug2.pas(9,12) Error: Operator is not overloaded: "LongWord" + "Char"DefinitionBug2.pas(9,16) Error: Error in type definitionDefinitionBug2.pas(11,12) Error: Can't read or write variables of this typeDefinitionBug2.pas(13) Fatal: There were 8 errors compiling module, stoppingFatal: Compilation abortedError: /home/shared-development/fpc_usr/lib/fpc/3.3.1/ppcx64 returned an error exitcode ---------------------------------------------------------------------- Arioch · 2022-10-01 16:48 Quote from: y.ivanov on October 01, 2022, 06:38:34 pmAs long it evaluates to zero hmmm... not quite... Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  var a: int64(nil) + qword;  // project1.lpr(3,26) Error: Error in type definition Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: qword + ord(0); this works though Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: qword + qword(nil); and this too! Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: qword(nil) + uint64; and this   but this still doesn't Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var a: qword(0); дали детям игрушку :-D FPC win64 of git Fixes_3_2 - probably 3.2.3 or something ---------------------------------------------------------------------- alpine · 2022-10-01 17:29 @Bogen85 Mine is FPC 3.2.2 But: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i DefinitionBug2.pas(9,12) Error: Operator is not overloaded: "LongWord" + "Char" still means there is an expression evaluator lurking. Quote from: Arioch on October 01, 2022, 06:48:24 pmдали детям игрушку :-D Exactly. And I very much wonder what an expression has to do where a type non- terminal was expected. ---------------------------------------------------------------------- Arioch · 2022-10-01 17:57 Quote from: y.ivanov on October 01, 2022, 07:29:40 pmAnd I very much wonder what an expression has to do where a type non-terminal was expected.  if you really do it "very much" - there are soruces. I do not, though. Not THAT much. Guess that is rooted somehow in the need to transit "initialized variables" to AST The token then get some attibutes, like type, value, sizeof/address, mutability (const/var) Then later some sanity check is applied to make sure different flags and attributes are consistent, like typed const should have non-zero sezeof and address, and untyped one should lack them. Type expressions and value expressions are intertwined anyway (because of array of type) just tend to use different operators (^ in types, * in values). Also, why you evaluate value-expressions it might include type-casts, especially implicit ones (that very 1 / 2 == 0 in C but = 0.5 in Pascal ) So, perhaps, unified parser emitting both evaluation tree and adjusted data type was a reasonable implementation. Having both type ident = type-expr and var ident : type-expr FPC had to run that dual-evaluator after both colon and quality. As initialized vars were introduced - the parser had to be permitted to create both type and value in var context. And that is how it ended. Just speculating. Also, i remember colon is also used in some more places of the language: goto labelsand variant records. I wonder if the latter have some pinnatas too :-) ---------------------------------------------------------------------- alpine · 2022-10-01 20:15 Quote from: Arioch on October 01, 2022, 07:57:12 pmQuote from: y.ivanov on October 01, 2022, 07:29:40 pmAnd I very much wonder what an expression has to do where a type non-terminal was expected.  if you really do it "very much" - there are soruces. I do not, though. Not THAT much. I won't dig in the compiler sources. At least not for that.  Known is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC). It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined. ---------------------------------------------------------------------- PascalDragon · 2022-10-03 12:42 Quote from: y.ivanov on October 01, 2022, 10:15:17 pmKnown is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC). It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined. FPC's parser is not derived from a grammar, but it's a hand written one. In this case the “problem” is that the type expression for e.g. a variable or a field is done using the same function that parses a normal expression just set to a different mode (namely “parse type” instead of “parse normal body”) - this is done because the two share quite some functionality - , but for some reason it doesn't correctly filter out expressions that shouldn't be part of a type expression. ---------------------------------------------------------------------- alpine · 2022-10-03 15:23 Quote from: PascalDragon on October 03, 2022, 02:42:04 pmQuote from: y.ivanov on October 01, 2022, 10:15:17 pmKnown is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC). It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined. FPC's parser is not derived from a grammar, but it's a hand written one. I wouldn't agree with that. Every formal language have a formal grammar. Syntax diagrams are just other representation of the metalanguage such as BNF. So the parser should be implemented strictly according to (deriving from) that grammar, even it was hand written. Quote from: PascalDragon on October 03, 2022, 02:42:04 pmIn this case the “problem” is that the type expression for e.g. a variable or a field is done using the same function that parses a normal expression just set to a different mode (namely “parse type” instead of “parse normal body”) - this is done because the two share quite some functionality - , but for some reason it doesn't correctly filter out expressions that shouldn't be part of a type expression. As you confirm, and also as Arioch speculated, the parser parts for and somehow intertwined here. And I wonder how one can find enough similarities between the two and put them in one function. I'm pasting some Pascal BNFs I googled. Of course they're not comprehensive, but are correct as a bedding for FPC, though. How it is possible to merge them? BNF: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= | ::= = | <> | < | <= | >= | > | in ::= | | ::= + | - | or ::= | ::= * | / | div | mod | and ::= | | ( ) | | | not ... BNF: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= | | ::= | | ::= ( {,}) ::= .. ::= ::= | | | ::= array [{,}] of ::= ::= ::= record end... P.S. Despite the sub-range was defined in https://www.freepascal.org/docs- html/current/ref/refsu4.html#x26-290003.1.1 as: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= .. it is more like: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= .. but that introduces ambiguity with the enumeration type (starts with '(') and the weirdness of: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const  c1 = 1;  c2 = 2;type  t1 = 1 + c2 .. 5; // ok, 3..5  t2 = c1 + c2 .. 5; // ok, 3..5, see the next line  t3 = (c1 + c2) .. 5; // Error: Duplicate identifier "c1"  t4 = 2 * (1 + c2) .. 7; // ok, 6..7, see the next line  t5 = (1 + c2) * 2 .. 7; // Syntax error, "identifier" expected but "ordinal const" found  t6 = c1 .. (1 + c2) * 2; // ok, 1..6  t7 = c1 .. (c1 + c2); // ok, 1..3 ---------------------------------------------------------------------- MarkMLl · 2022-10-03 18:58 Quote from: y.ivanov on October 03, 2022, 05:23:06 pmI wouldn't agree with that. Every formal language have a formal grammar. Syntax diagrams are just other representation of the metalanguage such as BNF. So the parser should be implemented strictly according to (deriving from) that grammar, even it was hand written. I believe that what he means is that it doesn't use a metalanguage such as a YACC description. However that does leave me with a question: accepting for the moment that Pascal is LL(1), my understanding is that Wirth's earliest compilers- which presumably includes the first Pascal implementations- were recursive /ascent/ rather than recursive /descent/. Would any CS guru like to comment on whether the two approaches are provably equivalent? MarkMLl ---------------------------------------------------------------------- PascalDragon · 2022-10-04 11:55 Quote from: y.ivanov on October 03, 2022, 05:23:06 pmQuote from: PascalDragon on October 03, 2022, 02:42:04 pmQuote from: y.ivanov on October 01, 2022, 10:15:17 pmKnown is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC). It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined. FPC's parser is not derived from a grammar, but it's a hand written one. I wouldn't agree with that. Every formal language have a formal grammar. Syntax diagrams are just other representation of the metalanguage such as BNF. So the parser should be implemented strictly according to (deriving from) that grammar, even it was hand written. There never was a formal grammar we began with. And the syntax diagrams that exist are derived from what the compiler supports (and even then some are faulty, because the one writing the documentation didn't find out everything that the compiler itself understands). Quote from: y.ivanov on October 03, 2022, 05:23:06 pmQuote from: PascalDragon on October 03, 2022, 02:42:04 pmIn this case the “problem” is that the type expression for e.g. a variable or a field is done using the same function that parses a normal expression just set to a different mode (namely “parse type” instead of “parse normal body”) - this is done because the two share quite some functionality - , but for some reason it doesn't correctly filter out expressions that shouldn't be part of a type expression. As you confirm, and also as Arioch speculated, the parser parts for and somehow intertwined here. And I wonder how one can find enough similarities between the two and put them in one function. It's due to things like this (as you noticed further down as well): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program trange; const  MyMin = 42;  MyMax = 128; var  r: MyMin - 4 .. MyMax * SizeOf(Int16);begin  Writeln(Low(r), ' .. ', High(r));end. Quote from: y.ivanov on October 03, 2022, 05:23:06 pmP.S. Despite the sub-range was defined in https://www.freepascal.org/docs- html/current/ref/refsu4.html#x26-290003.1.1 as: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= .. it is more like: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= .. but that introduces ambiguity with the enumeration type (starts with '(') and the weirdness of: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const  c1 = 1;  c2 = 2;type  t1 = 1 + c2 .. 5; // ok, 3..5  t2 = c1 + c2 .. 5; // ok, 3..5, see the next line  t3 = (c1 + c2) .. 5; // Error: Duplicate identifier "c1"  t4 = 2 * (1 + c2) .. 7; // ok, 6..7, see the next line  t5 = (1 + c2) * 2 .. 7; // Syntax error, "identifier" expected but "ordinal const" found  t6 = c1 .. (1 + c2) * 2; // ok, 1..6  t7 = c1 .. (c1 + c2); // ok, 1..3 These should probably be reported then... ---------------------------------------------------------------------- MarkMLl · 2022-10-04 12:53 Quote from: PascalDragon on October 04, 2022, 01:55:09 pmThere never was a formal grammar we began with. And the syntax diagrams that exist are derived from what the compiler supports (and even then some are faulty, because the one writing the documentation didn't find out everything that the compiler itself understands). Speaking as somebody who's done his fair share of technical writing: I sympathise. Even when working in a company with clear responsibilities, getting comprehensive and intelligible information out of designers and developers- and distilling the edge cases into something that passes as English- can be like wringing blood out of a stone. MarkMLl ---------------------------------------------------------------------- alpine · 2022-10-04 13:11 Quote from: PascalDragon on October 04, 2022, 01:55:09 pm*snip* Quote from: y.ivanov on October 03, 2022, 05:23:06 pmP.S. Despite the sub-range was defined in https://www.freepascal.org/docs- html/current/ref/refsu4.html#x26-290003.1.1 as: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= .. it is more like: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ::= .. but that introduces ambiguity with the enumeration type (starts with '(') and the weirdness of: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const  c1 = 1;  c2 = 2;type  t1 = 1 + c2 .. 5; // ok, 3..5  t2 = c1 + c2 .. 5; // ok, 3..5, see the next line  t3 = (c1 + c2) .. 5; // Error: Duplicate identifier "c1"  t4 = 2 * (1 + c2) .. 7; // ok, 6..7, see the next line  t5 = (1 + c2) * 2 .. 7; // Syntax error, "identifier" expected but "ordinal const" found  t6 = c1 .. (1 + c2) * 2; // ok, 1..6  t7 = c1 .. (c1 + c2); // ok, 1..3 These should probably be reported then... Not sure the RDP can handle it without back-tracking ... I have tried this on D7 - it fails in the similar way as FPC. Perhaps we can say they're compatible in the way they fail. At the other hand gpc can handle it, but it is yacc based, i.e. it is LALR(1) parser. IMO such an issue is inevitable and the only thing that can be done about it is to correct the documentation, i.e. to put a '(' on a right place into the syntax diagram. ---------------------------------------------------------------------- Thaddy · 2022-10-04 15:26 @PascalDragon There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att. It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering. Reference: appendix A of the Delphi language guide for D7. I am a bit bemused you are not aware of that? ( At that time, though, most proper Elvises had left the building(s)) ---------------------------------------------------------------------- MarkMLl · 2022-10-04 15:45 Quote from: Thaddy on October 04, 2022, 05:26:34 pm@PascalDragon There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att. It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering. Reference: appendix A of the Delphi language guide for D7. I am a bit bemused you are not aware of that? But there's a big difference between having a grammar that describes a language, and working from a grammar to build a compiler using e.g. YACC. You said yourself: "partially correct, nigh complete". You can't build a compiler from that. MarkMLl ---------------------------------------------------------------------- marcov · 2022-10-04 15:50 Quote from: Thaddy on October 04, 2022, 05:26:34 pm@PascalDragon There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att. It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering. The grammar in the manual, that was for documentation purposes only, and was very simplistic and buggy. It was not really a language definition. ---------------------------------------------------------------------- Thaddy · 2022-10-04 16:06 That grammar was used internally too and not just for documentation. ---------------------------------------------------------------------- Thaddy · 2022-10-04 16:08 Quote from: MarkMLl on October 04, 2022, 05:45:13 pmYou can't build a compiler from that. MarkMLl Actually you CAN! But only partially conformant to the actual release Delphi compilers. You can actually build A Pascal compiler from the BNF that resembles D7. And that BNF grammar was leading. Some stupid ghosts - management, money - dropped that guidance along the way. Much like Agile causes more problems than it solves..... Dropping functional design... in favor of spaghetti code. ---------------------------------------------------------------------- marcov · 2022-10-04 16:17 Quote from: Thaddy on October 04, 2022, 06:06:48 pmThat grammar was used internally too and not just for documentation. Folding paper airplanes ? ---------------------------------------------------------------------- alpine · 2022-10-04 16:24 Quote from: Thaddy on October 04, 2022, 05:26:34 pm@PascalDragon There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att. It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering. Reference: appendix A of the Delphi language guide for D7. I am a bit bemused you are not aware of that? ( At that time, though, most proper Elvises had left the building(s)) Unfortunately not a proper BNF. See e.g. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i TypedConstant -> (ConstExpr | ArrayConstant | RecordConstant)ArrayConstant -> '(' TypedConstant ',' ')'RecordConstant -> '(' RecordFieldConstant ';'... ')'Is it : Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i (1,) // can't add more after the comma a proper array constant? ---------------------------------------------------------------------- PascalDragon · 2022-10-05 07:06 Quote from: Thaddy on October 04, 2022, 05:26:34 pm@PascalDragon There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att. It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering. Reference: appendix A of the Delphi language guide for D7. I am a bit bemused you are not aware of that? Please read again what I wrote (I know that you like to simply skim posts and only extract those parts that you think are relevant) - emphasis mine: Quote from: PascalDragon on October 04, 2022, 01:55:09 pmThere never was a formal grammar we began with. And the syntax diagrams that exist are derived from what the compiler supports (and even then some are faulty, because the one writing the documentation didn't find out everything that the compiler itself understands). Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals). ---------------------------------------------------------------------- MarkMLl · 2022-10-05 07:20 Quote from: PascalDragon on October 05, 2022, 09:06:58 amYes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals). I'm afraid that I get the impression that somebody is unaware that there is a class of tools including YACC etc. that takes a compiler definition as input and spits out a substantial part of a compiler as output. One quite simply can't use a "partially correct, nigh complete" description for automated compiler generation, in the same way that one can't use any other kind of sourcecode in that state. MarkMLl ---------------------------------------------------------------------- Thaddy · 2022-10-05 09:58 Quote from: PascalDragon on October 05, 2022, 09:06:58 amWhat did I skip? Other way around! Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals). Not TP but D5-D7, and that WAS used. I was there, you know that. I may have forgotten that: Borland used almost always internal tools, also for their flavor of BNF. E.g: Their IDE parser was built with it. Not after it.... You can ask anyone who was at Borland at the time. They will confirm it. Note: as I said before, I did only "minor" work with the rtl/vcl and analysis. But it is definitely a case of the programmers left the parser in the dark.