Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, but the defaults matter.

And I do understand why CL is the way it is. That doesn't mean it's perfect (neither is Scheme: I just happen to prefer it).



I think the specification committee for ANSI Common Lisp would have agreed that defaults matter. It's just that their criteria for defaults was "What professional programmers are doing right now".

Historically, Scheme somewhat dodged avoided issues like argument order by excluding functionality from the language spec. My experience is that once Scheme gets expanded out and becomes Racket, the many hands show up as inconsistencies among similar functions much like Common Lisp.

Clojure, to me, seems to have the right idea: procedures that abstract operations from data types...for example there is not one mapping procedure for lists and another mapping procedure for arrays. Racket seems to be headed in that direction.


> for example there is not one mapping procedure for lists and another mapping procedure for arrays.

In Common Lisp, MAP works just as well on either.


In Clojure map also works on hashes and sets. In keeping with the previous discussion, there's also only one variety of map in Clojure. It's this orthogonality of operations and datatypes that I think is Clojure going in the right direction.

None of which is to say that Clojure isn't standing on the shoulders of giants.


You might be interested in the FSet library (among others): https://common-lisp.net/project/fset/Site/index.html


Very well said. The advent of transducers in Clojure has made this 'orthogonality' especially true.


...And us schemers have the TinyCLOS derivatives, so our map could work on any DS: by default, however, it doesn't :-(.


I like the core Scheme language, but I never could get used to its macro syntax. I prefer Common Lisp macro syntax for that, and Clojure's macro system being very similar to that of Common Lisp is an added advantage!


Syntax-rules isn't great. But pretty much every scheme has recognized this, and added an imperative hygienic macro system (think Clojure's macro system, where you can't leak environment unless you want to, but better). There are three main choices at the moment: syntax-case, sc macros, and er/ir macros.

er (or explicit rename) macros are the simplest system: they're like CL macros, with a few minor differences. Also, because Scheme is a lisp-1 with a mutable global environment, you have to rename absolutely everything. Even lambda. Yes, really.

Because of this, CHICKEN (the only scheme that uses er macros) also has ir macros, which are like er macros, except that everything is implicitly renamed unless you say otherwise. However, expanding an ir macro is O(n) under the hood, which sucks. This is probably the worst part of CHICKEN, but it works well enough.

sc (syntactic closure) macros are similar to ir macros in nature, although the syntax and abstraction is different. It's a pretty nice system, currently used in Chibi and MIT scheme, and (while it's really too early to tell) seem to be the macro system most likely to make its way into R7RS-large.

Finally, there's syntax-case. It's used by racket (I think: racket's syntax-case has apparently been heavily extended) and guile, and is the R6RS macro system.

Personally, I don't like syntax-case. IMHO, it's overly complex, it throws away the standard macro abstraction for little benefit, and is generally a pain to use. But it's not objectively badly designed, and some people seem to like it (conveniently, this description, with some minimal modification, applies quite well to R6RS itself). You might be a person that likes it. I don't know. All I know is that I am not one of those people.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: