Syntax proposals

[marcov]

PD: What i have learn up to this post is that syntax change would surely need break backward compatibility at some point ...

Yes, and that is out of the question.

[damieiro]

   

PD: What i have learn up to this post is that syntax change would surely need break backward compatibility at some point ...

Yes, and that is out of the question.

Why not?

Extending the default {$ mode FPC }with a new proper heap/class model or modernised object model is not tied to the old modes that could have their support or deprecated way. You'll get backward compatibility in the other modes, and you expand/modernice the proper FPC mode that is not intended to be TPC/Delphi-Embarcadero and so on.

What i think it's not acceptable if that is using generics (a proper FPC way of doing things), it expands classes but no objects, for example. I miss a proper FPC way of doing things. I do not use embarcadero tools. I would prefer allways FPC because it will be allways free and i think it has the weight to make a free standard, not the commercial standards.

And the devs have my full respect for their great job. But i'd like (a personal taste) that FPC mark the way to go.

[marcov]

   

PD: What i have learn up to this post is that syntax change would surely need break backward compatibility at some point ...

Yes, and that is out of the question.

Why not?

Because we want to be a backwards compatible compiler. Exceptions have been made, usually for compatibility, but not for superficial syntax.

[damieiro]

Because we want to be a backwards compatible compiler. Exceptions have been made, usually for compatibility, but not for superficial syntax.

Ok. Free the "superficial sintax" ideas, please. Forgot all this post if needed for the answer, please.
I rephrase the question:
is going FPC go for their own way or only for mimic other's compilers?

I think we have a dual(trial?) class/object/record model forced by others and not an FPC proper way, for example. There is no issues on (classic?) pascal. The sintax debate i think is on class/object/record model.

[marcov]

Because we want to be a backwards compatible compiler. Exceptions have been made, usually for compatibility, but not for superficial syntax.

Ok. Free the "superficial sintax" ideas, please. Forgot all this post if needed for the answer, please.
I rephrase the question:
is going FPC go for their own way or only for mimic other's compilers?

One doesn't include the other.  New features are not excluded, but must be implemented as compatible as possible and be meaningful (really make some way of programming possible that isn't now, not just be syntax grafitti(*))

(*) a form of language development where everybody wants to do some minor rearrangement to make the syntax a few characters more terse or "pure" (whatever that means), just as a mark of contribution.   

I think we have a dual(trial?) class/object/record model forced by others and not an FPC proper way,
for example.

Yes. And if I would start a new language, I would certainly agree with you, having explained newbs the x:=ty.create syntax umpteen times over the years.

But we are not starting a new language. We are working on a compiler with 25 years of history (and even more in the dialects we "mimic").

And this is just a very minor detail, that can be also tackled with good documentation and tutorials, rather than syntax.

[damieiro]

Ok. I see the point. I agree with it partially

One doesn't include the other.  New features are not excluded, but must be implemented as compatible as possible and be meaningful (really make some way of programming possible that isn't now, not just be syntax grafitti(*))

(*) a form of language development where everybody wants to do some minor rearrangement to make the syntax a few characters more terse or "pure" (whatever that means), just as a mark of contribution.   

Well. The syntax proposal i made weren't intended to be in scope of no grafitti or other. I put it as a reflexion. The actual class method makes a practical deprecating of object model. And it means loses as stack allocation and forced TObject heritance. No root class is possible. No multiple heritage is possible (we are doing helpers?). Allocation and init are glued in constructor. I think the class model should be reviewed and i point in the syntax as i think the way we are writing code are avoiding future uses of that.
We have a very good looking sintax, but it doesn't let do something that C++ lets, for example. And i was thinking with that in mind. I have been terrible transmitting it as i see. But i point sintax because how you (i mean the programmer) write makes you (the programer again) think and viceversa (the opposite)

Yes. And if I would start a new language, I would certainly agree with you, having explained newbs the x:=ty.create syntax umpteen times over the years.

But we are not starting a new language. We are working on a compiler with 25 years of history (and even more in the dialects we "mimic").

