3 ms·
FWIW, Qlot solves the version pinning problem. Not to discredit your experience, just wanted to say that there are solutions today for the same issue. I'm inte
by jaccarmac 9y ago
FWIW, Qlot solves the version pinning problem. Not to discredit your experience, just wanted to say that there are solutions today for the same issue.
I'm interested exactly what the pain points are with CPS. Do you mean manually rewriting in continuations is tedious or is there a more insidious issue. I haven't tried writing async code in Lisp but macros would appear to eliminate continuation-writing-by-hand.
- orthecreedence 9y ago> macros would appear to eliminate continuation-writing-by-hand They don't =]. There's cl-cont, but it's like building a house on a foundation of toothpicks. Not to discount the work the author put in, but you can only do very specific things with it, and last time I looked, error/exception handling was pretty much completely missing. > I'm interested exactly what the pain points are with CPS Basically, for example, if I'm going to convert cl-postgres to use async, I have to rip out the protocol parsing from the networking (they are often globbed together) then I have to replace the networking with async and tie it back into the protocol parsing. This in itself isn't too bad, but then anything that calls the new async cl-postgres has to be converted to expect async...all the way up. This can be somewhat alleviated by promises (https://orthecreedence.github.io/blackbird/ https://orthecreedence.github.io/blackbird/) but they still don't change the fact that the entire stack is unwound once you call into async. Continuations would allow building green threads/coroutines which would eliminate CPS and allow you to preserve your stack while calling into async, but CL is pretty much written in stone to not have continuations (or coroutines et al) at this point. Qlot looks handy, thanks for the tip.
- TeMPOraL 9y ago> then I have to replace the networking with async and tie it back into the protocol parsing. This in itself isn't too bad, but then anything that calls the new async cl-postgres has to be converted to expect async...all the way up. Isn't this the very consequence of going async? I'm reminded of the article on this recently featured here[1]. Once you introduce async, you poison everything up to the event loop (which, with usual async implementations, you don't even see or control). [0] - http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... + https://news.ycombinator.com/item?id=16732948 https://news.ycombinator.com/item?id=16732948
- orthecreedence 9y ago> Isn't this the very consequence of going async? Like I mentioned, depends on the language features. If it has coroutines/green threads/continuations, you can use async without unwinding the entire stack. CL will probably always have this problem, unless the bigger implementations independently decide to implement the necessary building blocks (which they probably won't). Try explaining that to me 5 years ago, though.
- TeMPOraL 9y agoIf it's about avoiding stack unwinding, then maybe you could hack an implementation with the condition/restart system? This is the one stack-preserving feature in CL.
- Blackthorn 9y agoBiggest issue I personally had with CPS and why I'll never use it for anything is the need to wrap your entire call stack, at compilation time, in CPS macros. That's a no-go for calling external libs. Clojure does this a lot better with Pulsar.