664 - new, wart-like prompt

This is the right time for this change I've been meaning to make,
because it lets me drop my hack in 'abort-to'.

'abort-to' is likely still a bad idea because:
  a) Just because this example doesn't need to clear a few things on
  abort doesn't mean such use cases don't exist. In other words, there's
  no way to tell if your stack frame recently returned from an abort.
  That question isn't even well-posed at the moment; what does
  'recently' even mean?

  b) I may need to run deferred statements on each stack frame, and it's
  not clear how to rewrite 'defer' to be robust to aborts. Exceptions
  entering through the back door?

  Looks like all this is expected when implementing exception-like
  behavior using continuations:
    http://matt.might.net/articles/implementing-exceptions

  c) Of course we don't have composable exceptions. I still don't grok
  the value of that. We don't need yield since we have channels. What
  else might we need continuations for? Let's try to come up with a
  clean way to implement the amb operator or something.
    http://www.randomhacks.net/2005/10/11/amb-operator

1 files changed, 0 insertions, 1 deletions

diff --git a/mu.arc b/mu.arc
index 7e1c5f3e..5089a8db 100644
--- a/mu.arc
+++ b/mu.arc
@@ -830,7 +830,6 @@
                     (until (is caller top.routine*!fn-name)
                       (pop-stack routine*)
                       ; no incrementing pc; we want to retry the call
-                      (-- pc.routine*)  ; temporary hack, hardcoded for color-repl.mu
                       )
                     ((abort-routine*)))