[fpc-devel] Templates / Generics

[dannym]

Hi,

Am Freitag, den 04.11.2005, 20:28 +0100 schrieb Florian Klaempfl:
> I read the disussion above and I'll post my thoughts so far below:
> 
> - we'll use a syntax as close as possible to Chrome, e.g.
> type
>   TList<T> = class
>     ...
>   end;
> 
> - instantiation will be only possible in declaration blocks, not in code
> blocks:
> possible:
> var
>   mylist : TList<integer>;
> const
>   mylist : TList<integer> = nil;
> type
>   mylist = TList<integer>;
> forbidden:
> procedure p(mylist : TList<integer>);
> begin
>   ...
>   mylist:=TList<integer>.create;
>   ...
> end;

hmm.. a parameter declaration of a function declaration is not a
declaration block ? I've always thought of them like local variables,
just happening to be pre-filled..

and, will TList<integer> and mylist be compatible types ?

> Maybe we need an exception to this when supporting sub routine templates:
> procedure<T> p(mylist : TList<T>);
> begin
> ...
> end;
> but this doesn't lead to an ambigious syntax.
> 
> - instantiation steps which require code generation are done after main
> program compilation based on information saved in the unit files, this
> has some advantages:

you mean to save the parse tree of the generic (both the interface and
the implementation section) to the ppu ? I've been thinking about using
a extra file in order not to taint the ppu but if it is possible to use
the ppu itself for that, i'm all for it :)

> - several equal instantiations require only one specialisation


> - it's possible to setup an symbol environment as it has been used in
> the template definition, so the cyclic unit use problem is void it
> requires though that a lot symbols of the implementation part of a unit
> must be written to the unit file if the unit contains a template definition

note that line number information for nice error messages need to be
retained along with the parse tree of the generic (so that when another
unit uses a generic unit but specializes it to something stupid,
programmer gets a nice location of error rather than "guess where it
was" :)). 
Maybe it already is done, though :)

Note that for the error message, you'll need _two_ locations: one of the
generic type implementation where the actual error manifested and one
for the location of the specialization of the generic, to know what has
been used as the type parameter.

On second though, _maybe_ just one location (the first) and the names of
the types used for the type parameters suffice.

> 
> This approach will require some compiler clean ups but that isn't that
> bad ;)
> 
> Any comments :)?

cheers,
  Danny