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

Hi Cornelius, 

I'd advise you not to use the compile or rpc(String) methods -- use the
rpc(CompoundTerm) or the other rpc methods for everything, they are *much*
cleaner. The compile method is just a shorthand for this anyway. @/2 is just
a meta predicate, i.e. foo @ bar is really @(foo, bar) so you can construct
the @ goal in Java using a CompoundTerm with functor "@" and arity 2. 

cheers, 

josh 

Developer, Parc Technologies Limited
josh.singer@parc-technologies.com
http://www.parc-technologies.com

This e-mail message is for the sole use of the intended recipient(s)
-its contents are the property of Parc Technologies Limited (or its
licensors) and are confidential. Please do not copy, review, use
(except for the intended purposes), disclose or distribute the e-mail
or its contents (or allow anyone else to do so) without our prior
permission. Parc Technologies Limited does not guarantee that this
e-mail has not been intercepted and amended nor that it is
virus-free. You should carry out your own virus checks before opening
any attachment.  Any opinions expressed in this e-mail message are
those of the author and not necessarily Parc Technologies Limited.


> -----Original Message-----
> From: Cornelius Hagen [mailto:cornelius.hagen@wiai.uni-bamberg.de]
> Sent: Friday, March 14, 2003 3:08 PM
> To: eclipse-users@icparc.ic.ac.uk
> Subject: WG: [eclipse-users] 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
> 
> 
> 
>