Modules

[Matthew Tuck]

Hans-Dieter.Dreier@materna.de wrote:

> #ifs should never be neccessary because the compiler can evaluate the
> expression and remove the code that is inaccessible. IMO the only good thing
> concerning #ifs is that one can see at first glance that they are there for
> conditional compilation.

Not really.  Ifs can't handle situations where one branch won't compile
since required code is not present because it only works in the presence
of a certain library, etc.

Why would you want to know that something is conditionally compiled?  If
I use a normal if, it can optimise it out or not, it doesn't affect me
for the most part.

>> Modules are a collection of top-level elements, which will usually be
>> classes/singular objects/etc.  Hence modules are thrown together into
>> one program, none having a priveleged status over another.  You can
>> imagine this as concatenating text files, if the merging were text
>> files.  Since we are editing ASTs, there is no need for rules
>> prohibiting forward references.
> Agree to all. One remark however: I would allow to include not only
> toplevel elements but also class members and other nested elements as
> long as the path from root to the element in question touches only
> classes and name spaces.

I'm not sure what you mean by "only classes and namespaces".

> These would be mixed in. In this way certain
> aspects of the whole class system could be isolated in separate
> modules. Examples: The IDE, profiling, debugging, code generation
> (compiler version dependent), customised editing (see GUI builders
> thread). It's usable for all kinds of "one-way" relationships
> (were A knows about B, but B not about A).

You would certainly want to put different parts of the library in
different files for a whole wealth of reasons.  The "detached element"
would be especially useful for libraries in a unified containment
hierachy language.  By this I mean as follows - there is no distinction
between a "packaging" feature and a class feature.  Ada and Java both
have this.  You have "packages", which are essentially libraries that
contain elements like classes and possibly other libraries.  Then you
have "classes", which we all know and love.

The essential difference is that there is only one instatiation of
classes.  Also, classes can usually not contain other classes, although
in Java's case, it is allowed.  Hence the need for the distinction is
disappearing.  A "unified containment hierachy language" only uses
classes (or types/impls), and considers packages to be "singular
objects", that is a special sort of combined class/object.  Therefore
there is only one mechanism for information hiding rather than two.  Ada
is a mess in this respect.

One possible difference though, is that packages often do have "I use
this package" declaration, whereas classes don't.  This is because
packages usually correspond to files.  Therefore is "I use this" a class
or module concept?  It could be either.

I don't want it to be a module concept since I want to make modules at
least semi-implicit.  It's an option though.

As a class concept?  It could result in a lot of declarations.  Does a
method have to specify what it uses as well as a class?  I prefer to
think of methods as nested singular objects, although it's not certain
it's possible to do this.  Hence methods and classes would have the same
nesting mechanisms, simplifying and making the language more flexible. 
But this would carry large syntactic overhead.

An intelligent editor could take some of this away, but it's not certain
that's any different from letting the editor work out dependencies on
its own.  What is the point of these dependencies?

(a) To work out dependencies?  Should be done by the editor.
(b) To require the programmer to specify redundant information about
what they intend to use?
(c) To make it readable as to what other elements are used without
looking at the body?
(d) If included in types, could be used to restrict what elements a
defined method can implicitly access.

(b) & (c) are possible reasons, and (d) is more radical.  I'm not sure
what the best solution would be.

>> My view of the way the editor should handle this, is to normally not
>> show the modules at the top of the hierachy, although it could allow
>> this.  Hence the modules would normally might be transparent, except for
>> perhaps something to indicate you don't have write access to that code.
>> Some facility must exist to move top-level elements between modules.
> Agreed. Centura does it exactly as you sketch here. They have a "refresh"
> facility to re-load a module in case the user has switched off the
> automatic detection of file changes, and a "merge" facility that merges
> all included files.

That's a good point - the code may change outside of the editor.  If
it's read-only, it's OK, but if you can write to the code, we could get
problems.  If we have a lock facility to make it read-only if someone
else is editing it, that would work, but what about if not?

We probably should attempt to ensure files are not saved if they aren't
edited, although this might not be easy given my desire to make them
kind of implicit.  Or it might be dead easy.

Other than that, we probably just have to say, get a locking system.

One thing though, if the editor provides everything you have access to
as read/write, then you've essentially checked everything out you have
access to and hence no-one else will be able to edit it.  Hence a more
sophisticated system than this might be needed, like an explicit
checkout which makes the code read-write.

Hopefully though, at least the infrastructure for this could be built
into the editor.  The views would support the read-only sections, and
there would be a back-end plug-in locking system.

> They also have an "includes" section where you can see what you included
> (and also, what was indirectly included) as well as edit/insert/delete
> the file specs. Included parts are always noneditable, but you may spawn
> another instance of Centura on that include file with a single keystroke
> and that will open the include's outline at the current position.

What do you mean by include here?  #includes?  Other accessed packages?

> You would make a separate class / name space of the separated part
> and use delegation ("stub") to access it, and a back pointer to the
> surrounding class to access that from within the separated part?
> (Please forgive my insisting on "how do you" questions, but I need
> to know how it works, to see what it can do and where its limits are
> :).

No, nothing as complicated as that.  Every detached element will act
exactly as if it was attached at run-time.  You would essentially just
compile the detached element in the namespace of the other element, then
later reattach it at linking stage.
 
>>(1) Need to typecheck an element in a different module from it's
>>surrounding element.
> An interface view of the module containing the lacking type should help.

This is really an editing problem, so what do you mean be an "interface
view"?  What I meant was that the type checking information (like what
identifiers are inherited into the element's scope) is not in the
"surrounding element" anymore and could be in another module.

>>(2) Could not be optimised well until the modules are linked together.
> Maybe not even then.

No it definitely could be then.  At linking time the detached element is
put back where it should be.  The only reason it wasn't there in the
first place was to put it in another file.  From there you could
optimise if you wish.

But for sure putting something in another module will make it less
efficient if you don't do any inter-module optimisation.  That up to the
developers.
 
>>(3) Being able to see a top-level element no longer implies you can
>>access it.
> Don't you mean "access it no longer"? Otherwise please explain.

I was talking about having a private element of an impl detached to the
top-level.  Hence we might have a "phantom" element (private method)
which is at the top-level but which we can't call.  I don't really see
that as a problem though.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/