Discussion - What if fpc syntax becomes C-like?

[marcov]

In time it will only mean that the FPC codebases will become (even more) a patchwork of styles and dialects. That is more likely to send a newbie running for the hills than clean, Pascal syntax.

I have to politely disagree, being that many far more mainstream languages than Pascal utilize a patchwork of styles and continue to attract newbies - i.e, JavaScript, PHP, C++ (though admittedly C++ has become an unhinged nightmare), etc.

It is different if you have some major backing, are the only option in the browser or are undisputed in some other way. IOW popular languages are mostly chosen because they are popular, not because their inherent properties. Even if they are "unhinged nightmares".

This is also why copying random syntax from those languages won't make you as popular.

[jex]

Ok, this has gotten bigger than what I anticipated.
To be clear about couple things, first I did NOT mean in any way this to be a "request" to the devs to change something. (That'd be completely silly imo). I wrote "discussion" in the title for a reason, I meant for this to be a mere discussion not a request or "ORDER" as I see some of you somehow received it to be that way.

I did NOT mean that pascal syntax sucks and needs to be buried etc (even if I do, it's only my opinion and as some has said, I can just move on)

What I wanted to discuss about is WHY pascal isn't that popular (anymore!). And I mentioned in particular the great possibilities that FPC/Lazarus provides and I was questioning if there's a known reason (or guesses as I've given my guess about syntax) as to why it isn't as "popular" as it should be (from my perspective, and possibly all of you fpc/laz users/fans).

To be even more clear when I brought syntax into topic, specifically the "C-like" syntax, I meant to mention that as a potential cause for that (?), as I said above, I was only guessing while making it a point for someone to clear it for me.

Simply this was not me just ranting about how I don't like the syntax etc, despite that I mentioned that the syntax is a bit 'wordy', but that wasn't my whole point I was trying to make.

Thanks to everyone who tried to answer my questions, Yes I was asking a question, not giving "facts"
Thanks to marcov's initial response I understood most of what I wanted to understand

[munair]

Ooo...that's ugly
Really, if you want an unsafely typed language, don't pick Pascal family. The only high level language today that can't differentiate a boolean and integer are direct C descendants. The hybrids and those inspired from both (Go, Java) know the benefit and implement boolean properly as its own, distinct type from integer. It's easy to implement, yes. But developing a language is not a matter of implementing it easily, because if that's the case, just use Assembly.

Before C there was BASIC which also does not differentiate a boolean from an integer. In the early days BASIC did not even have a boolean type. I remember the CONST FALSE = 0 / TRUE = NOT FALSE programmer's construct which were just integers under the hood.

Pascal was designed to be an educational language, hence the choice to make it (very) strictly typed. Other than educational value there is no reason why booleans and numerical datatypes could not be interchanged. On assembly level they are all just bytes... Strictly typed languages typically produce more code because of the required explicit conversions, overloaded functions etc... While not a C programmer, I understand why the developers have chosen to leave the discipline to the programmer.

[munair]

There is a new implementation of BASIC coming out around mid-summer which may be of interest to you.

Making it backwards compatible is building on the relics of the past which has a limiting, restricting effect. Free Pascal / Lazarus is a perfect example maintaining its Delphi compatibility.

[440bx]

.. there is no reason why booleans and numerical datatypes could not be interchanged.

No. Definitely not.  The truth value of a statement has nothing to do with numbers.   The same way that a number is a totally different thing than a character. 

On assembly level they are all just bytes...

Yes but, that is only because bits are not individually addressable.  That statement you made is also true for characters and it doesn't imply that because they are also represented as numbers that they should be treated as such.

Strictly typed languages typically produce more code because of the required explicit conversions, overloaded functions etc...

On the contrary.  A compiler for a strongly typed language can produce better code than it could for a "loosely" typed language and the reason is because, strong typing provides more information and more _accurate_ information which enables the optimizer to use algorithms that it could not safely use if it didn't have all that information.

[munair]

However, the semicolon bit was different because it hadn't come up (seriously) before, and I misjudged the initial impact on the parser. It was way larger than I initially thought (thanks to Mark and Thaddy for discussing it). Initially I thought it would be solvable locally, e.g. just fixing the ELSE statements (e.g. by forcing always a block), but the straw that broke the camel's back is behaviour with incorrect code. You would really have to redo the most basic level of the scanner/parser.

Has there ever been an established language that underwent such a dramatic change?

[munair]

On the contrary.  A compiler for a strongly typed language can produce better code than it could for a "loosely" typed language and the reason is because, strong typing provides more information and more _accurate_ information which enables the optimizer to use algorithms that it could not safely use if it didn't have all that information.

Better code is not necessarily less/more efficient code. If safety is a requirement, then strictly typed languages are the way to go. Like I said, there is a reason why some language developers leave the discipline to the programmer. Assembly programmers can do things no one can in a higher level language and there is something to say for some of that freedom to shine through a higher level lang. In the end, it is all a matter of preference.

Yes but, that is only because bits are not individually addressable.  That statement you made is also true for characters and it doesn't imply that because they are also represented as numbers that they should be treated as such.

There is a clear difference between numerical and alphanumerical data, also on assembly level. Apart from the different numerical values between 0 and '0' there is the difference in addressing and data handling. Assembly has a whole range of instructions that specifically deal with character/string handling that assume specific registers to be set/initialized.

No. Definitely not.  The truth value of a statement has nothing to do with numbers.   The same way that a number is a totally different thing than a character. 

I disagree. It is convenient to treat an identifier as a boolean expression to see if it holds a non-zero value. In BASIC this is basic programming practice. If booleans have the highest priority in expressions, you don't end up with the restrictions found in languages such as Pascal. Think about it, every expression is potentially boolean until it turns out otherwise (math expression). This is a very natural approach and it doesn't require additional type checking.

[PascalDragon]

@PascalDragon

That is your view and your view only.

Well, that's not exactly a revelation, or at least it shouldn't be considering I wrote this as immediately following that statement:

Now... my personal finding of OP to be inefficient does not mean it is a bad language. Not at all. In fact, it is apparently a great language which many, many others find to be useful and efficient for their particular needs. My point is simply that while OP/Lazarus is perfect in fitting the needs of some, it does not meet the needs of some others.

So, your pointing out what I already said is an exercise in redundancy.

Look again at what I quoted:

The more I delve into Object Pascal the more I am finding it is not for me and will probably set it to the side, shortly. I like OP's verbosity, but there are many shortcomings in the language which make it inefficient as a commercial-level production language. Given the resistance by purists against evolving, OP will remain little more than a niche/hobby language.

You made a general statement here. You did not say "in my opinion there are many shortcomings" or something like that. You stated generally that these "make it inefficient as a commercial-level production language". And that is simply not true.

This statement is not correct in the general case either. I mean yes, if I don't want to use a certain feature I don't need to use it, but if I use third party code I at least need to be able to understand it. Let's assume a user who doesn't like to use interfaces. And now he has to use third party code that's heavily based on interfaces (and let's say that rewriting/reimplementing it is not feasible). Thus he'll at least need to understand how interfaces work, so he can use them correctly.

Yeah... this made absolutely no sense in the context of the point I was making. But rather, it actually re-enforces my point that if a tool doesn't work for his particular needs, he should feel free to pick another that does meet his needs.

You stated that one does not need to use a feature if one does not want it. I (and marcov) explained why this isn't realistic.

[marcov]

Pascal was designed to be an educational language, hence the choice to make it (very) strictly typed.

Pascal was designed for development of algorithms in HLL and teach them to students. The audience to teach was mostly Math students close to their Masters, and compiler construction was also a real concern. Or after. In that they and age they were pretty much the only programmers.

It is not like Logo that was meant to teach children.

Other than educational value there is no reason why booleans and numerical datatypes could not be interchanged.

This is incorrect. Boolean and integer math are also separate, so heaping them together is not intuitive either.  So the question should be why they should be heaped together, something that probably has roots in minimizing code  of the first B and C compilers so it would fit in the memory of the mini computers they were using.

Note that new C99 boolean types follow the pascal definition more https://stackoverflow.com/questions/4767923/c99-boolean-data-type

On assembly level they are all just bytes...

So then why does C use int and not byte?

Strictly typed languages typically produce more code because of the required explicit conversions, overloaded functions etc... While not a C programmer, I understand why the developers have chosen to leave the discipline to the programmer.

Typecasts don't generate code, overloaded functions neither.  Don't let dumb C advocacy by newbies fool you. The reason that C compilers are fast is mostly the work put into C compilers, not the language itself.

So there are three aspects:

• Size (1,2,4,8 byte)
• convention (are values outside of TRUE and FALSE) defined and if so how
• Typecompatibility with integer

About size we can be simple. Making boolean the same size as integer is the most portable way. Nowadays that is best, but in the past it was often wasteful, which is why Turbo Pascal had it as 1-byte. Embedded systems often have booleans as "true" size, 1-bit, as they often have bitaddressable memory.

Convention is a matter of taste. Both conventions make sense. The C definition defines all values in a range, the Pascal definition (which forces 1=true) keeps that if A and B are both true, they are also binary the same, iow = is a binary operator.   As said C99 tries to acquire this property too for the "boolean" type, the old integer boolean is more or less legacy now.

Then the compatibility to int. I don't see any use advantage or reason, so it is IMHO just legacy from the early days of B/BCPL when C was mostly untyped

[marcov]

Has there ever been an established language that underwent such a dramatic change?

BASIC had nearly everything done to it at some point. It is the most fragmented language I think.

The transition from interpreters with linenumbers to more compiled versions without (early to later Quck Basics and later VB) comes to mind, but I don't know the details well enough.

[munair]

Boolean and integer math are also separate, so heaping them together is not intuitive either.  So the question should be why they should be heaped together, something that probably has roots in minimizing code  of the first B and C compilers so it would fit in the memory of the mini computers they were using.

It is not that they should be heaped together as a specific purpose. The question is, should booleans be strongly typed? What is the harm in for example:]http://sharpbasic.com/images/bool-01.png]

So then why does C use int and not byte?

I was speaking of bytes in general regardless of word size. C is a bit peculiar in that it does not have a datatype called 'byte' but 'char' instead, and to make things more confusing arrays of chars instead of strings. It wouldn't be my first choice of language design.

[munair]

BASIC had nearly everything done to it at some point. It is the most fragmented language I think.

The transition from interpreters with linenumbers to more compiled versions without (early to later Quck Basics and later VB) comes to mind, but I don't know the details well enough.

With each 'upgrade' they became different languages altogether. GW-BASIC is not compatible with QuickBASIC. QuickBASIC 7.0 (PDS) was mostly compatible with QB 4.5 a notable difference being string addressing in the far heap. Visual Basic 1.0 (for DOS) was mostly compatible with PDS without graphical (text) UI. Visual Basic for Windows (up until 6.0) no longer supported DOS. Visual Basic .NET was a completely new language (not the best IMO).

Most of these upgrades are no different than the Pascal upgrades since the early 70s.

[marcov]

Boolean and integer math are also separate, so heaping them together is not intuitive either.  So the question should be why they should be heaped together, something that probably has roots in minimizing code  of the first B and C compilers so it would fit in the memory of the mini computers they were using.

It is not that they should be heaped together as a specific purpose. The question is, should booleans be strongly typed? What is the harm in for example:]http://sharpbasic.com/images/bool-01.png]

