[fpc-pascal] Constants in generics

[Sven Barth]

Am Di., 27. Nov. 2018, 08:18 hat Ryan Joseph <ryan at thealchemistguild.com>
geschrieben:

>
>
> > On Nov 27, 2018, at 4:59 AM, Sven Barth via fpc-pascal <
> fpc-pascal at lists.freepascal.org> wrote:
> >
> > Best check again once you've done the switch to tconstsym for constants.
> :)
> >
>
> I made most of the changes you mentioned so please look. Including the
> constsyms didn’t break anything and helped to clean up the code. I would
> have done that from the start but I wasn’t sure you wanted me mixing in new
> types.
>

Good, thank you. Hopefully I'll find the time this evening to look at your
changes again. :)


> Some things remaining:
>
> 1) kSomeDays is a typed const so I get a load node instead of
> tsetconstnode, which I need to need to know in order to make the name
> string. See the TODO’s in tgenericparamdef.create.
>
> type
>         TDay = (Mon, Tue, Wed);
>         TDays = set of TDay;
> const
>         kSomeDays:TDays = [Mon, Wed];
>
>
> var
>         d: specialize TMyRecord_Set<integer,kSomeDays>; // this doesn’t
> work
>         d: specialize TMyRecord_Set<integer,[Mon,Wed]>; // this works
> because I get a set node
>

The difference between typed and untyped constants are available everywhere
else in the language as well, so I have no qualms (at least for now?) to
error out on them.

For sets I believe that this should work however (see here:
https://freepascal.org/docs-html/current/ref/refse9.html#x21-200002.1 ):

=== code begin ===
const
  kSomeDays = [Mon, Wed];
=== code end ===

2) Again in tgenericparamdef.create I don’t know how to make the pretty
> name string from a set (see the TODO)
>

I'll need to take a look at that. Maybe we'll need to add a list of
elements to the set comet type if it isn't already there. 🤷‍♀️

3) You may be right about forcing the const type at declaration. I still
> kept the undefined const placeholder in there but if you have nested
> specializations you can get type errors because the placeholder uses a nil
> node. It’s too early to know if there’s any reason for undefined consts.
>
> 4) I’m not sure if changing the types to consts messed up PPU loading or
> it works out of the box. Seems to be ok from initial tests though.
>

Did you try with the generic and the specialization in different units and
changing only one of the two? Though you might want to check whether
tstoreddef.ppuload (or wherever tdef.genericparas is initialized after a
unit load) correctly instantiated the tconstsym instances instead of
ttypesym ones. It might already work correctly, but better safe than sorry.
😅

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20181127/2a2f466a/attachment.html>