And this is just a very minor detail, that can be also tackled with good documentation and tutorials, rather than syntax.

I think it could not have to start from scratch. It could evolve from actual foundation. And i do not agree that if something is doing for many years, but it's done wrong, to persists in that forever. It's like the assigment operator. ":=" is far better than a C "=" operator.

Added: I do not know at what exactly "backward" compatible are we calling. If embarcadero adds new stuff, will it be supported?. I think this is not backward...

[marcov]

Well. The syntax proposal i made weren't intended to be in scope of no grafitti or other. I put it as a reflexion. The actual class method makes a practical deprecating of object model. And it means loses as stack allocation and forced TObject heritance. No root class is possible.

True. That is pretty modern actually, most languages nowadays have a rooted class model. Except for Dinosaurs like C++, but that has other reasons.

No multiple heritage is possible (we are doing helpers?).

Interfaced multiple inheritance is perfectly possible.

Helpers are syntactic sugar, mostly developed originally to enable component builders to work against multiple delphi versions, and polish some common incompatibilities away with helpers. Helpers are used to patch things up IMHO, not a language element to model new development. That doesn't mean they are not useful of course, just not part of the language "model".

Allocation and init are glued in constructor.

Yes. No messing with pointers, and a systematic guard against memory leaks in case there is an exception in the constructor.

I think the class model should be reviewed and i point in the syntax as i think the way we are writing code are avoiding future uses of that.

If you want to have a new class model, define a new class model, and work that out, e.g. with a branch. Don't get mired in detail syntax or piecemeal approach. Such a change would take years.

Of course the chances for this to get into mainstream FPC are near zero at the moment, but if you are interested in the C++ model, FPC does have a CPPclass for C++ interfacing.

While substituting the main model is out of the question with tens of millions of FPC and Delphi lines of code out there, improving on CPP class model interoperability would be a boon for FPC and in line with your interests.

Also, the Delphi model is backing for the Delphi designer system, something Borland had to extend BCB for since C++ can't handle it.

We have a very good looking sintax, but it doesn't let do something that C++ lets, for example. And i was thinking with that in mind. I have been terrible transmitting it as i see. But i point sintax because how you (i mean the programmer) write makes you (the programer again) think and viceversa (the opposite)

I don't think C++'s syntax with its "&"'s everywhere is that nice. Also the multiple inheritance is peppered with red tape of do's and don'ts, and vague error messages.

I think it could not have to start from scratch. It could evolve from actual foundation. And i do not agree that if something is doing for many years, but it's done wrong, to persists in that forever. It's like the assigment operator. ":=" is far better than a C "=" operator.

Not realistic IMHO. Even if for some crazy reason we would go that way, probably new units and modes would be introduced for the new model, and then both models would co-exist for a long,long time.

It happened before, adding Delphi mode to the existing TP modes in say 1998-99.

Added: I do not know at what exactly "backward" compatible are we calling. If embarcadero adds new stuff, will it be supported?. I think this is not backward...

The primary rule is that old codebases must be kept running, regardless of origin (Delphi, FPC).

The jury is out on new features in Delphi, because they are increasingly silly, or geared towards other uses. Case by case basis for now, or at least till sharing code with Delphi becomes impossible for the average user.

But we still are missing D2009 features like anonymous methods, so this kind of feature absorption goes very slowly.

[SymbolicFrank]

I use the following a lot:

Code: [Select]

TMyThread.Create;

Or when I want a return value:

Code: [Select]

TMyThread.Create(MyQueue);  // var MyQueue: TConcurrentQueue = nil

With a custom constructor, of course, that starts the tread running and optionally holds a pointer to a queue (or parent, or port number) for the return value and/or other communication.

They normally auto-terminate when done. Keeping a reference to the pointer is asking for problems, so I don't.

[damieiro]

Sorry for big quote. I like this conversation very much. I'm learning a lot. Forward thanks

Quote from: damieiro on Today at 11:25:41 am

Well. The syntax proposal i made weren't intended to be in scope of no grafitti or other. I put it as a reflexion. The actual class method makes a practical deprecating of object model. And it means loses as stack allocation and forced TObject heritance. No root class is possible.

