Arc Forumnew | comments | leaders | submitlogin
1 point by rocketnia 4462 days ago | link | parent

Sure they can be merged. If the input to the catcher function is a data structure indicating what kind of jump is being intercepted and the output is a similar data structure indicating what kind of jump to continue into, it can even be a pure function (if the user so chooses; they could also raise an error or call a continuation manually). The before part of a dynamic wind could work this way too.

The catch is that this reflective kind of tool may not be very efficient... but fortunately, it doesn't have to be the lowest-level tool. In fact, with 'dynamic-wind around, it might not even need to be an axiom:

  ; TODO: Test this code. It's big and confusing and therefore almost
  ; certainly buggy.
  
  ; We're using '$ (as seen in Anarki) to get things from Racket.
  (= raise $.raise)
  (= dynamic-wind $.dynamic-wind)
  (mac b-and-a (bef . rest)
    (let (aft . body) rev.rest
      `(dynamic-wind (fn () ,bef) (fn () ,@body) (fn () ,aft))))
  (mac before (bef . body)
    `(b-and-a ,bef ,@body nil))
  
  ; The "refl" is for "reflective."
  (def refl-dynamic-wind (bef body aft)
    (with (resume-unknown-ccc-exit nil normalentry t)
      (before
        (let normal normalentry
          (wipe resume-unknown-ccc-exit normalentry)
          (let entry (bef:if normal '(enter) '(unknown-ccc))
            (case entry.0
              enter        (unless normal
                             (err "Can't enter normally"))
              raise        (raise entry.1)
              unknown-ccc  (when normal
                             (err "Can't enter using unknown-ccc"))
              known-ccc    (entry.1)
                (err:+ "Unknown entry " (tostring:write entry)))
        (let exit (aft:catch:let normalexit nil
                    (b-and-a
                      wipe.normalexit
                      (do1 (on-err [do `(raise ,_)]
                                   (fn () `(return ,(body))))
                           (= normalexit t))
                      (unless normalexit
                        (when (ccc [= resume-unknown-ccc-exit _])
                          (throw `(unknown-ccc))))))
           (case exit.0
             return       exit.1
             raise        (raise exit.1)
             unknown-ccc  (if resume-unknown-ccc-exit
                            resume-unknown-ccc-exit.nil
                            (err "Can't exit using unknown-ccc"))
             known-ccc    (exit.1)
               (err:+ "Unknown exit " (tostring:write exit))))))
  
  (mac refl-b-and-a (bvar bef . rest)
    (let (aft avar . body) rev.rest
      `(refl-dynamic-wind
         (fn (,bvar) ,bef) (fn () ,@body) (fn (,avar) ,aft))))))
  (mac refl-before (bvar bef . body)
    `(refl-b-and-a ,bvar ,bef ,@body nil nil))
  
  ; NOTE: Arc's 'after uses all sub-s-expressions but the first as the
  : catcher, while this uses only the last two.
  (mac refl-after rest
    (let (aft avar . body) rev.rest
      `(refl-b-and-a nil nil ,@body ,avar ,aft)))
  
  
  ; Example usage:
  
  (def reimplemented-on-err (catcher body)
    (refl-after (body)
      exit (case exit.0 raise
             `(return ,(catcher exit.1))
             exit))
  
  (def reimplemented-protect (body aft)
    (refl-after (body)
      exit (do (aft) exit)))
  
  (def reimplemented-dynamic-wind (bef body aft)
    (refl-b-and-a
      entry (do (bef) entry)
      (body)
      exit (do (aft) exit)))
  
  (def reimplemented-raise (error)
    (refl-after nil
      exit `(raise ,error)))
---

JavaScript's catch and finally aren't so different either:

  function myFinally1( body, aft ) {
      try { body(); }
      finally { aft(); }
  }
  
  function myFinally2( body, aft ) {
      try { body(); }
      catch ( e ) {
          aft();
          throw e;
      }
      aft();
  }
However, things like myFinally2() are pretty annoying when trying to use Chrome's debugger with "Break on uncaught exceptions," so I've stopped treating these as equivalent in practice.


1 point by Pauan 4462 days ago | link

"JavaScript's catch and finally aren't so different either"

I realized afterwards that you can define protect in terms of on-err, but that isn't quite the same as using the same operator for both use cases. And, uh, that code looks awfully intimidating, so please forgive me for not looking deeply into it and trying to understand it.

In any case, my question still hasn't been answered: is there any use case for this at all?

-----

2 points by rocketnia 4462 days ago | link

"I realized afterwards that you can define protect in terms of on-err"

Nah. While that's a straightforward analogy from catch and finally, 'protect deals with continuation early exits (not seen in JavaScript), whereas 'on-err isn't supposed to. Jarc's 'on-err did for a while, but I seem to remember that being fixed.

---

"And, uh, that code looks awfully intimidating, so please forgive me for not looking deeply into it and trying to understand it."

Fair enough. ^_^

Just in case anyone wants to use that monstrous code, feel free.

---

"In any case, my question still hasn't been answered: is there any use case for this at all?"

Inasmuch as a language designer is trying to expose as much as possible to the programmer, even things they don't expect to be useful, that's not a question that needs an answer. The real question is "Why not?"

But dido spelled out at least one goal: "I do believe that there should be some way to retrieve the original exception, rather than the last one raised by protect handlers"

I'm guessing dido's point is that a buggy protect handler shouldn't keep the programmer from discovering bugs under its protection. (It's being overprotective? :-p ) For instance, dido might like to see both errors at the command line.

---

For you and anyone else who didn't read the 'refl-dynamic-wind code, here's an outline of the guards' inputs and outputs, so you can get a sense of the flexibility it gives to the programmer:

  ; Possible inputs to the entry guard:
  (enter)
  (unknown-ccc)
  
  ; Possible results of the entry guard:
  (enter)          ; only if (enter) was the input
  (raise <error>)
  (unknown-ccc)    ; only if (unknown-ccc) was the input
  (known-ccc <destination continuation>)
  
  ; Possible inputs to the exit guard:
  (return <value>)
  (raise <error>)
  (unknown-ccc)
  
  ; Possible results of the exit guard:
  (return <value>)
  (raise <error>)
  (unknown-ccc)
  (known-ccc <destination continuation>)
(It could also help to read the examples I posted, which are at the bottom of that giant code block.)

Come to think of it, it's probably possible to keep hacking on 'refl-dynamic-wind until the interface is like this:

  ; Possible inputs to the entry guard:
  (enter)
  (continue <destination>)
  
  ; Possible inputs to the exit guard:
  (return <value>)
  (raise <error>)
  (continue <destination>)
  
  ; Possible results of either guard:
  (enter)
  (return <value>)
  (raise <error>)
  (continue <destination>)
I'd like to point out that this interface isn't the full extent of what the language designer might like to expose to the programmer.

For instance, in Kernel, continuation guards have access to both the destination continuation and the value being passed to it. If we implemented 'refl-dynamic-wind there, every one of the (continue <destination>) cases above could become (continue <destination> <value>).

If an Arc implementation provided that extended interface, it would make for a more flexible language from a dynamic standpoint and a less predictable language from a static standpoint.

-----