Hi,

I'm trying to add support for generics (templates) to fpc.

Do we want to have a "generics" section (like "interface", "implementation") or do we want a special source code type (like "unit", "program") in the source code ?

I'm tending to a special source code type "generic unit".

The generic source code file (.pas,.pp) is installed (not the .ppu,.o). Then in the 'uses' handler, when not finding a ppu, it reverts to the pas file, and then finds that it is a special source code "generic unit" or so, so it *doesnt* compile it right now, but 'uses' actually just registers the generic classes as 'available for compilation later'.

When first using a specialization declaration like 'GList<Integer>', _then_ it is compiled (after injecting the specialization types to use) (where to? a special .o file like glist-system-integer.o or glist-someunit-someclass.o ? use a .ppu too ? I guess so)

I'm leaving "advanced" features out for now, like "any" types (variant-interface to a generic), although it could be argued that the generic class could compile using the "any" types (most likely "Variant") later.

Opinions?

cheers,
Danny

further infos:
http://qc.borland.com/wc/qcmain.aspx?d=11168

You only need 1 generic should a complete generic unit be used? Also using it as a unit is inconsistent with the way that units are handled and will require a lot of if..then parts in the unit loading code. And that code is already one of the most complex parts of the compiler. It is already on a after 2.0 todo list to be rewritten because of this complexity.

Hi,

attributed to what ? Need where ? Need how ? (uses, derivation, type alias, variable declaration, ?)

I have a test maplist module with only one generic per unit (that the $DEFINE/type approach only works with one generic/unit might add to it ;)), if you mean that. I agree that multiple generic classes in one unit would be good. But mixing generic classes and non-generic classes in one unit isn't a must-have item, really.

I see. Well, then lets do generics sections (like "interface", "implementation") (maybe "generics interface", "generics implementation" ?) or perhaps not separate them section-wise at all (that is, mix generic types and non-generic types in the unit as if they were the same; would be confusing, perhaps)

cheers,
Danny

When you define an implementation of a generic class then you only need that generic class. It is strange to defer compilation of a complete unit with generic classes. And to allow only one generic class in a single unit is also very strange and sounds more like a hack instead of a real solution.

A generics section is the easiest to implement. The block_type in the parser can then be set to bt_generics and allow different meaning of characters like < and >.

Peter

hi,

characters < and > have no meaning with a type as operand, correct ?

So if its only for that, a special section isnt really required.

A possible reason for separation is that you _need source code for generic types_ to use them, which is obviously not the case for normal types.

So choices now are:
a) add generic interface section, generic implementation section b) intermix them in the normal sections, with the only difference being "if '<' follows typename, its a generic type"

So the next part to decide on is how to actually implement specialization.

I've been thinking: define type parameters to actual types, with them defined compile the generic source code into new object file (genericunit-typeparameter1-typeparameter2.o or something).

Comments?

cheers,
Danny

Handle it like a macro with a parameter. That is much easier to implement. Creating new modules/objects is much more complex.

Hi,

If you think that suffices, sure.

Can you give details about which parts to do with macros?

I've been thinking along the way of allowing (nested) types (or just
type aliases, suffices) within classes, and then for specialization do
internally:
  type
    G = class
      type
        T = string;
        Q = string;
      procedure X(a: T);
    end;

procedure G.X(a: T); <--- parser needs to be changed to accept nested types of the mentioned class for implementation (this is really the only 'major' modification neccessary which I can see)

For that we still need (nested) types within classes, though (Synopsis and fpk know what I mean)

For your macro approch, can you give a pseudo-code like layout of the proposed way ?

thanks :)

cheers,
Danny