[fpc-devel] An extension of fpc language: the BASED construct

[Giuliano Colla]

Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto:

> Am 26.12.2017 13:33 schrieb "Giuliano Colla" 
> <giuliano.colla at fastwebnet.it <mailto:giuliano.colla at fastwebnet.it>>:
>
>     If the idea is not rejected, then a number of refinements (which
>     I'm ready to implement) are required to make the feature generally
>     available:
>
>
> My following remarks are independent of an eventual acceptance of the 
> feature :
>
>     - All architectures should be supported (now it's only for x86_64
>     - symcpu.pas).
>
> It might be possible to implement this in a platform independent way 
> that might simply need to expand the capabilites of "absolute".

The feature in itself is platform independent.

The only catch is that in pdecvar.pas (where variable declaration is 
handled) there's a per platform hook for each symbol type, in order to 
allow for special handling of some features.
For consistency I did follow the same rule, which is used for all the 
other declarations, disregarding whether they're platform independent or 
not.
As a consequence, for each supported platform you must add in its 
specific symcpu.pas a type entry:

tcpubasedvarsym = class(tbasedvarsym)
end;
tcpubasedvarsymclass = class of tcpubasedvarsym;

and a line of code:

   cbasedvarsym:=tcpubasedvarsym;

As this is tedious, I've only done it for the platform I'm using 
(x86_64/symcpu.pas). To deploy the feature, the same lines must be added 
in each platform symcpu.pas unit. There's no more that that.

>     - It should be decided if to make the feature generally available,
>     or conditioned by an {$IFDEF FPCHASBASED}
>
>     - It should be decided if the feature should be available in all
>     modes or only in a selected number of modes (what of TurboPascal
>     Mode or Delphi Mode?).
>
> Rule of thumb: new features added as a separate mode switch, no 
> FPC_HAS_* define necessary as by definition this can be done with 
> version checks (there is only one trunk version, namely the current one).
>
>     - It should be decided if error messages should be specific for
>     the BASED construct or common to the ABSOLUTE one, slightly
>     rephrasing the error message.
>
> Might be one or the other depending on the message.
>
>     - It should be decided if internal error # which currently keep
>     the same number of the nearby ABSOLUTE internal error should be
>     given new values.
>
> Internal errors shall always be unique as they are used to find the 
> error location, even for copy pasted code.
>

What's the rule to avoiding clashes? I gathered sort of YYYYMMDD## is it 
correct?

Giuliano



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20171227/7e2d26e2/attachment.html>