"The time has come," the Walrus said, to break old code.

[Leledumbo]

Trolls, trolls everywhere. The effect of Free Pascal becoming Sourceforge's project of the month has started to come. Prepare for a wave of C family programmers who want to make this lovely language UGLY! Curly braces are for COMMENTS, not block delimiter! Semicolon is SEPARATOR, as how you read Pascal program:

Code: [Select]

begin DoA; DoB; DoC end;as english:

Code: [Select]

begin DoA, then DoB, then DoC endPascal is READABLE AS HELL, don't let some trolls OBFUSCATE it!

[CaptBill]

such a refurbished Object Pascal would be a formidable draw for the many frustrated Java programmers out in the wild. Hopefully we will gradually see the end of bulky, cumbersome, and error prone Java coding.

I don't buy that at all. That is the classic "the hordes will come!" argument attached to nearly every proposed modification.

Anyway, since adopting curly braces is quite draconian and the benefits listed are doubtful, and it doesn't agree with the stated project goals, perhaps it is best this work is done and maintained by believers until this assumption is somewhat proven (or at least has some supporting evidence). See also e.g. http://www.freepascal.org/faq.var#extensionselect
 
It might be possible to implement the above behavior only in a language mode, which would remove the backwards compatibility problem. Still it will require fairly serious changes to the lexer probably.

Now a simple "solve for x" riddle for you:

Who did he just call THE DOOR MOUSE?

[marcov]

I think you're right, probably a troll. Lovely username though, well chosen. 

Well, if you know the original, French name of the character :-)

[hinst]

Speaking about new features; I still fail to comprehend how could the "runtime string encoding" feature be approved. Who made the decision to implement it? Worst feature ever in my opinion

[marcov]

Speaking about new features; I still fail to comprehend how could the "runtime string encoding" feature be approved. Who made the decision to implement it? Worst feature ever in my opinion

Which runtime string encoding?  Rawbytestring?  That is all Delphi compatible.

[hinst]

Which runtime string encoding?  Rawbytestring?  That is all Delphi compatible.

Please take a look at this forum post: http://forum.lazarus.freepascal.org/index.php/topic,21223.msg123992.html#msg123992
I could not find detailed documentation on the topic. Probably because it does not exist yet. The way I understand it: string in FPC 2.7.1 has codepage information attached to it

Code from RTL:

Code: [Select]

procedure fpc_AnsiStr_Concat (var DestS:RawByteString;const S1,S2 : RawByteString{$ifdef FPC_HAS_CPSTRING};cp : TSystemCodePage{$endif FPC_HAS_CPSTRING}); compilerproc;
Var
  S1Len, S2Len: SizeInt;
  same : boolean;
  S1CP, S2CP, DestCP: TSystemCodePage;
