For review: Term display helper

[Fergus Henderson]

On 02-Mar-1998, Waye-Ian CHIEW <chiew at ibm.net> wrote:
> [fjh wrote:]
> 
>    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.

Yes.  Since Prolog (and hence Mercury) syntax has a special case for lists,
the Mercury library has special-case code to deal with them, both for
reading and for writing.

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

Agreed.

> 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)

Here I disagree.  The output should be [1, 2, 3].
If you have a scripting language, it should be powerful
enough to produce that output.

If you're going to have a scripting language at all, it
should be powerful enough and expressive enough to write
things that are significantly more complex than this.
The world is littered with insufficiently expressive,
poorly designed scripting languages, many of them
cryptic and/or arcane.  We should think very carefully
before adding another one.  If we do decide to have
a scripting language, then it would probably be best
to reuse one of the languages that was explicitly designed
for use as an embedded scripting language (e.g. tcl, Python, etc.).

>    > 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:

Well, they could be.  A good debugger would provide a dynamic
environment in which you can easily load in Mercury code.

>    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?

No, by "dynamic" I just meant doing type-casts which were checked at
run-time.  But now that you point it out, yes, you could use dynamic
linking rather than adding a new module to your program and relinking.

> That would still mean writing Mercury code, compiling it, and then dynamically
> linking it in.  It's ultimately much messier than writing a script.

Not necessarily.  Compiling it and dynamically linking it in should
be a single command.  It may be a trifle slower to load (even if the
system only compiles it to bytecode) but doing things this way would
save the user from having to learn yet another scripting language.

>    > 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?

I don't think "builtin type" is the right abstraction to use here
anyway.  (What do you mean by builtin, anyway?  There are various
different categories of builtins.)   I think the right abstraction
is "atomic".  In particular, array, univ, and type_info are all
builtin, but you probably don't want the term helper to display
entire arrays or univs as single entities.

As for how to do it, have a look at the technique used in
term__univ_to_term in library/term.m, which I think is
probably the best way to do it currently.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.