Live data from Hacker News

Common Lisp's block / return-from and unwind-protect

axisofeval.blogspot.com

11–20 of 63 posts

Re: Common Lisp's block / return-from and unwind-protect

#12
post #3

Block/return-from is a lexical transfer of control that can be non-local (you can transfer out of a lambda or defun to an enclosing scope). For the dynamic equivalent there's catch/throw. Both transfers activate unwind-protect if they unwind the stack through it.

One of the only languages where I saw this non-local returns is Kotlin.

You can return from a function from within a lambda (and I believe this works on any number of levels), for example:

    fun go(list: List): Boolean {
        list.forEach { if (it.isEmpty()) return@go true }
        return false
    }

Re: Common Lisp's block / return-from and unwind-protect

#13

Gah, another Lisp post to tempt me to add yet another mini project to my plate...I always am curious about trying more Lisp because I keep seeing commentary about how powerful it is to actually build applications once you get moving on building things. Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compoun…

Yes, building anything non-trivial in CL will show the discerning programmer that there is nothing new under the sun.

Except the little detail that JIT/AOT toolchains still aren't as widespread as they should be, with several languages offering only one variant, and there as still quite a few Lisp tricks either left behind in modern IDEs, or with various kinds of support depending on the language, like accessing everything across language and runtime, hot code reloading, time travel debugging.

Ah, and most relevant, many folks still believe that writing OSes in what was once a macro Assember for PDP-11 is the only way.

Re: Common Lisp's block / return-from and unwind-protect

#14

Gah, another Lisp post to tempt me to add yet another mini project to my plate...I always am curious about trying more Lisp because I keep seeing commentary about how powerful it is to actually build applications once you get moving on building things. Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compoun…

I'm learning programming at age fifty-four and have chosen Common Lisp as my one language for life. If you want something easy to learn with a ton of support pick Python, Elixir, and/or JS. CL sucks for mini-projects since the learning curve requires serious commitment and is SO different from what people are used to. CL requires a long-term commitment and demands the programmer challenge pop programming trends and d…

Additionally jump into LispWorks or Allegro Common Lisp, to enjoy how the survivors from Common Lisp days with a full blown IDE feels like.

Re: Common Lisp's block / return-from and unwind-protect

#15

Is Common Lisp the first kitchen sink language (ala C++)? It always seems to me like there's a lot of "Oh yeah, Common Lisp has a feature for this, too"-type blog posts, though very little about actual usage of it.

Common Lisp is the uniformization of what Lisp Machines across Genera, TI, and Xerox PARC (although Interlisp-D was a different species) were offering for a full graphics workstation, alongside other systems.

It was as kitchen sink as having POSIX (basically a full blown UNIX specification), to be expected to fill in the stuff missing from ISO C standard library.

Re: Common Lisp's block / return-from and unwind-protect

#16

Gah, another Lisp post to tempt me to add yet another mini project to my plate...I always am curious about trying more Lisp because I keep seeing commentary about how powerful it is to actually build applications once you get moving on building things. Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compoun…

I've written a few small CL web applications( with about 100 users active a day), along with a few terminal applications (with only ~10 users). Other languages I know is C , Erlang, Elixir and a bit of python. This will end up sounding a bit evangelical but so be it.

I feel that the lisp code was easier to write and reason about, the being able to hot reload code from the repl significantly decreased the time to completion. I also 'connect' to a networked repl when sentry reports an unhandled error to figure out what has gone wrong.

You might be tempted to believe that CL repl is "similar enough" to python's repl, however this is NOT the case. Being able to redefine functions, variables and macros while working on the code (without a restart) allows you to deal with errors.

The syntax is a 'no brainer', Extreme consistency in function calls means that you don't need to think about it. Other languages which SOMETIMES use infix, sometimes require brackets, that is just crazy.

Lisp libraries have less churn than 'modern languages', some libraries have not been touched for some time, unlike python/ruby/js. The code does not seem to rot and old lisp code runs on modern implementations.

I work in emacs, lem, I know people who use vscode and alive, and vim. There is no 'hard' requirement to use emacs, you will get by as long as you have 'emacs like' repl integration.

All in all, I do not regret working in lisp. It doesn't have the cult of the other languages and I'm fine with that.

Re: Common Lisp's block / return-from and unwind-protect

#17

Gah, another Lisp post to tempt me to add yet another mini project to my plate...I always am curious about trying more Lisp because I keep seeing commentary about how powerful it is to actually build applications once you get moving on building things. Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compoun…

I'm learning programming at age fifty-four and have chosen Common Lisp as my one language for life. If you want something easy to learn with a ton of support pick Python, Elixir, and/or JS. CL sucks for mini-projects since the learning curve requires serious commitment and is SO different from what people are used to. CL requires a long-term commitment and demands the programmer challenge pop programming trends and d…

You have an extremely deep understanding of the discipline of computer programming for someone who has only just started to learn!

Re: Common Lisp's block / return-from and unwind-protect

#18
post #12
post #3

Block/return-from is a lexical transfer of control that can be non-local (you can transfer out of a lambda or defun to an enclosing scope). For the dynamic equivalent there's catch/throw. Both transfers activate unwind-protect if they unwind the stack through it.

One of the only languages where I saw this non-local returns is Kotlin. You can return from a function from within a lambda (and I believe this works on any number of levels), for example: fun go(list: List ): Boolean { list.forEach { if (it.isEmpty()) return@go true } return false }

Longjmp in standard C, swapcontext in POSIX C. I think GCC allows gotos to the containing function from a local function (but I never used GCC local functions).

Smalltalk, and I believe ruby, allow non local return from blocks.

Re: Common Lisp's block / return-from and unwind-protect

#19

Is Common Lisp the first kitchen sink language (ala C++)? It always seems to me like there's a lot of "Oh yeah, Common Lisp has a feature for this, too"-type blog posts, though very little about actual usage of it.

It's a rather subjective assessment. ALGOL 68 and PL/I were apparently considered rather "kitchen sink" by the standards of their time.

Re: Common Lisp's block / return-from and unwind-protect

#20
post #12

Earlier quoted context omitted.

One of the only languages where I saw this non-local returns is Kotlin. You can return from a function from within a lambda (and I believe this works on any number of levels), for example: fun go(list: List ): Boolean { list.forEach { if (it.isEmpty()) return@go true } return false }

Longjmp in standard C, swapcontext in POSIX C. I think GCC allows gotos to the containing function from a local function (but I never used GCC local functions). Smalltalk, and I believe ruby, allow non local return from blocks.

longjmp simply restores the machine registers (including PC and SP) and thus doesn’t respect any sort of unwind-protect, a concept unknown in C.

unwind-protect is a more general form of the c++ raii (in fact c++ got raii from Common Lisp).

Post reply on HN