| Age | Commit message (Collapse) | Author |
|---|
|
|
|
abstract syntax
|
|
|
|
|
|
|
|
|
|
Haskell runtime but will be intepreted in the C runtime
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libgu
|
|
|
|
|
|
|
|
nullary constructors. closures are dynamically allocated only for CAFs. this reduces memory use and time to allocate dynamic closures
|
|
|
|
|
|
|
|
the pgf_evaluate_expr_thunk function. this ensures lazyness
|
|
|
|
|
|
a failing function will not crash
|
|
|
|
|
|
|
|
you try to use it
|
|
|
|
|
|
|
|
|
|
|
|
somehow did not push before
|
|
|
|
machines
|
|
of values w.r.t the type P. This was previously not checked, and caused hard-to-find run-time errors.
|
|
|
|
accidentally. silence two harmless warnings
|
|
abstract syntax. there might be some bugs yet to be found, meta variables and computation under lambda is only partially supported
|
|
loadConcr, unloadConcr and addLiteral modify the Concr structure as a side
effect. This means that other functions with a Concr argument (e.g. parse
and linearize) are no longer pure.
Possible solutions:
1. Don't try to hide the imperative nature of the C run-time system: remove
all uses of unsafePerformIO and let all functions operate in the IO monad.
2. Don't export functions with side effects. Perhaps the desired functionality
of loadConcr, unloadConcr and addLiteral can be folded into readPGF.
The Concr structures can then treaded as immutable after after the
readPGF function returns...
|
|
|
|
|
|
rules, since they are easily compilable to byte code. This fails in the Haskell runtime since let expressions are not allowed as abstract syntax expressions.
|
|
|
|
|
|
that now we can compute with lambda functions and with true tail recursion
|
|
|
|
|
