Lispish
640
4
Advertisement
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.
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.
Advertisement
Advertisement
Advertisement
Discussion