John Tromp <[email protected]> wrote to me: > dear Andre, > You may want to include my entire message, since my response to the fonc list > bounced (unsurprisingly, as I'm not a member), and was only seen by > you and Jan... > >> Apples and oranges look far more similar than PGA and BLC. >> I would say it is more a case of apples and apple trees. > > Let's say that comparing PGA and BLC is like comparing oranges and > apple trees:-)
Pears and apple trees then, Ok? Below I quote John's entire first message (and repeat my remark). >> John Tromp <[email protected]> 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:-) Apples and oranges look far more similar than PGA and BLC. I would say it is more a case of apples and apple trees. Very different in appearance, but deep inside they share DNA, and the one form gives birth to the other form. > >> 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... > >> 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. > >> 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). > > regards, > -John
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
