Shortcomings of the Ivory programming system

Shortcomings of the Ivory system and issues with the Ivoryscript language are listed here

  1. Limited compiler error checking and recovery

    Up to now, the focus has been on the correct generation of byte and source code from syntactically correct scripts.

  2. Type resolution inconsistency for dynamic class methods

    This is best described with an example. Assuming:

    selectRoot :: (Name -> *)
instance Select Root where
...
(.) n = selectRoot n

    and the standard definitions for Num and Int, then there is a difference between:

    123 + .x.p

    and

    .x.p + 123

    In the first case, Int and * unify and the class type variable is substituted with Int; this results in a static dispatch using the primitive addInt. For the second case, * and Int unify and the substitution is with type *; This results in a dynamic dispatch for (+).

  3. Incorrectly returned type register

    Where there is an alternative return type, the type register is not being set correctly.

    (\!q -> case q of {True -> 123; False -> "a string"}) True

    There is a type inference issue to resolve here as well w.r.t. alternatives.

  4. Incorrect type comparison code generation

    Rules are very dependent on fast type comparisons, particularly as they are implemented with a multi-way if. For source code, the environment register need not be taken into account in almost all cases.

    An exception is be a function like: 

    foo t1::Type t2::Type = t1 = t2

    Here, incorrect code is being generated. There should be a call to the C++ primitive function eqType.

  5. Byte code architecture dependence

    The original intention was to define two forms of byte code: The idea being that multiple processors with different architectures would be able concurrently to access the same store. In practice, this has proved more difficult to implement efficiently than was anticipated, so only the latter form is in use.
home

Last update: 11 October, 2005