[Oberon] FPGA - OberonV4 Dialogs
joerg.straube at iaeth.ch
Thu Nov 15 09:26:44 CET 2018
"Types.Mod" could be ported to ProjectOberon 2013 but there are other ways to do it.
Types.Mod is a module used for so called „Meta-programming“. Meta-programming is when one module treats or even modifies data structure of other modules. Not a thing you should normally do! There are some instances where it is useful. Eg module Modules.Mod loads arbitrary modules in memory, and module System.Mod inspects what modules are loaded or even unloads foreign modules from memory. All those low level things you need in an OS are called meta-programming.
Handling types that are not owned by you is possible with Types.Mod. Often this is used to load/store (=externalize) arbitrary data structures.
I prefer that every data structure that is meant to be externalized should offer its Load and Store procedures. This is a much cleaner way.
If you want to have a quite decent GUI for ProjectOberon 2013 , rather try
to look into "Elems" than into the more complex "Dialogs". Elems, by the way, have own Load and Store procedures and don‘t need Types.Mod
From: Oberon <oberon-bounces at lists.inf.ethz.ch> On Behalf Of Tomas Kral
Sent: Wednesday, November 14, 2018 1:53 PM
To: oberon at lists.inf.ethz.ch
Subject: Re: [Oberon] FPGA - OberonV4 Dialogs
Studying V4 further, I have come across this coding
Types.NewObj(o, Types.This (Modules.ThisMod (module), name)); type :=
`NewObj', `TypeOf', `BaseOf', `TypeTags' defined in Types.Mod
I really need some help in understanding of Linz Oberon better.
How does type tags and GC differs in V4 to RISC System5?
How can these methods be ported from V4 to RISC5?
Tomas Kral <thomas.kral at email.cz>
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon