[m-rev.] for review: printing higher order values and typeinfos in the debugger

[Fergus Henderson]

On 25-Feb-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 25-Feb-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > For example, for the `map' type we print out the type of the map
> > when an exception occurs.  This is useful information.
> > But for arrays we don't, due to efficiency concerns.
> > If an array index gets an exception, the information about the
> > type is available with the print_optionals command.
> 
> Actually, it isn't, not immediately.
> 
> At the moment, the print_optionals command governs what happens next time
> you arrive at a level, so in the command sequence
> 	
> 	print *
> 	print_optional on
> 	print *
> 
> the second "print *" will print the same variables as the first.
> 
> This behavior could be changed, of course.

Ah.  I wasn't aware of that.  I think that behaviour is not what the
user will expect, and so it would be good to change it.

(But I think it's worth documenting in the NEWS file regardless.)

> > Also, now that I look at it a bit closer, I don't see why type_desc/0
> > should be ignored.  I understand why special handling is needed for
> > type_ctor_desc/0.  But in the existing C back-end, type_desc/0 is
> > represented just as MR_TypeInfo.  Is there any reason why the current
> > code won't handle type_desc/0 correctly already?
> > Can't the first line after the comment in the code below be deleted?
> 
> Doing so would have two effects I don't like: locking us into the design
> decision that a type_desc has the same representation as a type_info (which
> will itself have two different representations for different back ends),

It doesn't lock us into such a design.  It just means that when
implementing such a design, we'd need to make sure that `deconstruct'
continues to work for type_descs, to avoid a regression in the debugger.
But we'd need to make that work anyway, to avoid a regression in
`deconstruct' itself (which is more important anyway -- users might
well right code which depends on the latter, but it's very unlikely for
them to write code which depends on the debugger's behaviour).

> and confusing users by printing type_descs without printing type_ctor_descs,
> when probably the most important predicate that deals with type_descs,
> type_ctor_and_args, returns a type_ctor_desc too.

The most important predicate that deals with type_descs is type_of/1,
IMHO.  100% of applications which use type_ctor_descs will use type_of/1
and type_descs at some point.  On the other hand, many applications may
use type_of/1 but not make any use of type_ctor_descs.  It's going to
be less confusing on the whole to get things right for those applications.

Even for applications which use both type_descs and type_ctor_descs,
I don't think it will be more confusing to print type_descs but not
type_ctor_descs than it would be to not print either.  And printing
type_descs is a lot more useful.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------