Recent

Author Topic: Making the semicolon useless  (Read 24836 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Making the semicolon useless
« Reply #30 on: April 03, 2020, 09:43:51 am »
Languages changes, evolves or die.

And most mutations die.

guest58172

  • Guest
Re: Making the semicolon useless
« Reply #31 on: April 03, 2020, 09:57:01 am »
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:

Code: Pascal  [Select][+][-]
  1. if condition then
  2.   trueStatement;
  3. else
  4.   falseStatement;

You see before the else.

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
Re: Making the semicolon useless
« Reply #32 on: April 03, 2020, 10:02:42 am »
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:

Code: Pascal  [Select][+][-]
  1. if condition then
  2.   trueStatement;
  3. else
  4.   falseStatement;

You see before the else.

In Pascal, ;  is the block or statement separator, what you ask is to introduce whitespace and line separators in the language that is a quadratic complexity added to the parser.... Very good idea...
Anyway, the whole discussion is rather futile given the fact that Pascal relies on the ; in more than one way as many explained. See Marco's answers for example.

I might add that the only language that I use that parses such things without effort is Python, not Go, which has its own quirks.
Anyway a teaser:
Code: Pascal  [Select][+][-]
  1. {$mode delphi}{$H+}
  2. {$macro on}{$Define endblock:=;}
  3. procedure truestatement;begin end endblock
  4. procedure falsestatement;begin end endblock
  5. var
  6.   condition:boolean = true;
  7. begin
  8. if condition then
  9.   trueStatement // endblock
  10. else
  11.   falseStatement endblock
  12. end.
« Last Edit: April 03, 2020, 10:19:35 am by Thaddy »
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making the semicolon useless
« Reply #33 on: April 03, 2020, 10:25:19 am »
In Pascal, ;  is the block or statement separator, what you ask is to introduce whitespace and line separators in the language that is a quadratic complexity added to the parser.... Very good idea...

Having spent time supporting and maintaining products such as operating systems which were driven by their compatibility with some dominant competitor (e.g. any DOS-compatible OS had to be able to run Lotus 1-2-3 and MS Flight Simulator), I'd suggest that having a codebase which is dominated by exceptions and hacks is a very bad idea indeed.

ALGOL-derived languages have firm rules as to the significance of statement separators, and with the exception of literal strings and the dot after end. treat line endings as simple whitespace which can be discarded early in order to allow the compiler to use lookahead. Adding exceptions to this without introducing a new language mode (e.g. one in which  ;  is not just optional but is forbidden) is a recipe for disaster.

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: Making the semicolon useless
« Reply #34 on: April 03, 2020, 10:29:32 am »
To err is human, but to really mess things up, you need a computer.

To err is human, but to really mess things up, you need a badly-implemented parser.

And you can't implement a parser properly without a robustly-designed syntax.

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

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
Re: Making the semicolon useless
« Reply #35 on: April 03, 2020, 10:53:42 am »
Indeed.
Specialize a type, not a var.

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Making the semicolon useless
« Reply #36 on: April 03, 2020, 11:44:02 am »
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:

Code: Pascal  [Select][+][-]
  1. if condition then
  2.   trueStatement;
  3. else
  4.   falseStatement;

You see before the else.
I suppose that would be possible by considering the semicolon as required statement terminator. But then it would not just be allowed in this case but mandatory.
Conscience is the debugger of the mind

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Making the semicolon useless
« Reply #37 on: April 03, 2020, 11:44:53 am »
Languages changes, evolves or die.

And most mutations die.
That escalated quite quickly. This is just a discussion, relax.  8-)
Conscience is the debugger of the mind

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Making the semicolon useless
« Reply #38 on: April 03, 2020, 12:10:47 pm »
Languages changes, evolves or die.

And most mutations die.
That escalated quite quickly. This is just a discussion, relax.  8-)

It wasn't meant in a bad way, so it is not an escalation, but I admit in retrospect it can be taken wrongly.

