[fpc-devel] Macro Processing

[Daniël Mantione]

Op Sat, 14 May 2011, schreef Joerg Schuelke:

> I think of this a little different. Maybe more from an other
> perspective. For me RTTI is a level of language extension. Like OOP, or
> generics, or inheritance. Macros are very low level (if you have them).

RTTI *allows* for language extensions, like str/val for enums. RTTI by 
itself are just data structures describing Pascal types, emitted 
automatically by the compiler. Language extensions can use those data 
structures to provide their functionality.

> It is not that I think that I would use a macro instead under all
> circumstances. But it should be possible to do it without RTTI which is
> of higher level in the language.

I still don't see why it should be possible to do it without RTTI. But the 
question is, is the unknown reason that you don't want to use str a 
justification for adding the can of worms that is called macro's?

> The principle is do not use it if you do not like it. That should not
> influence the rest of the language. This way I think that it is not
> that bad to have a small, but powerful macro expander incorporated.

It's not that bad, but it should make something possible. Until now I 
haven't seen many bright examples of things that cannot be elegantly 
without macro's.

> 52 bytes of data. And the RTTI code?

Not much. Converting an enum to a string is a single procedure. It's 
quickly won back if you use the feature a few times. Actually this is a 
nice story about the hidden costs of language features. The procedure 
would be extremely simple (lookup a pointer to the string in an array, 
return the string), but FPC supports non sequential enums:

type colour=(red:=1,green:=10,blue:=100);

The majority of the code in the procedure that converts an enum to a 
string deals with handling this special situation (don't worry: normal 
enums are still a simple lookup). Often when you add features, it has 
unforseen consequences and it can be a complicated effort to make 
everything together well enough. This is why you want to be carefull 
adding new features.

> What if you do not smartlink?

Then you get so much extra code in your exe that the RTTI is still a small 
and irrelevant portion. Actually in the past you could disable RTTI 
generation, but it was too sensitive for bugs. Removing unused code & data 
is the task of the linker, we decided to make the linker do what it is 
designed for.

> I repeat, I have really nothing against RTTI, but I state that it
> comes from a high level language extension.

Good.

> By the way this RTTI thing comes from the argument: Do not use a
> macro, instead do it this way. But this forces me to use RTTI, which is
> possibly not what I want.

Hmmmm... For the same reasoning you could say inline functions are ugly 
and you want not to be forced to use inlining.

The point is that every time you can avoid a macro you win on code 
clarity, compiler speed (no time spent on evaluation & expansion), 
debugability, parsability by IDE's, and so on.

Inlining is better that doing the same with macro's, so is the use of 
str/val better than macro tricks.

We don't want to force you to use RTTI, but our point is that there is 
proper solution to achieve the same benefit that the macro approach gives.

> But this way I can show you even OOP is useless :) what I do not
> believe.

While I do believe in the merit of OOP, there are many dubious OOP 
features that you can criticize in a valid way, escpially because few of 
those features open new possibilities. But unfortunately it's a waste of 
time; we need this for compatibility.

Daniël