begin
{$ifdef FPC_HAS_CPSTRING}
  if (Pointer(DestS)=nil) then
    DestCP:=cp
  else
    DestCP:=StringCodePage(DestS);
{$else FPC_HAS_CPSTRING}
  DestCP:=StringCodePage(DestS);
{$endif FPC_HAS_CPSTRING}
  if (DestCP=CP_ACP) then
    DestCP:=DefaultSystemCodePage;
  { if codepages are different then concat using unicodestring,
    but avoid conversions if either addend is empty (StringCodePage will return
    DefaultSystemCodePage in that case, which may differ from other addend/dest) }
  if S1='' then
    S1CP:=DestCP
  else
    S1CP:=StringCodePage(S1);
  if (S1CP=CP_ACP) then
    S1CP:=DefaultSystemCodePage;
  if S2='' then
    S2CP:=DestCP
  else
    S2CP:=StringCodePage(S2);
  if (S2CP=CP_ACP) then
    S2CP:=DefaultSystemCodePage;
  if (S1CP<>DestCP) or (S2CP<>DestCP) then
    begin
      ansistr_concat_complex(DestS,S1,S2,DestCP);
      exit;
    end;
  { only assign if s1 or s2 is empty }
  if (S1='') then
    begin
      DestS:=s2;
      exit;
    end;
  if (S2='') then
    begin
      DestS:=s1;
      exit;
    end;
  S1Len:=Length(S1);
  S2Len:=length(S2);
  { Use Pointer() typecasts to prevent extra conversion code }
  if Pointer(DestS)=Pointer(S1) then
    begin
      same:=Pointer(S1)=Pointer(S2);
      SetLength(DestS,S1Len+S2Len);
      if same then
        fpc_pchar_ansistr_intern_charmove(PAnsiChar(DestS),0,DestS,S1Len,S2Len)
      else
        fpc_pchar_ansistr_intern_charmove(PAnsiChar(S2),0,DestS,S1Len,S2Len+1)
    end
  else if Pointer(DestS)=Pointer(S2) then
    begin
      SetLength(DestS,S1Len+S2Len);
      fpc_pchar_ansistr_intern_charmove(PAnsiChar(DestS),0,DestS,S1Len,S2Len+1);
      fpc_pchar_ansistr_intern_charmove(PAnsiChar(S1),0,DestS,0,S1Len);
    end
  else
    begin
      SetLength(DestS,S1Len+S2Len);
      fpc_pchar_ansistr_intern_charmove(PAnsiChar(S1),0,DestS,0,S1Len);
      fpc_pchar_ansistr_intern_charmove(PAnsiChar(S2),0,DestS,S1Len,S2Len+1);
    end;
  SetCodePage(DestS,DestCP,false);
end;


[marcov]

Probably because it does not exist yet. The way I understand it: string in FPC 2.7.1 has codepage information attached to it

It does exist, and is actively used for non OO functions (like sysutils basic operations like opening files and manipulate directories), removing the need for third party utf8- versions.
 

[skalogryz]

Some low-cost changes to allow Java users to migrate to  a refurbished Pascal.

1.   replace  brace comments -- { ..} and  (* .. *) with C/C++ style comments ..  //  and /*  .. */
2.   replace begin ... end  with  {.. }  blocks.
3.   abandon the semicolon separator  -- in favour of the terminator.
4.   standardize integer types to track closely C#/C++/C
5.   implement reference counting for all objects, classes, etc.
6.   . . .

I think that's called D language

[Edson]

1.   replace  brace comments -- { ..} and  (* .. *) with C/C++ style comments ..  //  and /*  .. */
2.   replace begin ... end  with  {.. }  blocks.
3.   abandon the semicolon separator  -- in favour of the terminator.
4.   standardize integer types to track closely C#/C++/C
5.   implement reference counting for all objects, classes, etc.
6.   . . .

Number 2 and 3: would change the language. It wouldn't be Pascal.

Number 1:
   Particulary, I like the comments // and /*...*/ of C  , because of:

