feature: Name spaces

[stefjoosten]

@Michiel-s, @stefjoosten , and @hanjoosten have discussed an implementation of the multi-context functionality. We have agreed on the following:

1. A pattern is a namespace, so we'll drop the keyword PATTERN in favor of NAMESPACE.
2. Every namespace is defined in one file.
3. The filepath from the root including filename (without extension) is the name of the namespace.
4. Syntax conventions similar to Haskell except for a good reason.
5. Importing yields a disjoint union of namespaces. The imported names are prefixed with the name of the namespace and a dot. (like the qualified import mechanism in Haskell). Syntactical details are yet to be determined.
6. The word namespace is synonymous to the Haskell word 'module'. We prefer 'namespace' to remain close to the modelling world (as opposed to the programming world).
7. The universe is populated with namespaces
8. A namespace may contain contexts, relations, concepts, rules, and services and other statements.
9. The INCLUDE statement becomes obsolete. The IMPORT statement enhances the namespace with the disjoint union of both namespaces.
10. The EQUALS statement allows the user to equate named objects.

We'll implement this in a feature branch. This will lead to a release that is NOT backwards compatible.

[sjcjoosten]

Many thanks for freeing up the name PATTERN! I'm happy with the proposed changes.
Does this mean that every file now begins with:
NAMESPACE Filename
Stef replies: We wouldn't even have to use the keyword NAMESPACE because each file is exactly one namespace. However, what we discussed is to use the keyword NAMESPACE to start every namespace with NAMESPACE <Filename>, but not have ENDNAMESPACE at the end. This gives us at least a case sensitive name of the namespace that is independent of OS naming conventions. Besides it reminds the user of the fact that a file is a namespace.

Instead of CONTEXT X PATTERN Y?
Do we require ENDNAMESPACE, drop it, or make this optional?
Stef replies: There is no ENDNAMESPACE at the end. The end-of-file is also the end of the namespace.

I want to ask about the use of file names here.

How are filenames considered?

• Does the case of the filename need to match the case in the namespace, or does the OS matter here? Note that it can be tricky to get the casing right on a case insensitive system: if I do a rename of the cases in svn from a linux platform, that rename will not be carried out correctly on a windows platform. Also note that OS X is optionally case sensitive.
  Stef replies: This was part of our discussion: We'll follow the Haskell convention: case sensitive names for name spaces.
• Are file-paths written with / or \, or does it depend on which OS I am on? If we take the OS, I would be unable to write cross-OS designs. Note that Hello\world/! is a valid filename in Os X's finder (it will appear as Hello\world:! in the terminal). I don't particularly like the use of . for separating folder names, but it is common practice to do so in both Haskell and Java.
  Stef replies: This was part of our discussion: We'll follow the Haskell convention. The path separator will be the dot.
• Do we allow a namespace to be defined in a directory with the same name? It would allow me to write import Person instead of import Person.Main while keeping all the Person related stuff neatly tucked away in a directory. Second question, do we allow a .zip or .tgz file to be used in the place of a path name? (import Person would search for Person.adl, Person/ and Person.zip consecutively. Yeah this is a passively phrased feature request...)
  Stef replies: good point. Sounds attractive. In our discussion we have agreed to start with a bare minimum implementation. It sounds like this can be postponed a bit?

If we don't use a NAMESPACE line at the start of each file, we do not avoid thinking about these issues, as we will still refer to namespaces in some way.
Stef replies: agreed. A good reason to insist on a NAMESPACE line at the start of each file.

Stef says: When the discussion has settled down, I (or someone else) will summarize this comment to its bare essence needed to document our design decisions.

[hanjoosten]

As @sjcjoosten points out, a can of worms exists in the edge cases. I prefer to keep things practical. If we borrow the best practices of Haskell, we will end up with a very acceptable solution. This conforms to the above point 4.

As a consequence, each file will start with the full namespace. Names will have points for separating folder names, as Haskell modules do. Hence we do not have to deal with OS-dependent conventions other than the local one. Unicode of course should be the rule.

[stefjoosten]

Here is an attempt to define some operational semantics of namespaces and contexts.

CLASSIFY Context, NameSpace, Concept, Relation, Service, Rule ISA NamedObject

RELATION valid[NamedObject*Context]
    MEANING "o valid c means that named object o exists with the context c."
RELATION definedIn[NamedObject*NameSpace]
    MEANING "o definedIn n means that NamedObject o is defined in namespace n."
RELATION imports[Context*NameSpace]
    MEANING "c imports n means that there is an import statement in context c that mentions namespace n."

RULE imports : definedIn;imports*~ |- valid
   MEANING "Every named object defined in a context or imported (recursively) from another namespace is valid within that context."
VIOLATION (TXT "{EX} InsPair;valid;NamedObject;", SRC I, TXT ";Context;", TGT I)

