Arc Forumnew | comments | leaders | submitlogin
Abusing conditions and restarts in Common Lisp
2 points by shader 3604 days ago | 6 comments
http://www.dawnofthedata.com/2014/05/abusing-langauge-features-common-lisp.html


2 points by shader 3602 days ago | link

So, are there anything like restarts available for Racket/arc?

And what is the status of the various CL implementations of arc? I know there were a few, but remember little else.

-----

3 points by rocketnia 3602 days ago | link

"So, are there anything like restarts available for Racket/arc?"

I'm pretty sure the answer is no, for now.

With the right use of Racket's 'parameterize and 'current-parameterization, we could build a system that works like Common Lisp's conditions and restarts. (Global variables are an alternative to 'parameterize, but they'll have more awkward interactions with continuations and threads.)

I've only played with CL once or twice, but I seem to recall one of the nicest parts about conditions and restarts is that when a condition isn't caught at the REPL, the user gets a sub-prompt they can use to invoke a restart. Threads might give us something close to this behavior, if we make the REPL's catch-all condition handler block the thread while the user chooses a restart.

Unfortunately, all preexisting Racket/Arc errors will still use the exception system rather than this homemade condition system. In order to make conditions the main error mechanism, we might have to modify the way Arc compiles to Racket so that it traps exceptions and turns them into conditions.

Finally, CL's condition handlers use its subclassing system to find the most specific handler. Arc doesn't have hierarchical dynamic typing like that, or at least not in the main language, so it might not make sense to handle conditions that way.

Altogether this is quite a few feature interactions that would need to be considered, and we'd end up with quite a different REPL experience--maybe even a qualitatively different language. How do we know if it's worth it?

-----

2 points by shader 3602 days ago | link

"How do we know if it's worth it?"

It's probably not. Restarts (and similar) just seemed like a really useful tool for use in production environments. Anything that makes error handling more powerful, flexible, or understandable is a good thing. But changing arc to support it might be a bit much, at least at this point.

I do think it would be good if we could improve arc's error handling though. Or at least error reporting on the repl.

Arc doesn't have hierarchical dynamic typing like that...

I had created a hierarchical typing system for arc once, by just changing the tagged symbol to a list of symbols that is treated as the type hierarchy, but I think I lost the code... I'll have to see if I can find it.

-----

1 point by akkartik 3602 days ago | link

Well, arc has delimited continuations from racket, and I gather you can do anything with them. But if you figure out how, you come tell us :)

I think the CL implementations must have happened when I was away from the forum. Wart started out as a common lisp implementation of arc: http://arclanguage.org/item?id=12814; https://github.com/akkartik/wart/tree/sbcl. But again, I did this without ever grokking conditions and restarts. The OP was actually quite illuminating for me.

-----

1 point by shader 3602 days ago | link

Well then, maybe I was just imagining things. Would be interesting to have a CL implementation of arc.

Though, I'd probably end up implementing something closer to wat.js with the arc library.

What was the reason pg decided not to go with CL for the base of arc? I remember seeing him say it somewhere...

-----

2 points by malisper 3602 days ago | link

He originally did write it using Common Lisp[0].

I'm not sure why he changed it though. There must have been some benefit (maybe the lisp-1 vs lisp-2) which made it easier to write arc.

[0]http://www.paulgraham.com/hundred.html

-----