1.1. They have some kind of better "visual height" (I don't know how to say exactly it in English). The characters { ... }, look weak. In plain text with no syntax highlighting, it is easier to find the comments with the characters /* */.

1.2. They are easier to type. In English keyboard, the keys '/' '*', are better accesible than '{', '}' (no shift needed). In latin keyboards, the case is worse.
 
1.3 The keys / and * are usually close, on the Keyboards. It helps on the typing and changing of simple comments and multiline comments. They are ergonomic.

1.4 Sintactically, the parser for the language would be faster processing comments: // /*...*/ than processing // (* .. *) or // {...}

I think Pascal could easily adopt the comments /* ... */, like has adopted //. But having to support three kinds of multiline comments (* *), {} and /* */ could be complicated.

But if Pascal adopts comments like C, it would make happy to C#, C++, Java, Javascript, PHP, PL/SQL, D, ... programmers.

PS. I had to say it.

[skalogryz]

Number 1:
   Particulary, I like the comments // and /*...*/ of C, because of:
...
1.2. They are easier to type
...

an idea for IDE (Lazarus), on typing of "/*" sequence automatically replace it with "{".
As well as "*/" is replaced with "}"

[Leledumbo]

1.3 The keys / and * are usually close, on the Keyboards. It helps on the typing and changing of simple comments and multiline comments. They are ergonomic.

Not on mine, shift and { is closer. In fact, I have to use / + shift + 8 to type /* on my keyboard, surely shift + { has slight advantage here.

1.4 Sintactically, the parser for the language would be faster processing comments: // /*...*/ than processing // (* .. *) or // {...}

First, comments are removed by lexer, not parser. Second, checking for 2 starting character is slower than 1. Though in the end, the difference would be negligible.

I think Pascal could easily adopt the comments /* ... */, like has adopted //. But having to support three kinds of multiline comments (* *), {} and /* */ could be complicated.

Indeed that's easy, as the only change needed is to add /* to existing starting characters (and */ to corresponding terminator). And it will complicate the lexer, so adding another comment style is not necessary. Get used to existing one, if those C family programmers want to code in Pascal. This is not your family language member and will never be.

[Edson]

1.4 Sintactically, the parser for the language would be faster processing comments: // /*...*/ than processing // (* .. *) or // {...}

First, comments are removed by lexer, not parser. Second, checking for 2 starting character is slower than 1. Though in the end, the difference would be negligible.

I didn't want to be so technical.
One lexer needs to check for the char '/', in Object Pascal language now, because of the comment //. And it has to check two chars anyway. If we add /*, the comparison is done only after detect the char '/' with two chars again. The cases of comparison are reduced drastically, filtered by the char /.
If we have to check aditionally for the char '{' it gives an extra load to the lexer, that can be reduced using a table char, but the table can't be definitly because it has to check two chars again, because of the Pascal directives: {$. If the char '{' would be exclusive for comments, the tokenizer could recognize it faster.

Comments like (* .. *) are worse, because of the char '(' are used many times on a normal code (parameters and expressions). So the lexer have to compare more. Using trees of chars can help, but it carry some additional complexity.

Having just one begining char for comments: '/' could make the lexer faster, more legible and smaller.

[bylaardt]

I laugh because this java joker remember me a tale ...

- in 1911, Lima Barreto wrote a book, here in Brasil: "O Homem que sabia javanês" (The man who knew Javanese) (look at http://pt.wikipedia.org/wiki/O_homem_que_sabia_javan%C3%AAs )
- is a tale of a trickster;
- he said he can spoke javanese...

please javanese is not the universal language!

PS: who are cacofonix? a troll?

[Leledumbo]

One lexer needs to check for the char '/', in Object Pascal language now, because of the comment //. And it has to check two chars anyway. If we add /*, the comparison is done only after detect the char '/' with two chars again. The cases of comparison are reduced drastically, filtered by the char /.
If we have to check aditionally for the char '{' it gives an extra load to the lexer, that can be reduced using a table char, but the table can't be definitly because it has to check two chars again, because of the Pascal directives: {$. If the char '{' would be exclusive for comments, the tokenizer could recognize it faster.

Don't forget that / alone is a lexeme for floating point divide operator token, so adding /* would give 3 branches for possible tokens. It's no different from processing { and {$, which currently also has 2 branches.

Comments like (* .. *) are worse, because of the char '(' are used many times on a normal code (parameters and expressions). So the lexer have to compare more. Using trees of chars can help, but it carry some additional complexity.

Having just one begining char for comments: '/' could make the lexer faster, more legible and smaller.

No, no, no. FPC lexer is a simple handwritten lexer. It doesn't matter if ( is used in parameters, expression or wherever. Lexer doesn't care about it and it won't degrade its performance. Try to write a handwritten lexer, it's easy and you will understand why your theory doesn't apply.

[Nebula]

If you want to go-a-trolling, why not recommend Pascal to these guys
http://www.i-programmer.info/news/87-web-development/7191-mozilla-wants-to-recommend-the-best-tools.html