One Major Difference Between Clojure and Common Lisp
gilesbowkett.blogspot.com
gilesbowkett.blogspot.com
Either way, if you get the terminal condition of a recursive function wrong, you will blow the stack. It's true Clojure isn't built to do TCO, but that's a non-sequitur. The idea that you don't typically use recursion in Clojure is ridiculous - for is a macro, it's syntactic sugar over Clojure's recursion primitives, loop and recur. Even if you didn't want to use that, change the nil? check to empty? and it works. I'm not going to claim that Clojure's list/sequence semantics are necessarily the cleanest (the empty _sequence_ in Clojure is nil, an empty list/vector/set etc is not), but they're not hard to learn if you make any effort at all. Again, your existing Lisp experience may or may not help you understand Clojure's data structures, but I am surprised that this is a surprise to anybody.
> First, this code assumes that (if (null list1)) in Common Lisp will be equivalent to (if (nil? list1)) in Clojure, but Clojure doesn't consider an empty list to have a nil value.
That sentence makes it very clear the writer either hasn't been arsed to read through even one Clojure tutorial or is being intentionally dense. If they have an educated opinion, great, but I have no patience for this level of ignorance, especially if it's feigned ignorance.
Not to say recursion is not important. Without it lambda calculus is not Turing complete. But Clojure does provide explicit TCO. Saying this is a big difference is excessive IMHO.
Not in Common Lisp. The last time I tried to show someone how well recursion worked in a typical Common Lisp implementation, I crashed Firefox trying to paste the result of a naive factorial function into a text buffer. Stack depth limits in other languages are often arbitrary.
If one looks at music software in Common Lisp, the code is on a higher level than building lists like that.
> Secondly, this code tries to handle lists in the classic Lisp way, with recursion, and that's not what you typically do in Clojure.
Neither is it done in Common Lisp.
> Those 7 lines of Common Lisp compress to 2 lines of Clojure
The actual difference is that Common Lisp uses LOOP and not FOR, and that LOOP needs two nested LOOP forms:
CL-USER 11 > (defun build (list1 list2)
(loop for e1 in list1 append
(loop for e2 in list2 collect (list e1 e2))))
BUILD
CL-USER 12 > (build '(1 2) '(a b))
((1 A) (1 B) (2 A) (2 B))
(loop for i in '(1 2 3) for j = (expt i 2) collect (list i j))
(loop for i in '(1 2 3) and j in '(1 4 9) collect (list i j))
ITER-USER 26 > (iterate outer (for i in '(1 2))
(iterate (for j in '(a b))
(in outer (collect (list i j)))))
((1 A) (1 B) (2 A) (2 B))
> But, at the same time, if you're looking to translate stuff from other Lisps into Clojure, it's not going to be just copying and pasting. Beyond inconsequential, dialect-level differences like defn vs. defun, there are deeper differences which steepen the learning curve a little.
That's true. Clojure is not a Lisp, but partially derived from it, with many other influences from Haskell and other languages. It's mostly incompatible to Lisp: software can't be shared or copied, it needs to be complete rewritten. Thus basic Lisp literature is only of use when it's about features which got copied. For example the book 'On Lisp' might help to understand macros in Lisp and Clojure, whereas books like 'Practical Common Lisp' or Norvig's PAIP aren't very useful for Clojure programmers.
That code from other lisp implementations needs rewritten to be ported, is really not that much different from how many other lisp implementations were to each other.
CL and Scheme did a lot to unify things, such that any scheme should run another scheme's code. Same for any CL implementation. But, for example, running emacs lisp in any other lisp just isn't going to work.
CL-USER> (defun fact (n) (do* ((i n (- i 1)) (j i (* j i))) ((= i 1) j)))
FACT
CL-USER> (fact 15)
1307674368000
ELISP> (defun fact (n) (do* ((i n (- i 1)) (j i (* j i))) ((= i 1) j)))
fact
ELISP> (fact 15)
1307674368000 (#o23016735654000, #x13077775800)
That does not say anything about whether or not a language is an assembly. Just as this says nothing about whether a language is a lisp.
Emacs Lisp is directly in the tradition of McCarthy's Lisp. It shares names, concepts, literature, even code.
Logo, Dylan, ML, Clojure don't. They were derived or inspired by Lisp, but they are now they own language family...
The result of that design is that Clojure shares literally zero lines of code with other Lisps: Autolisp, ISLisp, Emacs Lisp, Standard Lisp, Common Lisp. Many basic concepts are absent, renamed or redesigned ('Atom', 'Linked List', ...). Clojure is fully incompatible to any other language with Lisp in its name. Programs have to be re-architectured, because the concepts are different: no TCO, but 'functional', different approach about side effects (-> avoid), lazy persistent datastructure at its core, different idea of OOP (-> avoid), Lisp infrastructure (-> avoid), ...
There is no software I know of, which is shared. The number of tools shared is 'one': GNU Emacs. It's a different community with different goals, different software, different applications, different libraries.
Just think of it: zero lines of code is shared.
My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications. Sometimes it's only a marketing slogan. It has the same vague meaning like 'object-oriented' or 'Functional'. There is no consensus what OOP in a broad sense means and how it should be defined. 'Lisp' is just as useless.
It does not mean that Clojure is useless or worse than Lisp. Totally not. Clojure has new ideas on data structures put to work and enabled some very productive people enjoying their tools. They are doing wonderful stuff.
> Programs have to be re-architectured, because the concepts are different:
"Re-architectured" can be read in a multitude of ways. Changing a few datatypes because Clojure prefers vectors instead of lists, etc., feels like it falls well below the bar for "re-architectured".
> no TCO, but 'functional'
This would hold weight if CL mandated TCO, but it doesn't.
With this in mind, I'd like to examine a few of your points from a different angle:
Racket:
- Basic concepts are the same, (atom, linked lists, '...')
- Restructuring not really needed (up for debate, depends entirely on your prefered initial design choices in either language. Racket isn't that opinionated.)
- Tail call optimization required as per Scheme standard, so is present. Note that this is not actually something Lisp mandates.
- Doesn't 'care' about side effects, community is pragmatic and will generally advise you to do whatever is practical
- Has an object oriented sub-language with message passing and so on
There are a lot of points here that, according to you, makes Racket essentially a Lisp, even your non-point about TCO. I'm curious to know what you feel about people saying Scheme is a Lisp, considering the above.
The whole debate of "Is X (a) Lisp?" reminds me of nationality debates that essentially boil down to some people saying blood is more important than culture. You seem to be taking both sides, however; arguing culture and blood (source code). You cherry pick the cultural differences like most people standing on one side of the nationality debate would and argue that just those specific differences are the most important.
That's the thing, though; Swedish people could argue however much they want that they're very different from Norwegian people. To the rest of the world, though, they're essentially the same. Especially when you start comparing them to people from Peru, Venezuela, South Africa, and so on. When you're in the bubble the very small differences are much bigger to you, but if you zoom out to get some perspective these differences are much smaller than the commonalities.
> Racket is Racket. It's its own language.
You've also been nothing but vague in terms of what makes Racket not a Lisp, which is ironic considering your previous argument that we should have more clearly defined requirements for what makes a Lisp, but I'm beginning to think that this was mostly hot air.
I think you've mostly proven that the 'vague' definition serves a much more practical purpose than your seemingly arbitrary distinction between these languages, and it will continue to do so, as it implies far more than you've displayed in this thread.
True, and I have to apologize for that. But I don't have the time, nor the priority to go into full detail. The main points are: different community, different goals, almost zero code sharing, different technical solutions, different literature, ... The differences are technical and social. Each of the points would need more explanation, for which I don't have the time.
For me 'Lisp' is something practical. I have a bunch of non-trivial code -> can I compile/load it? Can I port it easily? Are there people who would be interested to share? What are they using? Can I work with them?
Example:
Macsyma is an old Lisp program. New Lisp dialects appeared. Macsyma was ported to them: Maclisp, Franz Lisp, NIL (New Implementation of Lisp), Lisp Machine Lisp, VaxLisp, Common Lisp...
This software can't be ported to Clojure or Racket, without fully re-architecting the software, and I'm only thinking about the basic Macsyma, without GUI or other system dependent parts.
> that the 'vague' definition serves a much more practical purpose
which one? to confuse people? To raise expectations of collaboration in a community, which are then not fulfilled?
Example:
Lisp-2:
(defun new-map (f l)
(dolist (e l)
(funcall f e)))
(defun new-map (f l)
(dolist (e l)
(f e)))
Lisp-2
(defun foo (l)
(flet ((new-map (f l)
(dolist (e l)
(f e))))
(new-map (function sin) l)))
(defun foo (l)
(let ((new-map (lambda (f l)
(dolist (e l)
(f e)))))
(new-map sin l)))
Neither does Emacs Lisp nor ABCL. Yet they are Lisps by your definition.
> different approach about side effects (-> avoid)
Though not precluded. You can write Clojure with side-effects, but to do so you need to be explicit about it.
> different idea of OOP (-> avoid)
Which says nothing about the language or its Lisp-nature. Clojure has generic dispatch with multimethods, supporting runtime polymorphism. As you say later, "OOP" is meaningless since it's definition is vague, so using this as a reason for Clojure to not be a Lisp is odd.
> Just think of it: zero lines of code is shared.
Are saying that a lisp is only a 'Lisp' if you can freely share code between them? Without modification? If the names used for functions aren't the same, then that disqualifies it from being a Lisp?
Your position seems to be that unless the lisp is a direct descendant of Lisp 1.5 then it cannot be called a Lisp. In addition to Clojure, this disqualifies Scheme (and its dialects.)
Different Lisps (by your definition) take different approaches to things like namespace separation (Lisp-1 vs. Lisp-2) and scope (dynamic vs. lexical). These differences can be subtle and lead to hard to find bugs when sharing code.
> My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications.
Yet you have put a stake in the ground and defined the broad idea of 'Lisp' as an entity that shares its roots with the ideas in MacLisp.
In any discussion involving Common Lisp, there will be the opinion that "Clojure is not a Lisp" without (in my view) providing sufficient context for this clearly confusing statement.
(FWIW, I call Clojure a Lisp. It is clearly in the Lisp tradition, not to mention more technical things like: code-is-data, serious REPL, accurate numbers like 10.00000000000000001M. I don't think "Lisp" should be reserved for mainly incremental improvements on an old movement.)
Like Prolog or Julia.
In any case, there is no definition of even "chair". (Which partitions the world into chair and not-chair. Simply imagine a continuum between a particular chair morphing into a not-chair; where exactly does it stop being a chair?) So I'm unconcerned about edge-cases, where a language is actually in a fuzzy part of that continuum. Not to mention those amusing blogposts claiming "Javascript is a Lisp!" which maybe aren't objectively true but inspiring.
But there are a lot of languages in the Lisp family that don't share the syntax (except from the basics, maybe), nor the standard libraries. See e.g. http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/
I keep seeing people make this statement, without any explanation of why. To me, hardly a heavy user of other Lisps, but with enough time spent in Common Lisp and Scheme to have an idea of what's going on, it feels pretty lispy.
Is C++ a C? Is Oberon a Pascal? Is F# a ML? Is C# a Java? Is Go a Squeak? Is Objective-C a Smalltalk? Is Javascript a Self?
Just think of it as civil law (versus common law) when interpreting it.
Clojure is a Lisp. It may not be Lisp, but it's a Lisp. Just like any nix OS is not UNIX but is a Unix OS.
Clojure is most definitely a dialect of Lisp. From clojure.org:
> Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system.
The intent of the design of Clojure was clearly to be a dialect of Lisp, hence the above quote from Rich Hickey proudly displayed on their site.
LISP appeared in the late 50's/early 60's. Common Lisp only appeared in the early-to-mid 80's. There were many other lisps in between and many since. Common Lisp is only one of many dialects of Lisp. Clojure is another.
(Not saying that this is what lispm did in this case, (s)he seems to know a lot about lisp; rather this is a common confusion I've seen)
Take code from any Lisp book from the past 50 years and type it into Clojure. It won't work. Even really basic Lisp code won't work.
> There were many other lisps in between and many since.
They all share a core language.
Simple REPL in Emacs Lisp:
ELISP> (defun read-eval-print-loop ()
(do* ((input (read) (read))
(value (eval input) (eval input)))
((equal input '(quote quit))
'done)
(print 'input>)
(princ input)
(print 'value>)
(princ input)
(print value)))
read-eval-print-loop
ELISP> (read-eval-print-loop)
input>
(mapcar (quote +) (quote (1 2 3)))
value>
(mapcar (quote +) (quote (1 2 3)))
(1 2 3)
done
Code unchanged.
; OpenLisp v10.1.0 (Build: 5932) by C. Jullien [Aug 30 2014 - 07:38:27]
;; WARNING: \"startup.lsp\" file not loaded.
? (defun read-eval-print-loop ()
1> (do* ((input (read) (read))
3> (value (eval input) (eval input)))
2> ((equal input '(quote quit))
3> 'done)
2> (print 'input>)
2> (princ input)
2> (print 'value>)
2> (princ input)
2> (print value)))
;; elapsed time = 0.000s, (0 gc).
= read-eval-print-loop
? (read-eval-print-loop)
? (mapcar #'1+ '(1 2 3))
input>
(mapcar #'1+ '(1 2 3))value>
(mapcar #'1+ '(1 2 3))(2 3 4)
The same code unchanged in Common Lisp:
CL-USER> (defun read-eval-print-loop ()
(do* ((input (read) (read))
(value (eval input) (eval input)))
((equal input '(quote quit))
'done)
(print 'input>)
(princ input)
(print 'value>)
(princ input)
(print value)))
READ-EVAL-PRINT-LOOP
CL-USER> (read-eval-print-loop)
(mapcar '+ '(1 2 3))
INPUT> (MAPCAR (QUOTE +) (QUOTE (1 2 3)))
VALUE> (MAPCAR (QUOTE +) (QUOTE (1 2 3)))
(1 2 3)
'quit
DONE
If it does not, it is not Lisp. Then it would be Scheme, Logo, Dylan, Clojure or some other language.
LOOP is something that imho very controversial. I don't think it's fair to say that its use is idiomatic.
No, not really: it's as controversial as Common Lisp's Lisp-n nature (which is to say, both of which are controversial amongst Scheme programmers writing Common Lisp). It's a perfectly useful macro. ITERATE is a bit more traditionally Lispy, and is an easy library away if one wants it.
> I don't think it's fair to say that its use is idiomatic.
Not using it is typically less clear. It's part of the standard; it's more elegant than using other parts of the standard; it's idiomatic.
Simple example from Winston&Horn's book LISP for a database query language:
(db-select screwdrivers with color eql red)I wish the author would have spent a little bit more time researching. The comparison is just plain sloppy. Why is Clojure's `recur` not mentioned, for instance? This is documentation that's not that difficult to find by googling, and is mentioned in (I believe) every Clojure book available.
1. It's a lisp, which means homoiconic, i.e. build software just like Lego (different from non-lisps)
2. Immutability and purity in the core library + sane, managed concurrency via atoms, refs, core.async, i.e. write serious multithreaded code without putting your hair on fire; helps on the front-end via ClojureScript as well (different from most other Lisps)
3. The JVM, which means very good performance in the general case + build once, run everyone + a lot of libraries
(defun build (list1 list2)
(loop for x in list1 append (loop for y in list2 collect `(,x ,y))))
(defun build (list1 list2)
(mapcan (lambda (x) (mapcar (lambda (y) `(,x ,y)) list2)) list1))
The lack of TCO in JVM hosted languages is besides the point.
It is also possible for the Clojure compiler to do TCO in certain cases: Rich Hickey made the conscious decision to not do it.
If I read your statement as Rich Hickey having the opportunity but passed on it, I'd reply that he did that with recur. Unless you mean silent TCO like e.g. Scheme does.
It certainly looks more elegant to do it silently, but Clojure doesn't strive for that sort of elegance.
Personally, I like clojure's approach as IMHO recur makes intent clear, but recur is a subset of what TCO optimises in other languages.
(defun foo () (foo)) ;<- tail call
(defun bar () (bar)) ;<- tail call
(defun baz (a b) (+ ;<- tail call
(* a 2)
(* b 3)))I was gonna post the question "Why should I learn clojure?" but that's easy to google for and get good articles.
I was then gonna post "What's a good book for learning Clojure?" but I can get that on Quora.
So my real question is: what can I read about Clojure that will get me up to speed on its unique awesomeness? I don't need a tutorial that shows me how to add two ints or invoke a function. Show me the good stuff!
I read a fair amount of both and the former explains the subject matter too superficially IMHO. +1 for Joy of Clojure which is a nice read in parallel.
Joy of Clojure is a good book. It goes deeper while assuming more of the reader. The technical detail is useful and interesting, but for me, the narrative seems a bit less cohesive [disclaimer: I have the first edition, not the second]. I haven't read Clojure Programming.
[1]: Edit. For example the running exercise is porting a Java build system to Clojure. That's full on software engineering, not a let's-pretend.
I focused on Programming Clojure as it's almost half the size of Clojure Programming and I want to get to other, more focused clojure books (Reactive Programming, Macros). But for me, personally, the examples given so far (I've made it at least through the State-chapter) weren't well explained. I'll see how Clojure Programming holds up in that regard but so far many explanations have been better IMHO.
The destructuring mechanisms in Clojure are very, very powerful. For some reason this author does not seem to like them, even though they reduce his 7 line CL program to a 2 line Clojure program. That's not a fluke, from what I've seen. Stuff that would require a lot of caddars and cddaars and whatnot in a normal Lisp are much more straightforward in (idiomatic) Clojure.
The interop between Clojure and Java (or ClojureScript and JavaScript) seems to be a lot cleaner and more straightforward than the sometimes-ugly FFIs you see with other languages.
It has just about all the standard Lisp goodies, too (macros, etc.)
What destructuring? I didn't see any in the example.
I'd say start here, it will get you in the mindset of Clojure.
In any case, at Standard Chartered we didn't have tail call optimization with our Haskell dialect either. It didn't matter too much in practice, because you should be using combinators anyway. And when you are calling foldr or map, you do not care that somewhere hidden away they are implemented with a loop in C++, as long as they behave right.
And really i think the "Classic" lisp way to loop is loop, not recursion.
Scheme forces the point and requires full TCO.
Both, I think (from long ago memories). The "modern" loop macro (which is probably Turing complete like I seem to remember people saying format is :-) is I think a relatively new thing, I overhead a lot of discussion about its design in the early '80s.
Although it probably had precursors, mainline Lisp, now Common Lisp, is decidedly multi-paradigm, there were even sops thrown to FORTRAN programmers as I recall, probably back from when there were only a very few computer languages in existence (heck, LISP's first implementation, on a vacuum tube computer, was as FORTRAN subroutines). So overt things like loop are in theory idiomatic as well as recursion.
The ones that don't provide any form of TCO are old Lisp Machine implementations and ABCL on the JVM.
SBCL, OTOH, provides full TCO.
Some older overview about Common Lisp implementations and their TCO support:
map :: (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : map f xs
Yes, GHC can and does just use the recursive goodness, and compile it away to no-stackframe-adding jumps.
The --full-tail-calls flag is not on by default, partly
because it is noticably slower (though I have not measured
how much), and partly I think it is more useful for Kawa to
be compilatible with standard Java calling conventions and
tools.
You could avoid calling functions and instead do your own stuff but that doesn't change the fact that the JVM doesn't support it.
That is what they mean by performance, you lose performance because you can't do naked function calls in those cases.
Since except mutual recursion (which is difficult to detect tail recursion for correctly) the benefit of tail recursion is a performance boost it is ignored when the cost of implementing it kills your performance.
Kawa now does general tail-call elimination, but only if you use the flag --full-tail-calls. (Currently, the eval function itself is not fully tail-recursive, in violation of R5RS.) The --full-tail-calls flag is not on by default, partly because it is noticably slower (though I have not measured how much), and partly I think it is more useful for Kawa to be compilatible with standard Java calling conventions and tools. Code compiled with --full-tail-calls can call code compiled without it and vice versa.
If it costs too much at run time, Clojure absolutely should not implement it. Lack of TCO isn't that big of a deal.
Clojure is instead waiting for a solution on JVM-level.
(defun build (list-1 list-2)
(loop
:for elem-1 :in list-1
:for elem-2 :in list-2
:collect (list elem-1 elem-2)))
Afaik it is possible in racket. Read the note at the end here: http://matt.might.net/articles/lexers-in-racket/
Edit: Jesus Christ, Clojure doesn't even have conses. Why the hell do people call this a "Lisp"?
> (= () nil)
false
> (('a . 'b) . ('a . 'b))
java.lang.RuntimeException: Unable to resolve symbol: . in this context
> (cons 'a 'b)
java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol > (cons 'a ['b])
(a b)
> (doc cons)
-------------------------
clojure.core/cons
([x seq])
Returns a new seq where x is the first element and seq is the rest.But it's still a Lisp, I went straight from old half-remembered mainline LISP and Scheme to Clojure in a recent small web server project without difficultly. The dynamic style of development is the same as is the typing, if you're not using lists, then the OPs problems don't come up (idiomatic Clojure web programming uses maps, key value pairs), the syntax is still s-expressions, albeit polluted by arrays denoted with square brackets where it makes sense.
And I believe the article is wrong in one sense, the JVM treats non-tail recursion like other languages, growing the stack. It's tail call optimization (TCO) that's the issue: mandatory in Scheme, don't know about its prevalence in Common Lisp implementations, and it's awkward in Clojure but wasn't much of a jump from SICP for the typical cases. And I think it might be a good idea to require signaling when you intend to tail recurse, it's easier and much quicker to find in compilation than when you blow the stack running it.
While I very much like the first class syntax for arrays, maps, and sets, there's a tremendous advantage to having one main or even exclusive built in composite data type, e.g. I hear that a strength of Lua, which I gather has been very successful. LISP's DNA, as well as Scheme's I'm pretty sure, was established in the days when that was lists.
Don't lisp advocates usually say it has no syntax.
(Quote from CLtL: Many people have suggested that brackets be used to notate vectors, as [a b c] instead of #(a b c). This notation would be shorter, perhaps more readable, and certainly in accord with cultural conventions in other parts of computer science and mathematics. However, to preserve the usefulness of the user-definable macro-character feature of the function read, it is necessary to leave some characters to the user for this purpose. Experience in MacLisp has shown that users, especially implementors of languages for use in artificial intelligence research, often want to define special kinds of brackets. Therefore Common Lisp avoids using brackets and braces for any syntactic purpose.)
So clojure tried principled consistency, I like the logic of it, but not the result. Erik Meijer and Brett Victor claim it's a good thing to do. Find a concept and go all the way down with it.
[1] it would be fun to be denotational even for these. (arithmetic-sum (number two one three) (number six six six)), yes it would be.
But I think people like us have to accept that many other people hate a sea of parens to the point they violently reject LISPs (e.g. http://ancell-ent.com/images/parens.png) ; my question WRT to Clojure is, how many of them have come on board in part due to adding to and in some cases changing the (nearly) pure s-expression syntax we love?
If a fair number have, I'm willing to accept it for the benefit of "Lisp", for Clojure has created the greatest movement in "Lisp" since the Lisp Machine and microprocessor heyday of the '80s.
Ah, I might add that for me, the REPL style of programming is my #1 feature. One of my greatest programming feats what with CodeCenter/ObjectCenter, an interpretive environment for C/C++, where I ported a scanner driver and rewrote the engine for monster Kodak document imaging scanners in 3 weeks. The very first time I hooked up one of these 600 pound, bigger than a washing machine scanners and hit the "Go" button it worked all the way through to writing files.
Well, until I ran out of file descriptors, forgot a close() ^_^. But I found being able to do that rather impressive, granted, I'd been working on the lower level SCSI code for a couple of years with optical drives and scanners.
Without punctuation:
int thing int a int b while c = a ++ > b b = 0 a = b + c return c
Without types:
thing a b while c = ++ a > b b = 0 a = b + c return c
thing a b while c eq inc! a > b b = 0 a = sum b c return c
thing a b while c eq inc! a > b b isnow 0 a set-to sum b c return c
thing a b while c eq inc! a gt b b isnow 0 a isnow sum b c c
(int thing int a int b) while (c = a ++ > b. b = 0) a = b + c return c
More specifically, we don't focus on the parens. And in the image, they're still there, just a very light yellow....
For me the two keys are smart indention and the habit of counting off each opening paren at the beginning of an indented line as I close it. I did this sort of work on GoldHill's EMACS clone in the brief period I worked for them, getting it to blink the opening paren when the point is positioned to the right of the closing paren.
would you give an example of this? Just curious as someone who has spent more time in clojure than in lisp.