ApochPiQ suggested in a thread on practicing recursion writing a simple Lisp dialect interpreter. I took that suggestion. With an almost shockingly small amount of Python code, I have a working Lisp interpreter. So far, I've avoided the harder parts - call/cc and macros, specifically. It's now reasonably functional, and I've had fun implementing some neat stuff, like the streams system from SICP.
I'm at a cross roads now with no obvious, essential next feature to implement. My current feeling with the project so-far is that while it's been neat, almost everything I've done has had a 1-to-1 mapping onto features of Python; closures, garbage collection, dynamic typing, etc. It's less like I'm implementing Lisp and more like I'm leaching Python's features into Lisps syntax. Here's what I'm thinking my options for the next step are:
1). Macros. This requires me learning, say, Scheme's macros, which wouldn't be a bad thing either. This sounds like an ambitious project, though.
2). call-with-current-continuation. I've thought a little about this, and have yet to come up with a reasonable way to achieve it, which I guess makes it a challenge.
3). Reimplementing it all. Writing it in another language would force me to "truly" implement the features of Lisp without just using those same features in another language. C++ wouldn't be bad, but the lack of a garbage collector makes the project into something quite large, and I'm not particularly interested in writing a GC. C# would be another option, but, again, it has most of the features of Lisp already (dynamic typing, however, would be gone). I've considered Haskell, too. I've put some time into learning Haskell, but have hardly written more than factorial programs in it, so this might give me something to expand into.
4). Modify to not use Python's obviously corresponding features. Though something feels wrong about simply overlooking a language feature just to be "more hardcore". I guess it's not far from just writing it in a lower-level language like C++. This just doesn't seem too exciting.
5). Lisp compiler to the .NET CIL? I've never done anything like this before (I hadn't done anything like writing an interpreter before, either!). Would this be a phenomenal amount of work? I assume it still would let me leach the .NET garbage collector, which I consider a good thing.
6). Going through "Lisp in Small Pieces" and doing it's projects. I guess I'd rather figure this all out on my own or through referring to language specification. (I've been using Scheme's R5RS. Any other suggestions?)
What do you all think a good next project would be? Am I overestimating the difficultly of a domain-specific GC implementation? I'm interested in investing several weeks to a couple months to get something fairly concrete. I've really enjoyed the interpreter project thus-far and want to continue. I'm not interested in making this a truly useful language or project; there's already more than enough Lisp dialects out there. So speed concerns, library support, and all those actually useful things can be essentially ignored.
And my thanks to ApochPiQ for the original suggestion!
So I wrote a Lisp
Quote: C# would be another option, but, again, it has most of the features of Lisp already (dynamic typing, however, would be gone).
why is that? C# 4.0 supports dynamic types natively, or you can get the dynamic language runtime if you're using 3( though of course that is a bit more work.
Quote:
5). Lisp compiler to the .NET CIL? I've never done anything like this before (I hadn't done anything like writing an interpreter before, either!). Would this be a phenomenal amount of work? I assume it still would let me leach the .NET garbage collector, which I consider a good thing.
I don't think it would be a monumental amount of work, but it also might have a number of design decisions that would limit things (do you want access to .net types, or are the few native types sufficient?).Compiling to the cil is actually fairly easy, especially for something like lisp.
I wrote a simple Lisp interpreter in C++. It was easier than I thought. I had an extremely simple and naive garbage collection system, a stop-the-world implementation. Macros were a bit of a pain to implement though, I was never entirely happy with how I did it.
But it was fun to go from zero to Lisp in a short enough space of time. But just be aware that if you go for option #3, it will take a while for you to basically return to where you are now, and you'll be sitting there deciding what to do next shortly enough.
#5 sounds like it might be fun. I personally wouldn't bother with #4.
But it was fun to go from zero to Lisp in a short enough space of time. But just be aware that if you go for option #3, it will take a while for you to basically return to where you are now, and you'll be sitting there deciding what to do next shortly enough.
#5 sounds like it might be fun. I personally wouldn't bother with #4.
Author
Quote:Original post by TelastynQuote: C# would be another option, but, again, it has most of the features of Lisp already (dynamic typing, however, would be gone).
why is that? C# 4.0 supports dynamic types natively, or you can get the dynamic language runtime if you're using 3( though of course that is a bit more work.
Shows my ignorance. I haven't touched C# for a while, and even then I was far from pro.
Quote:Quote:
5). Lisp compiler to the .NET CIL? I've never done anything like this before (I hadn't done anything like writing an interpreter before, either!). Would this be a phenomenal amount of work? I assume it still would let me leach the .NET garbage collector, which I consider a good thing.
I don't think it would be a monumental amount of work, but it also might have a number of design decisions that would limit things (do you want access to .net types, or are the few native types sufficient?).Compiling to the cil is actually fairly easy, especially for something like lisp.
What do you mean by "acces to .net types, or are the few natives types sufficient?" I don't need to be able to access a class in C# from Lisp, if that's what you mean.
Update: Thanks for the response, rip-off. If doing a basic reference counting and tracing GC isn't so bad, this sounds like a reasonable option.
Glad to know you found the suggestion useful [smile]
Here's a suggestion for you, in the vein of the original "practicing recursion" concept: implement macros, but implement them in your Lisp dialect instead of in the parent interpreter. In other words, give full native access to the program's code in s-expression form to the program itself, and allow inspection and (probably limited) mutation of the code. If you want to, you could even reimplement your interpreter in itself, which is always a fun thing to do with Lisps.
I think you'll find that to be a challenge but not terribly hard, since Lisp syntax is so elegantly self-recursive. It's bizarrely rewarding, too, and will probably teach you some excellent lessons that'll improve your programming overall.
Here's a suggestion for you, in the vein of the original "practicing recursion" concept: implement macros, but implement them in your Lisp dialect instead of in the parent interpreter. In other words, give full native access to the program's code in s-expression form to the program itself, and allow inspection and (probably limited) mutation of the code. If you want to, you could even reimplement your interpreter in itself, which is always a fun thing to do with Lisps.
I think you'll find that to be a challenge but not terribly hard, since Lisp syntax is so elegantly self-recursive. It's bizarrely rewarding, too, and will probably teach you some excellent lessons that'll improve your programming overall.
Author
I've decided to make a C++ implementation. I'm still uneasy about the GC, so for right now I'm just making an everything-leaks-but-I-don't-care version. I'll consider doing your suggestion, ApochPiQ, when I'm back up-and-running in this version.
In case you didn't know, I'd also check out IronScheme which is a CLR implementation. There is also Yarr, ClojureCLR and others to learn from.
Otherwise, search for tiny lisp which I believe uses third party GC.
Otherwise, search for tiny lisp which I believe uses third party GC.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
