I want to do a pivot away from the macro stuff to ask another question. Since I’ve wanted to contribute to the compiler for so long and I finally have a little understanding I’d like to know if there’s anything minor I could do, that isn’t offensive to the compiler team.

What comes to mind first as being minor (or not, I don’t know) and important are default record fields. Is there are reason this never existed in Pascal? It’s in C++, C#, Swift etc…. and I use it often. The compiler added advanced records but making a static class method which is hidden down in the implementation is annoying boiler plate I’m sick of doing (plus calling it, or forgetting to). The new initialize operator is the best alternative but again it’s boiler plate and adds methods in the implementation.

Is there any reason we can’t do that? Is it a design choice?

type
	TVec2 = record
		x: integer = 0;
		y: integer = 0;
	end;

Regards,
Ryan Joseph

Hi,

Ryan Joseph wrote

I want to do a pivot away from the macro stuff to ask another question. Since I’ve wanted to contribute to the compiler for so long and I finally have a little understanding I’d like to know if there’s anything minor I could do, that isn’t offensive to the compiler team.

<rant>It's not about the compiler team. It's about the integrity of a programming language, which doesn't matter these days a lot, when all languages turned into a feature race to provide the same broken concepts, but with slightly different syntax. Nevermind. I sometimes do not even understand how people did stuff for 50 years without TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>

What comes to mind first as being minor (or not, I don’t know) and important are default record fields. Is there are reason this never existed in Pascal? It’s in C++, C#, Swift etc…. and I use it often.

Because C# and Shift are managed languages, and C++ just includes everything for no good reason. And this is actually major, with far fetching implications. C++ is an utter mess for this, with the default initializer sometimes called and sometimes not, when you declare a variable of this type. Because if you pull the way computers work into the equation, it complicates things a lot. It matters where you define a variable of this type. On the heap, on the stack or on the global variable list, you have to compile different code for this, and you are probably won't be able to cover all corner cases. (Eg. what if you allocate this type with GetMem(sizeof(type))?)

It's a design choice.

In general, could you stop trying turning Pascal into C/C++? What C++ provides is mostly what is provided by advanced records (the useful subset). Except C++ allows writing the default initializer into the type declaration which then may or may not get executed, because C++ is a godforsaken mess.

What you can also do is, to declare the type, then declare a set of defaults with "const", which you can also write into the interface section. Then if you need a certain initialization for that type, just do it with an assignment.

var
  myvar: mytype;
const
  myvardefault: mytype = <initializer>;
begin
  myvar:=myvardefault;
end;

In this case the compiler will even warn you, if you A., forgot to initialize the variable B., forgot to initialize a field in the initializer. I'm using similar pattern in my 3D engine, where I have various set of default vertices and matrices defined as consts, which are still the same type, and i can initialize them this way to whichever default I need..

If you need huge amounts of this construct, I would advise you to generate it as Michael said, which is what you would do with extended preprocessing or similar syntax sugar, like this one. It's just implicit code generation.

Charlie

I read Ryan's mail as an attempt to get involved in some compiler-development. And he's wondering what a nice task could be.

Can't we think of something? Maybe he can help with the last parts of the modules-support from Sven.
Or with the merges of the Attributes branche that I once started. Although I know that it's high on Sven's todo-list.

Maybe both topics are to difficult. But maybe something else? Some optimisation?

Regards,

Joost.

Hi,

Well, true. Sorry if I sounded too rude. But both threads he started sounded a bit like "this is broken in the language, so lets fix it", where I beg to differ.

There are plenty of things to implement indeed. I think we are mostly lacking on high-level optimizations, but that's a very tedious job, and hardly helps the use case Ryan was working on, which seemed to be clearly his driving force in this.

About the really high level generics, RTTI, & whatever topics I'm probably not the right person to consult indeed. :)

Charlie

I just want practical solutions to the problems I face daily. Making boiler plate constructors to initialize records is one of them. Maybe designing a programming paradigm and strictly adhering to it is works for you but I want to make my life easier and enjoy programming as much as I can.

Seriously though why shouldn’t init'ing records be easier? Do people like making constructors all the time and scrolling around to find them? I don’t know about the implications of the idea but if it’s too insanely complicated to manage then obviously it’s not worth it.

Regards,
Ryan Joseph

I can’t help with higher level stuff because I don’t know how the compiler works well enough. Optimizations as well are way over my head.

I’ve been using Pascal for over 20 years now and in that time the language itself has changed, computers have changed and even I’ve changed. The language isn’t broken but there should be easier ways to accomplish some tasks. I didn’t even think about it until I saw other languages do it better and then wondered why we aren’t doing the same thing.

I didn’t think that was a controversial statement to make. I really thought people wanted macros with parameters and I’m shocked again to find that default record fields may be widely despised also, but that’s why I’m asking.

Regards,
Ryan Joseph

On Jun 22, 2018, at 8:32 PM, Joost van der Sluis wrote: I read Ryan's mail as an attempt to get involved in some compiler-development. And he's wondering what a nice task could be.

Yes that’s right. I honestly thought default record fields was a requested feature and it’s one I wanted also.

Remember this is all relative to the users. Sven's dynamic array extensions are great but honestly I’d rather have better record init since I do that more often. That doesn’t mean I don’t want dynamic arrays in the biggest item on my wish list is anonymous functions but that’s way over my head. I’d like class helpers to exist in multiple scopes at once but I’m pretty sure I couldn’t do that either, or I’d give up before it was finished.

Regards,
Ryan Joseph

Ryan,

We all desperately want dynamic packages completed. Perhaps you might have some interest in that?

I never heard of "dynamic packages" before so that’s not a good start. :) What is it?

