Frankenstein Pascal

[bytebites]

C-language and elegance is something that does not match.

[MarkMLl]

There are countless books about algorithms to scan, parse, generate code and massage data structures used in compiler writing as well as extensive theory on grammars but, I am yet to see a book that is an in-depth scientific/mathematical study of the effects of the grammar on the expressive power of the language and its ability to minimize/eliminate terse and error prone grammatical construct (e.g, =/==, |/||, </<< and countless others in C/C++.)

If I could throw in one additional point. There are, in my opinion, far too many academics who are prepared to suggest some outrageous construct and then devote years to finding a way to compile it efficiently (or, as a related issue, have the compiler issue sensible diagnostics when things go wrong).

There's a very good reason why Her Majesty's Government doesn't recruit diplomats with impenetrable Geordie, Scouse or Devonshire accents: if you want to convey your message succinctly and unambiguously a good start is to use intelligible enunciation and idiom.

My conviction is that if a structure in a programming language is difficult to compile reliably it would probably be better omitted: it's all very well say "we know how to fix it by enhancing the compiler" but every enhancement brings with the risk of yet more bugs and problems.

So, let's keep our base languages simple. Let's identify what /has/ to be in the language, and then find an extension mechanism for the extra features... function and class libraries have proven to be remarkably capable and have extended the life of the basic ALGOL-style languages enormously, but we should always be on the lookout for additional tools /provided/ that they can be implemented robustly.

MarkMLl

[MarkMLl]

Ok, boolean logic is always considered bitwise in Pascal. In C, we can distinguish what we want be & vs &&, | vs || and ! vs ~. In pascal, have to jump little hoops like '(A<>B) and (B<>0)', or alternatively typecasting 'boolean(A) and boolean(B)',  if A and B are integer types, which they happen to do, a lot. It's not 'cleaner code'. 440bx suggest to use '!!' which might be an alternative albeit a bit clumsy.

No it's not, it's determined by the type of the operands. That's a major distinguishing feature between 1970s Pascal and 1970s C, and one that 50 years on C++ is still trying to incorporate (if it fails, it's because of the expectation of its users and their legacy code).

MarkMLl

[PascalDragon]

t'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.

You are not the first with such suggestions and you're also not the first we're shooting down, because there simply will not be any modifications added to the compiler that changes syntax/language fundamentals. And this has not only to with us compiler developers preferring the Pascal language as it is, but also with maintainability. Every addition to the compiler, every new feature needs to be maintained. Now essentially completely reworking the language even if it would be behind a modeswitch is a big chunk of code that would need to be maintained. So no, I'm not even remotely sympathetic to these "suggestions".

That said, what you do in the compiler's source yourself is merely up to you, it's open source after all. But don't expect your changes to appear in upstream.

I totally understand 'weird' features not going mainstream, but if every month someone suggest the same thing then apparently there are thousands thinking like me, just never stirring it up.

Features or syntax additions/modifications should fit nicely into the spirit of the language, that's important.  Things like "++" create all kinds of problems, particularly if they are allowed to precede or follow an identifier (as done in C/C++.)  It really does not fit well into the language, that is also true of the curly braces, they are already used to delimit comments.  FPC allows the use of "<<" and that is a quite a source of headaches.

Here is a feature I suggested https://forum.lazarus.freepascal.org/index.php/topic,49505.0.html that is a nice fit in the language, it's a rather simple one (at least it should be simple) but, it got shot down.  Features that don't fit the language are very unlikely to be adopted (with exceptions such as the previously mentioned "<<".)

The support for the C-style shift operators had been added long before we'd become more self-conscious regarding language design and what it means to work with a language. Nowadays they wouldn't be added anymore (and especially not with the stated reason that it simplifies porting of C code  ) and I'm really considering at least coupling them to the COperators directive...

[dseligo]

But C's 'for' construction does have some elegance and flexibility.

