For review: Term display helper

[Waye-Ian CHIEW]

Hello!

   > This is the term display helper, which takes univ terms and displays them in a
   > choice of pretty formats.
   > 
   > It is not finished and not really useable;  some critical additions, like
   > the scripting language and the interactive browser, haven't been implemented
   > yet. 
   > 
   > -- Ian!!

   Uh, the scripting language?!?

Yes;  they're needed by the display helper to flatten out recursive structures
like lists and trees.  

term_io source has special case code to look for lists and print them out in
the Prolog [1, 2, 3] form.

There should really be a more general way of doing this.

If the term printer has to print out: .(1, .(2, .(3, [])))
Then there should be a script for it that says:  if this is a "." functor, then
print out its first field, then descend the second field and repeat. 
The output would look like: .(1, 2, 3)

The scripts are also handy for handling fancier structures like maps:
node(node(empty, "one", 1, empty), "two", 2, node(empty, "three", 3, empty))
This script for this would say: if this is a "node" functor, then descend the
first field and repeat, print out the second field, print out a "->", print out
the third field and descend the fourth field and repeat.  
And the output would look like: node("one" -> 1, "two" -> 2, "three" -> 3)

				   ---

   > DISPLAY SCRIPTS
   > X
   > X   A simple scripting language can be attached to any visibility tree
   > X   node.  It's a user-definable way of fine-controlling the display of
   > X   data types.

   Ah.  Now I understand why you want a scripting language.

   An alternative approach would be to provide some Mercury-level
   hook which the user could use to control visibility of
   a particular type, e.g. using typeclasses.

That would be much more convenient than using scripts.
But they're still not dynamic:  I don't think it is possible to write custom
hooks for every conceivable type.  It would make more sense to have a set of
commonly used scripts provided as default, with the user being able to define
their own scripts.

				   ---

   I guess this doesn't work yet because we don't have a good way
   of doing these sort of hooks in Mercury.  Typeclasses aren't quite
   enough, we also need dynamic type-class casts (overlapping instance
   declarations would be another way of achieving the same effect, but
   we don't have them either).

   Still, I think it would probably be best to leave off the scripting
   language for the moment.

Do you mean using dynamically code to install more hooks at runtime?
That would still mean writing Mercury code, compiling it, and then dynamically
linking it in.  It's ultimately much messier than writing a script.

				   ---

   > X   cd <path>
   > X      Changes the current path to <path>.  

   I'm not sure that it would be a good idea to reuse "cd" as the name
   for this command.  Something else might be a better idea.
   Perhaps "goto".

Term trees have some of the properties of directory trees.  When moving around
through a term tree, there's a notion of a 'current path' (./), a parent term
(../) and the term tree root (/).  It would probably make sense to use "cd" as
a convenient analogy.

				   ---

   > term_interface__builtin(Univ) :-
   > X	term__univ_to_term(Univ, Term),
   > X	Term = term__functor(Const, _, _),
   > X	( Const = term__integer(_) ;
   > X	  Const = term__float(_) ;
   > X	  Const = term__string(_) ).

   This is not an adequate way of testing for builtins.
   int, float, and string are not the only builtins; others include

     character
     array(T)
     c_pointer
     io__state
     univ
     type_info

Is there a more convenient way of checking for builtin types?

-- Ian!!
Lesser artists borrow. Great artists steal.