Comments for Apocalisp

Comment on A Critique of Impure Reason by Massimo A. Dentico

Massimo A. Dentico — Fri, 06 Nov 2009 19:54:51 +0000

No act of imagination is necessary: stack-based Forth-oriented processors exist from the '80s, but they are based on usual Von Neumann architecture anyway. The alternative dataflow architecture, which is an ideal mapping of pure functional programming languages to hardware, had, unfortunately, an intrinsic problem of inefficiency back when was actively researched. Quoting from Wikipedia: ".. Instructions and their data dependencies proved to be too fine-grained to be effectively distributed in a large network. That is, the time for the instructions and tagged results to travel through a large connection network was longer than the time to actually do the computations. .." The hardware landscape is greatly changed, I don't know if this still hold today.

Comment on Structural Pattern Matching in Java by Rúnar

Rúnar — Sun, 20 Sep 2009 04:22:25 +0000

Neal,

As presented in the GoF book, the visit and accept methods are void. I suppose they don’t really have to be, but if they aren’t then you end up with something very similar to what I’ve presented here.

Comment on Structural Pattern Matching in Java by Neal Gafter

Neal Gafter — Sun, 20 Sep 2009 04:06:07 +0000

You assert that the visitor pattern relies on mutation, but I don’t see how. I’ve used the visitor pattern many times while programming with immutable data in Java.

Comment on More Scala Typehackery by michid

michid — Fri, 04 Sep 2009 16:41:38 +0000

Yes sure but my point is that it is only extensible to n variables for a fixed n not to arbitrary many.

Comment on More Scala Typehackery by apocalisp

apocalisp — Fri, 04 Sep 2009 16:28:23 +0000

I have extended this to two variables, which would indicate that it could be extended to more, but you have to modify all the Lambda traits when adding more variables. I’m looking at extending to arbitrary number of variables, and my first inclination is that you’re right. It will ultimately be improperly kinded.

Comment on More Scala Typehackery by michid

michid — Fri, 04 Sep 2009 16:23:55 +0000

After some more thinking I think it can’t. That is whether can we extend the lambda calculus implementation to an arbitrary number of variables nor can we implement the SK(I) calculus.

The Scala type system (in the way we use it here) seems to correspond to the simply typed lambda calculus with the kinds of the Scala types corresponding to the types of the lambda terms. The simply typed lambda calculus is not Turing complete and type assignment is decidable for it.

App[Lam[App[X, X]], Lam[App[X, X]]]#Eval

Is just not typeable in the simply typed lambda calculus and the compiler could actually do better here ;-)

Comment on More Scala Typehackery by apocalisp

apocalisp — Thu, 03 Sep 2009 14:03:48 +0000

I’m confident that it can be.

Comment on More Scala Typehackery by michid

michid — Thu, 03 Sep 2009 09:12:04 +0000

Pretty cool!

Can this be extended to more than one variable? For showing Turing completeness I think one would have to extend this to an arbitrary number of variables. Probably trying to implement the SKI calculus is an easier option!?

I’ll definitively have to play around with it a bit more later.

Comment on A Scala Puzzler by michid

michid — Sat, 29 Aug 2009 16:02:29 +0000

Nice puzzle, thanks!

It doesn’t seem possible to implement Exp in this way. A lambda term for exponentiation is

exp = \mn.nm

AFAIU your encoding corresponds to a simply typed lambda calculus where the kinds of the Scala types correspond to the types of the lambda terms.

The type of a church numeral is then

((Num -> Num) -> Num) -> Num

So applying a church numeral to another as done in the exp term above is a ‘type error’.

Trying to implement exp as above with Scala results in

n takes no type parameters, expected one

and similar.

BTW, your encoding is quite similar with what I came up with: http://michid.wordpress.com/2008/10/29/meta-programming-with-scala-conditional-compilation-and-loop-unrolling/

Comment on Some Notes in Hostility Toward Subtyping by apocalisp

apocalisp — Fri, 28 Aug 2009 17:38:28 +0000

Nuttycom,

I definitely agree that you have to abandon mutable data structures.