True. That is pretty modern actually, most languages nowadays have a rooted class model. Except for Dinosaurs like C++, but that has other reasons.

Ok. I think a empty root it's useful allways even with a very good foundation in TObject. I think it could deprecate totally object and can give the option as lightweight classes.  With stack allocation of a class (by some syntax means like a managed class or other way) and avaiable empty root class it would make a common foundation of a record with methods or objects. In other words, the class would be a superset of actual class, object and record functionality. (as a idea).
I advance that I'm not a C player. I'm a allways Pascal player and assembly player. I sure say (not think) without doubt that i can do anything in pascal that i can do in c or c++ and with same efficiency and much bigger maintainability. No C team here

No multiple heritage is possible (we are doing helpers?).

Interfaced multiple inheritance is perfectly possible.

Helpers are syntactic sugar, mostly developed originally to enable component builders to work against multiple delphi versions, and polish some common incompatibilities away with helpers. Helpers are used to patch things up IMHO, not a language element to model new development. That doesn't mean they are not useful of course, just not part of the language "model".

Why not multiple heritage instead of interfaces?.

Allocation and init are glued in constructor.

Yes. No messing with pointers, and a systematic guard against memory leaks in case there is an exception in the constructor.

I'm not understanding. What kind of guard helps this if glued?. A memory request is in the "new instance" of the constructor, then it could happen in the constructor code after that instance if some memory is required (for example other auxiliary class), then the set of values (the init). A memory fault there could be in constructor. And a memory leak would be by not destroying constructed memory structures in destruction part. I here make a difference. Any Memory request Is construction. Any Value setting is init. Init should not have memory construction (only value setting). It's ok that value setting go in constructor, but i think it's not ok that a a constructor could be called as a re-init (as a method) outside constructor scope. But i can be completely wrong..

Example of pseudocode

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

1. constructor TMyObject.create
2.  
3. begin
4.   OtherObjectNeeded:=TOtherObject.create;   {Possible leak if called like a method after contructed outside the object scope -> two creates}
5.  {this could be enforced as only allow calling constructor method by object descendants}
6.   {do init variables}
7. end;  
8.  

I think the class model should be reviewed and i point in the syntax as i think the way we are writing code are avoiding future uses of that.

If you want to have a new class model, define a new class model, and work that out, e.g. with a branch. Don't get mired in detail syntax or piecemeal approach. Such a change would take years.

Well, i'm in the learning curve . To make a new model i need to understand fully what things are done in the way they are and what are discarded . I allways trust in
the intelligence of experts and others. No need to reinvent the wheel.

Of course the chances for this to get into mainstream FPC are near zero at the moment, but if you are interested in the C++ model, FPC does have a CPPclass for C++ interfacing.
While substituting the main model is out of the question with tens of millions of FPC and Delphi lines of code out there, improving on CPP class model interoperability would be a boon for FPC and in line with your interests.
Also, the Delphi model is backing for the Delphi designer system, something Borland had to extend BCB for since C++ can't handle it.

Well, no. I have no interest in C and C++.  I fully dislike their way to do the job. And the solutions. A lot of "new" languages are born by C disgust so it have a lot of
partial descendants that i dislike. I'm very on Wirth line.

We have a very good looking sintax, but it doesn't let do something that C++ lets, for example. And i was thinking with that in mind. I have been terrible transmitting it as i see. But i point sintax because how you (i mean the programmer) write makes you (the programer again) think and viceversa (the opposite)

I don't think C++'s syntax with its "&"'s everywhere is that nice. Also the multiple inheritance is peppered with red tape of do's and don'ts, and vague error messages.

Plainly: I really dislike C and C++ syntas. As a example, var or const in parameters in pascal is a step forward, for example. The caller doesn't need to know how it is passed in implementation and a lot of errors of putting or not a & are out. I think you understand me here wrong. No C or C++ sintax INMHO. Never. (in spanish, saying two times "No" means "big No", never meaning yes as in english , i commom mistake i do when writting in english)

