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.
no subject
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...
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...
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.