It was meant to note that in evolution few changes make it long term. IOW "Not every changement is an improvement". Sometimes even only after quite a while (e.g. when circumstances change and the change lead to overspecialisation).

I thought that a fitting analogue for how a simple idea like skipping semicolons can get complicated really quickly as this discussion demonstrates.



Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
Re: Making the semicolon useless
« Reply #39 on: April 03, 2020, 02:19:15 pm »
For such a feature to implement, you require a grammar that verifies its validity anyway.
And that is quite complex as I tried to explain: the parser for such a language becomes - at least!!- ll(N) instead of ll(1).
A formal Pascal grammar should be ll(1) by definition. (Don't worry, FPC already does not comply to this)

But I would start with a grammar that can prove correctness.
Specialize a type, not a var.

guest58172

  • Guest
Re: Making the semicolon useless
« Reply #40 on: April 03, 2020, 05:08:34 pm »
I don't think that the semi colon is a problem and I don't think it is useless either, as argumented by others. But to the opposiste I would even like it to be allowed in a specific case:

Code: Pascal  [Select][+][-]
  1. if condition then
  2.   trueStatement;
  3. else
  4.   falseStatement;

You see before the else.

In Pascal, ;  is the block or statement separator, what you ask is to introduce whitespace and line separators in the language that is a quadratic complexity added to the parser.... Very good idea...

There's a misunderstanding here. The semicolon before else does not introduce complexity.
To be clear in the discussion I was not partisan of making the semicolon optional, I just came to say that it could be allowed before else.

you have
Code: bnf  [Select][+][-]
  1. IfStatement   ::= 'if' Condition ThenStatement ElseStatement?
  2. ThenStatement ::= 'then' Statement
  3. ElseStatement ::= 'else' Statement


That's perfectly LL(1), in no way more than one lookup is necessary.

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
Re: Making the semicolon useless
« Reply #41 on: April 03, 2020, 05:16:41 pm »
It introduces complexilty because of the dangling else .... That is not complex, isn't it... Try to adapt a Pascal grammar...<SIGH  >:D>
Specialize a type, not a var.

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Making the semicolon useless
« Reply #42 on: April 03, 2020, 06:45:28 pm »
It was meant to note that in evolution few changes make it long term. IOW "Not every changement is an improvement". Sometimes even only after quite a while (e.g. when circumstances change and the change lead to overspecialisation).
Ok I understand where you're coming from. I would agree in general with what you say.

In this case of course, it is not a random mutation and I would love to have a semicolon-less code. That's why I am entertaining this discussion, to get insights from others and not be alone thinking about it.
Conscience is the debugger of the mind

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Making the semicolon useless
« Reply #43 on: April 03, 2020, 06:50:26 pm »
you have
Code: bnf  [Select][+][-]
  1. IfStatement   ::= 'if' Condition ThenStatement ElseStatement?
  2. ThenStatement ::= 'then' Statement
  3. ElseStatement ::= 'else' Statement


That's perfectly LL(1), in no way more than one lookup is necessary.
I am not sure I understand where you define the semicolon here.

Though would like semicolons optional, if we have semicolons, I would rather like your idea, because more often than I would like, I am adding or removing the semicolon as I move the statement, add an else, etc. And it would be simpler not to have to do that.
Conscience is the debugger of the mind

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Making the semicolon useless
« Reply #44 on: April 03, 2020, 06:54:19 pm »
In this case of course, it is not a random mutation and I would love to have a semicolon-less code. That's why I am entertaining this discussion, to get insights from others and not be alone thinking about it.

Well, I've said most arguments, the only remaining one is that in retrospect I think Mark and Thaddy are right. It cuts so deep into the base principle of the parser, that you probably have to start over.

So I would like to retract my earlier advise to try modify fcl-passrc, but advise you to whip up some relevant examples (also think about errorhandling, so also wrong/non compilable tests!) and try to use some parser generator tool to get some grammar that is roughly working on these examples to flesh out the details and get a starting point.
« Last Edit: April 03, 2020, 07:37:28 pm by marcov »

 

TinyPortal © 2005-2018