5 ms·
Well, I suppose it's better that they re-use someone else's gratuitously different syntax than invent their own gratuitously different syntax.
by M_Bakhtiari 9y ago
Well, I suppose it's better that they re-use someone else's gratuitously different syntax than invent their own gratuitously different syntax.
- fsloth 9y agoI think most modern programmers prefer explicit destructuring and taking an element from a collection by its key rather than excplicitly traveling node links using car and cadr. The 'original' lisp has some really arbitrary naming conventions. Languages are cognitive tools and as such they should be able to evolve, rather than dogmatically stick to a specific formulation laid down in the formative years of a field. It does not manner how you name your tokens or how you choose to destruct your data structures. It's still lisp.
- _delirium 9y ago> taking an element from a collection by its key rather than excplicitly traveling node links using car and cadr Isn't that also the norm in Common Lisp? You can do any convoluted thing you want, of course, but in my own code, I retrieve elements by key using e.g. 'getf' or 'gethash'. (I do agree that there are many naming warts.)
- lispm 9y ago> original' lisp has some really arbitrary naming conventions. Like car and cdr? Check the Carp manual for some surprise arbitrary naming.
- aidenn0 9y agoI disagree that Clojure's AST changes are gratuitous. Rich has repeatedly provided his reasons for them. You may think they are bad reasons, but it's not like he just said "ZOMG there are too many parens!" That being said, I tend to use destructuring in common-lisp, and if you are taking an element from a collection by using c*r then you are probably doing it wrong. Optima has more complete support for destructuring, but this works just fine in CL with out any libraries: (let ((some-plist '(:foo 1 :bar 2))) (destructuring-bind (&key foo &allow-other-keys) some-plist foo))
- deleted 9y ago[deleted]
- kbp 9y agoAnd while it didn't make it into the Common Lisp version of LET, there were versions in earlier dialects that supported destructuring. For example, the Maclisp reference manual's description of LET[0] says: It is permissible to place an s-expression pattern in place of a symbol in the (sym init) form of an element of the bvlspec. The symbols in the pattern will become bound to the matching elements of the initialization (see DESETQ). This kind of pattern-matched assignment is called destructuring. (let (((a b) '(1 2))) (cons b a)) => (2 . 1) 0: http://www.maclisp.info/pitmanual/contro.html#5.6.1 http://www.maclisp.info/pitmanual/contro.html#5.6.1
- deleted 9y ago[deleted]
- kbp 9y ago> I think most modern programmers prefer explicit destructuring and taking an element from a collection by its key rather than excplicitly traveling node links using car and cadr. Then they'd be happy with Lisp from 40 years ago. Common Lisp (which was not the first to have either feature) has DESTRUCTURING-BIND (as well as some other constructs like extended lambda lists and within LOOP) where you can use destructuring, and it has generic sequence functions that work on more than lists like MAP, REMOVE-IF-NOT, REDUCE, etc, as well as lookup functions for getting things out of key-value maps (list-based or not) by key, or from sequences by index. Explicitly cdring down lists is mostly only done in introductory textbooks. It feels like a lot of Clojure advocacy is written in terms of this "Lisp before Clojure" strawman of some minimalist Scheme subset. Lisp has had arrays, dictionaries, records, etc (with literal syntax and proper accessors), as well as destructuring and generic sequence functions, for almost half a century (more than half a century for some of that). Whether or not you prefer Clojure's syntax for those things, Lisp had those things long before Clojure existed.
- pjmlp 9y agoActually I do prefer Clojure's approach better than traditional Lisp syntax.
- fithisux 9y agoMe too. My only problem with Clojure is that it is not available in a native flavor like most Schemes or CLs. Otherwise it is a very good substrate for the evolution of CL. Despite the functional style advertised by Javascript, at least for me Clojure ticks almost all the points of a proper functional language except one, which is fixed by core.typed. SML should take a closer look at what is happening with Clojure for its SMLnext proposals.