3 ms·

As a clojure fan, I agree about conses. It's rare to use something like that. Personally I'm happy equality doesn't work like common lisp. See here for a pos

As a clojure fan, I agree about conses. It's rare to use something like that. Personally I'm happy equality doesn't work like common lisp. See here for a post explaining equality in CL: http://eli.thegreenplace.net/2004/08/08/equality-in-lisp http://eli.thegreenplace.net/2004/08/08/equality-in-lisp It's old and I don't use common lisp, so please correct me or the post if needed. I've tried to get into lisp numerous times. Clojure was the one that clicked for me. I can't say if that's because of clojure or because it was just the right time for me after N times trying to get lisp. Every now and then I poke at a scheme or CL. Scheme seems do-able for me, particularly Chicken Scheme, but I everytime I try CL, I come across what seems like too many functions to do what it seems like one function should do. Whenever I see something like SETQ, etc., that's a big turn off for me. On the other hand, I really dislike Clojure startup times. Doesn't matter for server/long running apps, but when you are debugging or iterating, it gets to be a pain. There are some mitigations with their own set of issues. Pixie and Hy have been brought to my attention. Pixie seems more or less abandoned, but Hy looks interesting. I haven't been able to tell from the docs if it has clojure datastructures (which are the best part of clojure), but Pixie does. So maybe sometime I'll try to bring those over to Hy and see if they get accepted.

qwertyuiop924 10y ago
No, what I mean is that clojure's conses are fairly useless compared to the conses of CL and Scheme. Also, all programming languages implicitly have most of those equality operators. But yeah, Scheme's equality is a bit cleaner. Not a super fan of Clojure datastructures. If I want to modify my cdr, than let my modify my cdr.
nilved 10y ago
How are conses in Clojure different from those in Scheme? Is it the implementation? Because the API seems the exact same to me.
- aidenn0 10y ago
  Not a Clojure developer but, IIRC, Clojure doesn't have conses, but rather the function cons creates a seq. A Seq in Clojure is immutable and (usually) lazy, which is nothing like what CONS makes in lisp (a mutable pair that is the basis for building singly-linked lists). Note that linked-lists are only a good data structure in fairly narrow contexts (e.g. shared structure, certain types of mutation you can do). Since Clojure is focused on limiting mutation, it makes sense for them to use Seqs instead of linked-lists.
  - qwertyuiop924 10y ago
    However, conses can be used for other types of structures as well.
  - zodiac 10y ago
    Didn't racket also make the decision to make cons create immutable lists (and using mcons for mutable lists)?
    - qwertyuiop924 10y ago
      But that's not what Clojure did. In clojure, cons cells aren't cons cells: they're a cell that can point to a sequence of some type, and contain a pointer to arbitrary data. They also do not make up lists, and have weird equality rules. Racket's conses are merely immutable.
aidenn0 10y ago
Yes, CL has old and useless functions. There is zero need to ever use SETQ for example. SETF is a pure superset of SETQ's functionality. For other examples, I don't know that I've seen a serious use of PROGV or PROG in this century either. Most experienced lisp programmers never use EQ, since EQL is more well designed, and the overhead is either negligible or nonexistent. Yes it's annoying that EQUAL doesn't recurse into non-string vectors. Useful equality in CL is roughly: EQL for comparing non-aggregate types and identity checking of aggregate types, EQUAL for comparing lists, and EQUALP for case-insensitive comparisons. Some people add in = for numeric comparisons, but that's a style question (seeing = means "these arguments are definitely going to be numbers" and not much else, as if you're doing an equality test between e.g. an integer and a float, then you're doing it wrong, and differing numeric types is the only time = is different from eql when all arguments are numbers). Comparing non-primitives is typically done with domain-specific comparison functions, as there are many ways to decide if two arbitrary objects are "equal" (for the old-saw OO example of 2d geometric shapes, you might have shape-area-equal, shape-perimeter-equal ...). Some things I like about CL: I find its package and macro system combine to be an amazing sweet spot of simplicity and power for metaprogramming. Scheme's hygienic macro system is the stuff that earned several people their doctorates; CL's is explainable in under a minute, and 99% of hygiene problems are solved by the package system (IIRC Clojure inherits its macro system from CL, using namespaces to solve the "FLET" problem). CLOS+MOP made me feel like perhaps OO wasn't the colossal mistake I'd always thought it was. It's not the only great OO system out there, but it is great and so much better than the various C++ derived systems that I was first exposed to that it will always have a special place in my heart. The condition system is great. The only quick summary I can give is that you can have condition handlers run in the stack context in which the exception was thrown (which lets you do much more useful things than running in the context in which you establish the handler, which is how all other exception systems I've seen work). Common Lisp has amazing development tools; in particular the combination of SBCL/SLIME puts nearly all other F/LOSS IDEs to shame[1]: It's a high-level language, but you can view a function's disassembly, capture instruction-level profiling data, recompile a single function and rerun all of that without stopping your program. The overhead of edit/compile/debug is essentially zero. All that being said, I do need to take a look at clojure again (I went through Fogus's "Joy of Clojure" book when it was new, but haven't touched the language since). 1: http://pryrepl.org/ http://pryrepl.org/ is apparently an attempt to bring some of this to Ruby, but I have on many occasions seen Ruby programmers say that "If you're using a debugger you're doing it wrong" and Pry doesn't seem to have a lot of users.