I think it could not have to start from scratch. It could evolve from actual foundation. And i do not agree that if something is doing for many years, but it's done wrong, to persists in that forever. It's like the assigment operator. ":=" is far better than a C "=" operator.

Not realistic IMHO. Even if for some crazy reason we would go that way, probably new units and modes would be introduced for the new model, and then both models would co-exist for a long,long time.

It happened before, adding Delphi mode to the existing TP modes in say 1998-99.

Well, i want to be optimist. If a feature that could be useful, for example, an empty root class, and that could be made by non invasive syntax like TMyClass=emptyclass or TMyClass=Class (empty/nil) (for not using TMyClass =class that means TMyClass=class(Tobject)) and it's useful i think it could be possible a little steps forward without breaking the old job. I know i want to be optimist .

Added: I do not know at what exactly "backward" compatible are we calling. If embarcadero adds new stuff, will it be supported?. I think this is not backward...

The primary rule is that old codebases must be kept running, regardless of origin (Delphi, FPC).

The jury is out on new features in Delphi, because they are increasingly silly, or geared towards other uses. Case by case basis for now, or at least till sharing code with Delphi becomes impossible for the average user.

But we still are missing D2009 features like anonymous methods, so this kind of feature absorption goes very slowly.

Thanks a lot for the aclaration. I do not know anything of these . I never used anonymous methods. Call me a oldie

[Ñuño_Martínez]

Why not multiple heritage instead of interfaces?.

Multiple heritage was, along with templates and conversion operators/constructor, the think that made me crazy and the reason I promised myself I will never again use C++ in my life.  I really hope it will not be added to Pascal.  Don't you know about deadly diamond of death?

And as I've said somewere before: If you like C++, use C++;  I prefer Object Pascal.

[marcov]

Ok. I think a empty root it's useful allways even with a very good foundation in TObject.

It is a lot of trouble for rare cases.

I think it could deprecate totally object and can give the option as lightweight classes.  With stack allocation of a class (by some syntax means like a managed class or other way)

Those are two different things.

and avaiable empty root class it would make a common foundation of a record with methods or objects. In other words, the class would be a superset of actual class, object and record functionality. (as a idea).

That is the idea yeah, but that comes with a consequences that you need to define, and work with pointers to the non static ones. And that case is much more common than stack instantiation.

I advance that I'm not a C player. I'm a allways Pascal player and assembly player. I sure say (not think) without doubt that i can do anything in pascal that i can do in c or c++ and with same efficiency and much bigger maintainability. No C team here

Ok, but the end conclusion is the same. You need to know both object models very intimately from both a theoretical and practical point. Only then you can make choices, and even after that there is still compatibility to regard. And you didn't even seem to know that the FPC classes model already supports a form of multiple inheritance.

This is a dead end.
 

Why not multiple heritage instead of interfaces?.

It is a messy and complicated.

I'm not understanding. What kind of guard helps this if glued?. A memory request is in the "new instance" of the constructor, then it could happen in the constructor code after that instance if some memory is required (for example other auxiliary class), then the set of values (the init).

The constructor can contain any code, e.g. registering the class with global resources. If such code can't complete it raises an exception and the instance returned from the initmemory-constructor combo would be incompletely instantiated. The choice in object pascal is to then free that class and let the exception (which can contain extra info) bubble up.

A memory fault there could be in constructor. And a memory leak would be by not destroying constructed memory structures in destruction part. I here make a difference. Any Memory request Is construction. Any Value setting is init. Init should not have memory construction (only value setting). It's ok that value setting go in constructor, but i think it's not ok that a a constructor could be called as a re-init (as a method) outside constructor scope. But i can be completely wrong..

Anything that compiles is allowed in the constructor. You must differentiate between what is good practice and what is actually allowed.
 

If you want to have a new class model, define a new class model, and work that out, e.g. with a branch. Don't get mired in detail syntax or piecemeal approach. Such a change would take years.

Well, i'm in the learning curve . To make a new model i need to understand fully what things are done in the way they are and what are discarded . I allways trust in
the intelligence of experts and others. No need to reinvent the wheel.

