Lazarus

Miscellaneous => Suggestions => Topic started by: MarkMLl on February 01, 2021, 10:16:43 am

Title: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 01, 2021, 10:16:43 am
It seems that hardly a month can pass before somebody, almost always a newcomer to the forum and frequently a newcomer to Pascal, makes the earnest suggestion that the language would be improved if instead of having begin and end tokens Pascal adopted braces ("curly brackets") to delimit a block.

If I comment to this I usually point out that as well as being a long-accepted comment marker in Pascal, the closely-related language Modula-2 uses braces to delimit sets, and since much of the syntax of Object Pascal (i.e. the post Jensen & Wirth dialect) resembles Modula-2 it would make sense to reserve the option to use Modula-2 style sets etc. at some point in the future.

A literal set delimited by braces is unordered, i.e. the two sets {'a', 'b', 'c'} and {'a', 'c', 'b'} are indistinguishable from the POV of the language. Taking that into consideration, using braces to delimit a code block would appear to be particularly inappropriate, since the whole point of a code block is that the statements it encloses are executed in an ordered fashion.

I would propose instead that rather than using braces { } to delimit a code block, it would be more appropriate to use (square) brackets [ ]. I believe that there are a number of plausible arguments in this suggestion's favour:

* Among ALGOL-derived languages, square brackets are universally understood to represent array indexes which are by their nature ordered.

* Square brackets were adopted as block delimiters by Smalltalk in 1970. As such this usage predates C (1972) and is roughly contemporaneous with B and BCPL.

* I believe that this suggestion would be compatible with Pascal's existing syntax.

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.

MarkMLl
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: 440bx on February 01, 2021, 11:23:12 am
I find the fixation some people have with curly brackets a bit peculiar but, I suggest a compromise.  Those who want curly brackets should purchase a hair curler and curl their hair before writing code.  That way they get their "curl fix" and might be more inclined to leave the Pascal language alone.

If someone could get donald trump to sell hair curlers, we might get the "curly boys".

Seriously, if someone loves curly brackets so much, they should program in C, all the curly brackets they can type. 

Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: Zvoni on February 01, 2021, 11:51:59 am
If someone could get donald trump to sell hair curlers, we might get the "curly boys".
"CURL FIRST!"

Nevermind, that it would be a "fake implementation" like everything else in Donnie's Life.....
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: marcov on February 01, 2021, 11:59:32 am
It seems that hardly a month can pass before somebody, almost always a newcomer to the forum and frequently a newcomer to Pascal, makes the earnest suggestion that the language would be improved if instead of having begin and end tokens Pascal adopted braces ("curly brackets") to delimit a block.

Yes.

Quote
since much of the syntax of Object Pascal (i.e. the post Jensen & Wirth dialect) resembles Modula-2 it would make sense to reserve the option to use Modula-2 style sets etc. at some point in the future.

It is already reserved for comments.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: PascalDragon on February 01, 2021, 01:10:35 pm
I would propose instead that rather than using braces { } to delimit a code block, it would be more appropriate to use (square) brackets [ ]. I believe that there are a number of plausible arguments in this suggestion's favour:

You do notice that by suggesting an alternate, you're essentially starting the absolute same discussion that's involved with the usual suggestion just with a bit of different flavoring?

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.

There won't be any kind of braces as block markers, cause this is Pascal which uses words instead of symbols for such things.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: Bart on February 01, 2021, 01:15:06 pm
There won't be any kind of braces as block markers, cause this is Pascal which uses words instead of symbols for such things.

Yes, Pascal is a verbose language by design.
If you dislike verbosity, there are plenty of alternatives available, some of them are also very suitable for NARGs.

Bart
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: ASBzone on February 01, 2021, 01:27:34 pm
Seriously, if someone loves curly brackets so much, they should program in C, all the curly brackets they can type.

