[fpc-devel] generics

[Danny Milosavljevic]

hi,

Am Freitag, den 29.04.2005, 21:48 +0200 schrieb Peter Vreman:
> At 18:06 29-4-2005, you wrote:
> >Hi,
> >
> >Am Donnerstag, den 28.04.2005, 07:53 +0200 schrieb Peter Vreman:
> > > > 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'.
> > >
> > > You only need 1 generic type at once.
> >
> >I dont understand what you mean by that sentence. At once when
> >attributed to what ? Need where ? Need how ? (uses, derivation, type
> >alias, variable declaration, ?)
> 
> 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.
> 
> 
> 
> >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.
> >
> > > Why 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.
> >
> >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)
> 
> 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 >.

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

-- 
www.keyserver.net key id A334AEA6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20050502/37333971/attachment.sig>