<div dir="ltr"><div>I agree with Chuck, interfaces are useful to avoid the issues of implementation inheritance all together and use composition instead.</div><div>This has been explored by former ETH PhDs with the language Lagoona, see <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.8656&rep=rep1&type=pdf">On Reconciling Objects, Components,and Efficiency in Programming Languages</a> for rationale and implementation techniques (the language Emerald follows a similar approach)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 25, 2020 at 11:15 AM Charles Perkins <<a href="mailto:chuck@kuracali.com">chuck@kuracali.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi <span style="color:rgb(32,33,36);font-size:0.875rem;letter-spacing:0.2px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;white-space:nowrap">Jörg,</span><div><span style="outline:currentcolor none medium"><span name="Jörg" style="color:rgb(32,33,36);font-size:0.875rem;font-weight:bold;display:inline;vertical-align:top;letter-spacing:0.2px;line-height:20px"><br></span></span></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px"><br></span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px">If I understand your example correctly, the Interface procedures are declared in the base "Dynamic" module while their implementation resides in a derivative, potentially separately compiled record definition. This is a useful pattern for a self-contained project. It requires you to make every interface implementation a descendant of one record in the "Dynamic" however. Every time you add a new interface you have to recompile the dynamic module and everything that uses it, because the symbol file has changed. In addition, different developers may be adding interfaces independently. Either everyone is making changes to the same "Dynamic" module and their changes have to be merged, or each developer has a different "Dynamic" (or otherwise-named) module and their interfaces do not compose.</span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px"><br></span></font></div><div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px">I would like to be able to request the same behavior from two completely independent types, and if the interfaces match, perform the function call. The idea I'm going for is something that will allow you to make, for example, an interface that will print anything with a "printer" method, a different interface that will serialize to JSON anything with a "ToJSON" method, etc.</span></font></div><div></div></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px"><br></span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px">Philosophically though I think it's the same question of why have Oberon-2 with type-bound procedures when the same functionality can be achieved with plain Oberon-07 and procedure variables? Type-bound procedures introduce complexity in the compiler and module formats that are not strictly necessary.</span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px"><br></span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px">Just as Oberon-2 is not the same language as Oberon, I think a language that has this 'dynamic trait' capability should be called something else, like perhaps Oberon-2i. </span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px"><br></span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px">My two cents...</span></font></div><div><font color="#202124"><span style="font-size:14px;letter-spacing:0.2px">Chuck</span></font></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 25, 2020 at 8:24 AM Jörg <<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE-CH"><div><p class="MsoNormal"><span lang="DE">Chuck<u></u><u></u></span></p><p class="MsoNormal"><span lang="DE"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">In plain Oberon-07, you could solve this as follows: Not the nicest syntax but it seems doable.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">MODULE Dynamic;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">TYPE<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Obj* = POINTER TO Desc END<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Desc* = RECORD<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> toString*: PROCEDURE (o: Obj; VAR a: ARRAY OF CHAR)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> END<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">END Dynamic.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">MODULE Int;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">IMPORT Dynamic;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">TYPE<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Obj* = POINTER TO Desc;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Desc* = RECORD (Dynamic.Desc)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> val: INTEGER<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> END;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">PROCDEURE I2S(o: Obj; VAR a: ARRAY OF CHAR); BEGIN a:=”integer” END I2S;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">PROCEDURE New*(VAR o: Obj; i: INTEGER); BEGIN NEW(o); o.toString := I2S; o.val := i END New;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">END Int.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">MODULE Real;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">IMPORT Dynamic;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">TYPE<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Obj* = POINTER TO Desc;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Desc* = RECORD (Dynamic.Desc)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> val: REAL<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> END;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">PROCDEURE R2S(o: Obj; VAR a: ARRAY OF CHAR); BEGIN a:=”real” END R2S;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">PROCEDURE New*(VAR o: Obj; r: REAL); BEGIN NEW(o); o.toString := R2S; o.val := r END New;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">END Real.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">MODULE Test;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">IMPORT Dynamic, Int, Real, Out;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">VAR i: Int.Obj; r: Real.Obj; dyn: Dynamic.Obj;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">BEGIN<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Int.New(i, 3); dyn := i;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> dyn.asString(dyn, a); Out.String(a); Out.Ln;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> Real.New(r, 3.14); dyn := r;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> dyn.asString(dyn, a); Out.String(a); Out.Ln;<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">END Test.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><div style="border-color:rgb(181,196,223) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:12pt;color:black">Von: </span></b><span style="font-size:12pt;color:black">Oberon <<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank">oberon-bounces@lists.inf.ethz.ch</a>> im Auftrag von Charles Perkins <<a href="mailto:chuck@kuracali.com" target="_blank">chuck@kuracali.com</a>><br><b>Antworten an: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Datum: </b>Sonntag, 25. Oktober 2020 um 16:03<br><b>An: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Betreff: </b>Re: [Oberon] Protocols (interfaces) in Oberon-2<u></u><u></u></span></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Apologies for this : " <span style="font-family:"Courier New"">x0, x1, u: REAL;"</span><span style="font-family:Arial,sans-serif"> was a fragment that snuck in from testing. I have the above code successfully parsing in a fork of Andreas's Extended Oberon compiler. I don't have the method table generation code working yet. It turns out that the Run-time needs to have symbolic type information available, which could be simply loading the smb file alongside the rsc file for code that uses interfaces, or it could involve embedding a hash of the name and parameters of the type-bound procedure in another section of the rsc file. I haven't decided yet.</span><u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Sun, Oct 25, 2020 at 7:33 AM Charles Perkins <<a href="mailto:chuck@kuracali.com" target="_blank">chuck@kuracali.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><p class="MsoNormal">I think Interfaces / Protocols / Dynamic Traits (what Rust calls them) would be a quite useful extension to Oberon. I'm looking at doing it a different way, like this: <u></u><u></u></p><div><p class="MsoNormal"><br><span style="font-family:"Courier New""> VAR W: Texts.Writer;</span><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-family:"Courier New""> TYPE <br> I* = POINTER TO IDesc;<br> IDesc* = RECORD<br> h: INTEGER<br> END ;<br><br> R* = POINTER TO RDesc;<br> RDesc* = RECORD<br> h: REAL<br> END ;<br><br> Stringer* = INTERFACE OF<br> PROCEDURE String* (VAR a: ARRAY OF CHAR) ; <br> END ;<br><br><br> PROCEDURE ( i : I ) String* (VAR a: ARRAY OF CHAR) ;<br> BEGIN a := "integer"<br> END String;<br><br> PROCEDURE ( r : R ) String* (VAR a: ARRAY OF CHAR) ;<br> BEGIN a := "real"<br> END String;</span><u></u><u></u></p></div><div><p class="MsoNormal">In the above scheme an Interface looks just like a collection of type-bound procedure definitions with no bodies.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The trick is when it comes time to use the interface, which is when the code needs to know which actual procedure to call based on the record type assigned to it during execution. The record type assigned to an interface could be any record that contains the String type-bound procedure (in this case.) It might be the first method, or the third, or the sixth... Go solves this by generating a dispatch table for the Interface when a type is assigned to it. <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In Oberon that table-making routine could be satisfied by adding another Trap condition in Kernel.Trap much like how New is implemented.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Courier New""> PROCEDURE Test*;<br> VAR i: I; r: R; t: ARRAY 32 OF CHAR; <br> s,s2: Stringer; <br> x0, x1, u: REAL;<br> <br> BEGIN <br> NEW(i); NEW(r);</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Courier New""> i.h := 3;<br> r.h := 7.5;<br> s := i;</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Courier New""> s.Stringer(t); </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Courier New""> Texts.WriteString(W,t);<br> s := r;</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Courier New""> s.Stringer(t);<br> Texts.WriteString(W,s);</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Courier New""> END Test;<br></span><br>The above idea for Interfaces builds on the mechanisms already in place in the Oberon-2 compiler and run-time. I think it would be quite useful for allowing a program to choose from multiple implementations of an interface without constraining them to derive from the same base type while still keeping strong static typing and separate linking and loading.<u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Chuck<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Sun, Oct 25, 2020 at 6:27 AM Luca Boasso <<a href="mailto:luke.boasso@gmail.com" target="_blank">luke.boasso@gmail.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><div><p class="MsoNormal">A key feature of protocols / interfaces is the safe multiple inheritance: you can explicitly or implicitly (like in the Go language) implement several interfaces and be type compatible with each one of them.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Do you support something like the following?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Courier New"">TextDesc = RECORD (TextProtocol.TextDesc, WriteProtocol.WriterDesc) END ; (*this means: “implements TextProtocol.TextDesc AND WriteProtocol.WriterDesc "*)</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">If this is not supported I don't see this feature being that useful. To support the feature above the implementation is more complicated than Oberon-2's bound procedures. See <a href="https://research.swtch.com/interfaces" target="_blank">https://research.swtch.com/interfaces</a> for one way of doing this, or<a href="http://www.academia.edu/download/42084165/Efficient_Implementation_of_Java_Interfa20160204-28309-28q4h3.pdf" target="_blank"> "Efficient implementation of Java interfaces: Invokeinterface considered harmless" </a><u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Sun, Oct 25, 2020 at 6:46 AM Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank">andreas_pirklbauer@yahoo.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">Correction: In Text1, it’s TextDesc = RECORD (TextProtocol.TextDesc) of course<br><br>—————————<br><br>Protocols (sometimes called interfaces) can be added to<br>Oberon-2 without adding any keywords to the language.<br><br>This is one of the key differences to how it is usually defined<br>and implemented, e.g. in Swift [*] or in Integrated Oberon [**]<br><br>Under the new minimalistic design, what distinguishes a protocol<br>from an actual implementation (of the class) is that in the protocol<br>definition the implementations of the class methods are simply not<br>defined. Instead, any module that *imports* a protocol definition<br>can “adopt” (i.e. implement) it. See the example below.<br><br>An experimental implementation showed that if the language<br>is extended in *this* way, the implementation cost is minimal.<br><br>But the question is: Is it worth it? Simplicity of implementation<br>should of course not be a criteria for adopting a new feature.<br><br>Personally, I am rather sceptical of the usefulness of protocols.<br>But perhaps someone provides a good reason to adopt them.<br><br>-ap<br><br><br>Example:<br><br> MODULE TextProtocol; (*protocol definition*)<br> TYPE Text = POINTER TO TextDesc;<br> TextDesc = RECORD data*: (*text data*) END ;<br> PROCEDURE (t: Text) Insert (string: ARRAY OF CHAR; pos: LONGINT);<br> PROCEDURE (t: Text) Delete (from, to: LONGINT);<br> PROCEDURE (t: Text) Length (): LONGINT;<br> END TextProtocol;<br><br> MODULE Text1; (*one implementation of the Text protocol*)<br> IMPORT TextProtocol;<br> TYPE Text = POINTER TO TextDesc;<br> TextDesc = RECORD (TextProtocol.TextDesc) END ; (*this means: “implements TextProtocol.TextDesc"*)<br><br> PROCEDURE (t: Text) Insert (string: ARRAY OF CHAR; pos: LONGINT);<br> BEGIN (*implementation of Insert*)<br> END Insert;<br><br> PROCEDURE (t: Text) Delete (from, to: LONGINT);<br> BEGIN (*implementation of Delete*)<br> END Delete;<br><br> PROCEDURE (t: Text) Length (): LONGINT;<br> BEGIN (*implementation of Length*)<br> END Insert;<br> END Text1;<br><br><br> MODULE Text2; (*another implementation of the Text protocol*)<br> IMPORT TextProtocol;<br> TYPE Text = POINTER TO TextDesc;<br> TextDesc = RECORD (TextProtocol.TextDesc) END ; (*this means: “implements TextProtocol.TextDesc"*)<br><br> PROCEDURE (t: Text) Insert (string: ARRAY OF CHAR; pos: LONGINT);<br> BEGIN (*implementation of Insert*)<br> END Insert;<br><br> PROCEDURE (t: Text) Delete (from, to: LONGINT);<br> BEGIN (*implementation of Delete*)<br> END Delete;<br><br> PROCEDURE (t: Text) Length (): LONGINT;<br> BEGIN (*implementation of Length*)<br> END Insert;<br> END Text2;<br><br><br>[*] <a href="https://docs.swift.org/swift-book/LanguageGuide/Protocols.html" target="_blank">https://docs.swift.org/swift-book/LanguageGuide/Protocols.html#</a><br>[**] <a href="https://github.com/io-core/technotes/blob/main/technote014.md" target="_blank">https://github.com/io-core/technotes/blob/main/technote014.md</a><br><br>--<br><a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">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" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><u></u><u></u></p></blockquote></div><p class="MsoNormal">--<br><a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">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" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><u></u><u></u></p></blockquote></div></blockquote></div><p class="MsoNormal">-- <a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a> <u></u><u></u></p></div></div>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">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/mailman/listinfo/oberon</a><br>
</blockquote></div>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">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/mailman/listinfo/oberon</a><br>
</blockquote></div>