Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.prolog
Subject: Re: taking a predicate name as an a
Message-ID: <2573@skye.ed.ac.uk>
Date: 25 May 90 17:24:19 GMT
References: <3017@goanna.cs.rmit.oz.au> <26900003@teapot>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 35

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.