I always hated 'for' in C, and I still do. Those round brackets and I always have to think if I set condition correctly.

As for curly brackets: on my keyboard I have to use AltGr+B and AltGr+N to get them and it's kind of clumsy to do. For me it's easier to write 'begin'/'end'.

[dseligo]

But i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such.

I agree with that.
In my opinion it would be better that delphi conversion tool "translate" Delphi code to Lazarus. I know that units then wouldn't be compatible with Delphi anymore, but it would be easier to maintain FPC/LCL without Delphi mode. I don't know if that's possible.

[avra]

So, in general boolean logic is not really elegant in Pascal. I know C sometimes looks like black magic, but it (boolean logic) is the thing we have to do as programmers, and the same line in Pascal may end up 3 times as long as in C. Allowing bools for multiplication and other math functions (implicit casting of bool to integer) would be very nice to have too.

I have an idea. Why don't you go the other way around? Go to GCC developers and suggest them to bring more of Pascal into C? Just tell me where so I can follow the discussion...     

[marcov]

But i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such.

I agree with that.
In my opinion it would be better that delphi conversion tool "translate" Delphi code to Lazarus. I know that units then wouldn't be compatible with Delphi anymore, but it would be easier to maintain FPC/LCL without Delphi mode. I don't know if that's possible.

Delphi compatibility is much easier than having to get 100 different opinions about what else to converge on.

Further I of course agree with PascalDragon. Too much work, and we are not even searching for language syntax alternatives. There are threads enough about this on the forum (also on C readability and quicker typing, modula2 blockstructure etc). Just search them.

Maybe try to convince GCC to a more pascal mode.

[dseligo]

But i do observe FPC going trough great lengths to maintain Delphi compatibility, while personally i don't care at all for such.

I agree with that.
In my opinion it would be better that delphi conversion tool "translate" Delphi code to Lazarus. I know that units then wouldn't be compatible with Delphi anymore, but it would be easier to maintain FPC/LCL without Delphi mode. I don't know if that's possible.

Delphi compatibility is much easier than having to get 100 different opinions about what else to converge.

Further I of course agree with PascalDragon. Too much work, and we are not even searching for language syntax alternatives. There are threads enough about this on the forum (also on C readability and quicker typing, modula2 blockstructure etc). Just search them.

Maybe try to convince GCC to a more pascal mode.

What has GCC to do with what I wrote?

[cdbc]

Hi
I'm with Pascaldragon & Marcov on this one...
Why add elements with a ton of work, when they're overworked anyway!
I'm happy with FPC & Lazarus as they are!
Regards Benny

[marcov]

What has GCC to do with what I wrote?

Well, you can approach it from two directions,  Cify Pascal or Pascalize C :-)

[dseligo]

What has GCC to do with what I wrote?

Well, you can approach it from two directions,  Cify Pascal or Pascalize C :-)

Did you mix me with OP who wants curly brackets in Pascal?

[440bx]

So, let's keep our base languages simple. Let's identify what /has/ to be in the language, and then find an extension mechanism for the extra features...

I definitely agree with that.  As I'm sure you know, the problem is, it is easy to state the goal. Its correct/robust/solid implementation is a different story.  That's why I believe committees to oversee language design are a good thing.  It's just too easy to believe something is a good idea at the time yet ends up being a really bad one, in one way or another, in the long run.  Writing code is comparatively easy, designing is hard.

I'm really considering at least coupling them to the COperators directive...

At least at first blush, it makes a lot of sense to couple "<<" with the COperators directive.  It probably should have been from the beginning.

[RAW]

C-language and elegance is something that does not match.

Hi
I'm with Pascaldragon & Marcov on this one...
Why add elements with a ton of work, when they're overworked anyway!
I'm happy with FPC & Lazarus as they are!
Regards Benny

ME TOO !!!! 

[marcov]

Did you mix me with OP who wants curly brackets in Pascal?

Shouldn't I? :-)