Frankenstein Pascal

[yodabitiota]

First post here, so short introduction. Happy FPC&Lazarus user both hobby as professional.

Not sure where to put such question as this, figured might as well drop it here.

Thing that's on my mind for ages is a 'frankenstein' pascal. You know, fancy c operators like ++, replace begin and end block by curlies, and replace the curlies with hashes. But apart those cosmetic tweaks, mostly to increase cross-language readability, very little else. Well, maybe as wish to use 'var' ad-hoc (which has been discussed). It'd just make pascal more similar to 80% of the languages out there. Which i don't really use but i'm lazy.

So, my first approach was to see what macro's and operators could do. That's very limited when it comes to reserved words, or writing an operator or macro for '++' seems not possible at the moment.

So, a wild idea would be to start modifying FP compiler itself. Which is a rabbit hole i'm not sure willing to dive into or have time resources for, though something had to be the occasion one day, but even if so would be sane to check if such endeavor is actually possible; making a mode switch {$FRANKENSTEIN ON} and applying some tweaks to the parser.

Slightly more lazy approach would be to start by dropping it as feature request, somewhere people know about the internals may know, and maybe asking some feedback. It's likely i'm not the first with such suggestion so maybe there's some existing discussion or efforts about such feature that google not easily answered. Any pointers welcome.

[AlexTP]

It is some far-left extremism, that curly brackets for begin-end. And it's not needed, Pascal has it's own syntax which is OK.

[yodabitiota]

It is some far-left extremism, that curly brackets for begin-end. And it's not needed, Pascal has it's own syntax which is OK.

Ok, instead of Frankestein you want to call it Vegan Pascal? Sure.

Syntax is ok, readability suffers. There's a reason python only uses whitespace for block markings. And var declarations out of block are only slightly less bad than global variables at occasion.

I really wish some of those were a feature.

[winni]

It is some far-left extremism, that curly brackets for begin-end. And it's not needed, Pascal has it's own syntax which is OK.

Can you please explain the connection between far-left extremism and curly brackets.
I'm curious.

Winni

[trev]

Can you please explain the connection between far-left extremism and curly brackets.

I imagine that it is the opposite of the connection between far-right extremism and square brackets.

[trev]

Related: https://forum.lazarus.freepascal.org/index.php/topic,53139.0.html

[440bx]

But apart those cosmetic tweaks, mostly to increase cross-language readability,

Readability ??... sounds a lot more like it would greatly increase _unreadability_. 

At least in my mind, it is dubious that the "languages" that use "++" and curly braces are actually programming languages.  When I see that code, it makes me feel like a veterinarian looking at an epileptic chicken's EKG.  It's painful to look at the poor thing's misery.

It'd just make pascal more similar to 80% of the languages out there.

I don't think it is practical nor desirable to make Michelle Pfeiffer look like Roseanne Barr with a beard and curly braces tattooed on her forehead. 

So, a wild idea would be to start modifying FP compiler itself.

It does sound like a wild idea particularly considering that there are, unfortunately, plenty of languages out there that poke the programmer's eyes with curly braces, ampersands and more punctuation characters than Timothy O'Leary ever saw even in his wildest trips.

making a mode switch {$FRANKENSTEIN ON} and applying some tweaks to the parser.

That's how the C language was designed.  40 years later and the scars are still showing.

start by dropping it as feature request,

You might have a future in politics.  Next time there is a big earthquake, you can claim it's a "feature" designed to shake things up.

Any pointers welcome.

here is one http://www.iso-9899.info/wiki/The_Standard 

[engkin]

First post here, so short introduction. Happy FPC&Lazarus user both hobby as professional.

Not sure where to put such question as this, figured might as well drop it here.

Thing that's on my mind for ages is a 'frankenstein' pascal. You know, fancy c operators like ++, replace begin and end block by curlies, and replace the curlies with hashes. But apart those cosmetic tweaks, mostly to increase cross-language readability, very little else. Well, maybe as wish to use 'var' ad-hoc (which has been discussed). It'd just make pascal more similar to 80% of the languages out there. Which i don't really use but i'm lazy.

So, my first approach was to see what macro's and operators could do. That's very limited when it comes to reserved words, or writing an operator or macro for '++' seems not possible at the moment.

So, a wild idea would be to start modifying FP compiler itself. Which is a rabbit hole i'm not sure willing to dive into or have time resources for, though something had to be the occasion one day, but even if so would be sane to check if such endeavor is actually possible; making a mode switch {$FRANKENSTEIN ON} and applying some tweaks to the parser.

Slightly more lazy approach would be to start by dropping it as feature request, somewhere people know about the internals may know, and maybe asking some feedback. It's likely i'm not the first with such suggestion so maybe there's some existing discussion or efforts about such feature that google not easily answered. Any pointers welcome.

