2.18: adda/cstr/dynamic module import:
. dynamic module import?
at first I was perplexed at how to parse functions
if you can't be sure what's active,
conflicting with each other in the namespace .
. but this does work out; and,
it's essential for the mandate to have
complete lisp-like control over your machine .
. lisp can treat any control structure (live or template)
as if it were also data:
inspecting its space, and then using what it finds .
. this could be called having 1st-class plug-in's .
parsing for conditional imports:
. this will be like generics, but instead of
the programmer specifying the type of instance,
the run-time is checking parameter types,
to figure out which of several subprograms to run .
. after an explicit import,
rather than just a situation where a program
looks around the file system on its own,
some of the imported names may be overloaded .
. if multiple imports are conditional,
then we must assume that any combination
of imports will happen .
. the programmer may have it arranged such that
in practice no overloading ever occurs;
but generally this can't be known at compile time .
we should be responding to every import
without regard to the condition intended;
and, if there is then overloading,
we should tell the compiler user
that a run-time binding has been used,
so they have the option of specifying a particular module
rather than slow things down by
testing the run-time param'type in order to
find the suitable subprogram from among
the multiplicity of modules currently in effect .
. a run-time binding works like this:
the function to call is dynamicCall,
which is given the intended subprogram's param's,
along with a link to the intended subprogram's symbol
(found in the caller's run-time symbol table);
and, that symbol has a list of pointers to
the subprograms of the same name
in the various imported modules .
. in summary,
the symbol table needs 2 listings:
one for the types it finds,
and another for the other (instance) symbols .
. in a simple example with no run-time binding,
the symbol table's list of instance symbols is temporary
(not of use after the compiler is done);
but, in the case of needing dynamic calls,
the symbol table needs a permanent list of instance symbols .