dahlia

http://groups.google.com/group/lisphp

I made the mailing list (Google Groups) which is the place for discussion about Lisphp:

[email protected]

Join us if you are interested in this project!

dahlia•

on July 6, 2010

Try this:

  $env['echo'] = new Lisphp_Runtime_PHPFunction(create_function('', '
      $args = func_get_args();
      foreach ($args as $arg) echo $arg;
  '));

after:

  $env = Lisphp_Environment::full();

jcw•

on July 6, 2010

Thanks! From the 'try lisphp' page, I assumed that echo was built in.

dahlia•

on July 5, 2010

I implemented cdr just to respect a Lisp tradition. Lisphp's Lisphp_List type isn't a linked list but a subtype of ArrayObject, which supports random access. So instead of doing:

  (car (cdr (cdr (cdr list))))

you should just do:

  (at list 3)

jacquesm•

on July 5, 2010

Yes, that's what I thought, and I don't see a real way around it.

The bigger problem is in code that consumes the lists item by item, every time an extra copy of the remainder of the list will be made, there it is much harder to work around this.

Very neat code by the way, thanks a ton for making this.

I'll be playing around with it for a bit, I've written a chunk of code for a small site a while ago in a 'functional' PHP style (as in, no assignments except at the highest level), I'll see if I can convert that project to your lisp dialect and get it to work.

Scriptor•

on July 5, 2010

It could be mitigated in some cases as long as the garbage collector is working fine. For example, in a tail-recursive function that uses a first/rest pattern to go through an array a new copy would normally be allocated with each recurse. If LispHP can do some form of tail recursion elimination, it will theoretically take up constant memory and hopefully the GC takes care of the practical part.

jules•

on July 5, 2010

Even if memory usage weren't a problem you still have O(n) time for cdr. This may not be a problem if you implement the higher level functions (map, filter, etc.) efficiently.

eru•

on July 6, 2010

Yes, higher order functions (especially foldr (resp. reduce)) are the way to go.

on July 5, 2010

Since Lisphp is a new dialect, you don't need to worry about backward-compatibility. You should get rid of car/cdr entirely. There is no inherent reason for using linked lists for anything - even s-expressions. For example, no one has ever complained about the lack of car/cdr in Parenscript (although to be fair, Parenscript is not homoiconic, just a translator from CL to JS). Having a good backquote-comma templating syntax is more valuable.

You should even get rid of a custom type for Lisphp sequences and use PHP arrays directly. Ditto all other datatypes. Then if you use PHP's calling convention you should be able to call PHP code directly without needing USE and FROM, and more importantly PHP code can do the same to Lisphp with minimal pain. That way writing Lisphp libraries for others to use becomes viable.

jacquesm•

on July 5, 2010

I think it's actually quite neat that it tries to stay close to the lisp code that you see in examples and books about lisp.

on July 5, 2010

What's the point of sacrificing something like platform integration for car/cdr? Anyone who is going to want to use Lisphp for real work is not going to have a problem writing their code to use arrays. Anyone who thinks that car/cdr is more valuable than platform integration is not going to use Lisphp for real work. And everyone else will come by and say "Lisphp has those weird car/cdr and it can't even work with PHP libraries without glue code, Lisp is a toy."

on July 5, 2010

Call them what you want. First/car & rest/cdr are the classic tool for writing code that iterates across datasets.

on July 6, 2010

Recursion, map, and fold can be used for iteration. car/cdr is just one way to access elements of a sequence.

on July 6, 2010

Think about what you just said and why it's not a valid rebuttal. I know you know better.

Hint: via recursion, how do you advance along a sequence in a collection-agnostic way?

on July 6, 2010

So now iterators mean car/cdr is "classic" so it should be present in all Lisp dialects from here to eternity?

on July 6, 2010

Again, you can call them "first" and "rest" if you like.

It is the ability to decompose an arbitrary sequential data structure efficiently that is important. It's not important because of any historical bias; it's important because it is incredibly useful.

If you can't support first/rest in an efficient manner, it is a bad sign.

on July 6, 2010

So all those other programming languages that come with arrays and not linked lists are completely useless? Mildly useless? Only kind of useless? Or is it the case that it really doesn't matter?

on July 6, 2010

Most of them DO provide a way to do this. For example, Ruby is array based but provides a way to do this through enum. The lispish way is first/rest. Clojure, a lisp with very novel data structures, does this just fine even with associative arrays and vectors. It introduces a seq abstraction to support it.

It's important when you need to write your own iteration primitives. Map, fold, etc are all well and good, but sometimes they won't do because the iteration may require some unusual steps.

In your particular dialect of lisp, what does the code for writing map or fold look like? The one that doesn't copy memory egregiously, that is. And how bad must the performance of javascript linked lists be to scare you away from them so damn hard, anyways?

Or perhaps, what you're supporting is a "lispish" language that isn't really something we should directly compare to lisp, in the vein of Nu?

on July 7, 2010

I don't have a dialect of Lisp. I work on a translator from a subset of Common Lisp to JavaScript (http://common-lisp.net/project/parenscript/). In particular, this subset does not have car/cdr, or any other list manipulation functions. No one has ever complained about this.

This is map:

(defun map (fn arr) "Call FN on each element in ARR and return the returned values in a new array." ;; In newer versions of ECMAScript, this may call Array.map, too (let ((idx 0) (result (array))) (dolist (el arr) (setf (aref result idx) (fn el)) (setf idx (1+ idx))) (return result)))

This is reduce:

(defun reduce (func list &optional init) ;; the use of init here is actually a bit broken wrt null (let* ((acc)) (do* ((i (if init -1 0) (1+ i)) (acc (if init init (elt list 0)) (func acc (elt list i)))) ((>= i (1- (length list))))) (return acc)))

What would a linked list data structure provide? Incompatibility with all other JavaScript code and a mandatory runtime library?

Thanks for introducing me to Nu btw. What makes you say that it is not a Lisp?

dahlia•

on July 7, 2010

Lisphp's map/filter/reduce functions are implemented in the same manner that Parentscript does.

This is map: http://github.com/dahlia/lisphp/blob/81849070ac7ff13948786b5...

This is filter: http://github.com/dahlia/lisphp/blob/81849070ac7ff13948786b5...

This is fold: http://github.com/dahlia/lisphp/blob/81849070ac7ff13948786b5...

Lisphp respect the iterator protocol of PHP instead of Lisp tradition in the practical reason.

jrockway•

on July 6, 2010

There is no inherent reason for using linked lists for anything

Uh, constant-time insertions?

on July 6, 2010

Did you read the parent post?

dahlia•

on July 5, 2010

http://dahlia.ruree.net/try-lisphp/

I'm the author of this, I made the web REPL also.

Well, of course, it uses a sandbox environment.

mahmud•

on July 5, 2010

From a quick look, you managed to get one thing right, even though it baffles even respected language implementers: a proper stack trace on error. Most people who write a HLL interpreter in another HLL tend to cheat and implement a half-baked source to source translator.

[Edit:

Question: Why does it have T, NIL, #T and #F? what roles do these symbols play in the language; which ones are canonical truth values, which ones signify list termination, and which ones signify the empty value? This is the perennial Lisp question.]

on July 5, 2010

> Most people who write a HLL interpreter in another HLL tend to cheat and implement a half-baked source to source translator.

Is this a jab at the Lisp tradition of compiled sublanguages?

mahmud•

on July 5, 2010

It's a jab against the general case, below.

A lame, wasteful little script to print out a TODO list ;-)

  (defun map-print (item list)
    (mapcar (lambda (x)
  	    (format t "~a in ~a~%" item x)) list))
  
  (defun permute (list)
    (mapcar (lambda (x)
  	    (map-print x list)) list))
  
  (defun languages ()
    (destructuring-bind (response headers body)
        (trivial-http:http-get "http://mahmud.arablug.org/languages.txt")
      (when (= response 200)
        (loop for line = (read-line body nil nil)
  	 while line
  	 collecting line))))
  
  (permute (languages))

jimbokun•

on July 5, 2010

Bad stack traces is certainly one of the major complaints against Clojure.