anatoli wrote:
> This is all, of course, of purely academical interest. The notation
> is extremely inconvenient to do any real work. I'd rather prefer
> a real, language-supported lambda over types.
> Or... wait a minute! You did find all those problems; does it mean
&g
e notation
is extremely inconvenient to do any real work. I'd rather prefer
a real, language-supported lambda over types.
Or... wait a minute! You did find all those problems; does it mean
you tried to *use* this stuff for something? Just curious.
--
anatoli tubman
anatoli wrote:
> Attached are two interpreters: one for untyped lambda calculus,
I'm afraid the attached interpreter can't be an implementation of the
lambda calculus. For one thing, it lacks the hygiene of substitutions:
Lambda> :t lambdaEval (A (L X (L Y (A X Y))) T)
lambdaEval (A (L X
anatoli <[EMAIL PROTECTED]> writes:
> ghc -fglasgow-exts -fallow-undecidable-instances allows
> constructs which amount to lambda abstraction over types.
> I've written a small untyped lambda calculus interpreter
> in the Haskell class/instance sublanguage, just to prove
> this point. (The ter
Hal Daume III <[EMAIL PROTECTED]> wrote:
> I'd be interested in seeing how you do this. I attempted such a thing a
> while back but was unsuccessful.
Attached are two interpreters: one for untyped lambda calculus,
and one for an Unlambda-style language (combinators).
Of course pure lambda terms
