[m-dev.] For review: declarative debugging back end (3/3)

[Fergus Henderson]

On 16-Jul-1998, Mark Anthony BROWN <dougl at cs.mu.OZ.AU> wrote:
>
> My fault, my terminology is bad.  I am trying to say that I don't want
> the front end to depend on how constructors are tagged in the back end.
> There are two broad approaches:
> 
>     - Represent atoms uniformly across all back end modules.  When a
>       back end module creates an atom, it must convert from the
>       representation it uses to the uniform representation the front
>       end expects.

Well, it could just create it in the uniform representation the
first place, couldn't it?

>     - Let back end modules use any representation, but when the front
>       end wants to look at an atom it calls a procedure provided by the
>       back end module to do so.

It's clear to me that using an abstract interface to hide the representation
details is a good idea, so that you have a clean separation between the
front-end and the back-end.

It's not clear to me that there is much advantage in supporting the use
of a different representation for each source module (rather than just for
each different declarative debugger back-end).

(This is just a comment; I don't mind if you stick with things as they
are currently.)

> The first option is what I meant by "the use of the ground representation".
> Perhaps instead s/the ground/a uniform/?
> 
> Even better, I could replace the last sentence of the comment by:
> 
> 	In particular, this allows a module to represent data the same
> 	way inside atoms as out.  This is quicker and more compact than
> 	using a uniform representation, because no conversion is required
> 	while building the EDT.

The same applies if you use `univ' as your uniform representation, doesn't it?

> > > %
> > > % This section contains the interface that the back end must
> > > % conform to.
> > > %
> > 
> > You separated this section from the "interface to the back end" section,
> > but I think they should be together.
> 
> They are separated because they will be used in different areas, which
> is not clear because nothing uses it yet.
> 
> The first section (data common to both front and back) contains types
> that the back end produces elements of for the front end to look at.
> These declarations need to be visible to the front end as well as any
> back end.
> 
> The third section (interface that the back end must conform to) contains
> types that the back end will produce elements of, but which the front
> end will not look at directly.
> 
> The middle section (interface to the front end) contains types used
> by the front end only, and provides procedures to navigate the EDT.  This
> means that a high level interface can be presented to the front end
> (via root/3 and child/2), while the back end interface (the typeclass
> methods) remains low-level.

Ah, I see.  I guess I'd say it's actually a three-layer architecture,
then, not a two-layer one.  The bottom layer is the back end.  The
middle layer is the module evaluation_tree itself (which is a fairly
thin layer of abstraction over the back end interface).  The top layer
is the front end.

Regarding my comment below,

> > In particular, it's hard to understand the `analysis' type unless you
> > see how it is used.

basically what I was saying was just that the order of the declarations
made it a bit difficult to understand things in one pass; in order to
understand it, the reader needs to first read the definition of the
analysis type, not understanding it it, then read the typeclass declaration,
and then go back and re-read the definition of the analysis type -- this time
knowing what it is for and thus being able to understand it.

So, I think it might be easier to understand if you order the three sections
in the order first the back end interface, then the stuff shared
between the two, then the front-end interface.

I could be wrong about this, of course -- to some extent these things
are a matter of taste.  If you have a good look at it and decide that
it would be easiest to understand in the order it is currently in,
then I'd be happy with that.  I just want you to have a good think about it.

> This file could arguably be split into two:
> 
> library/evaluation_tree.m:
> 
> 	Would contain the first and third sections of the original,
> 	and would be implicitly imported whenever a module is
> 	compiled to generate EDTs.
> 
> library/evaluation_tree_interface.m:
> 
> 	Would contain the second section of the original, and import
> 	evaluation_tree.  This would not be imported into back end
> 	modules, but should be explicitly imported by a programmer
> 	writing a front end.
> 
> Do you think this is a better idea?

Hmm.  I'm not sure.  It might be.

Perhaps you should just split it into three nested modules.

Anyway, that's the end of my comments for this round of reviewing.

Cheers,
	Fergus.

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