🚀 go-pugleaf

In article <26900003@teapot> milgr@teapot.prime.com writes:
>Small (trivial) exmaple of why predicate-based modules are better for
>my needs:

Ok, a minor point: I suspect that predicate-bases systems may always
be at least somewhat better for some things.  So the real question is
whether the difference will be great enough in a large enough number
of cases.  I don't know the answer.  

>:- module(rev20_ctrlr_info).
>:- import([addr_to_ctrlr, dsk, amlc, ...]).
>:- use_module([cpu_info]).   % defines cpu_type, alpha, degraded_mode.

Here I wonder why you have to list dsk, amlc, etc. explicitly.
Why can't you say use_module for some module that cointains
them all?  If you don't want to tye in the export list for
that module, you might be able to have a program generate it.

Another approach might be to allow some modules access to internal
symbols in certain other modules (just as derived classes in C++ can
have access to some of the internals of their base class).  I know
this is a fairly vague description, but something along those lines
might be possible.


>Secondly, if I want to modify one module, it appears that I need to
>reload all of the modules in order to compile one module.  (Prologix
>has an interpretter with a compiler built in.  One must load in a file
>to compile it).

This sounds like an artifact of the particular implementation you
are using.  That sort of thing can happen with predicate-based
systems too.  For example, if you import from some module, the
compiler may have to look at that module to see if anything it
exports is a meta-predicate.