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

Zoltan Somogyi zs at cs.mu.OZ.AU
Mon Feb 25 01:52:45 AEDT 2002


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.

> > MR_PseudoTypeInfo, yes. However, the existing C definitions of type_desc
> > and type_ctor_desc are clumsy, so there is no point in keeping them. Since
> > they are not performance critical, it is ok for them to have a single
> > implementation in Mercury.
> 
> Hmm. The speed of dynamic type checks may be performance critical for
> some apps.  E.g. this is important for the speed of io__write...

Actually, I don't think it is. At the moment, io__write_univ calls
type_ctor_and_args twice, without even factoring out the common code.
Those two calls are there to provide special treatment to arrays and typeinfos.
However, I don't think either of these is strictly needed anymore. Handling
them as ordinary terms will now avoid the problems that required special
handling in the past, although it will produce slightly different output
(e.g. "<<array>>" instead of "array" as the functor name). It will also make
the speed of operations on type_descs irrelevant for io__write.

I can see how applications may find dynamic type checks of the kind performed
by univ_to_type speed critical. I find it much less likely that an application
that is not basically a prettyprinter would find operations on type_descs
speed critical.

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

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



More information about the reviews mailing list