dmaze ([personal profile] dmaze) wrote2006-09-06 07:27 pm
Entry tags:

Some potential computing projects

  • Install Lotus Notes Designer on the Windows side of my laptop. Use it to build a Notes database to track my status reports. (Visibly work-derived, if you're wondering "why on earth Notes".)
  • Write a Scheme(-like) interpreter/compiler. Probably in Haskell.
  • Pick up my project to build a call graph from an ELF object file.
  • In the "not even a little related to work" camp, write a railroad dispatching simulator.
  • Give up on these "projects"; just play games, that's all computers were ever really meant for.

[identity profile] iabervon.livejournal.com 2006-09-11 04:59 pm (UTC)(link)
Write a Scheme(-like) interpreter/compiler. Probably in Haskell.

That's always fun, although I haven't tried doing it in a non-C-like language yet. I've got a bytecode format that seems to be suitable, if you want to avoid the cycles of finding language features that break the system design. Scheme is very tricky in that dynamic-wind is a library function, but its existance complicates the representation of closures, which is not a nice thing to have outside the core language description.

I think you should engineer a collision steered by an Atmel mega 8.

Scheme in Haskell...

[identity profile] fredrickegerman.livejournal.com 2006-09-13 05:53 pm (UTC)(link)
Has actually been done. The hardest part is interning the symbols, and you can use Data.StringMap for that nowadays. :-) And there's already a monad transformer which gives you call/cc on top of any other monad. The really fun bit is re-factoring to put the minimal amount of stuff into the IO and continuation monads and then impedence-matching the result. :-)

Or you could try using strongly-typed primitive functions and learn how to use GADTs. Hmm.

Once you understand call/cc, dynamic-wind is easy. But you need to either heap-allocate the stack or provide a mechanism for moving stack chunks to the heap and back again.

Me, I'd love to have a JIT for the lambda calculus with variable arity functions, plus a few basic types like ints. You can just use Church encoding for the rest. Dynamic points-to analysis would make it all fast...

Re: Scheme in Haskell...

[identity profile] iabervon.livejournal.com 2006-09-13 07:39 pm (UTC)(link)
The thing I found difficult about dynamic-wind was that I had Scheme continuations as interpreter continuations (using a CPS interpreter). So there was no way for it to check on dynamic scopes or call procedures when calling a continuation. The next time around, I built dynamic-scope-handling into the (bytecode) interpreter, so it could add stuff to the execution at the point of changing scopes.

But, in any case, if you implement the lambda calculus directly, and write call/cc in the obvious way without thinking about dynamic-wind, dynamic-wind is impossible to add later. At least, I think that's true; I'm now not quite sure that you can't add "check for scope-changing hooks" to the front of continuations that call/cc generates. It'd still seem fragile to make call/cc responsible for making sure that dynamic-wind's contract isn't violated.