3 ms·

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

deleted 12y ago
[deleted]
ScottBurson 12y ago
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 12y ago
  Package PCL for old people means 'Portable Common LOOPS', the first CLOS implementation... ;-)
- chaitanya 12y ago
  > Re footnote 4: the Alexandria library has a function 'parse-body' that will be helpful. That's nice. I had initially defined LET/LET* using a similar function, but then removed it to keep the macro definitions simpler. > Also: I'm not sure it's a good idea to give these macros the same names as the CL builtins. I gave this some thought, and came to the conclusion that using P-LET* is not very different from using PCL:LET*. So the way I envisioned this is that you don't import symbols from the PCL package; just use them with the package prefix. Though not everyone would prefer things this way, so if this was not a toy project I might have done what you suggested.
debacle 12y ago
I think you should note in captions that each of your code samples came from Domenic's blog, to be polite. Initially it seems like you sort of lifted the entire first bit of the post. As far as your Lisp implementation goes, since promises are really just syntactical sugar around continuation passing (not in a bad way), and since both the continuation and the callback are first class, it should be trivial to land on a syntax that is as easy or easier to read than the JavaScript implementation. I think your final implementation hides a bit too much.
- chaitanya 12y ago
  > I think you should note in captions that each of your code samples came from Domenic's blog, to be polite. I actually mention this in a footnote, but I will do what you have suggested to be clearer still. > it should be trivial to land on a syntax that is as easy or easier to read than the JavaScript implementation. I think your final implementation hides a bit too much. Can you elaborate how this syntax might look?
briantrice 12y ago
It would be good to tackle multiple-promises-dependencies that the when()/all() protocols achieve, compared to then().
- chaitanya 12y ago
  I avoided it so that the post does not become very long and the main point doesn't get diluted. That said, I do use multiple-promise-depenencies to implement PCL:LET in the accompanying source https://github.com/chaitanyagupta/promises/blob/1.0/pcl.lisp#L12 https://github.com/chaitanyagupta/promises/blob/1.0/pcl.lisp... (ON-PROMISES does the same thing as when()/all()).
chajath 12y ago
think it would also be interesting to compare this approach to other (quasi-) meta-programmatic approach in JS like async.js

deleted 12y ago

[deleted]

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 12y ago
Package PCL for old people means 'Portable Common LOOPS', the first CLOS implementation... ;-)
chaitanya 12y ago
> Re footnote 4: the Alexandria library has a function 'parse-body' that will be helpful. That's nice. I had initially defined LET/LET* using a similar function, but then removed it to keep the macro definitions simpler. > Also: I'm not sure it's a good idea to give these macros the same names as the CL builtins. I gave this some thought, and came to the conclusion that using P-LET* is not very different from using PCL:LET*. So the way I envisioned this is that you don't import symbols from the PCL package; just use them with the package prefix. Though not everyone would prefer things this way, so if this was not a toy project I might have done what you suggested.

debacle 12y ago

I think you should note in captions that each of your code samples came from Domenic's blog, to be polite. Initially it seems like you sort of lifted the entire first bit of the post. As far as your Lisp implementation goes, since promises are really just syntactical sugar around continuation passing (not in a bad way), and since both the continuation and the callback are first class, it should be trivial to land on a syntax that is as easy or easier to read than the JavaScript implementation. I think your final implementation hides a bit too much.

chaitanya 12y ago
> I think you should note in captions that each of your code samples came from Domenic's blog, to be polite. I actually mention this in a footnote, but I will do what you have suggested to be clearer still. > it should be trivial to land on a syntax that is as easy or easier to read than the JavaScript implementation. I think your final implementation hides a bit too much. Can you elaborate how this syntax might look?

briantrice 12y ago

It would be good to tackle multiple-promises-dependencies that the when()/all() protocols achieve, compared to then().

chaitanya 12y ago
I avoided it so that the post does not become very long and the main point doesn't get diluted. That said, I do use multiple-promise-depenencies to implement PCL:LET in the accompanying source https://github.com/chaitanyagupta/promises/blob/1.0/pcl.lisp#L12 https://github.com/chaitanyagupta/promises/blob/1.0/pcl.lisp... (ON-PROMISES does the same thing as when()/all()).

chajath 12y ago

think it would also be interesting to compare this approach to other (quasi-) meta-programmatic approach in JS like async.js