[Oberon] Oberon for a C++ user.

[Jörg Straube]

Lars

When I'm talking of dynamically generated code, I remember a nice little exercise we had to solve at university:
   "Write a program that prints itself"

Try it. It's trickier than it sounds :-)

Jörg

> Am 27.09.2016 um 08:23 schrieb Joerg <joerg.straube at iaeth.ch>:
> 
> Hi Lars
> 
> I want to come back to your distinction of dynamic vs. static.
> I guess you mean by dynamic „at run time“ and by static „at design time“.
> 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.
> So, it is possible to generate even totally new modules "at run time".
> 
> When a code produces code this can be seen as kind of "Artificial Intelligence“  It’s not easy but doable.
> 
> br
> Jörg
> 
>> Am 27.09.2016 um 07:45 schrieb Jörg Straube <joerg.straube at iaeth.ch>:
>> 
>> Lars
>> 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 https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf
>> Jörg
>> 
>> Am 27.09.2016 um 07:29 schrieb Jörg Straube <joerg.straube at iaeth.ch>:
>> 
>>> Lars
>>> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.
>>> Jörg
>>> 
>>>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>>>> 
>>>> Lars:
>>>> 
>>>>> An interesting thought: if one were to make a module allocated at run time
>>>>> would this offer anything useful or different than an object being
>>>>> allocated? 
>>>> 
>>>> 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.
>>>> 
>>>>> Or would we reinvent object oriented programming if modules
>>>>> could be allocated on the heap?  If we just reinvented objects, now we
>>>>> know exactly what modules are: design time objects without any heap
>>>>> allocation at run time.
>>>> 
>>>> 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.
>>>> 
>>>> W.
>>>> --
>>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>> 
>>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160927/e18aeebe/attachment.html>