Recent

Author Topic: Curly brackets in strings  (Read 2198 times)

wp

  • Hero Member
  • *****
  • Posts: 11858
Re: Curly brackets in strings
« Reply #15 on: October 02, 2022, 01:39:26 pm »
Neither does Delphi XE 10.4 CE.

Thaddy

  • Hero Member
  • *****
  • Posts: 14210
  • Probably until I exterminate Putin.
Re: Curly brackets in strings
« Reply #16 on: October 02, 2022, 01:39:39 pm »
For the same reason.
Specialize a type, not a var.

wp

  • Hero Member
  • *****
  • Posts: 11858
Re: Curly brackets in strings
« Reply #17 on: October 02, 2022, 01:48:14 pm »
I think Thaddy is right. Suppose this:
Code: Pascal  [Select][+][-]
  1. { This comment contains a curly brace }. }
Everybody would say that the comment ends at the first brace (even the highligher of the forum software does so). If the parser does not perform analysis of what is inside the braces then there is no difference to the situation
Code: Pascal  [Select][+][-]
  1. {
  2.   WriteLn('}');
  3. }'

simsee

  • Full Member
  • ***
  • Posts: 184
Re: Curly brackets in strings
« Reply #18 on: October 02, 2022, 01:55:43 pm »
So we can conclude that the curly brackets are always active, regardless of the surrounding context.

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: Curly brackets in strings
« Reply #19 on: October 02, 2022, 01:58:40 pm »
So we can conclude that the curly brackets are always active, regardless of the surrounding context.
Yes
Compilers scan from '{' to the nearest '}', and only then scan tokens, including quoted strings.
As result
Code: Pascal  [Select][+][-]
  1. {
  2.   WriteLn('}');
  3. }'
is then same as
Code: Pascal  [Select][+][-]
  1. ');
  2. }'
and
Code: Pascal  [Select][+][-]
  1. { This comment contains a curly brace }. }
is
Code: Pascal  [Select][+][-]
  1. . }
Both produce error.

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Curly brackets in strings
« Reply #20 on: October 02, 2022, 02:02:02 pm »
fpc dont like this one too:

