
Promises and Lisp - chaitanya
http://lisper.in/promises/
======
javajosh
_Debugging is a bit of a challenge with promises._

Indeed, and that is why I am personally not really that bullish on promises,
at least not how they are currently implemented. When you're debugging you
want access to the implicit state-machine that the promise statement
constructed, but at least in JS such state is hidden away in the `then()`
function.

A good compromise (which I'm currently exploring in JS) is to make the state-
machine navigable from the root, giving you the ability to examine it and
mutate it explicitly during a debug session.

~~~
chaitanya
> A good compromise (which I'm currently exploring in JS) is to make the
> state-machine navigable from the root, giving you the ability to examine it
> and mutate it explicitly during a debug session.

You might also want to check out the JS library q, which has support for stack
traces that span async jumps if a promise errors out
[https://github.com/kriskowal/q#long-stack-
traces](https://github.com/kriskowal/q#long-stack-traces)

~~~
Arnavion
I would not recommend new projects to use Q when Bluebird exists. The latter
is better in every way - perf, features and tracking the ES6 Promise API more
closely.

~~~
chaitanya
Thanks. I had not heard about Bluebird before.

------
anyfoo
Congratulations, you have almost invented Monads! 8)

~~~
616c
I have been told, albeit not part of the core, Haskell is not the first to the
party and they most certainly have been monadic CL libs.

[http://common-lisp.net/project/cl-monad-macros/monad-
macros....](http://common-lisp.net/project/cl-monad-macros/monad-macros.htm)

There are some people in the CL community who mention why CL users might not
appreciate monads like those in other languages and/or programming
styles/disciplines.

(Original)
[http://marijnhaverbeke.nl/monad.html](http://marijnhaverbeke.nl/monad.html)

(HN Discussion)
[https://news.ycombinator.com/item?id=7651175](https://news.ycombinator.com/item?id=7651175)

------
coldtea
Doesn't async/wait solves the same problem in a more elegant way?

------
thomasfoster96
Is this some sort of contorted version of Greenspun's tenth rule?

------
chaitanya
OP here. I would welcome and feedback or suggestions for the post.

~~~
ScottBurson
Re footnote 4: the Alexandria library has a function 'parse-body' that will be
helpful.

Also: I'm not sure it's a good idea to give these macros the same names as the
CL builtins. This will require users to do 'shadowing-import' if they want to
use them without the package prefix, and then when they want to reference the
builtins (in performance-sensitive code, perhaps) they'll have to use an
explicit 'cl:'. At the very least, I'd suggest exporting a second set of names
also, which are prefixed with "p-" or some such, so people can import them
without shadowing.

~~~
lispm
Package PCL for old people means 'Portable Common LOOPS', the first CLOS
implementation... ;-)

