Sign in to follow this  
  • entries
    260
  • comments
    948
  • views
    175353

Lispish

Sign in to follow this  
Pouya

75 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

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