Hi John and Andre,
On Mon, 25 Mar 2013, John Tromp wrote:
dear Andre/Jan,
PGA is very different from BLC of course, but both are a simple linear
notations. PGA starts with jump instructions, and it has step by step
extensions for variables, control structures, semaphores etc. It has been
used as a projection of Ruby's OO constructs.
So I hope PGA could give you some ideas.
PGA looks like a notation for control flow as a basis for an imperative
language. BLC is a self-contained pure functional language aimed at
minimal programs. This seems a case of comparing apples and oranges:-)
I had a quick look at PGA it and it seems to be more like a minimalistic
assembler. E.g. the core language seems to have variable names and jump
statements in there (correct me if I am wrong). To introduce variables I
was rather thinking of something were you would compile/project "x + 1" to
((lambda x (+ x 1)) x). I.e. evaluation takes place "inside" a lambda
expression.
That said, maybe there are some nice ideas in PGA on how to compile DSLs
to BLC.
After reading John Tromp's paper [1] (also see De Bruijn Index [2]) I got
very interested in Binary Lambda Calculus (BLC). In my little spare time I
implemented a BLC interpreter in C [3, 4].
Cool! You can also find a simple interpreter on my webpage,
from which I derived the IOCCC entry at
http://www.ioccc.org/2012/tromp/tromp.c
http://www.ioccc.org/2012/tromp/hint.html
that uses several interesting sample BLC programs,
which you may want to try as additional tests for your interpreter.
My C implementations still trail my Haskell implementation in
flexibility, robustness and performance though...
Yes, I saw 'tromp.c' previously ;) Sure, I'll have a look at running less
trivial programs, soon.
I'm still undecided about how to approach some things:
* How does parallel processing fit into the picture?
* What's the best way to implement a DSL including booleans, integers,
floating point numbers, strings, .. on top of BLC?
* Is it possible to describe the electronics of integer addition and
multiplication in BLC and still have it jit-compiled to run efficiently on
x86 hardware?
* How to implement I/O (maybe use monadic objects)?
All these features are somewhat beyond the scope of BLC, and
most either require, or benefit greatly, from a type system, which is
purposely lacking in BLC. I think you should look at a language
like Haskell for achieving such goals.
I'm thinking about using a dynamic type system like in Ruby. Or maybe
there is no need for a type system. Maybe it is possible to have a DSL
which maps 'true' to 0000110 internally and then converts it back when
printing out a result. Maybe it could be a similar concept as in Ruby
where every object has an 'inspect' method which is called by the REPL to
print a result.
Could the I/O
implementation provide equivalent functions to Scheme's quote and eval, too?
The binary encoding of terms in BLC serves as the quoted form,
while the 210 bit interpreter is your eval. You can write a quote function,
but it needs an already quoted form as input (and gives you a double
quoted form as output).
I see. That's "eval" right there :)
Maybe "quote" could be a function which returns the following
subexpression as a list. E.g.:
quote 0010 -> (false, false, true, false)
where quote would be a global variable (e.g. 110) and the list (false,
false, true, false) would be represented as shown in your paper.
Best regards
Jan
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
