A modest proposal in response to those who want "curly brackets"

[PierceNg]

Or GoLang...

That one refuses to be called a C family member despite taking the basic block structure from it just because it's also inspired by Oberon (consequently, Pascal) for declaration sectioning, declaration order (identifier first, type later) and type bound procedures, perhaps also import aliasing.

The few times I used Go for little ~100 LOC CLI tools it felt like C with training wheels.

[lainz]

I don't understand all the hate about other languages.

[ASBzone]

My son (age 19) has dabbled in Pascal, but greatly prefers Python, which he took to in a heartbeat when he saw it.  I tease him about compiled speed all the time, and his fear of strongly typed languages, but he's integrated Numba and Numpy to get a lot of performance from his code.

This week he has convinced me that we should both learn an extra language, and he chose Nim.  I was going to pick GoLang, but he thinks it will be cool to do the same language.  I'm going to take him up on that, and we'll have a little bit of fun porting some of our existing apps (at least smaller ones) into Nim.  He likes it because it is quite Python like, and I appreciate that it has robust typing.

Personally, while I can understand why people often ask for X feature in some other language, I am okay with each language having its focus and strong points and differences.  I cannot imagine any language having all the features that *I* like in a language, yet managing to remain appealing to everyone else.  I also expect that the resulting complexity from such a language or UI would be very undesirable.

Off to a little bit of Nim development I go... 

[Martin_fr]

Think of Pascal as your dentist. And then you know why curly braces wont fit.

[PascalDragon]

To be honest, I don't see a reason why not to have some sort of "Cascal" project.

But it's not something the FPC compiler will dabble in.

(yes, people will complain that copy-pasted C code doesn't compile in Cascal)

Which is the reason why someone added support for << and >> in FPC which is still driving me nuts regarding future nested specialization support especially as it's done inside the scanner...

So in that time I was used  "(*"   and  "*)" instead curly brackets. and "(." ".)" instead "["  "]"
But  "(*"   "*)" are still great for debugging, for example when you need to comment some code that already have comments with curly brackets.

Fun fact: FPC handles the replacement for square brackets as well (and obviously the comment style):

Code: Pascal  [Select][+][-]

1. {$mode iso}
2.  
3. var
4.   a: array(.0..4.) of LongInt;
5. begin
6.   (* mixing is okay for square brackets as well, but to do this for comments you need to
7.      use mode ISO and FPC 3.3.1! }
8.   a(.4.) := 42;
9.   a(.3] := 2;
10.   a[2.) := 1;
11. end.

[MarkMLl]

When I was started learning Pascal (Turbo Pascal 3.0 for DOS) there is no curly brackets on my keyboard.

:-) Of course, Wirth started working on Pascal using something like an IBM 029 cardpunch (I'm being cautious here since some details of the chronology remain unclear) which similarly lacked braces. If one refers to the earliest version of his report on the language (predating J&W) one finds that he used /* */ as digraphs.

MarkMLl

[MarkMLl]

Fun fact: FPC handles the replacement for square brackets as well (and obviously the comment style):

Am I right in assuming that (* *) shouldn't be considered to be digraphs for { } since (* } and { *) don't work? My recollection is that some things are still picky about which form they use, e.g. macros requite breaces.

MarkMLl

[dseligo]

When I was started learning Pascal (Turbo Pascal 3.0 for DOS) there is no curly brackets on my keyboard.

In that time curly brackets was replaced with local characters for my country so "{"  was replaced with "Š"
and "}" was replaced with "Đ".   

It looks like we started learning Pascal around same time in the same country. 

[marcov]

Fun fact: FPC handles the replacement for square brackets as well (and obviously the comment style):

Am I right in assuming that (* *) shouldn't be considered to be digraphs for { } since (* } and { *) don't work? My recollection is that some things are still picky about which form they use, e.g. macros requite breaces.

That is a feature so you can use style B to quickly comment blocks that contain comments in Style A.

It is a feature I regularly miss in C btw, or it is just my ignorance.

[MarkMLl]

That is a feature so you can use style B to quickly comment blocks that contain comments in Style A.

It is a feature I regularly miss in C btw, or it is just my ignorance.

I can't comment on C, but obviously Modula-2 allows comments to be nested... whether or not that is a good thing without an easy way for the programmer to see exactly where the compiler thinks the outer comment stops (i.e. regularly-used listing files etc.) is arguable.

Modern C/C++ compilers are a "triumph of ingenuity over common sense": the language should have been properly-designed in the first place.

MarkMLl

[PascalDragon]

Fun fact: FPC handles the replacement for square brackets as well (and obviously the comment style):

Am I right in assuming that (* *) shouldn't be considered to be digraphs for { } since (* } and { *) don't work? My recollection is that some things are still picky about which form they use, e.g. macros requite breaces.

As I have written in the comment of the example code, in trunk in mode ISO (and it should also be EXTENDEDPASCAL, but isn't ), it is indeed handled as a digraph. In the other modes this is not done due to Delphi- and nowadays also backwards compatibility.

[MarkMLl]

Am I right in assuming that (* *) shouldn't be considered to be digraphs for { } since (* } and { *) don't work? My recollection is that some things are still picky about which form they use, e.g. macros requite breaces.

As I have written in the comment of the example code, in trunk in mode ISO (and it should also be EXTENDEDPASCAL, but isn't ), it is indeed handled as a digraph. In the other modes this is not done due to Delphi- and nowadays also backwards compatibility.

Thanks for that. I wasn't sure whether that only applied to (square) brackets, or also to braces ("curly brackets").

MarkMLl

[marcov]

As I have written in the comment of the example code, in trunk in mode ISO (and it should also be EXTENDEDPASCAL, but isn't ), it is indeed handled as a digraph. In the other modes this is not done due to Delphi- and nowadays also backwards compatibility.

(Afaik nesting comments were one of the first differences between mode fpc and TP, before the Delphi compatibility)

[damieiro]

A doubt:

Not for the braces vs begin end (i go for begin end).

If this suggestion were adopted, and if a later variant of Pascal adopted the Modula-2 convention of using braces { } to identify an (unordered) literal set, it might also be possible to use braces to identify a group of statements that could be parallelised or at least reordered subject to dataflow dependencies by the compiler.

I think interesting the Ordered set vs unordered. Does the compiler does some distinction, reorder these by default or is it some kind of walkthrough about parallelisable syntax. I think the good idea of this suggestion is this point.

[MarkMLl]

I think interesting the Ordered set vs unordered. Does the compiler does some distinction, reorder these by default or is it some kind of walkthrough about parallelisable syntax. I think the good idea of this suggestion is this point.

A set is, by definition, unordered: it's basically a bitmap specified by which bits are set. Some languages/implementations limit set size to that of a machine word, some have a specific set variant to allow word-sized operations (but I've come across cases where the bit order isn't adequately defined).

Smalltalk (and possibly others) has a bag as a fundamental data type (supported by the language, not just by a library) which is a set where each element is counted. But the elements themselves still have no implicit order.

MarkMLl