nested subprogram pathnaming

7.17: adda/syntax/nested namespaces of various impl's:
. what is the path delimiter for nested name spaces,
main/sub or
main.sub?
. notice if a file system were
pre-declared and const,
then pointers are not needed;
so, the path is x.y.z not x/y/z .
8.22:
. nested subprograms need not be const's;
they can be redefined at any time
without having to recompile the superprogram;
but the question is moot; because,
sub, in the above example,
is a local within the body of main,
so the path should look like this:
main`body/sub .
. this is quite essential syntax too;
because, some objects can be both
callables and tuples or pointers,
so there could be a main.component
and a main`body -- the callable part .
. additionally it fits in with
the idea of separating face from body
(ada's specification from implementation).
. we define the face first,
and then later we give the face's body,
easily remembered as syntax: face`body .

7.17: adda/ada/same syntax for {pointer, component} paths:
. if using (super/sub) for pointer
but using (super.sub) for non-pointer,
then we are having to recall impl'details
in order to know how to construct a path .
8.22:
. that could be why ada uses dots for everything;
but, I got the idea from our url's
unix file path syntax;
and, that's an importantly well-known standard
that uses (/)'s to mean a folder transition
which is an intuitive example of a pointer;
ie, if you want people to get pointers
you might want pointers to look like folder paths
and not be confused with the likes of subdomains .

7.17: mis.adda/localized typedefs ambiguous?:
. when combining nested contexts with type decl's
depending on what syntax chosen for context paths,
that could determine whether there is an ambiguity
when expressing type: is the thing a type
or is it an obj' declared as having that type
... but there can be no confusion:
the type of type is literally "(.type)!
8.22:
. a similar point that still stands is,
if you have a lot of dots in your pathnames,
then the reader has to
memorize all the typenames
in order to differentiate these examples:
path.x.int -- a declaration of x as int;
path.x.not-a-type -- evaluation of not-a-type .