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

Hi Warwick,

Thank you! One more question.
Your points are very clear: 
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).
To implement this in java, I'd try 1,3,4,5 the rpc(String)-method.
But how about 2:? Usually one compiles a file in java with
compile(File)-method that does not provide the possibility to use @/. I
tried a work-around via rpc( "compile(arrow0.txt) @ d" ).
But get an Exception (Throw) with the comment:
string stream 9: syntax error: postfix/infix operator expected 
| compile(arrow0.txt) @ d 
|               ^ here string contains unexpected characters in
term_string(_942, "compile(arrow0.txt) @ d")
		   
Obviously, this doesn't work.
Is there an alternative?

Thanks

Cornelius




-----Ursprüngliche Nachricht-----
Von: owner-eclipse-users@icparc.ic.ac.uk
[mailto:owner-eclipse-users@icparc.ic.ac.uk] Im Auftrag von Warwick
Harvey
Gesendet: Donnerstag, 13. März 2003 19:30
An: Cornelius Hagen
Cc: eclipse-users@icparc.ic.ac.uk
Betreff: Re: [eclipse-users] 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