[mercury-users] Term manipulations in Mercury -- advice requested

[Gregory D. Weber]

Thanks very much!  Since your information was the opposite of what I expected,
it probably saved me from endless frustration going down the wrong path
with the std_util facilities.

Greg

Ralph Becket writes:
 > Gregory D. Weber, Tuesday,  1 June 2004:
 > > Greetings!  I am interested in using Mercury as the programming language
 > > to develop a first-order rule learning system.  I have done a fair amount
 > > of Scheme and Common Lisp programming and a wee bit of Prolog.
 > 
 > Good idea!  Let us know how you get on.
 > 
 > > [...]
 > >
 > > If I were doing this in Prolog, I would be using functor, arg, and
 > > "=.." ("univ").  I think I see two possible ways to do it in Mercury.
 > > 
 > > 1.  One is to use the facilities of the term and related libraries
 > > (varset__init, varset__new_named_var, term__atom, term__context,
 > > term__variable, term__functor, or parser__read_term_from_string, to
 > > build terms; term__unify and term__substitute, to match terms to
 > > examples).
 > > 
 > > 2.  The other is to use facilities of std_util (functor, construct,
 > > argument, deconstruct; and for matching, unify or just '=').
 > > 
 > > My impression is that (1) is going to be more complicated,
 > > that it might be more flexible and require less compile-time
 > > information than (2), and that it might be less efficient than (2).
 > 
 > (1) is fairly efficient: if you're going to be manipulating term
 > structures, then you should first think of using the term module.  
 > We use it in many places in the compiler.
 > 
 > (2) is intended for reflective programming where you examine the type
 > and structure of values at run-time.  You could conceivably use it, but
 > I wouldn't: I'd imagine a combinators + higher order approach would be
 > better for your purpose.
 > 
 > (3) You could roll your own specialised term module, but in my
 > experience this often turns out to be a fair bit of work and doesn't
 > always pay off.
 > 
 > My advice: pick (1) and explore the other options if you identify a
 > serious performance issue.
 > 
 > -- Ralph
 > --------------------------------------------------------------------------
 > mercury-users mailing list
 > post:  mercury-users at cs.mu.oz.au
 > administrative address: owner-mercury-users at cs.mu.oz.au
 > unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
 > subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
 > --------------------------------------------------------------------------
 > 

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------