On Wed, Aug 22, 2012 at 3:32 PM, Andy Wingo <wingo@pobox.com> wrote:
> Hello,
>
> On Wed 22 Aug 2012 01:54, Alex Shinn <alexshinn@gmail.com> writes:
>
>> You acknowledged that whether we put it in the
>> small language or not, people will have raise-continuable.
>> This is incompatible with your definition of c-w-i-f.
>
> No, this is not.  If a user implements raise-continuable, it does not
> use the exception mechanism.

You can implement continuable and even restartable exceptions
in terms of the existing exception system.  Consider the following:

(define-record-type restartable-exception
  (make-restartable-exception exn cont)
  restartable-exception?
  (exn restartable-exception-exn)
  (cont restartable-exception-cont))

(define (raise-restartable exn)
  (call-with-current-continuation
   (lambda (k) (raise (make-restartable-exception exn k)))))

(guard (exn (restartable-exception? ((restartable-exception-cont exn) 42)))
  (+ 1 (raise-restartable "what is the answer to the big question?")))

>> No one is talking about non-local exits that do not use
>> the exception mechanism.
>
> Why did you mention amb, then?

I'm talking about mixing amb with the exception system.
amb by itself is fine - no one here is suggesting that
dynamic-wind could be used for finalization.  But you
have to be careful when mixing the two.

>>>> `exception-protect' is useful but is only an 80% solution.
>>>> It is therefore not appropriate for call-with-input/output-file.
>>>
>>> This is ridiculous.  The same argument would support not closing the
>>> file after a normal exit from the c-w-i-f procedure.
>>
>> No it would not, because that's the existing c-w-i-f semantics
>> (that the port is closed after the first normal return).
>>
>> You are proposing a change to the semantics which could
>> break existing R6RS programs, and existing R5RS programs
>> that use an exception system.
>
> Since when do you care about R6RS?

Peace, Andy :)  Let's not get personal.

For the record, I've never said anything bad about R6RS on
these lists, beyond considering individual features being
appropriate or not for R7RS.

And regardless, I set aside my personal opinions and
agendas the day the SC asked me to chair.  The charter
requires compatibility with a subset R6RS in so far as
practical.  So for over two years now the group has been
working on this, and a large part of what we do is debate
whether given R6RS features should be included in the
small language.  The result is that to a large extent, R7RS
WG1 is a line drawn between R5RS+SRFIs and R6RS.

And I'm really looking forward to finishing this up, so I
_can_ go back to having subjective opinions and working
on my own projects which have been abandoned for too
long.

> It doesn't matter though, the answer
> here is still no: R6RS programs use different libraries.  c-w-i-f in
> R6RS does not have the be the same one as in R7RS.

It's not that simple.  Dynamic extent can have complex
interactions where third-party libraries may "sandwich"
your own code.

Consider the following parser combinator example:

(let ((parser (parser-or parser1 parser2)))
  (with-parsers
   (call-with-input-file file
     (lambda (in)
       (let ((stream (make-parser-stream in)))
         (parser in))))))

parser-or generates a disjunction of parser1 and
parser2, so that `parser' will return the first result
that succeeds.  make-parser-stream gives you a
stream so that backtracking is possible.  Let's
suppose for historical reasons the individual parsers
simply raise exceptions when they fail.  Thus it's
the job of with-parsers to catch the exceptions
and move on to the next parser.

If call-with-input-file closes the port on exceptions,
this code breaks.

> As R5RS has nothing to say about exception systems, it cannot possibly
> break these.

True, so we're not bound by backwards compatibility.
We do have to take existing practice into account,
however, and many R5RS implementations provide
exception systems.  If we ask nicely John might take
a survey of which ones close ports on exceptions in
c-w-i/o-f :)

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports