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