[fpc-devel] generics

[Danny Milosavljevic]

Hi,

Am Montag, den 02.05.2005, 17:56 +0200 schrieb Peter Vreman:
> > 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?
> 
> Handle it like a macro with a parameter. That is much easier to implement.
> Creating new modules/objects is much more complex.

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

-- 
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/41943fc7/attachment.sig>