Changes between Version 1 and Version 2 of PolymorphicDynamic


Ignore:
Timestamp:
Jul 2, 2011 2:44:06 AM (4 years ago)
Author:
vivian
Comment:

add mobile code to use cases; transform to Interface

Legend:

Unmodified
Added
Removed
Modified
  • PolymorphicDynamic

    v1 v2  
    77There are instances when an object that is not fully known at the time of compiling asks to be linked into a running program.  This is currently possible for monomorphic types: 
    88{{{ 
    9 data Dynamic = Dynamic TypeRep Obj   -- Obj is like HValue; GHC is inconsistent 
     9data Dynamic = Dynamic TypeRep Obj   -- Obj is like HValue 
     10                                     -- GHC is inconsistent 
    1011 
    1112toDyn       :: Typeable a => a -> Dynamic 
     
    1819 
    1920I have a natural language program that uses type inference to drive a chart parser.  Each word has a type and a semantic function.  The semantic functions are actually Haskell monadic actions that may or may not be polymorphic, depending upon the particular word.  So as to be able to increase the vocabulary while running, the word definitions are looked up in a dictionary and dynamically linked at run-time.  I found cases, such as with the word `and` in which the monadic action '''must''' be polymorphic.  This extension would solve that problem. 
     21 
     22The Clean manual gives as motivation: "type-safe storage, retrieval, and communication of arbitrary expressions between (independent) applications."  This includes mobile code and serialised data, the type of which is not known until the data is loaded. 
    2023 
    2124== Interface to user (programmer) == 
     
    3740}}} 
    3841 
     42Clean allows pattern-matching at the type-level against Dynamic types: 
     43{{{ 
     44transform :: Dynamic -> [Int] 
     45transform (0 :: Int)            = [] 
     46transform (n :: Int)            = [n] 
     47transform (f :: [Int] -> [Int]) = f [1..100] 
     48transform _                     = [] 
     49}}} 
     50(From the Clean 1.0 Reference Manual)           
     51 
    3952== Design == 
    4053 
     
    4861 
    4962During type-checking, normally before run-time, a specific argument type will be given and so the compiler can figure which dictionary to use for the class methods.  By running the full type-checker at run time it should be possible to use the unification substitutions to determine which dictionary to use and then to dynamically link the class methods so that the function can be applied. 
     63 
     64 * `Typeable` instances are created at the programmer level.  Since this new feature needs to make use of the type-checker at run time, it seems reasonable to instead use (opaquely) the datatype for types that is used within the compiler. A primitive 
     65{{{ 
     66typeOf :: a -> Type 
     67}}} 
     68can be applied to an expression to yield its type, the type can then be wrapped in a Dynamic with the value of the expression. 
     69 
     70 * When injecting a `Dynamic` back into statically type-checked code, the wrapped type must be used to ensure that the `Dynamic` is of the correct type. 
     71 
     72 * In order to facilitate branching on the type of a `Dynamic`, including pattern matching in function specifications, a new keyword `typecase` could be added: 
     73{{{ 
     74myList :: Dynamic -> [Int] 
     75myList d = typecase d of 
     76             n :: Int   -> [n] 
     77             l :: [Int] -> l 
     78             _            -   > error "Could not coerce dynamic value" 
     79}}} 
     80Where `typecase` attempts to coerce to the provided type and removes the `Just` around the value.