Code: Pascal  [Select][+][-]
  1. program test;
  2.  
  3. { I am a comment with this: { something... }
  4.  
  5. begin
  6. end.

Result:

Quote
fred@fred-80m0 ~> fpc test.pas
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling test.pas
test.pas(3,29) Warning: Comment level 2 found
test.pas(6,5) Fatal: Unexpected end of file
Fatal: Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode


« Last Edit: October 02, 2022, 02:37:02 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Curly brackets in strings
« Reply #21 on: October 02, 2022, 02:07:39 pm »
In your case you can use proper real old school comments as already suggested: (*...*).

On that at least we agree. J&W-era Pascal had definitely moved from /* */ to (* *) as the digraph, I don't have a copy to hand but I suspect that it used that form in the code examples rather than braces. The fact that I habitually use (* *) for "long term" comments suggests that it's a habit I got into early, despite most of the systems I've used having the full ASCII character set.

I believe that braces got into ASCII circa 1965 and were definitely in the definitive ASCII-68, but the fact that Xerox PARC's Smalltalk of the late '70s and early '80s still had arrows in the character set suggests that some manufacturers stayed on an older version (replacing print drums in fast line printers was expensive). I believe that Wirth was using a CDC when he worked on Pascal, a quick trawl in Bitsavers suggests that their large-scale printers didn't have braces (but did have some of the ALGOL-style "funnies") but I've seen some CDC Pascal stuff in the past which implied that at least some of their terminals etc. had something like a 12-bit character set which included e.g. much if not all of the APL operators.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dseligo

  • Hero Member
  • *****
  • Posts: 1196
Re: Curly brackets in strings
« Reply #22 on: October 02, 2022, 02:16:12 pm »
So we can conclude that the curly brackets are always active, regardless of the surrounding context.

Not only curly brackets. This also doesn't compile:
Code: Pascal  [Select][+][-]
  1.     program Project1;
  2.     begin
  3.       (*
  4.       writeln('*)');
  5.     *)
  6.     writeln;
  7.    end.

Thaddy's explanation in post #13 is correct.

simsee

  • Full Member
  • ***
  • Posts: 184
Re: Curly brackets in strings
« Reply #23 on: October 02, 2022, 02:33:54 pm »
 But this compiles:

Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. begin
  4.   writeln('ok//');
  5. end.

So, for single line comments the rule the rule does not apply.

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Curly brackets in strings
« Reply #24 on: October 02, 2022, 02:38:01 pm »
The code inside the start of a comment is ignored until the compiler sees a closing of the comment.
...

Hum, ok, but it seems that the compiler does care of other open brackets.
See my post: https://forum.lazarus.freepascal.org/index.php/topic,60786.msg455827.html#msg455827
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

dseligo

  • Hero Member
  • *****
  • Posts: 1196
Re: Curly brackets in strings
« Reply #25 on: October 02, 2022, 02:56:45 pm »
But this compiles:

Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. begin
  4.   writeln('ok//');
  5. end.

So, for single line comments the rule the rule does not apply.

It does apply, your '//' isn't inside a comment.

The code inside the start of a comment is ignored until the compiler sees a closing of the comment.
<snip>

wp

  • Hero Member
  • *****
  • Posts: 11858
Re: Curly brackets in strings
« Reply #26 on: October 02, 2022, 03:56:26 pm »
It's always the same rule:
- Find a comment beginner '(*" --> search until the next '*)' is found, ignore everything else in between.
- Find a comment beginner '{' --> Search until the next  '}' is found, ignore everything else.
- Find a quote indicating that a string begins --> search until the next quote character is found (unless duplicated) and ignore everything else.

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Curly brackets in strings
« Reply #27 on: October 02, 2022, 04:10:57 pm »
wp - no, not always.  In some dialects, more theoretican practical, like ANSI Pascal the following are correct and complete comments:

(*  bla-bla-vla }
{ bla-vla-vla *)


Actually, TP (if not USCD) violated the standard and hardware history when making them incompatible. But doing so they enables erzats nested comments, so they did good

On the contrary.  (. 1..2 ] and [ 3 .. 4 .) are still valid sets/ranges.  Inconsistent, but practical :-)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Curly brackets in strings
« Reply #28 on: October 02, 2022, 04:48:45 pm »
wp - no, not always.  In some dialects, more theoretican practical, like ANSI Pascal the following are correct and complete comments:

(*  bla-bla-vla }
{ bla-vla-vla *)


Actually, TP (if not USCD) violated the standard and hardware history when making them incompatible. But doing so they enables erzats nested comments, so they did good

On the contrary.  (. 1..2 ] and [ 3 .. 4 .) are still valid sets/ranges.  Inconsistent, but practical :-)

Yes, depending on whether they are processed as digraphs at the lexer level or as separate elements.

I'd expect comments to always be discarded by the lexer, and that includes /everything/ between an opening and closing marker. I'd expect the (. and .) digraphs to be converted to single characters and then passed to the parser with no further attempt at interpretation.

Part of the issue with matching comments is because in FPC a comment marker closes a macro, and a macro definition, which could itself potentially include a (non-matching) comment.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Curly brackets in strings
« Reply #29 on: October 02, 2022, 05:24:27 pm »
My *blind guess* it that originally, in TP descending parser FSM, it was just simpler to copy-paste {/} and (*/*) pairs verbatim, than making special cases of "one closing another"

you meet '{' - search for the next '}'
you meet '(*' - search for the next '*)'

it is simple and large;y error-safe, just colling one single search fuinciton, Pos :-)

REP SCANSB is all you need, well, almost

multivariant searcher is much more complex, and thus slow and error prone.

This, by accident, enabled nested comments.  "And programemrs saw it, and they saw it was good" and demanded it to forever be so :-)

 

TinyPortal © 2005-2018