Recent

Author Topic: how to break out early of a case ?  (Read 42854 times)

440bx

  • Hero Member
  • *****
  • Posts: 2622
Re: how to break out early of a case ?
« Reply #75 on: November 27, 2021, 09:08:42 pm »
Anyway don't fall for the micro syntax trap, it takes more to make a good language than simply implementing a superset of all shorthands of all languages.

In the end what attracts users is visible ability/proof to complete certain tasks, like sizeable programs in the project's target domain.  It is not simply a matter of bullet lists of micro syntax comparisons.
But, in a way, it is.  Designing a language and writing a compiler for it are no simple tasks and, it is not realistic to think that its design and implementation will be perfect the first go round.  Like most everything, getting to something that is a real pleasure to use is an iterative process consisting of a long string of mostly small improvements - what you deride as "micro-syntax".

Being consistently against small improvements that add polish to a compiler/grammar, which I'm afraid, you tend to be, only yields a result that is not well polished around the edges.  The multiple variable initialization is a good example.



@munair,

So far, from what you've stated, I believe your philosophy towards designing and writing the compiler is in the right direction.  Making the compiler eventually self hosting is a good way to ensure the language packs a real punch.  I'm rooting for you. :)
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: how to break out early of a case ?
« Reply #76 on: November 27, 2021, 10:41:17 pm »
In the end what attracts users ... is not simply a matter of bullet lists of micro syntax comparisons.
But, in a way, it is.

With regret, I join this thread to say I agree. You only have to look at the popular distinction between "curly bracket languages" and "Everything else".

Only last week I mentioned Pascal and got an extreme negative reaction from an ex-commercial programmer. The fact that she now makes a living mucking-out stables shouldn't be held against her :-)

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

munair

  • Hero Member
  • *****
  • Posts: 780
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #77 on: November 28, 2021, 08:27:09 am »
With regret, I join this thread to say I agree. You only have to look at the popular distinction between "curly bracket languages" and "Everything else".

Two years ago I did do some programming in Go. The extra shift key required to type a curly bracket quickly becomes an annoyance if you're not used to it. Using actual keywords instead also allows for distinction between declaration blocks and execution blocks. After all, if there's one thing computers are good at, it is repeating things to make life easier for us:

C:
Code: [Select]
#include <gtk/gtkaboutdialog.h>
#include <gtk/gtkaccelgroup.h>
#include <gtk/gtkaccessible.h>
#include <gtk/gtkactionable.h>
... (some 250 includes in gtk.h only)

SharpBASIC:
Code: [Select]
incl is
  "gtk/gtkaboutdialog.h";
  "gtk/gtkaccelgroup.h";
  "gtk/gtkaccessible.h";
  "gtk/gtkactionable.h";
  ...
end;

The is..end; counterpart is do..end; (in Pascal begin..end). These keywords actually say something as opposed to {..}. I've never written a program in C or C++ (other than a "hello world" in C++ 3.0 DOS). These languages are way too symbolic for my taste.
keep it simple

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: how to break out early of a case ?
« Reply #78 on: November 28, 2021, 10:03:52 am »
These languages are way too symbolic for my taste.

I don't care for the use of "symbolic" in this context, since it's already used for things like algebra solvers which can do symbolic manipulation. I'd far prefer "concise"... "pithy" even.

"The C way" is definitely good for some things, but it's an inescapable fact that C has held C++ back and that C++ has, despite its wide adoption, severe flaws.

My choice would be for a core language like a tidied-up Pascal, but with abstractions that allowed all the higher-level cruft to be defined as privileged libraries and a front-end that allowed e.g. braces ** to be expanded to begin/end if that's what the user wanted.

I'm not sure whether that's doable, since keeping the default frontend similar to today's Object Pascal might demand an extensible syntax more flexible than anybody's managed so far. But I don't think that the current situation, where even trivial language tweaks can only be handled by modifying the core compiler with all that that implies, is tenable.

That is my personal opinion, no disrespect of the core team is intended.

MarkMLl

** Or, as I've written before, brackets https://forum.lazarus.freepascal.org/index.php/topic,53139.msg392670.html#msg392670
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: 9766
  • FPC developer.
Re: how to break out early of a case ?
« Reply #79 on: November 28, 2021, 06:41:07 pm »
Getting to something that is a real pleasure to use is an iterative process consisting of a long string of mostly small improvements - what you deride as "micro-syntax".

And that is not true IMHO. Those micro improvements are mostly for language comparison and hardly improve user productivity, if at all. But at the same time all the cruft makes adding real features harder and often has a long trail of little unforeseen consequences to disambiguate and fix.

A good example is the recently suggested named parameters that clashes with e.g. overloading (and that is only the most obvious clash)