Why should anything be strong typed? Why have typing at all. But you choose a certain model for a language, and then you stick to it. Pascal is already very forgiving in that it allows assignments of integers to real and random integer types to other integer types.

And it only leeds to unnecessary avenues for bugs. One could also invert the question and ask yourself if an extra typecast is so bad that one time you want to assign 42 to a boolean.

[munair]

Pascal is already very forgiving in that it allows assignments of integers to real and random integer types to other integer types.

Yet, it isn't forgiving in passing parameter types, like an integer argument to a word parameter. That is the kind of inconsistency that often prevents programmers from using such language.

Of course, there isn't any harm in requiring explicit cast, but what purpose does it serve other than wanting to notify the programmer that he may not know what he is doing? Why would a programmer have to always explicitly indicate what a compiler can do implicitly? That is the difference between strongly and weakly typed languages. I guess it will always be a matter of taste. Some prefer a compiler to force a programmer to discipline. Others prefer a compiler to allow more freedom (and creativity).

Why should anything be strong typed?

Actually, that is a very good question. Assembler doesn't know about types, not even about signed or unsigned. Higher level languages were invented to make things easier for the programmer. With those languages came philosophies, which, IMO were often taken too far.

[Martin_fr]

What is the harm in for example:]http://sharpbasic.com/images/bool-01.png]

The harm would be that simple typos would no longer be rejected as error.

Code: Pascal  [Select][+][-]

1. var
2.   CurrentValue: Integer;
3.   CurrentValid: Boolean;
4. ....
5. TempBool := CurrentValue; // typo: should be CurrentValid

Personally I am glad for every hour of debugging from which the compiler saves me.

And typing/reading/... a typecast where it is needed and wanted is much less effort that all the debugging that otherwise would be due.