[Oberon] Oberon Digest, Vol 148, Issue 17
Søren Renner
soren.renner at gmail.com
Wed Sep 28 13:45:30 CEST 2016
> 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".
>
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:
PROCEDURE VoxelFromName*(modname: Name): Voxel;
> VAR voxel: Voxel; fackery: VoxelFackery;
> BEGIN
> IF modname[0]='N' THEN
> *GETPROCEDURE(modname, "thisvox", fackery );*
> IF (fackery # NIL) THEN
> voxel := fackery();
> END;
> IF voxel=NIL THEN
> Out.String("failed voxelfromname 1");
> voxel:=EMPTY
> ELSE
> voxel.code:=modname;
> END;
> ELSE
> Out.String("failed voxelfromname 2");
> voxel:=EMPTY
> END;
> RETURN voxel
> END VoxelFromName;
GETPROCEDURE was added to Active Oberon and documented in a brief release
note which I happened to read.
On Tue, Sep 27, 2016 at 6:00 AM, <oberon-request at lists.inf.ethz.ch> wrote:
> Send Oberon mailing list submissions to
> oberon at lists.inf.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> oberon-request at lists.inf.ethz.ch
>
> You can reach the person managing the list at
> oberon-owner at lists.inf.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
>
>
> Today's Topics:
>
> 1. Re: Oberon for a C++ user. (Srinivas Nayak)
> 2. Re: Elegance and simplicity (Brian Clausing)
> 3. Re: Oberon for a C++ user. (J?rg)
> 4. Re: Oberon for a C++ user. (Lars)
> 5. Re: Oberon for a C++ user. (Skulski, Wojciech)
> 6. Re: Oberon for a C++ user. (J?rg Straube)
> 7. Re: Oberon for a C++ user. (Skulski, Wojciech)
> 8. Re: Oberon for a C++ user. (Joerg)
> 9. Re: Oberon for a C++ user. (J?rg Straube)
> 10. Re: Oberon for a C++ user. (Joerg)
> 11. Re: Oberon for a C++ user. (Felix Friedrich)
> 12. Re: Oberon for a C++ user. (J?rg Straube)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Sep 2016 14:31:18 +0530
> From: Srinivas Nayak <sinu.nayak2001 at gmail.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <57E8E3DE.3030504 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> >> - Modules can be seen as car manufacturer.
> >> - Objects are the cars.
>
> > The program (Oberon System) is the car manufacturer.
> > There is only a single car manufacturer per city (a single OS per FPGA).
> > 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.
> > 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).
>
> This is nice analogy.
> But why stop here? Lets finish the whole story.
> A factory can be closed or open. But two factories of same name can't
> exist. (Module loading unloading)
> 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)
>
> How shall we think about module exposing parts of a record?
> Is it like, some parts of a car specification being patented by factories
> and made public, but not others.
>
>
> With thanks and best regards,
>
> Yours sincerely,
> Srinivas Nayak
>
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Sep 2016 09:09:37 -0400
> From: Brian Clausing <brianclausing at earthlink.net>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Elegance and simplicity
> Message-ID: <66a4afb8-7eb1-46d7-fb4b-6c87bf9a7fa3 at earthlink.net>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Please excuse any error in sending this submission; it's my first time.
>
> May I recommend "The Search for Simplicity" by Per Brinch Hansen, the
> Diamond Cutter, another grandmaster analyst and programmer.
>
> Brian Clausing
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Sep 2016 16:37:03 +0200
> From: J?rg <joerg.straube at iaeth.ch>
> To: "'ETH Oberon and related systems'" <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <004b01d21803$73481cc0$59d85640$@iaeth.ch>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Examples that pop to my mind:
> - The tires of a car could be used by another car
> - The fuel tank can be filled by others
> - The arm rest can't be reused as its dimensions are too specific to the
> car
> - the glass roof can't be reused as it too specific
>
> br
> J?rg
>
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Srinivas
> Nayak
> Sent: Montag, 26. September 2016 11:01
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
>
>
> >> - Modules can be seen as car manufacturer.
> >> - Objects are the cars.
>
> > The program (Oberon System) is the car manufacturer.
> > There is only a single car manufacturer per city (a single OS per FPGA).
> > 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.
> > 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).
>
> This is nice analogy.
> But why stop here? Lets finish the whole story.
> A factory can be closed or open. But two factories of same name can't
> exist.
> (Module loading unloading)
> 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)
>
> How shall we think about module exposing parts of a record?
> Is it like, some parts of a car specification being patented by factories
> and made public, but not others.
>
>
> With thanks and best regards,
>
> Yours sincerely,
> Srinivas Nayak
>
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 Sep 2016 22:46:29 -0600
> From: "Lars" <noreply at z505.com>
> To: "ETH Oberon and related systems" <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID:
> <730deb80e30fa4d10ba29ba2c5538a20.squirrel at gator3286.hostgator.com
> >
> Content-Type: text/plain;charset=iso-8859-1
>
> On Thu, September 22, 2016 10:52 pm, J??rg Straube wrote:
> > Lars
> >
> >
> > Dynamic vs static is perhaps not the best distinction of modules vs
> > objects. I try to make an analogon.
> > - Modules can be seen as car manufacturer.
> > - Objects are the cars.
>
> As you know, I'm no fan of Analogies, like Dijkstra, however I sin and use
> them myself sometimes.
>
> A class, can be defined at design time like a module..but once the class
> created (memory allocated on heap) it becomes an object (object is an
> instance of class? according to Date and Darwen in Third Manifesto). So a
> class definition, is very similar to a module definition (module file),
> except one cannot dynamically create modules at run time. One may be able
> to dynamically load a module in an oberon system, which is interesting,
> but still not the same as allocating memory in a program on the heap for
> one.
>
> Why even refer to analogies when one can describe exactly what a module is
> and what it isn't:
>
> What is is not: an item that can be allocated at run time, it is only
> typed out as a definition at design time. That's what I meant by static
> because the module is not dynamically created on the heap.
>
> A class is like a static definition of an object, where the object can be
> dynamically created (allocated) at run time. An object that is on the
> stack is still allocated, just when the program begins. When is a module
> ever allocated? It's compiled, but not so much allocated..
>
> Again why use analogies when we can talk directly about what an object is,
> and what it is not, and what a module is, and what it is not...
>
> Time to sin:
> A car manufacturer has definitions (drawings) of the car. This is like an
> object definition at the top of the source file (class). Once the factory
> produces the car (object) from the design (class) papers, a new instance
> of the car is allocated (steel is taken from the earth, along with
> plastics and foam for seats).
>
> F*ck analogies! But that's as close as I can think of one... a class
> definition is very similar to the drawings with all the restrictions,
> specifications of the car. A module is similar to a class definition but
> instead of creating a module on the heap at run time, the module is
> compiled and generates a design time unit to be used by the programmer.
>
> 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? 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.
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 27 Sep 2016 05:14:15 +0000
> From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID:
> <CY1PR07MB22130D4264859B12E6ACCD2CFFCC0 at CY1PR07MB2213.
> namprd07.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 27 Sep 2016 07:29:06 +0200
> From: J?rg Straube <joerg.straube at iaeth.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <B76A2A0E-A201-480C-8313-57FC61A01DB1 at iaeth.ch>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 27 Sep 2016 05:44:31 +0000
> From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID:
> <CY1PR07MB22132CC5D35A12910F50C1FAFFCC0 at CY1PR07MB2213.
> namprd07.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> > Actually Oberon modules ARE allocated on the heap. This is the beauty of
> Oberon that you can load and unload them dynamically.
>
> Yes, but only a single copy. Duplication of the same code makes no sense.
> In that sense modules are different from objects.
>
> BTW, how about safety of unloading the code? In BlackBox they do not
> unload, they deactivate. How about the Oberon System?
>
> W.
>
> 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://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=pyCxw3iKYPlDKPXz87aWroZImdqWNC
> DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> 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=pyCxw3iKYPlDKPXz87aWroZImdqWNC
> DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 27 Sep 2016 08:27:57 +0200
> From: Joerg <joerg.straube at iaeth.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <3C72AA96-539F-4DB0-A558-FCB3BC933BB7 at iaeth.ch>
> Content-Type: text/plain; charset=utf-8
>
> Wojtek
>
> 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.
>
> J?rg
> > Am 27.09.2016 um 07:44 schrieb Skulski, Wojciech <
> skulski at pas.rochester.edu>:
> >
> >> Actually Oberon modules ARE allocated on the heap. This is the beauty
> of Oberon that you can load and unload them dynamically.
> >
> > Yes, but only a single copy. Duplication of the same code makes no
> sense. In that sense modules are different from objects.
> >
> > BTW, how about safety of unloading the code? In BlackBox they do not
> unload, they deactivate. How about the Oberon System?
> >
> > W.
> >
> > 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://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=pyCxw3iKYPlDKPXz87aWroZImdqWNC
> DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > 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=pyCxw3iKYPlDKPXz87aWroZImdqWNC
> DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 27 Sep 2016 07:45:59 +0200
> From: J?rg Straube <joerg.straube at iaeth.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <953EB47C-DD0F-473C-B6F5-371E5E403A2D at iaeth.ch>
> Content-Type: text/plain; charset="utf-8"
>
> 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/87873760/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 27 Sep 2016 08:23:29 +0200
> From: Joerg <joerg.straube at iaeth.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <9EF5E6B3-6ECD-4ECE-B6D9-3F3B3D8FB4E2 at iaeth.ch>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <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
> <mailto: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 <mailto: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 <mailto:Oberon at lists.inf.ethz.ch> mailing
> list for ETH Oberon and related systems
> >>> https://lists.inf.ethz.ch/mailman/listinfo/oberon <
> https://lists.inf.ethz.ch/mailman/listinfo/oberon>
> >>
> >> --
> >> Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch> mailing
> list for ETH Oberon and related systems
> >> https://lists.inf.ethz.ch/mailman/listinfo/oberon <
> 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/87b0b726/attachment-0001.html>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 27 Sep 2016 08:54:15 +0200
> From: Felix Friedrich <felix.friedrich at inf.ethz.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <05dd7d5f-8c3f-e512-d7e2-6378ba52ed2c at inf.ethz.ch>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> Hi J?rg
>
> That is correct. At the same time it does not solve all problems. If you
> have any other reference to the code of a module, for example via some
> procedure variable, the code can crash or, even worse, provide some
> other unexpected behavior.
>
> For this reason I consider the unloading of modules a very useful
> feature for a software development phase. I would rather not use it as a
> feature of some product in the field.
>
> Felix
>
>
> > Wojtek
> >
> > 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.
> >
> > J?rg
> >> Am 27.09.2016 um 07:44 schrieb Skulski, Wojciech <
> skulski at pas.rochester.edu>:
> >>
> >>> Actually Oberon modules ARE allocated on the heap. This is the beauty
> of Oberon that you can load and unload them dynamically.
> >> Yes, but only a single copy. Duplication of the same code makes no
> sense. In that sense modules are different from objects.
> >>
> >> BTW, how about safety of unloading the code? In BlackBox they do not
> unload, they deactivate. How about the Oberon System?
> >>
> >> W.
> >>
> >> 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://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=pyCxw3iKYPlDKPXz87aWroZImdqWNC
> DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
> >> --
> >> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems
> >> 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=pyCxw3iKYPlDKPXz87aWroZImdqWNC
> DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
> >> --
> >> 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
>
>
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 27 Sep 2016 08:42:03 +0200
> From: J?rg Straube <joerg.straube at iaeth.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Oberon for a C++ user.
> Message-ID: <A94D7AA2-89F9-4181-84BD-FB8581C1DEEE at iaeth.ch>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> ------------------------------
>
> End of Oberon Digest, Vol 148, Issue 17
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160928/a21429b6/attachment-0001.html>
More information about the Oberon
mailing list