Make sure that your trust doesn't turn into blind faith. For a comparison you need to evaluate both sides fully, and on a very deep detail level. I'm still learning things, and I'm working with the Delphi model for nearly 20 years now.

If you want to propose something that is not already live in some major Pascal compiler, it is wise to start working on some prototype compiler (doesn't have to generate fast code, just work).  Nobody will ever accept rearranging fundamental aspects of a compiler used in production like FPC otherwise.

Well, i want to be optimist. If a feature that could be useful, for example, an empty root class, and that could be made by non invasive syntax like TMyClass=emptyclass or TMyClass=Class (empty/nil) (for not using TMyClass =class that means TMyClass=class(Tobject)) and it's useful i think it could be possible a little steps forward without breaking the old job. I know i want to be optimist .

The eventual syntax is only a very small part of the object model, and the details mostly come at the end. How everything works, how to enable the compiler (or runtime libraries) to know enough to generate/execute code, memory safety, performance etc is much more important.

[SymbolicFrank]

Consistency is great. It makes everything more understandable.

In C++, you have at least 4, completely different syntaxes thrown together. And it is impossible to say what will happen in a piece of code without reading everything that comes before that. Because a single line of code somewhere can completely change the meaning of any other line of code.

A single macro or template can require a lot of effort to debug, and kill your project.

Another trap is taking anything to the extreme. Like: globals are bad, everything needs to be a class. Many things are just simple transformations, they should be functions. And settings have to be global.

Or any design pattern, or refactoring. Readability is very important, but that doesn't mean that everyone uses the same naming conventions, with the same capitalizations. It just means, that it should be easy to understand what the code does when you read it. That's all. Resharping everything into LINQ doesn't make it more readable.

And finally, the most important thing, bar none, is interfaces. An interface is how different modules/objects/programmers interact. And you should define those very strict, and up front.

Like, I had a boss that liked to say: "I use Windows Communication Foundation. That is an industry standard. So, I'm doing it right." But WCF can only communicate with WCF. On the same Microsoft Windows / .NET. That's not a standard. It doesn't work at all, if you want to communicate with anything else than that. And even then, you still have to define an interface. Otherwise, it's just random noise.

You have to specify stuff exactly. If I communicate with you, I give you these bytes, and this document describes exactly what they mean, and what action they request from you. It doesn't matter if that is how you call a function (parameters on the stack, in registers, pointers or values), or what each byte in a serial communication (like, a web page) means.

Describe how you should define interfaces, instead of saying: this is the only way to do it.

[damieiro]

@Nuño: The diamond problem is a Syntax problem mainly. The problem is that the heritage two method named exactly the same (from your multiples ancestor) , the compiler doesn't warn you to name explicitally which ancestor do you want to use, or compiler making more checks.

But, for example in a chain Ancestor->(Son1,Son2)->GrandSon if GrandSon wants to use Son1.Foo that exists on Son2.Foo (and those two could be even overriden an Ancestor.Foo or not), the compiler should ask for ambiguity and the programmer should write what is needed to use (son1.foo, son2.foo, ancestor.foo).

[damieiro]

Ok. I think a empty root it's useful allways even with a very good foundation in TObject.

It is a lot of trouble for rare cases.

I don't undestand you well. Why?. I was thinking in a very simple class to be the superset of records with methods, objects...
Or even (if some programmer wanted) their own Tobject foundation. (well that is far that i have thought), even the "empty" class i think it should have some minimum bookeeping from compiler (vmt tables, self variables like class name or at least facilities for the class to know these or storage if the default hasn't, etc..)

    and avaiable empty root class it would make a common foundation of a record with methods or objects. In other words, the class would be a superset of actual class, object and record functionality. (as a idea).

That is the idea yeah, but that comes with a consequences that you need to define, and work with pointers to the non static ones. And that case is much more common than stack instantiation.

Good! , are there (actually) some open design debate/work in progrees in forum to see that?

Ok, but the end conclusion is the same. You need to know both object models very intimately from both a theoretical and practical point. Only then you can make choices, and even after that there is still compatibility to regard. And you didn't even seem to know that the FPC classes model already supports a form of multiple inheritance.
This is a dead end.

I have read interfaces/protocols. Yeah, this helps for multiple inheritance, but not the thing i was intended to say (for me it's like having a familiar-in-law class (it's a joke )  that does the multiple heritage). Not my preferred way even if compiler should tackle the diamond problem as Nuño Said.
 

    Why not multiple heritage instead of interfaces?.

It is a messy and complicated.

I agree in complicated, not in messy Have been some historical work on this? (or ideas avaliation like eiffel aproach of heritage where it's explicitally which heritage used).

    I'm not understanding. What kind of guard helps this if glued?. A memory request is in the "new instance" of the constructor, then it could happen in the constructor code after that instance if some memory is required (for example other auxiliary class), then the set of values (the init).

The constructor can contain any code, e.g. registering the class with global resources. If such code can't complete it raises an exception and the instance returned from the initmemory-constructor combo would be incompletely instantiated. The choice in object pascal is to then free that class and let the exception (which can contain extra info) bubble up.

Yeah, but what i intended to say is that the memory fault (one kind of error) and the init fault (example code makind a div by 0) are glued too. So you have two errors in one exception that can be tricky in some debugging... It's not bad. I asked why this design. (for example, the strategy (enforced by compiler) here is to treat a constructor+init fault as a single piece because a constructed without init should not have sense...-> this kind of argument, that it's perfectly ok and being a matter of taste or being part of a more complex strategy). I miss some strategy references in doc to know not only "the how". To know "the why" too. Sorry if i'm a excessive asking person

If you want to propose something that is not already live in some major Pascal compiler, it is wise to start working on some prototype compiler (doesn't have to generate fast code, just work).  Nobody will ever accept rearranging fundamental aspects of a compiler used in production like FPC otherwise.

Well, my idea here was other aproach. I would make a precompiler with extended syntax to transform these code in pascal, then that code will be the food to the current fpc .

    Well, i want to be optimist. If a feature that could be useful, for example, an empty root class, and that could be made by non invasive syntax like TMyClass=emptyclass or TMyClass=Class (empty/nil) (for not using TMyClass =class that means TMyClass=class(Tobject)) and it's useful i think it could be possible a little steps forward without breaking the old job. I know i want to be optimist .

The eventual syntax is only a very small part of the object model, and the details mostly come at the end. How everything works, how to enable the compiler (or runtime libraries) to know enough to generate/execute code, memory safety, performance etc is much more important.

I understand, agree and respect this point. Realiability, efficient generated code and safe changing is a must in a big, successful and long term compiler. I only tried to say that, without crossing these red lines, i think there could be some room for advancing. And i would repeat my first question: is there *here* a specific compiler evolution forum to exchange ideas? (not needed a dev forum to make devs  losing their time with user low matured ideas)

[Ñuño_Martínez]

@Nuño: The diamond problem is a Syntax problem mainly. The problem is that the heritage two method named exactly the same (from your multiples ancestor) , the compiler doesn't warn you to name explicitally which ancestor do you want to use, or compiler making more checks.

But, for example in a chain Ancestor->(Son1,Son2)->GrandSon if GrandSon wants to use Son1.Foo that exists on Son2.Foo (and those two could be even overriden an Ancestor.Foo or not), the compiler should ask for ambiguity and the programmer should write what is needed to use (son1.foo, son2.foo, ancestor.foo).

Of course. The thing is when using STDLIB classes (mainly containers and stream ones) the compiler goes crazy and does what it wants witout asking or warning or hinting because standars classes used multiple heritage generating diamonds (IIRC there wrere a stream class that had two diamonds in its tree) and messing with conversions and copy constructors (my compiler was reluctant trying to convert every object to string everytime if finds the assign operator or the copy constructor with it, no matters what I was doing [much like PHP to be honest, thankfully PHP used different operators for addition and concatenation]).  Somebody told me newer standard fixed it but it was too much traumatic for me.