<div dir="ltr"><span style="font-size:12.8px">> 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.</span><br style="font-size:12.8px"><span style="font-size:12.8px">> So, it is possible to generate even totally new modules "at run time".</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Yes. Here is code that loads a PROCEDURE from a module that is never imported and so may have been compiled since the main program (a realtime raytracer) was running:</span></div><div><div><span style="font-size:12.8px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">PROCEDURE VoxelFromName*(modname: Name): Voxel;<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>VAR voxel: Voxel; fackery: VoxelFackery;<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>BEGIN<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>IF modname[0]='N' THEN<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span><b>GETPROCEDURE(modname, "thisvox", fackery );</b><br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>IF (fackery # NIL) THEN <br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>voxel := fackery();<span class="gmail-Apple-tab-span" style="white-space:pre"> </span> <br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>END;<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>IF voxel=NIL THEN <br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Out.String("failed voxelfromname 1");<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>voxel:=EMPTY<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ELSE<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>voxel.code:=modname;<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>END;<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ELSE<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Out.String("failed voxelfromname 2");<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>voxel:=EMPTY<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>END;<br></span><span style="font-size:12.8px"><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>RETURN voxel<br></span><span style="font-size:12.8px">END VoxelFromName;</span></blockquote><div><br></div><div>GETPROCEDURE was added to Active Oberon and documented in a brief release note which I happened to read. </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 6:00 AM, <span dir="ltr"><<a href="mailto:oberon-request@lists.inf.ethz.ch" target="_blank">oberon-request@lists.inf.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Oberon mailing list submissions to<br>
<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<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>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.ethz.<wbr>ch</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:oberon-owner@lists.inf.ethz.ch">oberon-owner@lists.inf.ethz.ch</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Oberon digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Oberon for a C++ user. (Srinivas Nayak)<br>
2. Re: Elegance and simplicity (Brian Clausing)<br>
3. Re: Oberon for a C++ user. (J?rg)<br>
4. Re: Oberon for a C++ user. (Lars)<br>
5. Re: Oberon for a C++ user. (Skulski, Wojciech)<br>
6. Re: Oberon for a C++ user. (J?rg Straube)<br>
7. Re: Oberon for a C++ user. (Skulski, Wojciech)<br>
8. Re: Oberon for a C++ user. (Joerg)<br>
9. Re: Oberon for a C++ user. (J?rg Straube)<br>
10. Re: Oberon for a C++ user. (Joerg)<br>
11. Re: Oberon for a C++ user. (Felix Friedrich)<br>
12. Re: Oberon for a C++ user. (J?rg Straube)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Mon, 26 Sep 2016 14:31:18 +0530<br>
From: Srinivas Nayak <<a href="mailto:sinu.nayak2001@gmail.com">sinu.nayak2001@gmail.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:57E8E3DE.3030504@gmail.com">57E8E3DE.3030504@gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
<br>
>> - Modules can be seen as car manufacturer.<br>
>> - Objects are the cars.<br>
<br>
> The program (Oberon System) is the car manufacturer.<br>
> There is only a single car manufacturer per city (a single OS per FPGA).<br>
> Modules are car factories. There are several factories in the city: Ford Escort, Ford Whatever, etc. All factories are run by the same car manufacturer.<br>
> Objects are cars of different sorts manufactured by the car factories. Each factory can manufacture and release an unlimited number of cars, bounded only by the size of the parking lot (the size of the dynamic memory).<br>
<br>
This is nice analogy.<br>
But why stop here? Lets finish the whole story.<br>
A factory can be closed or open. But two factories of same name can't exist. (Module loading unloading)<br>
Car specification (a record) is unique to manufacturer. Two factories generally won't produce cars with same specification. But they can ask other factories when they want. (importing of module)<br>
<br>
How shall we think about module exposing parts of a record?<br>
Is it like, some parts of a car specification being patented by factories and made public, but not others.<br>
<br>
<br>
With thanks and best regards,<br>
<br>
Yours sincerely,<br>
Srinivas Nayak<br>
<br>
Home: <a href="http://www.mathmeth.com/sn/" rel="noreferrer" target="_blank">http://www.mathmeth.com/sn/</a><br>
Blog: <a href="http://srinivas-nayak.blogspot.in/" rel="noreferrer" target="_blank">http://srinivas-nayak.<wbr>blogspot.in/</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 26 Sep 2016 09:09:37 -0400<br>
From: Brian Clausing <<a href="mailto:brianclausing@earthlink.net">brianclausing@earthlink.net</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] Elegance and simplicity<br>
Message-ID: <<a href="mailto:66a4afb8-7eb1-46d7-fb4b-6c87bf9a7fa3@earthlink.net">66a4afb8-7eb1-46d7-fb4b-<wbr>6c87bf9a7fa3@earthlink.net</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Please excuse any error in sending this submission; it's my first time.<br>
<br>
May I recommend "The Search for Simplicity" by Per Brinch Hansen, the<br>
Diamond Cutter, another grandmaster analyst and programmer.<br>
<br>
Brian Clausing<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 26 Sep 2016 16:37:03 +0200<br>
From: J?rg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: "'ETH Oberon and related systems'" <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <004b01d21803$73481cc0$<wbr>59d85640$@<a href="http://iaeth.ch" rel="noreferrer" target="_blank">iaeth.ch</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Examples that pop to my mind:<br>
- The tires of a car could be used by another car<br>
- The fuel tank can be filled by others<br>
- The arm rest can't be reused as its dimensions are too specific to the car<br>
- the glass roof can't be reused as it too specific<br>
<br>
br<br>
J?rg<br>
<br>
-----Original Message-----<br>
From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.<wbr>inf.ethz.ch</a>] On Behalf Of Srinivas<br>
Nayak<br>
Sent: Montag, 26. September 2016 11:01<br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
<br>
<br>
>> - Modules can be seen as car manufacturer.<br>
>> - Objects are the cars.<br>
<br>
> The program (Oberon System) is the car manufacturer.<br>
> There is only a single car manufacturer per city (a single OS per FPGA).<br>
> Modules are car factories. There are several factories in the city: Ford<br>
Escort, Ford Whatever, etc. All factories are run by the same car<br>
manufacturer.<br>
> Objects are cars of different sorts manufactured by the car factories.<br>
Each factory can manufacture and release an unlimited number of cars,<br>
bounded only by the size of the parking lot (the size of the dynamic<br>
memory).<br>
<br>
This is nice analogy.<br>
But why stop here? Lets finish the whole story.<br>
A factory can be closed or open. But two factories of same name can't exist.<br>
(Module loading unloading)<br>
Car specification (a record) is unique to manufacturer. Two factories<br>
generally won't produce cars with same specification. But they can ask other<br>
factories when they want. (importing of module)<br>
<br>
How shall we think about module exposing parts of a record?<br>
Is it like, some parts of a car specification being patented by factories<br>
and made public, but not others.<br>
<br>
<br>
With thanks and best regards,<br>
<br>
Yours sincerely,<br>
Srinivas Nayak<br>
<br>
Home: <a href="http://www.mathmeth.com/sn/" rel="noreferrer" target="_blank">http://www.mathmeth.com/sn/</a><br>
Blog: <a href="http://srinivas-nayak.blogspot.in/" rel="noreferrer" target="_blank">http://srinivas-nayak.<wbr>blogspot.in/</a><br>
<br>
<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>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 26 Sep 2016 22:46:29 -0600<br>
From: "Lars" <<a href="mailto:noreply@z505.com">noreply@z505.com</a>><br>
To: "ETH Oberon and related systems" <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID:<br>
<<a href="mailto:730deb80e30fa4d10ba29ba2c5538a20.squirrel@gator3286.hostgator.com">730deb80e30fa4d10ba29ba2c5538<wbr>a20.squirrel@gator3286.<wbr>hostgator.com</a>><br>
Content-Type: text/plain;charset=iso-8859-1<br>
<br>
On Thu, September 22, 2016 10:52 pm, J??rg Straube wrote:<br>
> Lars<br>
><br>
><br>
> Dynamic vs static is perhaps not the best distinction of modules vs<br>
> objects. I try to make an analogon.<br>
> - Modules can be seen as car manufacturer.<br>
> - Objects are the cars.<br>
<br>
As you know, I'm no fan of Analogies, like Dijkstra, however I sin and use<br>
them myself sometimes.<br>
<br>
A class, can be defined at design time like a module..but once the class<br>
created (memory allocated on heap) it becomes an object (object is an<br>
instance of class? according to Date and Darwen in Third Manifesto). So a<br>
class definition, is very similar to a module definition (module file),<br>
except one cannot dynamically create modules at run time. One may be able<br>
to dynamically load a module in an oberon system, which is interesting,<br>
but still not the same as allocating memory in a program on the heap for<br>
one.<br>
<br>
Why even refer to analogies when one can describe exactly what a module is<br>
and what it isn't:<br>
<br>
What is is not: an item that can be allocated at run time, it is only<br>
typed out as a definition at design time. That's what I meant by static<br>
because the module is not dynamically created on the heap.<br>
<br>
A class is like a static definition of an object, where the object can be<br>
dynamically created (allocated) at run time. An object that is on the<br>
stack is still allocated, just when the program begins. When is a module<br>
ever allocated? It's compiled, but not so much allocated..<br>
<br>
Again why use analogies when we can talk directly about what an object is,<br>
and what it is not, and what a module is, and what it is not...<br>
<br>
Time to sin:<br>
A car manufacturer has definitions (drawings) of the car. This is like an<br>
object definition at the top of the source file (class). Once the factory<br>
produces the car (object) from the design (class) papers, a new instance<br>
of the car is allocated (steel is taken from the earth, along with<br>
plastics and foam for seats).<br>
<br>
F*ck analogies! But that's as close as I can think of one... a class<br>
definition is very similar to the drawings with all the restrictions,<br>
specifications of the car. A module is similar to a class definition but<br>
instead of creating a module on the heap at run time, the module is<br>
compiled and generates a design time unit to be used by the programmer.<br>
<br>
An interesting thought: if one were to make a module allocated at run time<br>
would this offer anything useful or different than an object being<br>
allocated? Or would we reinvent object oriented programming if modules<br>
could be allocated on the heap? If we just reinvented objects, now we<br>
know exactly what modules are: design time objects without any heap<br>
allocation at run time.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 27 Sep 2016 05:14:15 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID:<br>
<<a href="mailto:CY1PR07MB22130D4264859B12E6ACCD2CFFCC0@CY1PR07MB2213.namprd07.prod.outlook.com">CY1PR07MB22130D4264859B12E6AC<wbr>CD2CFFCC0@CY1PR07MB2213.<wbr>namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Lars:<br>
<br>
>An interesting thought: if one were to make a module allocated at run time<br>
>would this offer anything useful or different than an object being<br>
>allocated?<br>
<br>
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.<br>
<br>
>Or would we reinvent object oriented programming if modules<br>
>could be allocated on the heap? If we just reinvented objects, now we<br>
>know exactly what modules are: design time objects without any heap<br>
>allocation at run time.<br>
<br>
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.<br>
<br>
W.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 27 Sep 2016 07:29:06 +0200<br>
From: J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:B76A2A0E-A201-480C-8313-57FC61A01DB1@iaeth.ch">B76A2A0E-A201-480C-8313-<wbr>57FC61A01DB1@iaeth.ch</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Lars<br>
Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
J?rg<br>
<br>
> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
><br>
> Lars:<br>
><br>
>> An interesting thought: if one were to make a module allocated at run time<br>
>> would this offer anything useful or different than an object being<br>
>> allocated?<br>
><br>
> 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.<br>
><br>
>> Or would we reinvent object oriented programming if modules<br>
>> could be allocated on the heap? If we just reinvented objects, now we<br>
>> know exactly what modules are: design time objects without any heap<br>
>> allocation at run time.<br>
><br>
> 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.<br>
><br>
> W.<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>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 27 Sep 2016 05:44:31 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID:<br>
<<a href="mailto:CY1PR07MB22132CC5D35A12910F50C1FAFFCC0@CY1PR07MB2213.namprd07.prod.outlook.com">CY1PR07MB22132CC5D35A12910F50<wbr>C1FAFFCC0@CY1PR07MB2213.<wbr>namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
<br>
Yes, but only a single copy. Duplication of the same code makes no sense. In that sense modules are different from objects.<br>
<br>
BTW, how about safety of unloading the code? In BlackBox they do not unload, they deactivate. How about the Oberon System?<br>
<br>
W.<br>
<br>
J?rg<br>
<br>
> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
><br>
> Lars:<br>
><br>
>> An interesting thought: if one were to make a module allocated at run time<br>
>> would this offer anything useful or different than an object being<br>
>> allocated?<br>
><br>
> 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.<br>
><br>
>> Or would we reinvent object oriented programming if modules<br>
>> could be allocated on the heap? If we just reinvented objects, now we<br>
>> know exactly what modules are: design time objects without any heap<br>
>> allocation at run time.<br>
><br>
> 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.<br>
><br>
> W.<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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=CwIGaQ&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>pyCxw3iKYPlDKPXz87aWroZImdqWNC<wbr>DNXUGMfb31jAU&s=<wbr>TlEt17qNWyHP1HTG1paIrYBeocYUeg<wbr>pYyFZqjQLIzRM&e=</a><br>
<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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=CwIGaQ&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>pyCxw3iKYPlDKPXz87aWroZImdqWNC<wbr>DNXUGMfb31jAU&s=<wbr>TlEt17qNWyHP1HTG1paIrYBeocYUeg<wbr>pYyFZqjQLIzRM&e=</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 27 Sep 2016 08:27:57 +0200<br>
From: Joerg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:3C72AA96-539F-4DB0-A558-FCB3BC933BB7@iaeth.ch">3C72AA96-539F-4DB0-A558-<wbr>FCB3BC933BB7@iaeth.ch</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Wojtek<br>
<br>
Every module has a counter where it registers how many times it got imported. As long there is a module X importing module Y you cannot unload module Y. You first have to unload module X, the counter of Y is decremented and when it is 0 you can unload Y.<br>
<br>
J?rg<br>
> Am 27.09.2016 um 07:44 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
><br>
>> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
><br>
> Yes, but only a single copy. Duplication of the same code makes no sense. In that sense modules are different from objects.<br>
><br>
> BTW, how about safety of unloading the code? In BlackBox they do not unload, they deactivate. How about the Oberon System?<br>
><br>
> W.<br>
><br>
> J?rg<br>
><br>
>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
>><br>
>> Lars:<br>
>><br>
>>> An interesting thought: if one were to make a module allocated at run time<br>
>>> would this offer anything useful or different than an object being<br>
>>> allocated?<br>
>><br>
>> 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.<br>
>><br>
>>> Or would we reinvent object oriented programming if modules<br>
>>> could be allocated on the heap? If we just reinvented objects, now we<br>
>>> know exactly what modules are: design time objects without any heap<br>
>>> allocation at run time.<br>
>><br>
>> 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.<br>
>><br>
>> W.<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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=CwIGaQ&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>pyCxw3iKYPlDKPXz87aWroZImdqWNC<wbr>DNXUGMfb31jAU&s=<wbr>TlEt17qNWyHP1HTG1paIrYBeocYUeg<wbr>pYyFZqjQLIzRM&e=</a><br>
><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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=CwIGaQ&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>pyCxw3iKYPlDKPXz87aWroZImdqWNC<wbr>DNXUGMfb31jAU&s=<wbr>TlEt17qNWyHP1HTG1paIrYBeocYUeg<wbr>pYyFZqjQLIzRM&e=</a><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>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 27 Sep 2016 07:45:59 +0200<br>
From: J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:953EB47C-DD0F-473C-B6F5-371E5E403A2D@iaeth.ch">953EB47C-DD0F-473C-B6F5-<wbr>371E5E403A2D@iaeth.ch</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Lars<br>
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" rel="noreferrer" target="_blank">https://www.inf.ethz.ch/<wbr>personal/wirth/ProjectOberon/<wbr>PO.System.pdf</a><br>
J?rg<br>
<br>
> Am 27.09.2016 um 07:29 schrieb J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br>
><br>
> Lars<br>
> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
> J?rg<br>
><br>
>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
>><br>
>> Lars:<br>
>><br>
>>> An interesting thought: if one were to make a module allocated at run time<br>
>>> would this offer anything useful or different than an object being<br>
>>> allocated?<br>
>><br>
>> 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.<br>
>><br>
>>> Or would we reinvent object oriented programming if modules<br>
>>> could be allocated on the heap? If we just reinvented objects, now we<br>
>>> know exactly what modules are: design time objects without any heap<br>
>>> allocation at run time.<br>
>><br>
>> 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.<br>
>><br>
>> W.<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>
> --<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160927/87873760/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20160927/87873760/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 27 Sep 2016 08:23:29 +0200<br>
From: Joerg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:9EF5E6B3-6ECD-4ECE-B6D9-3F3B3D8FB4E2@iaeth.ch">9EF5E6B3-6ECD-4ECE-B6D9-<wbr>3F3B3D8FB4E2@iaeth.ch</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Lars<br>
<br>
I want to come back to your distinction of dynamic vs. static.<br>
I guess you mean by dynamic ?at run time? and by static ?at design time?.<br>
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.<br>
So, it is possible to generate even totally new modules "at run time".<br>
<br>
When a code produces code this can be seen as kind of "Artificial Intelligence? It?s not easy but doable.<br>
<br>
br<br>
J?rg<br>
<br>
> Am 27.09.2016 um 07:45 schrieb J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br>
><br>
> Lars<br>
> 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" rel="noreferrer" target="_blank">https://www.inf.ethz.ch/<wbr>personal/wirth/ProjectOberon/<wbr>PO.System.pdf</a> <<a href="https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf" rel="noreferrer" target="_blank">https://www.inf.ethz.ch/<wbr>personal/wirth/ProjectOberon/<wbr>PO.System.pdf</a>><br>
> J?rg<br>
><br>
> Am 27.09.2016 um 07:29 schrieb J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a> <mailto:<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a><wbr>>>:<br>
><br>
>> Lars<br>
>> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
>> J?rg<br>
>><br>
>>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a> <mailto:<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.<wbr>edu</a>>>:<br>
>>><br>
>>> Lars:<br>
>>><br>
>>>> An interesting thought: if one were to make a module allocated at run time<br>
>>>> would this offer anything useful or different than an object being<br>
>>>> allocated?<br>
>>><br>
>>> 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.<br>
>>><br>
>>>> Or would we reinvent object oriented programming if modules<br>
>>>> could be allocated on the heap? If we just reinvented objects, now we<br>
>>>> know exactly what modules are: design time objects without any heap<br>
>>>> allocation at run time.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> W.<br>
>>> --<br>
>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> <mailto:<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.<wbr>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> <<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>
>> --<br>
>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> <mailto:<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.<wbr>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> <<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160927/87b0b726/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20160927/87b0b726/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 27 Sep 2016 08:54:15 +0200<br>
From: Felix Friedrich <<a href="mailto:felix.friedrich@inf.ethz.ch">felix.friedrich@inf.ethz.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:05dd7d5f-8c3f-e512-d7e2-6378ba52ed2c@inf.ethz.ch">05dd7d5f-8c3f-e512-d7e2-<wbr>6378ba52ed2c@inf.ethz.ch</a>><br>
Content-Type: text/plain; charset="utf-8"; format=flowed<br>
<br>
Hi J?rg<br>
<br>
That is correct. At the same time it does not solve all problems. If you<br>
have any other reference to the code of a module, for example via some<br>
procedure variable, the code can crash or, even worse, provide some<br>
other unexpected behavior.<br>
<br>
For this reason I consider the unloading of modules a very useful<br>
feature for a software development phase. I would rather not use it as a<br>
feature of some product in the field.<br>
<br>
Felix<br>
<br>
<br>
> Wojtek<br>
><br>
> Every module has a counter where it registers how many times it got imported. As long there is a module X importing module Y you cannot unload module Y. You first have to unload module X, the counter of Y is decremented and when it is 0 you can unload Y.<br>
><br>
> J?rg<br>
>> Am 27.09.2016 um 07:44 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
>><br>
>>> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
>> Yes, but only a single copy. Duplication of the same code makes no sense. In that sense modules are different from objects.<br>
>><br>
>> BTW, how about safety of unloading the code? In BlackBox they do not unload, they deactivate. How about the Oberon System?<br>
>><br>
>> W.<br>
>><br>
>> J?rg<br>
>><br>
>>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
>>><br>
>>> Lars:<br>
>>><br>
>>>> An interesting thought: if one were to make a module allocated at run time<br>
>>>> would this offer anything useful or different than an object being<br>
>>>> allocated?<br>
>>> 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.<br>
>>><br>
>>>> Or would we reinvent object oriented programming if modules<br>
>>>> could be allocated on the heap? If we just reinvented objects, now we<br>
>>>> know exactly what modules are: design time objects without any heap<br>
>>>> allocation at run time.<br>
>>> 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.<br>
>>><br>
>>> W.<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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=CwIGaQ&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>pyCxw3iKYPlDKPXz87aWroZImdqWNC<wbr>DNXUGMfb31jAU&s=<wbr>TlEt17qNWyHP1HTG1paIrYBeocYUeg<wbr>pYyFZqjQLIzRM&e=</a><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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=CwIGaQ&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>pyCxw3iKYPlDKPXz87aWroZImdqWNC<wbr>DNXUGMfb31jAU&s=<wbr>TlEt17qNWyHP1HTG1paIrYBeocYUeg<wbr>pYyFZqjQLIzRM&e=</a><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>
> <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>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Tue, 27 Sep 2016 08:42:03 +0200<br>
From: J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon for a C++ user.<br>
Message-ID: <<a href="mailto:A94D7AA2-89F9-4181-84BD-FB8581C1DEEE@iaeth.ch">A94D7AA2-89F9-4181-84BD-<wbr>FB8581C1DEEE@iaeth.ch</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Lars<br>
<br>
When I'm talking of dynamically generated code, I remember a nice little exercise we had to solve at university:<br>
"Write a program that prints itself"<br>
<br>
Try it. It's trickier than it sounds :-)<br>
<br>
J?rg<br>
<br>
> Am 27.09.2016 um 08:23 schrieb Joerg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br>
><br>
> Hi Lars<br>
><br>
> I want to come back to your distinction of dynamic vs. static.<br>
> I guess you mean by dynamic ?at run time? and by static ?at design time?.<br>
> 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.<br>
> So, it is possible to generate even totally new modules "at run time".<br>
><br>
> When a code produces code this can be seen as kind of "Artificial Intelligence? It?s not easy but doable.<br>
><br>
> br<br>
> J?rg<br>
><br>
>> Am 27.09.2016 um 07:45 schrieb J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br>
>><br>
>> Lars<br>
>> 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" rel="noreferrer" target="_blank">https://www.inf.ethz.ch/<wbr>personal/wirth/ProjectOberon/<wbr>PO.System.pdf</a><br>
>> J?rg<br>
>><br>
>> Am 27.09.2016 um 07:29 schrieb J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br>
>><br>
>>> Lars<br>
>>> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.<br>
>>> J?rg<br>
>>><br>
>>>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
>>>><br>
>>>> Lars:<br>
>>>><br>
>>>>> An interesting thought: if one were to make a module allocated at run time<br>
>>>>> would this offer anything useful or different than an object being<br>
>>>>> allocated?<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>>> Or would we reinvent object oriented programming if modules<br>
>>>>> could be allocated on the heap? If we just reinvented objects, now we<br>
>>>>> know exactly what modules are: design time objects without any heap<br>
>>>>> allocation at run time.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> W.<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>
>>> --<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160927/e18aeebe/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20160927/e18aeebe/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<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>
<br>
------------------------------<br>
<br>
End of Oberon Digest, Vol 148, Issue 17<br>
******************************<wbr>*********<br>
</blockquote></div><br></div>