Recent

Author Topic: Discussion - What if fpc syntax becomes C-like?  (Read 4318 times)

howardpc

  • Hero Member
  • *****
  • Posts: 3519
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #15 on: April 05, 2020, 12:40:03 pm »
See e.g. https://www.freepascal.org/faq.html#extensionselect
A minor point (since that page is not editable by most forum users): scepsis should be scepticism.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8725
  • FPC developer.
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #16 on: April 05, 2020, 12:43:05 pm »
See e.g. https://www.freepascal.org/faq.html#extensionselect
A minor point (since that page is not editable by most forum users): scepsis should be scepticism.

Done, thanks

guest58172

  • Guest
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #17 on: April 05, 2020, 12:45:54 pm »
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.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8725
  • FPC developer.
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #18 on: April 05, 2020, 01:06:07 pm »
Maybe if you have doubts you can try in D. D has this semantics on pointers, classes and interfaces but also autodereferencing.

That would be pointless since D has yet again different semantics. Anyway, I don't think there is much interest obviously, so that would mean you'd need to fork to implement it.

guest58172

  • Guest
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #19 on: April 05, 2020, 01:09:14 pm »
It always ends the same way here.

Thaddy

  • Hero Member
  • *****
  • Posts: 10451
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #20 on: April 05, 2020, 01:11:58 pm »
You mean ; ? :-X
And the program ends with a dot...
« Last Edit: April 05, 2020, 01:15:19 pm by Thaddy »
When you ask a question that is actually answered in the documentation, you are either lazy or a moron.

jamie

  • Hero Member
  • *****
  • Posts: 3524
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #21 on: April 05, 2020, 03:05:25 pm »
I didn't mean to stir the pot but I was talking about turning fpc into C++, but extracting a little, very little ideas from some of its operations...

 Personally I love the verbosity of pascal which is why I use it, I can't stand the single or double operators used in C/C++ they aren't clear enough when reading code at first glance.

 I hate the {…} brackets I don't even use them much for comments in the pascal I use // a lot..

 I hate C++ classs styles... very poorly thought out..

 But putting that aside I like what I posted before
The only true wisdom is knowing you know nothing

PascalDragon

  • Hero Member
  • *****
  • Posts: 2119
  • Compiler Developer
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #22 on: April 05, 2020, 03:31:13 pm »
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 ?

Because Object Pascal has a strong type system. You can't simply have a String or an Integer be a Boolean as there is no rule for it.

Also if you so strongly desire it, then declare yourself some operator overloads:

Code: Pascal  [Select][+][-]
  1. program tboolovld;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. operator := (const aStr: String): Boolean; inline;
  6. begin
  7.   Result := aStr <> '';
  8. end;
  9.  
  10. {operator := (aArg: LongInt): Boolean; inline;
  11. begin
  12.   Result := aArg <> 0;
  13. end;}
  14.  
  15. operator := (aArg: TObject): Boolean; inline;
  16. begin
  17.   Result := aArg <> Nil;
  18. end;
  19.  
  20. type
  21.   TMyObject = class(TObject);
  22.  
  23. var
  24.   s: String;
  25.   i: LongInt;
  26.   o: TMyObject;
  27. begin
  28.   if s then
  29.     Writeln('Blubb');
  30.   {if i then
  31.     Writeln('Blubb');}
  32.   if o then
  33.     Writeln('Blubb');
  34. end.

Note: the implicit operator overload for integer types to Boolean is currently not supported. I have a fix for that however and I'll commit it soon.

The same goes with Assigning a Booleaning..

ABoolean = SomeInteger;

 You notice how I didn't use the := ?

What should that even do? That is an expression. A comparison does not equal an assignment.

ASerge

  • Hero Member
  • *****
  • Posts: 1671
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #23 on: April 05, 2020, 04:11:53 pm »
The Boolean auto translation would save us loads of coding …
Example:

   if SomeInteger Then.....

   If SomeString Then...
etc
 what this means is simple...
Even in c++, this is recognized as bad style, and in all books it is recommended to write for clarity !=null, =='\0', etc.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8725
  • FPC developer.
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #24 on: April 05, 2020, 04:20:25 pm »
The Boolean auto translation would save us loads of coding …
Example:

   if SomeInteger Then.....

   If SomeString Then...
etc
 what this means is simple...
Even in c++, this is recognized as bad style, and in all books it is recommended to write for clarity !=null, =='\0', etc.