Regards,
Ryan Joseph

They are the same as Free Pascal packages, that is a collection of units which can be compiled separately, but with the added ability to be loaded and unloaded after a program has started. Presumably there also exists some dynamic package utility functions built into the system unit that also allow users to search through a package and find units, variables, functions, and types found in the package, then bind to these things while the program is running.

Example usage of this would be to allow components to be installed inside the Lazarus IDE without the need to rebuild the IDE. Also, users can design programs that allow for plugins in the form of dynamic packages. Finally, a possibility also would exist to write a package browser that could examine packages and tell you what's in them without having to parse source code.

I'm sure there's more that can be done with dynamic packages, but I think you get the idea.

Sven says dynamic packages are coming, but a few independent things need to be completed. Sven, do you care to add anything?

On Jun 22, 2018, at 10:08 PM, Anthony Walter wrote: I'm sure there's more that can be done with dynamic packages, but I think you get the idea.

I’m not a Lazarus user so this is probably not a good fit for me. I’ve never encountered anything like a “package" in FPC so there would be a pretty steep learning curve just trying to understand the system in which they exist. They should like dynamically linked libraries but clearly they’re something different.

Regards,
Ryan Joseph

+1
It's not (only/just) what "the compiler team" wants. There are people actually using the compiler. For real life purposes. And a lot of what people are proposing, over and over again, are solutions for problems that nobody has (in real life)...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

+1
It is better to have a simple language with packages/libs to do the (real) job than a complex language that try doing anything that someone could imagine or want to do.

Best regards,
Marcos Douglas

Yes, you can already do almost everything you want with freepascal. Keep it easy.

Restraint is a virtue exercised by the wise and experienced; the young and foolish prefer abandon.

-Jim

Anthony Walter wrote

Sven says dynamic packages are coming, but a few independent things need to be completed. Sven, do you care to add anything?

It's mainly low level code generation and integration with the RTL, so I doubt that there is much that can be helped there.

Regards,
Sven

More often than not people use classes instead of records and even then for records constructors (or factory methods) cover the important cases. E.g. for TPoint there is Point() while 3.0.0 also added TPoint.Create() and a TPoint.Zero() as convenience method for an empty TPoint.

Also using an IDE like Lazarus it's easy to see the methods of a TPoint by typing "SomePointVar.|" and pressing Ctrl + Space. On the other hand to know whether the fields are initialized or not you'd need to navigate to the type which means leaving your current zone of development.

Regards,
Sven

On Jun 23, 2018, at 3:15 AM, Sven Barth via fpc-pascal wrote: More often than not people use classes instead of records and even then for records constructors (or factory methods) cover the important cases. E.g. for TPoint there is Point() while 3.0.0 also added TPoint.Create() and a TPoint.Zero() as convenience method for an empty TPoint.

Sure, and those are all welcome additions to the language which I use often.

I’m speaking of the general friction when creating custom records and having to go through the boiler plate of adding those methods every time and breaking the record into the implementation so I can have class functions (which need to be called also) or now initialize operators which save the calling step. It’s just friction in the development process and busy work.

My thinking was that because variables can assign values at declaration it would be reasonable to assume that record fields could have default values which would be sounds like a natural extension of the syntax that already exists.

I assumed (wrongly perhaps) because this feature exists in c++, c#, swift etc… that it was in demand.

Regards,
Ryan Joseph

My thinking was that because variables can assign values at declaration it

would be reasonable to assume that record fields could have default values which would be sounds like a natural extension
of the syntax that already exists.

Those are two different things actually: Declaration time initialization for variables vs default record field values. The former doesn't cause confusion because the value and the variable are in the same place, but the latter does, as Sven said: "On the other hand to know whether the fields are initialized or not you'd need to navigate to the type which means leaving your current zone of development."

Now suppose you have that feature a record type T in unit A, then a code somewhere that uses unit A has a variable V of type T declared. How could you be sure what value that V holds? At best you have to initialize it right there anyway, making the default value useless. Certainly don't imagine you're the writer of unit A who knows that T has some default values. Other languages POV are mostly simply ease of typing, they don't think the consequences this far.

Why would you be confused if a record set a default state? If you don’t know the fields in your record you’re in trouble anyways because you don’t know the state of your program.

var
  r: TVec2;
begin
  // the record is either A) garbage or B) a default value.
  // if you can’t remember the default values you set then
  // by all means do r := TVec2.Zero every time. Have fun
  // making class procedure Zero; methods for all your custom methods also
or just force default init with a keyword;
var
  r: TVec2; default;
begin
  // now I know r = {0,0} because I set those values

….

type
	TVec2 = record
		x: integer = 0;
		y: integer = 0;
	end;

Because Pascal doesn’t init by default you would be effectively overriding that behavior by adding default fields. In worst case scenario you’re still in the same place as before, i.e. you don’t know what the state is of your data. The programmer needs to know what they’re doing and what the contents of their data is regardless. Pascal's default behavior is “do noting” and default fields would just override that.

Swift FORCES the init of structures because they follow your general line of thinking which is “programers don’t know what the contents of their data are, so the language needs to guarantee a default state for them”. I hate that about Swift because it hold your hands at all times and adds enormous amounts of friction into the process. No in 3.1.1 we can use init operators to guarantee records are in a default state upon use. This is great but they add extra boiler plate code in the implementation section.

type
	TVec2 = record
		x, y: integer;
		class operator Initialize(var rec: TVec2);
	end;
class operator TVec2.Initialize(var rec: TVec2);
begin
	rec.x := 0;
	rec.y := 0;
end;

Regards,
Ryan Joseph