Friday, March 13, 2009
Thursday, March 12, 2009
Log 031209
Still minimizing code. Got it down to six basic instructions. I like minimalism, I think I can get it down to four...
Wednesday, March 11, 2009
Tuesday, March 10, 2009
Log 031009
Writing code generation code (hi). Introducing lambda_return, to make sure I got my code generation right.
Sunday, March 8, 2009
Log 030809
Left neuron reconnected to right neuron; took about a month. (Or is it one-and-half month?). Hope this won't be the cycle I'll get stuck in.
ML generation is probably a bad idea. Intermediate byte code is a good idea; reduced it to approx ten instructions. That should be enough.
Various edits (code.hi, lambda.hi, ml.hi, c.hi). Introduced lambda_expand. Re-evaluating thunk code, seems correct, but should be simplified.
ML generation is probably a bad idea. Intermediate byte code is a good idea; reduced it to approx ten instructions. That should be enough.
Various edits (code.hi, lambda.hi, ml.hi, c.hi). Introduced lambda_expand. Re-evaluating thunk code, seems correct, but should be simplified.
What Kind of Development Model is This?
Instead of debugging run-time code, which gave me a headache. I decided to implement some features, to simplify the runtime. I might also go for some intermediate bytecode representation.
Compiling out methods sure is a good idea. Added about twenty lines to compile them away, and I think I can remove a few hundred lines this way.
I am also building a back-end to compile stage1 to ML instead of C. Just to get to the point that I can self-compile, once. Not even sure what that buys me, except for some confidence that most of the generated code doesn't contain errors.
Compiling out methods sure is a good idea. Added about twenty lines to compile them away, and I think I can remove a few hundred lines this way.
I am also building a back-end to compile stage1 to ML instead of C. Just to get to the point that I can self-compile, once. Not even sure what that buys me, except for some confidence that most of the generated code doesn't contain errors.
Thursday, March 5, 2009
Log 030509
A month has passed without progress. Added a counter, looking at documentation generation (Haddock), back to debugging.
Wednesday, March 4, 2009
Coalgebraic Comparison
If you lax some restrictions on types, you can describe some nice new types like coalgebraic lazy lists. Coalgebraic since it approximates the coalgebraic carrier type, and lazy since an extra construct is introduced which acts like the 'step'-function on a coalgebraic structure.
Below, an example.
Below, an example.
import "system.hi"
namespace colist (
using system
using opt
type colist = \a => unit -> opt (a, colist a)
def conil: colist a = [ _ -> nothing ]
def cocons: a -> colist a -> colist a =
[ x, xx -> [ _ -> opt.just (x, xx) ] ]
def cocat: colist a -> colist a -> colist a =
[ xx, yy ->
[ u ->
v = xx u;
if opt.nothing_test v then yy u
else
(x, xx) = opt.value v;
opt.just (x, cocat xx yy) ] ]
def cocompare: ::Ord a => colist a -> colist a -> int =
[ xx, yy ->
v0 = xx nop;
v1 = yy nop;
if opt.nothing_test v0 then
if opt.nothing_test v1 then 0 else 1
else if opt.nothing_test v1 then (0 - 1)
else
(x, xx) = opt.value v0;
(y, yy) = opt.value v1;
if x < y then (0 - 1)
else if y < x then 1
else cocompare xx yy ]
def coprint: colist int -> unit =
[ xx ->
v0 = xx nop;
if opt.nothing_test v0 then
print "nil"
else
(x, xx) = opt.value v0;
_ = print (x+0);
_ = print ", ";
_ = coprint xx;
nop ]
)
using system
using colist
type tree = \a => [ leaf | branch (tree a) a (tree a) ]
def tree_to_colist: tree a -> colist a =
[ leaf -> conil
| branch l v r ->
[ u ->
cocat (tree_to_colist l)
(cocons v (tree_to_colist r)) u ] ]
Subscribe to:
Posts (Atom)