News for hackers. Stuff that matters.

A comment on Racket vs Clojure (it's all about the data structures). Parent comment

Re:Racket vs Clojure (it's all about the data structures) by Xurinos on Wednesday August 11, 2010 @02:41PM (#1595597)
> this kind of code is quite common due to the design of almost every Lisp

Scheme != Lisp (maybe a "lisp")

I was trying to figure out what you mean from a Common Lisp perspective. Are you referring to the author's example?

  All of Clojure's collections can be treated as if they 
  were a list, and you can write algorithms to traverse 
  them using the same pattern of empty?/first/rest that 
  you'd use on a list. This means that all the powerful 
  higher-order functions like map/filter/reduce work just 
  as well on a vector as a list.
Just off the top of my head, CL's map and reduce can operate on lists or vectors. Pretty much anywhere you see the word "sequence" in the spec, you can work with a vector or a list (and several other types). I can understand the point that it might be awkward in Racket; does it get awkward in CL?

I cannot speak for Racket/Scheme's limitations, but I am looking to see where Clojure might be a better choice for me than CL other than interoperability with Java. I have not seen a good data structures argument yet.

[ Parent | on HN ]
Re:Racket vs Clojure (it's all about the data structures) by sedachv on Wednesday August 11, 2010 @05:39PM (#1596241)
CL ostensibly comes with a built-in sequence class. The problem is none of the various utility methods that are included are generic functions, so in practice it doesn't do much good. Christophe Rhodes worked on an extensible sequence standard:

http://www.doc.gold.ac.uk/~mas01cr/talks/2007-04-03%20Cambri...

It's implemented in SBCL, I think there may be ports to other implementations.

This is the sort of thing the CDR (http://cdr.eurolisp.org) process is supposed to address. Right now they only have proposals for a generic hash table interface (http://cdr.eurolisp.org/document/2/index.html - not integrated with sequences!), and fixes to concatenate-sequence (http://cdr.eurolisp.org/document/3/index.html).

In summary: CL comes with some nicer datastructures than Scheme (hash tables, multidimensional and adjustable arrays), but other than that it has the same problems.

[ Parent | on HN ]
Re:Racket vs Clojure (it's all about the data structures) by Xurinos on Wednesday August 11, 2010 @05:50PM (#1596273)
That was good information. Thank you.

My takeaway for this is this -- If the utility methods are not generic functions, it is fairly trivial to write a generic function that wraps around the utility method and then play with additional types as needed. So if the problem with the data structures in scheme and Lisp are that people are spending a whole lot of time repeating conversion patterns, shouldn't those people be developing abstractions, at least for their own use/libraries?

When I read this kind of complaint, I get the feeling people tend to want Batteries Included Their Way. They do not go the one step further to wrap things in the manner they desire. Like-minded folks do not get the benefit of those wrappers. jQuery was a hit because someone deployed his library of common JavaScript patterns.

[ Parent | on HN ]
Re:Racket vs Clojure (it's all about the data structures) by sedachv on Wednesday August 11, 2010 @06:19PM (#1596373)
The problem is that any time you want to interface to code outside of that library, you run into the same "convert vector to list" problem the OP was talking about. The solution really is to cram down Rhodes' proposal into every implementation's throat, so that all existing code can start handling new sequence types.
[ Parent | on HN ]
Re:Racket vs Clojure (it's all about the data structures) by rw on Wednesday August 11, 2010 @03:17PM (#1595740)
In Scheme (vs. Common Lisp) sequence operations are typically defined in terms of cdr, which operates on [singly-linked] lists.
[ Parent | on HN ]