I've just started learning Pascal. For the most part the syntax feels redundant or idk how to explain exactly. I'm sure some will get the ideaI honestly have no idea what you're talking about. Can you provide an example?
Now say that fpc is being written from the ground up as a new project, same language features, support etc, but just the syntax is more C-like. Would this bring a positive or a negative results?
I've just started learning Pascal. For the most part the syntax feels redundant or idk how to explain exactly. I'm sure some will get the idea
Now say that fpc is being written from the ground up as a new project, same language features, support etc, but just the syntax is more C-like. Would this bring a positive or a negative results?
Maybe more will start learning it (mainly because it'll be much easier to quickly pick it up for experienced programmers) or at least exploring it. Can it get the attention of big enterprises to maybe adopt it in some way?
can it find the popularity that it truly deserves, because imo, I've just started learning it and so far I'm so impressed especially because it was built by the community. I really appreciate the tools and support FPC/Lazarus provides completely *FREE*. Nothing asked.
What do you think? Is that even technically possible?
In other words, what do you think is the main reason for FPC/Lazarus not getting the attention it deserves?
Now say that fpc is being written from the ground up as a new project, same language features, support etc, but just the syntax is more C-like. Would this bring a positive or a negative results?
Hello,
I've just started learning Pascal. For the most part the syntax feels redundant or idk how to explain exactly. I'm sure some will get the idea
Now say that fpc is being written from the ground up as a new project, same language features, support etc, but just the syntax is more C-like. Would this bring a positive or a negative results?
The Boolean auto translation would save us loads of coding …Ooo...that's ugly :P
Example:
if SomeInteger Then.....
If SomeString Then...
etc
what this means is simple...
If value is 0 its false or string empty its false otherwise they are true...
at the same time these identifiers can be used as Boolean or Value operators when it cones to performing the IF and WHILE loop control statements.
We already have functions that work this way, why is it so hard for the compiler to see there is no assignment there and thus should assume a Boolean operation ?
The same goes with Assigning a Booleaning..
ABoolean = SomeInteger;
You notice how I didn't use the := ?
Anyways, I know this will never get implemented.
The usual answer is
"Bad Language Design" or "That's ugly " etc..
Uagh .. %) The first example still sends shivers down my spine ...The Boolean auto translation would save us loads of coding …Ooo...that's ugly :P
Example:
if SomeInteger Then.....
If SomeString Then...
[...]
ABoolean = SomeInteger;
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.
Hello,
I've just started learning Pascal. For the most part the syntax feels redundant or idk how to explain exactly. I'm sure some will get the idea
Now say that fpc is being written from the ground up as a new project, same language features, support etc, but just the syntax is more C-like. Would this bring a positive or a negative results?
Maybe more will start learning it (mainly because it'll be much easier to quickly pick it up for experienced programmers) or at least exploring it. Can it get the attention of big enterprises to maybe adopt it in some way? can it find the popularity that it truly deserves, because imo, I've just started learning it and so far I'm so impressed especially because it was built by the community. I really appreciate the tools and support FPC/Lazarus provides completely *FREE*. Nothing asked.
What do you think? Is that even technically possible?
In other words, what do you think is the main reason for FPC/Lazarus not getting the attention it deserves?
These 3 semantic changes are not breaking changes I think so they could be added without breaking code.
See e.g. https://www.freepascal.org/faq.html#extensionselect (https://www.freepascal.org/faq.html#extensionselect)A minor point (since that page is not editable by most forum users): scepsis should be scepticism.
See e.g. https://www.freepascal.org/faq.html#extensionselect (https://www.freepascal.org/faq.html#extensionselect)A minor point (since that page is not editable by most forum users): scepsis should be scepticism.
These 3 semantic changes are not breaking changes I think so they could be added without breaking code.
In some pointer cases autodereferencing might be a problem. Also you'll need more than the most mundane examples if you want to prove a point. Everybody knows what to do in the simple cases, it is the difficult cases that are the problem.
See e.g. https://www.freepascal.org/faq.html#extensionselect
Maybe if you have doubts you can try in D. D has this semantics on pointers, classes and interfaces but also autodereferencing.
The Boolean auto translation would save us loads of coding …
Example:
if SomeInteger Then.....
If SomeString Then...
etc
what this means is simple...
If value is 0 its false or string empty its false otherwise they are true...
at the same time these identifiers can be used as Boolean or Value operators when it cones to performing the IF and WHILE loop control statements.
We already have functions that work this way, why is it so hard for the compiler to see there is no assignment there and thus should assume a Boolean operation ?
The same goes with Assigning a Booleaning..
ABoolean = SomeInteger;
You notice how I didn't use the := ?
The Boolean auto translation would save us loads of coding …Even in c++, this is recognized as bad style, and in all books it is recommended to write for clarity !=null, =='\0', etc.
Example:
if SomeInteger Then.....
If SomeString Then...
etc
what this means is simple...
The Boolean auto translation would save us loads of coding …Even in c++, this is recognized as bad style, and in all books it is recommended to write for clarity !=null, =='\0', etc.
Example:
if SomeInteger Then.....
If SomeString Then...
etc
what this means is simple...
it would have to test for not 0 because any value is considered true other than 0.
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 here, shortly. I like OP's verbosity, but there are many shortcomings in the language which make it inefficient as a commercial-level production language.
If it were efficient, it would be used more rather than being ranked way behind.
If companies found the language to be efficient, more companies would be using it. They apparently disagree with your opinion.
try a language, you like it than learn it, you don't like it than move on.
You would have to rewrite the entire parser, and redesign the whole dialect. Possible, but not trivial.
@marcovQuoteYou would have to rewrite the entire parser, and redesign the whole dialect. Possible, but not trivial.
This is a very patient and informative response to the OPs question.
I don't know if you are one of Lazarus' developers, but I'm going to take a blind guess and say you are (?).
It is nice that you are keeping in mind that most people who request a feature have absolutely no experience whatsoever in developing a parser or compiler. Even as long as I've been programming, I wouldn't pretend to know where to begin with customizing Free Pascal to my preferences, and I'm guessing (I could very easily be wrong here) the original poster wouldn't either. So, it is nice to see that you politely point out how much work it would take to implement his request rather than the often seen response given by others which equates to "Your feature request is stupid because we don't want it. Now go away!."
Hello,
I've just started learning Pascal. For the most part the syntax feels redundant or idk how to explain exactly. I'm sure some will get the idea
Now say that fpc is being written from the ground up as a new project, same language features, support etc, but just the syntax is more C-like. Would this bring a positive or a negative results?
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.
The exact same point is easily made regarding a feature requested by someone. If you like it - use it. If you don't like it - don't use it.
That is your view and your view only. There are enough companies out there that use Object Pascal, be it with FPC or Delphi. Because if not, at least Delphi would no longer exist with it being a commercial - and in the higher editions quite expensive - tool.
That is your view and your view only.
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.
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.
QuoteThis 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.
And no, having a compiler switch or dialect mode doesn't fix that, just look at the strange objfpc-Delphi mode split that is an artefact of such discussions that still persists 20 years later. 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.
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.
QuoteIn 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.
Ooo...that's ugly :P
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.
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.
.. 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.
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?
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.
@PascalDragonQuoteThat 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:QuoteNow... 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.
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.
QuoteThis 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.
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.
Has there ever been an established language that underwent such a dramatic change?
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] (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.
BASIC had nearly everything done to it at some point. It is the most fragmented language I think.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).
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.
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] (http://sharpbasic.com/images/bool-01.png)
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.
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.
What is the harm in for example:]http://sharpbasic.com/images/bool-01.png] (http://sharpbasic.com/images/bool-01.png)
I perfectly understand. Personally I love compilers that allow that kind of assignment. Instead of an error it could optionally throw a hint or warning at compile time as a debugging switch, just as is being done with uninitialized data (which also often lead to bugs which can be even less obvious than typos).What is the harm in for example:]http://sharpbasic.com/images/bool-01.png] (http://sharpbasic.com/images/bool-01.png)
The harm would be that simple typos would no longer be rejected as error.
Personally I am glad for every hour of debugging from which the compiler saves me.
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.
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.
Probably DecodeDateTime (https://www.freepascal.org/docs-html/current/rtl/dateutils/decodedatetime.html) and friends? In that case please take note that it's using out parameters which must be the same type, because it's essentially passing a pointer under the hood (which is why I excluded them in my list above).That was probably the issue I ran into.