Open hanjoosten opened 2 years ago
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.
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
I expect this issue to resolve: #447, #708, #816, #943, and #1212.
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.
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)
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.
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.