Advanced Redex Trails:

limitations, bugs, and workarounds


This is a fuller list of limitations, bugs, and workarounds in the prototype tracing system, Hat. (There is also an overview page, and a more detailed page about the browser interface.) Please mail us at ART-team@cs.york.ac.uk to report any new limitations, bugs, and workarounds that you discover.

Bugs and holes in the current trace compiler:

The traced program evaluates too much
The traced program
main = print (True || h True)
   
h = h
does not terminate. The reason is that the trace transformation assumes that all values of type R t are of the form R v Trace. In the example the Sat for h True has to be constructed (to be able to show the expression). h has value R h' (Nm "h"). Then h' is applied to R True (Nm "True"). However, h' has value bottom and hence the value of this application is also bottom, that is, is not of the form R v Trace.

This program has the additinal problem that it cannot be interrupted with Control-C. Interruption is only possible when reduction of a traced application is entered, not such an internal, real application.

main = print (True || h True True)
   
h x = h x
This does not terminate for the same reason as above. It can, however, be interrupted and finally runs out of heap.
Oversaturated applications are not shown correctly
main = print ((h True) True)
h x = f
f x = False
correctly gives h True as parent of f and main as parent of f True, but
main = print (h True True)
h x = f
f x = False
incorrectly gives h True True as parent of f and also of f True!

Oversatured applications are handled completely the wrong way round by the transformation. There is no code to every create an App trace node for the saturated application f True.

Overloaded numeric constants all fixed
literal Integers in patterns cause an "fsExp: strange expression" compiler error
(fixed, August 2000)
literal Ints/Integers in definitions cause an "fsExp: strange expression" compiler error
(fixed, July 2000)
literal floats cause an "overloaded rational" compiler error (fixed, August 2000)
Pattern bindings are projections but not handled as such
Example:
translateStatement symboltable startAddress (Assignment identifier exp)
    = (expCode ++ [Sto varAddress], expCodeLength+1)
    where
    (expCode, expCodeLength) = translateExpression symboltable startAddress exp
    Just varAddress = tableRead identifier symboltable
The parent of the value of varAddress should be tableRead .... Instead the parent is the parent of the object that was originally inserted into the table. Here definitely reductions are not recorded in the trail.
Strictness annotations in data type definitions
are not transformed correctly. With tracing, the data constructor is no longer strict in an argument annotated with !. Example:
data Test = T !Bool

f (T x) = True

t = error "Hello"

main = print (f (T t))
With tracing this program prints True, although it should abort with the error message "Hello".
Type Synonyms
Type synonyms for arrow types are not necessarily translated correctly. In fact, at the moment they are not translated at all.
newtype (fixed 18/8/00)
A newtype often leads to a segmentation fault of the traced program. More precisely, pattern matching on the data constructor yields a nonsense value, probably a pointer is interpreted as data constructor. For example:
newtype Test = T Int

f (T x) = x

main = print (f (T 3))
yields 13493678.
Higher-Order Types
Data types with type variables of a kind beyond simple * cannot be handled by the transformation. Currently not even the normal nhc can handle them.

When the latter problem is solved (or for a nhc independent version), the tracing transformation can be changed to handle higher-order type variables. We introduce a data type

newtype Fun a b = Trace -> R a -> R b
and the transformation replaces all ->'s by Fun.
Records
Records are currently not supported.
Derived Classes (fixed, July 2000)
Derived classes do not work correctly. Hence read does not work when derived. It demands an instance of class Read for the tracing type R.
The cause is that data types are transformed for tracing before deriving. The order should be reversed.
Prelude and Libraries
libraries Array, Directory, etc. missing
functions readFile, appendFile are missing from library IO
more generally, output IO is `special' because the tracer has to record it such that the user can later select trails from it. Thus, it is unclear what the meaning of many IO functions should be.
Unidentified bugs
on one occasion the compiler stopped with No match in _dCaf
on a few occasions the compiler crashed with heap overrun

Bugs and holes in the run time system part for tracing

Our of heap space
Currently also a tracing program just abort, if it runs out of heap space. It should connect to the browser instead. Probably the same problem occurs, if the program runs out of stack space.
Runtime system crashes
Program exited normally.
in_bind_ne: bindin_bind_ne: resolver error. Host = LOCAL
in_bind_ne: in_bind RETURNED BAD VALUE: -1
This seems to happen when the browser has just been started and may still be initialising, not yet able to communicate.

Wishes

Trusting derived instances
Currently derived instances have the same trusting status as the module in which they are derived. However, these instances should be trusted, because they are derived automatically. Possibly an additional compiler flag would permit to make these instances untrusted.

The same applies to other compiler-generated code, e.g. to the automatically created selectors for field names.


This page last modified: 2001.01.17.