<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 10.06.2019 um 00:28 schrieb Ben
Grasset:<br>
</div>
<blockquote type="cite"
cite="mid:CAL4d7FgoPysogxZ2F_t6Oq5Bb=GUvbJ5pTjGHp7cJ002zUWEUg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Sun, Jun 9, 2019 at 11:26 AM Florian Klämpfl
<<a href="mailto:florian@freepascal.org"
moz-do-not-send="true">florian@freepascal.org</a>> wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Yes, but this has *nothing* to do with the output of -vp.
Nothing.<br>
</blockquote>
<div><br>
</div>
<div>My point with that was more just getting at "clearly
typed pointer aliases are not actually that big of a deal
internally for FPC", as in it doesn't really matter if it
*technically* declares a new type.</div>
<div><br>
</div>
<div>Again, literally nobody in this entire message chain has
stated any actual reason why exactly they think it would be
specifically *bad* to have `^Type` in method parameters.</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>A compiler writer's point of view:<br>
<br>
I did something similar recently, when I added types with
parameters to my <br>
New Stanford Pascal compiler (for example CHAR (15), STRING (25),
DECIMAL (15, 2)). <br>
I decided to allow this notation in procedure declarations, too. <br>
</p>
<p>This has the following impacts on the compiler: <br>
</p>
<p>- you have to parse "type with parameters" in procedure
declarations, where you had only <br>
type identifiers up to now <br>
</p>
<p>- you have to construct a new "artificial" type record with a
name which is not a normal identifier <br>
but which matches for identical notations used later and insert
this record into the type list on <br>
first occurence. In my case, the types CHAR (n) etc. are standard
types, so they are inserted <br>
into the type list of the top-level block, even if they occur at
lower levels (there is one entry for <br>
CHAR (n) for every different value of n, although the CHAR (n)
types are compatible to each other<br>
to a certain degree, same goes for STRING (n) - CHAR (n) is simply
an abbreviation for <br>
ARRAY [1..n] of CHAR; STRING (n) are varying length strings,
involving a length field). <br>
</p>
<p>In the case of the pointer notation, things would be different: <br>
</p>
<p>- a pointer symbol should be accepted in front of the type
identifier (or in my case, "type with parameters") <br>
</p>
<p>- the base type must have been declared already <br>
</p>
<p>- if there is no definition for this pointer type, also in this
case a new "artificial" type record must be built, <br>
but the type record should be inserted at the same level as the
record of the base type. The generated <br>
name should be unique, not a normal identifier, and dependent from
the base type identifier. <br>
</p>
<p>But: <br>
</p>
<p>I am still not sure, if it is a good idea, because this would be
an exception for pointer types; <br>
other type constructors like arrays, records, enumerations etc.
are still not supported ... <br>
and it does not make sense IMO to support them. <br>
</p>
<p>Kind regards</p>
<p>Bernd <br>
</p>
</body>
</html>