Pascal integration

In Pascal, the console output doesn’t show up in the bottom-left panel if there is no line break (#13#10). Hence the following code will show nothing:

write('hello world');

In Pascal, the {$H+} option may be added as a compiler parameter “-Sh” which would avoid to have to write it in the code (it is still possible to specify {$H-} if ever one wishes to use short strings).

In Pascal, we use “<” et “>” to compare as well. It happens (with generics) that a word is wrapped but it is rare. So the code editor should not add “>” or only if after “specialize” or “generic” keywords. For example:

type
  generic TList<T> = class
  ...
  IntList = specialize TList<integer>;

why not use writeln()

One can use writeln to add line break indeed. Though in other languages, the line break is not needed. And when golfing that’s two more chars for ln.

Pascal is very wordy by design.

print(), println(), write(), wirteln() are common in many languages.
When some languages do not have the “ln” option, they have their own restriction to print one line by several commands.

If the only reason to alter the compiler directive is to save two chars, it is better to choose a more concise language having no begin end, which could save you 8 chars in each pair.

I think you did not understand.

The compiler option {$H+} is to have the string type to have variable length (AnsiString) instead of one that is fixed 256 bytes (ShortString). We don’t use ShortString anymore nowadays, unless there is a specific reason for that. The FreePascal compiler, used in Codingame, defaults to legacy, but in practice, {$H+} is in code templates.

This is not related to the write/writeln question. The problem with that is not that write doesn’t put line ending, but that the display of Codingame does not display the text in this case, whereas it does display it with other languages giving the same exact output (without line ending). For example if you do in Python print("hello world", end="")

About code template, the initial code in Pascal, using a TStringList, is very long. There are shorter, more natural when reading numbers, alternatives.

uses sysutils, classes;
procedure ParseIn(Inputs: TStrings) ;
var Line : string;
begin
    readln(Line);
    Inputs.Clear;
    Inputs.Delimiter := ' ';
    Inputs.DelimitedText := Line;
end;

var
    a : Int32;
    b : Int32;
    Inputs: TStringList;
begin
    Inputs := TStringList.Create;
    ParseIn(Inputs);
    a := StrToInt(Inputs[0]);
    b := StrToInt(Inputs[1]);

can be done with:

var
    a : Int32;
    b : Int32;
begin
    readln(a, b);

and if the variables are not numbers but strings separated by spaces:

uses sysutils;
var
    s : string;
    inputs : array of string;
    a : string;
    b : string;
begin
    readln(s);
    inputs := s.Split(' ');
    a := inputs[0];
    b := inputs[1];

That’s good. Your last message sounds like more honest in explaining the issue.

Coders are free to write {$H+} or {$H-} into their codes to control the behavior. I have no opinion on which one should be the default. You can make your request in the languages-update thread:

https://forum.codingame.com/t/languages-update

I guess the compiler’s default behavior (without extra parameter) will be CG’s preferred behavior unless there is a strong reason not to follow.

You have to provide clear and strong reasons to support your arguments. Golfing with pascal is impractical. Your reason should not be related to golfing or saving your effort to type a few extra chars.

The stub generator (which generates the template starting code) is not perfect in many ways. Its only purpose is to provide something that works (mainly to help beginners). It never pretends it works best. One commonly used keystroke sequence by many CG coders is [Ctrl-a, Del] at the beginning of every puzzle.

I don’t think I wasn’t honest before.

About the {$H+} there is room to argue whether or not to put it as a compiler parameter. Still I am making the request about it.

About the display issue when there is no end of line, in my view this is a bug. With other languages, such text is displayed. This is only a display issue, as the validators are fine with that.

The stub generator is not perfect for sure, but when you have the screen filled by unnecessary code, this is worse than “not perfect”.

Maybe nobody at Codingames knows how to program in Pascal, that’s ok. I can help.

While golfing, I use ReadLn too for more Strings at the Input-Line. And even if is a Integer too. You can read all together:

var
    a,  b, c, d : String;
    i : Int32; 
...
ReadLn(a,b,i);
...
ReadLn(b,c,d);

Sometimes you may need Trim() for the string.