Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    260
  • comments
    948
  • views
    176054

Lispish

Sign in to follow this  
Pouya

120 views

Some rather interesting Lispish conversation has been taking place recently between a few of us, and tron3k and johnb have been actively working on some rather interesting stuff, including tron making a rather ugly, but compact notation of lisp and his samples of Y connector and factorial.

I was suggesting the formation of this new syntax inspired by tron's works on his system. Before going into details, I should mention that I'm somewhat pro-Scheme myself. Though, I wouldn't go as far as suggesting fixes to common lisp (lie *cough* some people) or arguing on a clisp forum and flaming Kent Pitman on my views.

Now, I'm not suggesting a fix, but a completely new genre/branch of modern lisp. I think some people would agree with me on saying that clisp is rather traditional (although evolutionary).
Now, scheme is a rather elegant solution and I really can't argue anything against it, pure functional language, and very beautiful. But I bumped into a few major problems when trying to use it for my applications:

1. User/network interaction is very tedious and inefficient in a pure functional language, you NEED some imperative way of processing user inputs/events in your system. I'm guessing most of you who have done formal AI had had to do an interactive intelligent game in a declarative or functional system as some point, and you might have noticed that user interaction is just disgusting to support in these languages. This is why I ended up completely reforming PLP to a semi-imperative language when I was writing my game server.

2. Object hierarchies can get rather messy when everything is just a list. So yesterday we were having this discussion of representing DOM in scheme, and it ended up with a rather horrible solution. I admit that clisp can do this "non-standard" object types better than scheme. And I ended up accepting that sax parsing is much simpler since I can just call a different functor for each node/token type.

I really like Lambda calculus and I want to keep it there as much as possible, but in the design of the new syntax I was thinking of allowing certain imperical features and object typing for the afore mentioned problems.

I'm still waiting for a doc from tron3k for explanation on his syntax.
Sign in to follow this  


4 Comments


Recommended Comments

1. "clisp" generally means CLISP and not Common Lisp.

2. Scheme is not a pure functional language.

Examples from my absurdly terse language:

Factorial:
def~fac:n if~zero?:n 1 *:n,fac:1-:n

Y combinator: (don't even TRY writing this in Common Lisp)
def~y:f[x|f:x:x]:[x|f:x:x]

Share this comment


Link to comment
Well, clarficiation:
"clisp" was just my way of shortforming common lisp. Maybe I should use c-lisp next time for confusion.

Share this comment


Link to comment
Lisp is for hippies, you people scare me.

I'm going back to hacking OpenGL onto SHilScript.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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!