Oberon inspired a number of languages. For instance, Limbo's GC also collects files, and modules are just objects you assign to when importing them, and are collected when no longer referenced.
-rob On Wed, Feb 6, 2019 at 10:06 AM Michael Jones <michael.jo...@gmail.com> wrote: > ha ha! yes indeed. i was counting intermediaries, so off by one. wirth was > on robert's thesis committee. (A Programming Language for Vector Computers, > his auto vectorizing Oberon subset for the Cray-YMP.) > > On Tue, Feb 5, 2019 at 10:55 AM Jan Mercl <0xj...@gmail.com> wrote: > >> Just an of-by-one error. After all, Michael is also a programmer ;-) >> >> On Tue, Feb 5, 2019, 19:51 Dan Kortschak <d...@kortschak.io> wrote: >> >>> Robert Griesamer *is* Niklaus Wirth? >>> >>> On Tue, 2019-02-05 at 09:19 -0800, Michael Jones wrote: >>> > Go learns from Oberon via Go and Oberon insider Robert Griesemer, >>> > whose >>> > Wirth-number is zero. >>> > >>> > On Tue, Feb 5, 2019 at 3:47 AM Gerard <gvdsch...@gmail.com> wrote: >>> > >>> > > >>> > > Hello everyone. There has been one issue in Go that has never >>> > > gotten out >>> > > of my head, so it went on and on. The problem is modules. >>> > > >>> > > In the beginning there was Oberon. Let's just face it. Oberon was a >>> > > brilliant designed piece of engineering. Oberon did have some >>> > > marvelous >>> > > features that just don't exist today, such as GC for everything, >>> > > including >>> > > closing files (anyone ever seen that), and their memory system was >>> > > also GC, >>> > > including modules entirely. So they made a counter for each module >>> > > that was >>> > > being used. You add one, the counter increase. You lose one, the >>> > > counter >>> > > went down and when that counter went zero that module got erased >>> > > from >>> > > memory. Pretty clever. >>> > > >>> > > Oberon also got very small compiled modules. They were compiled and >>> > > the >>> > > API was being check-summed. And they didn't got generics ;-) There >>> > > was no >>> > > need for that since the basic types were so simple, a lot simpler >>> > > than in >>> > > Go. >>> > > >>> > > Why were they using this compiled API file? That was only used for >>> > > identification. Everything that has public code goes into the >>> > > compiled >>> > > header file. There is AFAIK no no linking. The only thing that is >>> > > being >>> > > used are the compiled modules and compiled header files. >>> > > >>> > > Now I have explained everything that I know that I know about >>> > > modules. >>> > > What are the areas of interest? The only answer that I can find out >>> > > is OS >>> > > design. But for that the benefits are huge, but only if you have >>> > > the guts >>> > > to really gutter the whole thing down. >>> > > >>> > > What compiles: >>> > > That is pretty easy. Everything that is public will be part of a >>> > > header >>> > > file, the rest stays inside the module itself. >>> > > >>> > > The benefits: >>> > > >>> > > 1. This maps a lot better for OS development. >>> > > 2. No linking involved. >>> > > 3. updates could have been "on the fly", with just a couple of >>> > > LOC you >>> > > can download and compile an entire module, as long as the API >>> > > hasn't >>> > > changed. >>> > > 4. Fit well with systems such as apt-get, GNU GUIX, but also go >>> > > get. >>> > > >>> > > >>> > > The downsides: >>> > > >>> > > 1. This could confuse people who tend to use it. How can you use >>> > > it? >>> > > That is why I think that this could probably only work for OS >>> > > design. You >>> > > just don't want to download a half baked module. >>> > > 2. It could have been used proprietary. Personally I have a lot >>> > > against proprietary code. >>> > > >>> > > >>> > > Questions: >>> > > >>> > > >>> > > >>> > > Links: >>> > > >>> > > 1. http://members.home.nl/jmr272/Oberon/ModToOberon.pdf >>> > > 2. https://en.wikipedia.org/wiki/Oberon_(programming_language) >>> > > 3. http://www.ethoberon.ethz.ch/WirthPubl/ProgInOberon.pdf >>> > > >>> > > >>> > > -- >>> > > You received this message because you are subscribed to the Google >>> > > Groups >>> > > "golang-nuts" group. >>> > > To unsubscribe from this group and stop receiving emails from it, >>> > > send an >>> > > email to golang-nuts+unsubscr...@googlegroups.com. >>> > > For more options, visit https://groups.google.com/d/optout. >>> > > >>> > >>> > -- >>> > >>> > *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> >> -j >> > > > -- > > *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