Quote
Being consistently against small improvements that add polish to a compiler/grammar, which I'm afraid, you tend to be, only yields a result that is not well polished around the edges. 

That is a matter of taste. If you value detail syntax over real features, it might seem that way. But that is not an universal truth.

Neither is mine probably, but I hope I at least explained my view on it.
« Last Edit: November 28, 2021, 06:58:23 pm by marcov »

munair

  • Hero Member
  • *****
  • Posts: 780
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #80 on: November 28, 2021, 10:28:18 pm »
That is a matter of taste. If you value detail syntax over real features, it might seem that way. But that is not an universal truth.

Detailed syntax is not an antithesis to real features.

Missing 'detailed features' adds to little annoyances over time. If there's room/logic to implement them, then why not? Taking grouped initialization as example, I remember having to set several iterators/counters to zero statement by statement after declaration, which is probably the first reason for the grouped initialization feature request. Admittedly, it doesn't carry as much weight as 'real features', but that's no reason to ignore those 'detailed features'. Polishing a compiler just adds that little extra that allows for an ever better programming experience.

Earlier in this thread you also opted for leaving out explicit fall through, which I would say is more than a detailed feature.
keep it simple

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: how to break out early of a case ?
« Reply #81 on: November 29, 2021, 09:29:45 am »
Missing 'detailed features' adds to little annoyances over time. If there's room/logic to implement them, then why not? Taking grouped initialization as example, I remember having to set several iterators/counters to zero statement by statement after declaration, which is probably the first reason for the grouped initialization feature request.

Initialisation where there is a list of expressions assigned to a list of lvalues can be very useful. However experience shows that the C-style multiple assignment a = b = 0 is nothing but trouble, particularly where there is automatic type coercion.

Noting Marco's comment about named parameters: that is something which, broadly speaking, I favour /but/ I suspect that the extra verbosity would prevent most people from using it in the situations where it would be really useful. I think that allowing multiple record field assignment (not just initialisation) would be less contentious and would provide an equivalent facility.

An alternative would be to allow a Smalltalk-style keyword sequence as function invocation, but while I use it in some of my own scripting I've never really tried to work out whether it is compatible with "Pascal as we know it".

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: 9766
  • FPC developer.
Re: how to break out early of a case ?
« Reply #82 on: November 29, 2021, 11:18:28 am »
That is a matter of taste. If you value detail syntax over real features, it might seem that way. But that is not an universal truth.

Detailed syntax is not an antithesis to real features.

Missing 'detailed features' adds to little annoyances over time.

Only in the eyes of people that want to see any missing shorthand from any other language as such. As said they are more about giving a false sense of familiarity than about productivity.

Quote
If there's room/logic to implement them, then why not?

As said (with example) there is often crosstalk (unintended consequences) between features in a large, organically grown languages as Object Pascal is. As an additional bump, FPC is also a multi dialect compiler, which adds yet another dimension of possible complications.

Quite often the consequences are not visible up front.  But once it is in, you are stuck with it due to the backwards compatibility policies. Also the compromises are often sometimes liked by none because the syntax of the originating language is too ambiguous and has to be changed, or the application is limited.

Besides feature clashes there is also error generation to contend with. FPC prides itself on high quality error messages, and not just vague endless rows of "syntax error, unexpected token <x>". This is also quite often overlooked by the initial design of such quick and dirty language extensions.

Moreover, the person initiating the support often moves on leaving the core developers to pick up the pieces.

If you want language experimentation, by all means do it in a new dialect as Sharpbasic, plan it up front, and you can still remove failed experiments in the early versions.

Quote
Taking grouped initialization as example,
 
I remember having to set several iterators/counters to zero statement by statement after declaration, which is probably the first reason for the grouped initialization feature request.

I don't believe that any occasional verbosity automatically warrants a language expansion.  Moreover because FPC is not a language experimentation project in the first place.

Quote
Admittedly, it doesn't carry as much weight as 'real features', but that's no reason to ignore those 'detailed features'. Polishing a compiler just adds that little extra that allows for an ever better programming experience.

Mostly I get the impression that the only ones that care are the handful pressing for extensions, and more from an angle of  language design rather than pure users.

Moreover I'm even more wary if those same suggesters also dodge bearing real responsibility as core developers, but are only gaslighting the forums.

Quote
Earlier in this thread you also opted for leaving out explicit fall through, which I would say is more than a detailed feature.

IIRC I opted for using gotos and then having the optimizer eliminate that, for the rare cases that fall through is necessary. Since that is a solution without any syntax extensions, it is quite in line with my opinion stated above.


« Last Edit: November 29, 2021, 12:07:04 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: how to break out early of a case ?
« Reply #83 on: November 29, 2021, 11:47:34 am »
I agree with most of what you've said, in particular that most of those demanding extra sugar are neither long-term FPC users nor people with the skillset that would allow them to contribute at the core level.

Only in the eyes of people that want to see any missing shorthand from any other language as such. As said they are more about giving a false sense of familiarity than about productivity.

However as a counterexample I'd like to highlight the ALGOL-style conditional expression that Wirth unaccountably omitted from Pascal:

Code: [Select]
  a := if b then c else d;

since this can't easily be emulated using a function and is such a common idiom in mainstream ALGOL derivatives- by which I of course mean C etc.- that its absence is embarrassing.

Apart from that I think that your comments about the difficulty of adding and testing facilities add weight to my contention that today's Pascal family (i.e. Object Pascal plus the other variants supported by FPC) has put on far too much weight and needs to be slimmed down to a core language flexible enough to support syntactic extensions.

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

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 780
Re: how to break out early of a case ?
« Reply #84 on: November 29, 2021, 12:37:51 pm »
Code: [Select]
  a := if b then c else d;

Like:

Code: Pascal  [Select][+][-]
  1. if b then a := c else a := d;

?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9766
  • FPC developer.
Re: how to break out early of a case ?
« Reply #85 on: November 29, 2021, 12:50:19 pm »
However as a counterexample I'd like to highlight the ALGOL-style conditional expression that Wirth unaccountably omitted from Pascal:

Code: [Select]
  a := if b then c else d;

since this can't easily be emulated using a function and is such a common idiom in mainstream ALGOL derivatives- by which I of course mean C etc.- that its absence is embarrassing.

Hasn't there has been talk about this, ifthen() becoming an intrinsic and only evaluating the sides as necessary.   (because objective pascal needed it???)

I don't know if it happened in the end. Maybe Pascaldragon knows.
« Last Edit: November 29, 2021, 12:56:03 pm by marcov »

winni

  • Hero Member
  • *****
  • Posts: 2847
Re: how to break out early of a case ?
« Reply #86 on: November 29, 2021, 12:53:01 pm »
Hi!

Code: Pascal  [Select][+][-]
  1. a := math.ifthen (b,c,d);
  2.  
  3.  

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 3648
Re: how to break out early of a case ?
« Reply #87 on: November 29, 2021, 01:33:37 pm »
Code: Pascal  [Select][+][-]
  1. a := math.ifthen (b,c,d);
  2.  

Not equivalent since it evaluates the parameters unconditionally.

Noting also @SymbolicFrank's comment: I agree, but I can assure you that if translating a large amount of code from just about any ALGOL-derivative other than the Pascal clade the absence gets to be a right pain. And one so basic that it's difficult to explain when asking questions of the original authors.

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: 3648
Re: how to break out early of a case ?
« Reply #88 on: November 29, 2021, 01:37:39 pm »
Hasn't there has been talk about this, ifthen() becoming an intrinsic and only evaluating the sides as necessary.   (because objective pascal needed it???)

I don't know if it happened in the end. Maybe Pascaldragon knows.

I think he's looked at it but never seen it as pressing. However I highlighted this more as something which was a weird omission from the language than as an immediate "must-have": IMO it should really have been implemented at about the time that Pascal functions gained the ability to return values larger than simple numbers.

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

440bx

  • Hero Member
  • *****
  • Posts: 2622
Re: how to break out early of a case ?
« Reply #89 on: November 29, 2021, 03:39:37 pm »
I don't believe that any occasional verbosity automatically warrants a language expansion.  Moreover because FPC is not a language experimentation project in the first place.
The multiple initialization feature isn't about eliminating some verbosity.  It is about giving the language a mechanism that allows it to show that 2 or more variables should have the same initial state.

The fact that a data type can be associated with multiple variables isn't about eliminating verbosity, it is about giving the language a mechanism that enables it to declare that two or more variables should be of the same type.  This would be error prone if each variable had to be declared individually and, it would make maintenance more difficult.  For those same reasons, the language should support multiple variable initialization.  I believe you know this but, instead you pretend it's about "verbosity" and FPC not being an "experimentation project".

In addition to that, the missing multiple variable initialization shows there is an inconsistency in the grammar and that the grammar is gratuitously intransitive where it could easily be.  Specifically,
Code: Pascal  [Select][+][-]
  1. var
  2.   VariableA                       : integer = 0;  { no problem initializing this }
  3.   VariableB, VariableC, VariableD : integer;      { no problem with that either - and it _not_ about eliminating verbosity }
but, when you try
Code: Pascal  [Select][+][-]
  1. VariableB, VariableC, VariableD : integer = 0;   { sorry, no can do }
A language that allows the first two, should also allow the third simply for symmetry, consistency and completeness (of course, why would anyone care about those things.)
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

 

TinyPortal © 2005-2018