Enhancement: Namespaces

[hanjoosten]

A long-awaited feature of Ampersand is that of having namespaces. In the discussions of the past, we found that having a module structure as Haskell has, would enable namespaces. I am going to attempt to implement modules in a Haskell way. This issue will be a placeholder for my thoughts along the way. I welcome discussion as well!

The work is being documented along the way: See here.

[hanjoosten]

Since the creation of this issue I found that introducing namespaces can be split up in several phases.

1) Work 'under the hood'. This can be seen as work in the internals of the codebase, replacing the use of Text for all kind of names with a specific datatype. This will enable the separation in namespaces for the definitions from the user's script, FormalAmpersand definitions and definitions required to build a prototype. This phase doesn't change the ADL language. 2) Entend the ADL language with import statements, as explained in the original post of this issue. It is very likely that the current 'INCLUDE' statement will be droped, because it might be conflicting with the import statements. However, this still remains to be seen.

[Michiel-s]

Proposal for namespace syntax

Inspired/copied from XML and RDF specifications (specifically turtle language)

The name is to replace what we now have in place to name stuff, like CONCEPT name, RELATION name, etc.

namespace_declaration ::= 'NAMESPACE' namespace

prefix_definition ::= 'PREFIX' prefix namespace

name ::=  ( namespace localname ) | ( prefix delimiter localname ) | localname

namespace ::= NCName
prefix ::= NCName
localname ::= NCName
delimiter ::= ':'

Copy paste to https://www.bottlecaps.de/rr/ui to view railroad diagram

[stefjoosten]

I expect this issue to resolve: #447, #708, #816, #943, and #1212.

[stefjoosten]

On Friday, 2023/02/24, on an Ampersand core team meeting, we (@Michiel-s, @hanjoosten, and @stefjoosten) decided to use the keyword MODULE instead of NAMESPACE, which matches the Haskell choice of words. The reason is that external users might associate the word namespace with the mechanisms in OWL and RDF, whereas we'd rather be associated with the Haskell mechanism of modules.

[stefjoosten]

As I understand now, this issue will give us identifiers with dot separators. For example foo.bar is the identifier bar within a namespace calledfoo. Since namespaces can be nested, gnu.foo.bar is also a good example.

If I want to include a file, I expect we'll keep the current mechanism, which boils down to the union of things from the current file and the included file, which is subjected to the type system as a whole.

If I want to include a file while keeping all the definitions of both files, i.e. a disjoint union, I will use the namespace mechanism. For example:

INCLUDE "Herit.adl" AS old
RELATION foo[A*B]
ENFORCE old.foo :< foo

This example copies the contents of the relation foo from file Herit.adl into relation foo in this script. Suppose that Herit.adl also has an INCLUDE statement:

INCLUDE "Dodge.adl" AS gnu

and the file Dodge.adl defines RELATION foo[A*B], then we can refer to that relation by old.gnu.foo. @hanjoosten, is this a correct interpretation of what is going on in this epic? If so, this should be suitable for trying out the migration theory (issue #1393)

[hanjoosten]

There is some wishful thinking still. In the first phase, there is no extension of the INCLUDE statement. It has no AS part. It hasn't been decided yet that that will be the way to go, for we are heading to a MODULE system. INCLUDE will be deprecated at some time.