Or GoLang...
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: trev on February 01, 2021, 01:29:37 pm
For the reverse obsession, when I was involved in the development of the Opus CBCS (BBS) in the early 1980s, the original author Wynn Wagner III (RIP) wrote C like Pascal - no curly braces to be seen, but begin and end everywhere - see, for example zreceive.c (http://webcache.googleusercontent.com/search?q=cache:N2EdrSNg4ZIJ:read.pudn.com/downloads99/sourcecode/comm/com_port/403548/zmodem/ZRECEIVE.C__.htm&hl=en&gl=au&strip=1&vwsrc=0) :)
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: Leledumbo on February 03, 2021, 08:02:17 pm
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.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: CM630 on February 03, 2021, 08:18:38 pm
The Arduino language (some kind of C I think) uses {} instead of Begin/ End. I still cannot get used to that.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 03, 2021, 08:44:27 pm
The Arduino language (some kind of C I think) uses {} instead of Begin/ End. I still cannot get used to that.

It's C++, with a little bit of extra preprocessing.

MarkMLl
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: skalogryz on February 03, 2021, 09:32:20 pm
To be honest, I don't see a reason why not to have some sort of "Cascal" project.
Just a C-like syntax notation (language, if you want) that would be translated directly into Pascal.
Naturally RTL and all language types would be Pascal based (strings, dynamic arrays, managed types... etc)

Maybe go a bit further than C-family and allow things like this:
Code: C  [Select][+][-]
  1. void SomeFunc(int a, b, c)

Again: this should be aside project (a translator), not a native compiler support.

Some syntax would need to be introduced to provide support for Pascal units.
But they can also be borrowed from c-like non-OOP languages, i.e. D.

In some sense, this is what Apple done with Swift-language.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 03, 2021, 10:38:45 pm
To be honest, I don't see a reason why not to have some sort of "Cascal" project.

Leaving aside for a moment the "reservations" of the community, I think the major argument against that is the extent to which type checking etc. would have to be relaxed... do we really want to be party to that? C is really not a well-thought-out language, it started off with essentially nothing which could not be implemented using assembler macros (adding a modicum of block structure to assembler code was a very popular project in the 80s, hence I suspect Trev's comment about somebody who used begin and end with C).

C++ has attempted to tighten things up and has then layered a lot of complexity on top, which is basically "putting lipstick on a pig". Few people who- IMO- really know what they're doing attempt to defend it: "Within C++, there is a much smaller and cleaner language struggling to get out." (Stroustrup).

MarkMLl
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: skalogryz on February 03, 2021, 10:48:03 pm
I think the major argument against that is the extent to which type checking etc. would have to be relaxed...
why relax any pascal restriction?
(except for the mandatory "var" section, which comes next to curly braces?)

People who is asking for curlies, don't have a type checking on their mind.

Even the operators priority could stay in a pascal way. (yes, people will complain that copy-pasted C code doesn't compile in Cascal)
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: dpremus on February 03, 2021, 11:54:09 pm
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 "Đ".    :)

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.

Code: Pascal  [Select][+][-]
  1. (*
  2.  
  3. { frist multiline
  4.   comment }
  5. procedure test1;
  6. begin
  7. end;
  8.  
  9. { second multiline
  10.   comment }
  11. procedure test2;
  12. begin
  13. end;
  14.  
  15. *)
  16.  


But only thing that I would like to see in Pascal, was multi line string. That will be great for SQL and HTML template.


Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: PierceNg on February 04, 2021, 01:06:28 am
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.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: lainz on February 04, 2021, 02:19:59 am
I don't understand all the hate about other languages.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: ASBzone on February 04, 2021, 02:29:30 am
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...  :D
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: Martin_fr on February 04, 2021, 02:40:26 am
Think of Pascal as your dentist. And then you know why curly braces wont fit.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: PascalDragon on February 04, 2021, 09:01:22 am
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.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 04, 2021, 09:46:45 am
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
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 04, 2021, 09:53:39 am
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
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: dseligo on February 04, 2021, 10:40:43 am
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.  :)
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: marcov on February 04, 2021, 11:24:47 am
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.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 04, 2021, 11:46:24 am
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
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: PascalDragon on February 04, 2021, 01:12:56 pm
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 :o ), it is indeed handled as a digraph. In the other modes this is not done due to Delphi- and nowadays also backwards compatibility.
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on February 04, 2021, 01:37:02 pm
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 :o ), 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
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: marcov on February 04, 2021, 03:04:36 pm
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 :o ), 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)
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: damieiro on September 23, 2021, 08:41:41 pm
A doubt:

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

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.


Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on September 23, 2021, 09:33:58 pm
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
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: prof7bit on September 25, 2021, 11:48:53 am
It doesn't get mentioned very often but one important point I noticed is this: For many people with one of the European keyboard layouts the curly braces are a major PITA! On my German keyboard I have blindly typed "begin" <Enter> faster than It takes me to bend my fingers into the weird position that is needed to type "{".

This is probably one of the reason why Pascal is much more popular in Europe than in USA. And why Americans are unable to see why anybody would have a problem with {}.

It is also one of the reasons I personally also gravitate towards other languages that do NOT use curly braces or any other symbols or keywords for block delimiting at all, for example Python proves that they are indeed not needed at all and their omission only improves the usability of the language. I rather have scanner and parser do the hard work to figure out the blocks than having the person in front of the keyboard having to do extra work for the convenience of the computer. After all these machines were invented to work for humans, not the other way around!
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on September 25, 2021, 12:18:55 pm
Well of course, when Wirth hurriedly defined Pascal keypunches (almost universally made by IBM, even if rebadged) rarely had braces ("curly brackets" to the unwashed). The result was that he initially allowed BCPL-style /* */ as digraphs to enclose a comment, before characteristically deciding to break an existing convention and use (* *) instead. I believe that there has been earlier discussion of the extent to which FPC (etc.) distinguishes between digraphs and lexemes in this situation.

Finally, I would remind everybody that I started this thread as a focus for the "braces vs begin-end" discussion, and as somewhere that the next irritating tyro who suggested a gross change could be pointed. And while I tried to make the arguments in my initial post fairly robust, I chose the subject name carefully: would anybody unfamiliar with the trope please read https://en.wikipedia.org/wiki/A_Modest_Proposal and consider my points in that context.

MarkMLl
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: Thaddy on September 25, 2021, 12:24:24 pm
"Everything is a comment" then?
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: MarkMLl on September 25, 2021, 12:31:48 pm
"Life is an isthmus"
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: Thaddy on September 25, 2021, 02:10:02 pm
It is more like "limitata"  :D

(A very narrow way of thinking, in latin )
Title: Re: A modest proposal in response to those who want "curly brackets"
Post by: VTwin on September 25, 2021, 05:21:07 pm
Using Code Templates I type "b<return>" and get:

Code: Pascal  [Select][+][-]
  1. begin
  2.   |
  3. end;

Two key presses for an indented code block.
TinyPortal © 2005-2018