Hi there, and thank you for this post. I did laugh after reading the title AND the first five six replies (thank you, 440bx).

As you have seen, you will not be allowed to touch the compiler. But don't get discouraged, it's easier and more logical to work on a transpiler: from Frankenstein Pascal to ObjFPC Pascal.

Beside the changes you want to include, you need to translate locations between Frankenstein Pascal source code and its counterpart ObjFpc Pascal. Line numbers will probably stay the same, it is the location in each line that will change. This will allow finding the location of, say, errors reported by the compiler in the correct location on your side.

If you do come up with a functional transpiler, ideas that are rejected by core developers could be added to yours. Also, new ideas could be tested on your side first before introducing them to FPC.

Edit:
Just to let you know what you are about to face, read this whole thread and it does not finish there, read the replies in the bug report mentioned in the first post. There is also a mailing list thread about it, I don't have the link, where the whole thing started.

I don't blame people resisting new ideas, good or bad, but that should not prevent you from giving your idea a try.

[Martin_fr]

similar to 80% of the languages out there

https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)#Blocks
Gives about 20 {} examples. And almost twice as many other examples.

Ok, https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages
gives approx 60 {} examples, but then there are unlisted none {} languages too.

Not sure, how the 80% got computed. <sarcasm>Probably computed using curly brackets</sarcasm>

[engkin]

Not sure, how the 80% got computed. <sarcasm>Probably computed using curly brackets</sarcasm>

I don't think so, that would make it cryptic and unreadable.

[Handoko]

If you like orange, then buy some oranges.

Yes, you can ask scientists to genetically modify apple to taste like orange. That might work. But why spending time, money and effort for doing it when there are plenty of varieties of orange you can choose from.

[engkin]

If you like orange, then buy some oranges.

Or plant some oranges.

But why spending time, money and effort for doing it when there are plenty of varieties of orange you can choose from.

Because it is possible. Because there is nothing wrong in customizing the language you like the way you wish. Because you enjoy doing what you want to do, not what others want you to do.

I am not sure that you are really looking for an answer because, for one, the question itself implies that there is no space for any improvement, and the available oranges should be more than enough! IMHO, that is not the case. I am sure you agree with me, because IIRC, you plan on making your own game, despite of all the available strawberries.

[Handoko]

I am writing my own game engine because I found none of the available is close to what I want. I really installed and tried them.

I didn't fully read the OP's post. But s/he mentioned feature request, which I believe that means asking other to do it. In my case, I never ask other to write the game engine for me. Changing a language syntax is like changing the flavor of a fruit. To me, it is not very useful. But I would say yes to genetically modify apple to make it high content of Vit C like orange.

[avk]

At least in my mind, it is dubious that the "languages" that use "++" and curly braces are actually programming languages. 

I've heard there is also a perception that classic C is just a computer virus disguised as a programming language.
And C++ is C after a complete takeover of the attacked system.
And C# is a caught and disarmed C in prison.
In turn, Java harmoniously combines the beauty of C++ syntax with the performance of Python.

[MarkMLl]

But don't get discouraged, it's easier and more logical to work on a transpiler: from Frankenstein Pascal to ObjFPC Pascal.

I agree, and was about to make a similar suggestion. That would be instructional (a) because it would be useful practical experience of how tricky it can be to write a compiler and (b) because it would (if accompanied with proper test cases) indicate where there were flaws in the proposed language definition.

As specific examples, since the 1970s it has been generally accepted that whitespace (including line ends) should be ignored while source is being lexed/parsed, with very few exceptions (literal strings not extending over multiple lines unless there is an escape mechanism, the remainder of the line after an  end  in ALGOL being ignored and so on). Languages such as Python which discard ; as a statement separator or terminator fly in the face of that convention: is this really a good thing? And then it turns out that C-like languages can get very nasty if you don't assume whitespace around some of the prefix/suffix operators... and that is an error of language design, not of compiler implementation.

Now when I posted my "Modest Proposal" https://forum.lazarus.freepascal.org/index.php/topic,53139.0.html a few weeks ago (thanks for handling the xref, @Trev) I at least did so with the benefit of substantial experience in multiple language paradigms, and I did my best to do it in a way that respected tradition and wouldn't break stuff. And I still didn't expect people to like it, hence the title :-)

While I am critical of the way that Wirth appeared to rush Pascal out with the specific intention of being similar to ALGOL but not quite compatible, the underlying concepts have been proven to be robust. Tacking extra bits onto Pascal to make it more "C-like" is about as useful as tacking extra bits onto C to make it more "Pascal like"... while both languages can benefit to some extent the result is invariably less elegant than a fresh properly-designed language.

MarkMLl