Recent

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

PierceNg

  • Full Member
  • ***
  • Posts: 111
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: 3828
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.
Just Why?

ASBzone

  • Hero Member
  • *****
  • Posts: 613
  • 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.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7279
  • 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: 3174
  • 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: 2844
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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and 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: 2844
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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and 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

  • Sr. Member
  • ****
  • Posts: 314
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: 9441
  • 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: 2844
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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and 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: 3174
  • 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: 2844
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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and 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: 9441
  • 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)

 

TinyPortal © 2005-2018