<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">Lars</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">When I'm talking of dynamically generated code, I remember a nice little exercise we had to solve at university:</div><div style="direction: inherit;"> "Write a program that prints itself"</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Try it. It's trickier than it sounds :-)</div><br>Jörg</div><div><br>Am 27.09.2016 um 08:23 schrieb Joerg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Hi Lars</div><div class=""><br class=""></div><div class="">I want to come back to your distinction of dynamic vs. static.</div><div class="">I guess you mean by dynamic „at run time“ and by static „at design time“.</div><div class="">There is a grey zone there. It is possible to generate at run time a text file, call at run time the compiler that compiles it, and load your dynamically generated code into memory and use that new program.</div><div class="">So, it is possible to generate even totally new modules "at run time".</div><div class=""><br class=""></div><div class="">When a code produces code this can be seen as kind of "Artificial Intelligence“ It’s not easy but doable.</div><div class=""><br class=""></div><div class="">br</div><div class="">Jörg<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 27.09.2016 um 07:45 schrieb Jörg Straube <<a href="mailto:joerg.straube@iaeth.ch" class="">joerg.straube@iaeth.ch</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><div style="direction: inherit;" class="">Lars</div><div style="direction: inherit;" class="">To be precise the Oberon sysem has two types of heaps: A heap for code and a heap for data. See Figure 8.1 in <a href="https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf" class="">https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf</a></div><div style="direction: inherit;" class="">Jörg</div></div><div class=""><div class=""><div style="direction: inherit;" class=""><br class=""></div></div>Am 27.09.2016 um 07:29 schrieb Jörg Straube <<a href="mailto:joerg.straube@iaeth.ch" class="">joerg.straube@iaeth.ch</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">Lars</span><br class=""><span class="">Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.</span><br class=""><span class="">Jörg</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu" class="">skulski@pas.rochester.edu</a>>:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Lars:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">An interesting thought: if one were to make a module allocated at run time</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">would this offer anything useful or different than an object being</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">allocated? </span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">A module provides executable code. There is only one copy of the module's code. An object provides data and pointers to the code, but it does not provide the actual code. There can be multiple copies of the object. Each copy can provide different data, but the same pointers to the same code. Note that in this description I have in mind Oberon-2 objects rather than Oberon-1 objects. Oberon-1 objects are more difficult to understand because the pointers to the code can be installed at run time. Note however, that Oberon-1 objects do not provide the code. Just the pointers.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Or would we reinvent object oriented programming if modules</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">could be allocated on the heap? If we just reinvented objects, now we</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">know exactly what modules are: design time objects without any heap</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">allocation at run time.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">You put the module on the heap with its code, because it is the module's goal to provide the code. OK. Now you need to execute that code from the heap. OK. You allocate another copy of the module on the heap. So you put the same executable code on the heap for the 2nd time. Now you can execute it. (If you cannot, then allocating the code would make no sense.) So now you have two copies of the same executable code on the heap. It makes little sense.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">W.</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">--</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:Oberon@lists.inf.ethz.ch" class="">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" class="">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br class=""></blockquote><span class=""></span><br class=""><span class="">--</span><br class=""><span class=""><a href="mailto:Oberon@lists.inf.ethz.ch" class="">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems</span><br class=""><span class=""><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" class="">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></blockquote></body></html>