To make RULE imports work, we need either Context ISA NameSpace or NameSpace ISA Context. @hanjoosten and @Michiel-s : This is a consequence we did not discuss last Friday...

[stefjoosten]

We need to answer two questions.

For named objects defined in a context we need another relation:

RELATION definedIn[NamedObject*Context]
    MEANING "o definedIn c means that a declaration of NamedObject o exists between the CONTEXT and ENDCONTEXT symbols of context c."

First question: do we want

definedIn[NamedObject*Context];definedIn[NamedObject*Namespace] |- definedIn[NamedObject*NameSpace]

to be satisfied in every interpretable namespace? This would mean that every named object defined in a context is implicitly defined in the namespace in which that context is defined.
If that is true we can treat every context as a subset of the namespace in which it is defined.

Here is another question: do we want

definedIn[NamedObject*Namespace];definedIn[Context*Namespace]~ |- valid

to be satisfied in every interpretable namespace? This would mean that named objects defined outside a context are valid in every context of that namespace.

[sjcjoosten]

@stefjoosten said:

To make RULE imports work, we need either Context ISA NameSpace or NameSpace ISA Context. @hanjoosten and @Michiel-s : This is a consequence we did not discuss last Friday...

Alternatively, you could change the signature of valid, and add a relation namespace:

RELATION valid[NamedObject*NameSpace]
     MEANING "o valid n means that named object o exists with the namespace n."
     PURPOSE "Keep track of the objects that are in scope."
RELATION namespace[Context*NameSpace]
     MEANING "c namespace n means that the context c is using the namespace n."
     PURPOSE "This relations helps determine what vocabulary to use in a certain context."

This makes sense if (user-) interfaces are contexts: we might want to say that two different interfaces use the same namespace.

[Michiel-s]

I agree with @sjcjoosten, an alternative approach is needed. For me it doesn't make sense to put Context and NameSpace in the same classification tree. A Context ISA NamedObject. And a NamedObject is definedIn a NameSpace.

If we change the definition of imports to: `RELATION imports[NameSpace*NameSpace]
The rule import can become:

RULE imports : I[Context];definedIn;imports*;definedIn~ |- valid[NamedObject*Context]~
   MEANING "Every named object defined in a context or imported (recursively) from another namespace is valid within that context."

[Michiel-s]

Oh I would like to suggest to use Namespace instead of NameSpace as it is a single word.

[sjcjoosten]

We aren't taking into account that namespaces are imported disjointly. Suppose we have the following script:

import X as A
import X as B
import X as C

Do we want to allow this? (I am assuming we're all in favor, but would gladly make the case if someone is not, so please ask!) If so, what would the population of the relation imports look like?

[stefjoosten]

Indeed, last friday we discussed this. I just didn't document it. :-( Importing yields a disjoint union of the namespaces. The imported names are prefixed with the name of the namespace and a dot. (like the qualified import mechanism in Haskell). Syntactical details are yet to be determined.

I have added this to the first comment in this issue. In a few days time I will delete this comment and the previous (Bas' question) about the disjoint union. Because we are all in agreement here.

[stefjoosten]

@sjcjoosten said:

Alternatively, you could <...> add a relation namespace:

RELATION namespace[Context*NameSpace]
     MEANING "c namespace n means that the context c is using the namespace n."
     PURPOSE "This relations helps determine what vocabulary to use in a certain context."

What exactly do you mean by 'context c is using the namespace n'?

• is this a separate statement? E.g. IMPORT n, represented in the metamodel by c imports n.
• is this use derived from a syntactical situation? E.g. using = namespace;imports*
• another interpretation of 'using'?
  Could you please clarify? (preferrably by editing your original comment, so I can delete this comment later)

[stefjoosten]

@sjcjoosten said:

Alternatively, you could change the signature of valid <...>:

RELATION valid[NamedObject*Namespace]
     MEANING "o valid n means that named object o exists within the namespace n."
     PURPOSE "Keep track of the objects that are in scope."

I can see how this helps to say that two different interfaces use the same namespace.
I do have a question: do we adapt the proposed rule to:

RULE imports : definedIn[NamedObject*Namespace] ; imports*~ |- valid
   MEANING "Every named object defined in a namespace or imported (recursively) from another namespace is valid within that context."
   PURPOSE "To define which named objects are valid in which namespace
VIOLATION (TXT "{EX} InsPair;valid;NamedObject;", SRC I, TXT ";Context;", TGT I)

In that case, do we want the following to be satisfied in every interpretable namespace?

definedIn[NamedObject*Context] ; definedIn[NamedObject*Namespace] |- definedIn[NamedObject*Namespace]

So the question is: is every named object defined (i.e.declared) in a context implicitly defined in the namespace in which that context is defined?
If yes, what is the purpose of having contexts? Do we still need them?
If no, what is the semantic difference between named objects defined inside a context and the ones outside the context? And how is that difference useful?

[Michiel-s]

Issue #606 asks for import ... as ... aliasing/renaming functionality.