Recent

Author Topic: A modest proposal in response to those who want "curly brackets"  (Read 13133 times)

PierceNg

  • Sr. Member
  • ****
  • Posts: 369
    • SamadhiWeb
Re: A modest proposal in response to those who want "curly brackets"
« Reply #15 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.

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: A modest proposal in response to those who want "curly brackets"
« Reply #16 on: February 04, 2021, 02:19:59 am »
I don't understand all the hate about other languages.

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: A modest proposal in response to those who want "curly brackets"
« Reply #17 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
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: A modest proposal in response to those who want "curly brackets"
« Reply #18 on: February 04, 2021, 02:40:26 am »
Think of Pascal as your dentist. And then you know why curly braces wont fit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: A modest proposal in response to those who want "curly brackets"
« Reply #19 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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A modest proposal in response to those who want "curly brackets"
« Reply #20 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
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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A modest proposal in response to those who want "curly brackets"
« Reply #21 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
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: A modest proposal in response to those who want "curly brackets"
« Reply #22 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.  :)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: A modest proposal in response to those who want "curly brackets"
« Reply #23 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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A modest proposal in response to those who want "curly brackets"
« Reply #24 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
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

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: A modest proposal in response to those who want "curly brackets"
« Reply #25 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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A modest proposal in response to those who want "curly brackets"
« Reply #26 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
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

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: A modest proposal in response to those who want "curly brackets"
« Reply #27 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)

damieiro

  • Full Member
  • ***
  • Posts: 200
Re: A modest proposal in response to those who want "curly brackets"
« Reply #28 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.


« Last Edit: September 23, 2021, 09:52:23 pm by damieiro »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A modest proposal in response to those who want "curly brackets"
« Reply #29 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
« Last Edit: September 23, 2021, 09:35:48 pm by 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

 

TinyPortal © 2005-2018