Well the boolean form would simply check for =1 of course, since that is allowed with normal Pascal booleans.

jamie

  • Hero Member
  • *****
  • Posts: 3524
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #25 on: April 05, 2020, 05:30:44 pm »
it would have to test for  not 0 because any value is considered true other than 0.

the same goes with a string..

 if not Length(AString) then...

etc


The only true wisdom is knowing you know nothing

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8725
  • FPC developer.
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #26 on: April 05, 2020, 05:50:32 pm »
it would have to test for  not 0 because any value is considered true other than 0.

Nope, Pascal "boolean" type is 0=false 1=true, rest undefined

GypsyPrince

  • Guest
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #27 on: April 05, 2020, 06:25:41 pm »
@jex

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.
 
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. For example... my preferred languages are C and assembly.  However, because I am about to retire I will no longer be doing secured embedded systems. I will only be dabbling with small apps as a hobby. So, neither assembly nor C will any longer meet my needs, as I will be interested only in rapid development. While I think VB.NET may be the closest thing to a "perfect" language, it also will not meet my needs because I want something that compiles to native code. Thus, the reason for my tinkering with Object Pascal/Lazarus to see if it does meet my particular needs.
 
A programming language and development system are nothing more than tools. That is it. No programming language is a holy relic which deserves to be worshipped. Additionally, no language is any better or any worse than any other - merely different. Though no language is any better or any worse than another as a whole, it must be stated that any language can certainly be better (or worse) suited for a particular situation or requirement than are others. Anyone who believes or asserts otherwise is seriously misinformed in that they do not truly understand the internals of a programming language, and likely do not understand the internals of computers as well. If a given tool does not meet your needs, always feel free to choose a different tool which does meet your needs, and do not let the sarcastic comments of others pressure you in your decision making. Only you can decide what tool is good for you and what tool is not good for you. Also, you will find many people in forums such as this who act like children and make sarcastic (if not outright rude) remarks when they feel your coding style doesn't meet their own preferences. Such people are trolls who live in a bubble and cannot see the world outside of their own limited experience. Just like the tool(s) you decide fit your needs, you alone must also determine what coding style fits your own needs best, and not what some basement dweller attempts to dictate to you.

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

https://www.elementscompiler.com/elements/mercury/default.aspx

Purely as an offer of alternative information... Mercury is being produced by a well established company to pick up where Microsoft has chosen to leave of with Visual Basic.  And, whereas Visual Basic is Windows dependent (mostly) and must run via a virtual machine (.NET/Core platform), Mercury will instead allow you to specify your app to utilize the .NET and Mono platforms, or to compile to native code.  Possibly the biggest feature... its evolution will not be stalled by small-minded language purists.

Like VB.NET, Mercury will also utilize many C constructs, true namespace elements, and will be more user-intuitive. The goal of Mercury will be to make developers more efficient and less concerned about feeling like they are part of some special club like many developers in other languages.
 
Understand that I am not promoting Mercury, but merely offering alternative information.
« Last Edit: April 05, 2020, 10:16:51 pm by GypsyPrince »

mercurhyo

  • Full Member
  • ***
  • Posts: 177
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #28 on: April 05, 2020, 06:32:16 pm »
Here we go again.

- Features requests to please 1-5 users WORLDWIDE

- Look at this other language, then that one, and that one

Remember that you are on the FreePASCAL forum? You'd better...

MODERATED: Please, avoid offending others!
« Last Edit: April 05, 2020, 09:33:44 pm by Tomas Hajny »
DEO MERCHVRIO - Linux Mint latest, Windows 7 - Laz latest fixes- RAD Studio XE7
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

lucamar

  • Hero Member
  • *****
  • Posts: 3020
Re: Discussion - What if fpc syntax becomes C-like?
« Reply #29 on: April 05, 2020, 06:50:44 pm »
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.

Inefficient for commercial-level production? :o I don't know what definition of "efficiency" you're using but I can tell you that I have been programming large commercial applications in quite a lot of languages for quite some time and Pascal (specificaly Delphi and FreePascal/Lazarus) let most (if not all) others languages and dev. environments in the dust. Even BASIC and BASIC-like languages (like BAL/ABAL).

Of course, all this is extremely subjective but take also into accoutn that "efficiency" goes done the drain at the beginning, until you learn well both the language and its tools; that's valid for any language and any tool, not just Pascal.
« Last Edit: April 05, 2020, 06:52:31 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

 

TinyPortal © 2005-2018