Jump to content
  • Advertisement
Sign in to follow this  
Ezbez

Unity So I wrote a Lisp

This topic is 2982 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
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.


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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!