Although both .sats and .dats files are compiled into .c file by the ATS
compiler, they shall not be simply viewed as counterparts of .c files. They
actually provide the concept of “module / namespace”. The following example
shows a common mistake I often make when I treat .dats files as .c files.
The project contains two files a.dats and main.dats, each of which can pass
the type checking of ATS.
==== a.dats ======
extern fun foo (): void
implement foo () = ()
==== main.dats ======
dynload “a.dats”
extern fun foo (): void
implement main () = foo ()
But as a whole, when I run “atscc a.dats main.dats”, I would get a linking
error, says that
main_dats.c:(.text+0x3ef): undefined reference to
`_xxx_2googlegroup_21_2main_2edats__foo’
So when we are on the project level, we should not view “extern” and
“implement” in ATS just as function declaration and definition in C.
Basically, each .dats has its own namespace.
One way (the only one I know) to solve this is to use the .sats file. The
project would probably be as the following.
==== a.sats ======
fun foo (): void
==== a.dats ======
staload “a.sats”
implement foo () = ()
==== main.dats ======
staload “a.sats”
dynload “a.dats”
implement main () = foo ()
The rule of thumb is that if we use “extern” in a .dats file, then the
corresponding “implement” has to be inside the same file. On the other
hand, if a .sats file contains multiple function declarations, we can
distribute the implementations of them into multiple .dats files.
When we “staload” a .sats file, we can give it a name (or say alias). I use
to view this as the counterpart of “import xx as yy” in Python, and “from
xx import *” when no name is specified. However, unlike Python, the names
imported into one .sats file won’t be exported to second file. (“staload”
is only effective for one level.) For example, in the following project,
b.dats won’t pass the type checking.
========= a.sats ========
typedef TA = int
========= b.sats =========
staload “a.sats”
typedef TB = TA
========= b.dats =========
staload B = “b.sats”
fun foo (): $B.TA = 3
To fix this, we should have b.dats as follows
========= b.dats =========
staload A = “a.sats”
fun foo (): $A.TA = 3
That’s why sometime you would see a .dats has a bunch of “staload”.
There’s an exception, which I am not sure is a mistake or not. The follow
project can pass the type checking.
========= a.sats =========
typedef TA = int
========= b.sats =========
staload A = “a.sats”
typedef TB = $A.TA
========= b.dats =========
staload “b.sats”
fun foo (): $A.TA = 3
The alias actually gets exported to a second file. However something like
“$B.$A.TA” is a syntax error.
If we stick to the thought that staload without name is like “form xx
import *”, the next question is what if there is stuff with the same name
but in different .sats files. For example, the following project can pass
the type checking, which means the second staload “override” the first one.
===== a.sats ========
typedef T = int
===== b.sats ========
typedef T = string
===== main.dats ======
staload “a.sats”
staload “b.sats”
fun foo (): T = “dd”
Going still further, we can change main.dats to the following and it still
passes the type checking. Whatever defined in the current file has the
highest priority.
===== main.dats ======
staload “a.sats”
typedef T = char
staload “b.sats”
fun foo (): T = ‘c’