qwertyuiop924 10y ago

No, what I mean is that clojure's conses are fairly useless compared to the conses of CL and Scheme. Also, all programming languages implicitly have most of those equality operators. But yeah, Scheme's equality is a bit cleaner. Not a super fan of Clojure datastructures. If I want to modify my cdr, than let my modify my cdr.

nilved 10y ago

How are conses in Clojure different from those in Scheme? Is it the implementation? Because the API seems the exact same to me.

aidenn0 10y ago
Not a Clojure developer but, IIRC, Clojure doesn't have conses, but rather the function cons creates a seq. A Seq in Clojure is immutable and (usually) lazy, which is nothing like what CONS makes in lisp (a mutable pair that is the basis for building singly-linked lists). Note that linked-lists are only a good data structure in fairly narrow contexts (e.g. shared structure, certain types of mutation you can do). Since Clojure is focused on limiting mutation, it makes sense for them to use Seqs instead of linked-lists.
- qwertyuiop924 10y ago
  However, conses can be used for other types of structures as well.
- zodiac 10y ago
  Didn't racket also make the decision to make cons create immutable lists (and using mcons for mutable lists)?
  - qwertyuiop924 10y ago
    But that's not what Clojure did. In clojure, cons cells aren't cons cells: they're a cell that can point to a sequence of some type, and contain a pointer to arbitrary data. They also do not make up lists, and have weird equality rules. Racket's conses are merely immutable.

aidenn0 10y ago

Yes, CL has old and useless functions. There is zero need to ever use SETQ for example. SETF is a pure superset of SETQ's functionality. For other examples, I don't know that I've seen a serious use of PROGV or PROG in this century either. Most experienced lisp programmers never use EQ, since EQL is more well designed, and the overhead is either negligible or nonexistent. Yes it's annoying that EQUAL doesn't recurse into non-string vectors. Useful equality in CL is roughly: EQL for comparing non-aggregate types and identity checking of aggregate types, EQUAL for comparing lists, and EQUALP for case-insensitive comparisons. Some people add in = for numeric comparisons, but that's a style question (seeing = means "these arguments are definitely going to be numbers" and not much else, as if you're doing an equality test between e.g. an integer and a float, then you're doing it wrong, and differing numeric types is the only time = is different from eql when all arguments are numbers). Comparing non-primitives is typically done with domain-specific comparison functions, as there are many ways to decide if two arbitrary objects are "equal" (for the old-saw OO example of 2d geometric shapes, you might have shape-area-equal, shape-perimeter-equal ...). Some things I like about CL: I find its package and macro system combine to be an amazing sweet spot of simplicity and power for metaprogramming. Scheme's hygienic macro system is the stuff that earned several people their doctorates; CL's is explainable in under a minute, and 99% of hygiene problems are solved by the package system (IIRC Clojure inherits its macro system from CL, using namespaces to solve the "FLET" problem). CLOS+MOP made me feel like perhaps OO wasn't the colossal mistake I'd always thought it was. It's not the only great OO system out there, but it is great and so much better than the various C++ derived systems that I was first exposed to that it will always have a special place in my heart. The condition system is great. The only quick summary I can give is that you can have condition handlers run in the stack context in which the exception was thrown (which lets you do much more useful things than running in the context in which you establish the handler, which is how all other exception systems I've seen work). Common Lisp has amazing development tools; in particular the combination of SBCL/SLIME puts nearly all other F/LOSS IDEs to shame[1]: It's a high-level language, but you can view a function's disassembly, capture instruction-level profiling data, recompile a single function and rerun all of that without stopping your program. The overhead of edit/compile/debug is essentially zero. All that being said, I do need to take a look at clojure again (I went through Fogus's "Joy of Clojure" book when it was new, but haven't touched the language since). 1: http://pryrepl.org/ http://pryrepl.org/ is apparently an attempt to bring some of this to Ruby, but I have on many occasions seen Ruby programmers say that "If you're using a debugger you're doing it wrong" and Pry doesn't seem to have a lot of users.