Re: Problem with repeatedly compiling files with partly the same content and EmbeddedEclipse

Hi Cornelius,

On Thu, Mar 13, 2003 at 06:05:26PM +0100, Cornelius Hagen wrote:
> Hi Josh,
>  
> this sounds very interesting. I tried it out with DosEclipse, e.g.
> 1) create_module(d).
> 2) module(d).
> 3) compile(file). [containts some facts and a relation foo]
> 4) state a query: foo(X,Y).  (and get the correts answers)
> 5) erase_module(d).
> 6) foo(X,Y) (calling an undefined procedure, correct) 
>  
> Two questions remain:
> * How do I change the active module with the java interface? The docs
> say, module/1 used in a file does not make this module the active one
> (with DocEclipse, and its function in DOsEclipse is special, so I can't
> use it with java.)

You can't change what the "active" module is as such; rather you just tell
ECLiPSe to do things in other modules.  You do this using the @/2 meta
predicate, as Josh mentioned.

Taking your above scenario, you might have something like this:

1:  create_module(d),
2:  compile(file)@d,	% compiles file as if done from module d
3:  export(foo/2)@d,	% export foo/2 from d so other modules can access it
4:  d:foo(X, Y),		% call module d's foo/2
5:  erase_module(d).

(1) creates the module as before.  You might like to make this a little more
sophisticated by checking whether the module already exists (erasing it if
it does) before creating it, since otherwise create_module/1 will abort with
an error.  This way, if the (5) was not executed for some reason (e.g.
problem in the code between (1) and (5)), it won't just die at (1), but
will recover gracefully.

(2) compiles the file "file" in the context of module d.  Any ECLiPSe
predicates in file will be compiled into module d by default.

(3) exports foo/2 from module d, so that predicate from other modules can
access it.

(4) calls the foo/2 exported from module d.  Because foo/2 is defined in d,
the body of foo/2 executes in the context of module d; that is, it can
access anything available in d, but not anything which isn't available in d.
Note that if you want to be able to call foo/2 without specifying the
module, you will need to import it into the module you wish to call it from;
e.g. (import foo/2 from d).

> * Actually, my predicate foo communicates with some queues via
> write_exdr and read_exdr. Do I need to declare them as tools when I
> compile the file in an extra module?

I'm not sure I understand what you're asking here (I've never used queues,
read_exdr or write_exdr).  A tool declaration is only needed for a predicate
*you* define, if that predicate needs to know which module it was called
from.  If foo/2 for some reason needs to know where it was called from, then
it needs to be declared a tool; otherwise it does not.  This is covered in
the "Advanced Topics" section of the "Module System" chapter of the User
Manual.  Typically, this is needed when doing meta-programming, where a goal
to execute is passed to a predicate in another module.  Suppose this goal is
bar/1.  Since bar/1 may be defined in many different modules, the called
module needs to know which one is intended, and this depends on which module
it was called from.  i.e. if the caller module was m, then call(bar(X))@m
will call the bar/1 visible in module m.

I suspect you probably don't need this for what you're doing.

Hope that helps.

Cheers,
Warwick