<div dir="ltr">I found the strategy for generics interesting and approachable with the specialization occurring over a module as a whole and the selection occurring on module import.<div><br></div><div>If generic modules are not compiled on their own but are only compiled (with an .rsc file generated just for that concrete type) when the module that imports it is compiled, then the combinatorial explosion of generated code can be limited to just those types actually used. If the generic module was already coerced to be compiled for that type by a different importing module (or the same one previously,) and the .smb files are compatible then it doesn't have to be compiled again.</div><div><br></div><div>It seems to me to be in the spirit of Oberon -- as simple as possible but no simpler.</div><div><br></div><div>Chuck</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 16, 2021 at 9:03 AM Liam Proven <<a href="mailto:lproven@gmail.com">lproven@gmail.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="auto"><a href="https://oberon-lang.github.io/" target="_blank">https://oberon-lang.github.io/</a><br><br><div>-- <br>Sent from my smartphone. Please pardon brevity & typos.</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>