[Oberon] Modula2 vs Oberon IMPORT

[Aubrey.McIntosh at Alumni.UTexas.Net]

There are Oberon systems that are programmed in Oberon, the language,
that run on Linux.

When running the Oberon system, you have access to a complete system +
language by the same design.

In this system, I can write a module that does some calculation and
writes formatted text.  It would import a module Texts.  The other
parts of the system would also import Texts.  This code is shared, and
it is loaded on demand.

In actual practice, the code is fast and small.  More importantly, the
code that you write is transparently what the compiler produces.  If
you find a module that has one set of code that is not often called
when another set is called, you can re-factor the source so that there
are two modules, and only import the one that you want.

This is a much bigger burden on the code designer/author.  But the
benefits are enormous, even to that same author in the future when
maintaining code.



On Sat, Jan 8, 2011 at 1:45 PM, Duke Normandin <dukeofperl at ml1.net> wrote:
> On Sat, 8 Jan 2011, Christian Demmer wrote:
>
>> Duke Normandin wrote:
>> >IMHO, "clever" compilers that IMPORT _only_ the required code, is the
>> >ideal situation.
>>
>> I think there is a misunderstanding of import of symbols and code and
>> separate compilation in general here.
>>
>> If a module is compiled the compiler writes a symbol file which contains
>> information (names etc.) about the module and all exported symbols and a
>> object file which contains the code for this module. There is no code in
>> a symbol file.
>>
>> If a second module is compiled which imports the first
>> module, the compiler reads the symbol file of the first module. The
>> object file, which contains the code of the second module has only
>> references to code and variables in the first module which must be
>> resolved by a linker. That could be a static linker or a loadtime
>> linker like the one in the original Oberon system.
>>
>> How this is done depends on the system used.
>>
>> >Yes! I realized that about qualified IMPORTs - after all, the entire
>> >Module is referenced in the IMPORT statement. Qualified imports simply
>> >allow you to use procedures with the same name, as I understand it.
>>
>> Qualified import is more or less a syntax feature and most likely not
>> related to the implementation of the code generator.
>>
>> >My concern is this - if a "main" Module IMPORTS 10 "slave" Modules,
>> >but uses only (e.g.) one procedure from each, then the code bloat in
>> >the final executable would be absurd, would it not? I might as well
>> >cut-n-paste the code into the "main" module, and re-use the code that
>> >way. Maybe this something a "peephole optimizer" could do?
>>
>> As explained above no such thing will happen. The compiler moves symbols
>> around. No code, only references to external code are handled by the
>> compiler.
>>
>> Hope this helps,
>
> I'm not yet sure! Are you referring to the way things are on an Oberon
> OS system, or otherwise? I'm learning Oberon-2 (and the Pascal-family)
> on a Linux box. Do your comments apply on such as system as well?
> --
> Duke
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>



-- 
--
Aubrey McIntosh, Ph.D.
1502 Devon Circle
Austin TX 78723-1814
http://home.grandecom.net/~amcintosh/aubrey/Search/