<div dir="ltr"><div><div><div><div>It is interesting to discover why the Go programming language introduced type aliases to the language with the recent 1.9 release.<br></div>That feature was absent from day 1 to avoid the same problems Andreas was referring to, but later they realized it is useful.<br></div>See <a href="https://talks.golang.org/2016/refactor.article"> https://talks.golang.org/2016/refactor.article </a>for more information.</div><div> The design document is here: <a href="https://golang.org/design/18130-type-alias">https://golang.org/design/18130-type-alias</a><br><br></div>Note that the Go type system has a mix of name equivalence and structural equivalence. If a type has a name, name equivalence is used otherwise structural equivalence it used between anonymous types.<br></div>See the specification for the details: <a href="https://golang.org/ref/spec#Type_identity"> https://golang.org/ref/spec#Type_identity</a><br><div><div><div><div><br></div><div>Cheers, <br></div><div>Luca Boasso<br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 10, 2017 at 8:43 PM, Diego Sardina <span dir="ltr"><<a href="mailto:dsar@eml.cc" target="_blank">dsar@eml.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><div>On Wed, Oct 11, 2017, at 12:48 AM, Andreas Pirklbauer wrote:<br></div>
<blockquote type="cite"><div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> </span>----------------------------<wbr>-----------------------</span><br></div>
<div><div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> On Fri Oct 6 12:40:42 CEST 2017 Jörg Straube:</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> </span></span><br></div>
<div><div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> Personally, I’m not indifferent ☺
> 
> I know that it can be done, but the question is WHY. Only because</span></span><br></div>
<div><div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> something can be done is a poor reason to do it.</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> If you put  a := b in your code,  you do that as you know or assume</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> a certain relationship between those two variables (they e.g. represent</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> instances of the same or comparable thing). If this hold true,</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> I don’t understand why you have to write two totally independent</span></span><br></div>
<div><div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> type declarations that (by accident) match structurally.</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> ------------------------------<wbr>---------------------</span></span><br></div>
<div><div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> On Fri Oct 6 13:20:09 CEST 2017 Jörg Straube wrote:</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace">></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace">> <span style="white-space:pre-wrap">VAR</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">>     nbrOfBirthsPerMonth: ARRAY 12 OF INTEGER;
>     nbrOfAccidentsPerMonth: ARRAY 12 OF INTEGER;
>
>    nbrOfBirthPerMonth := nbrOfAccidentsPerMonth </span>(*these match structurally but makes not much sense, should be forbidden*)</span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">> </span>------------------------------<wbr>---------------------<span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">Jörg,</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">a</span>s I said earlier, I agree that you kind of have a point here. HOWEVER, how is your example conceptually different from:</span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace">VAR</span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace">nbrOfBirthsPerMonth: INTEGER;
    nbrOfAccidentsPerMonth: INTEGER;</span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed, but *also* makes not much sense*)</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">or from this:</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">TYPE Births = INTEGER;</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">Accidents = INTEGER;</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><div><span class="m_-8320594765146248770font" style="font-family:monospace">VAR</span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace">nbrOfBirthsPerMonth: Births;
    nbrOfAccidentsPerMonth: Accidents;</span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed*)</span></span><br></div>
</div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">both of which are allowed in Oberon (the second variant is allowed, because in Oberon type aliases are considered as the *same type*), but “make no sense” according to your logic?</span></span><br></div>
</div>
</div>
</div>
</div>
</div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">In other words: If we *really* were to take a purist point of view (which I am NOT advocating!!), we might as well have the same discussion for the basic types such as INTEGER, i.e. without even referring to structured types (arrays or records).</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap"></span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">Just saying...</span></span><br></div>
<div><span class="m_-8320594765146248770font" style="font-family:monospace"><span style="white-space:pre-wrap">-AP</span></span><br></div>
</blockquote><div><br></div>
<div><br></div>
<div>These are different considerations.<br></div>
<div><br></div>
<div>In the right part (after "=") of a type definition, ARRAY, RECORD, POINTER TO and PROCEDURE are to be considered *type constructor* for defining new types, while in the case of an identifier denoting an already existing named type (aliasing), you may choose between:<br></div>
<div><div><br></div>
<div>- an alias introduces a distinct type (strict name equivalence, like in Ada), or<br></div>
<div>- an alias introduces an equivalent type (loose name equivalence, like in Pascal-family languages).<br></div>
<div><br></div>
<div>As an ex Ada programmer, I  liked the strict name equivalence principle. But I consider it useless now, because in every case I always evolved a type from aliasing a basic type to a record type, introducing more properties to it.<br></div>
<div><br></div>
<div>Indeed I liked the idea of removing type aliasing in Oberon-07, but it was reintroduced in the previous year. Wirth justified it saying that sometimes it's useful to introduce a short synonym for a lengthy, imported type name.<br></div>
<div><br></div>
<div><br></div>
<div>--<br></div>
<div>Diego Sardina<br></div>
</div>
<div><br></div>
</div>

<br>--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
<br></blockquote></div><br></div>