<div>Hi,</div><div> </div><div>Now I don't want to get this mail please!</div><div> </div><div>Sejal.<br><br></div><div class="gmail_quote">On Sun, Mar 24, 2013 at 1:13 PM,  <span dir="ltr"><<a href="mailto:gambit-list-request@iro.umontreal.ca" target="_blank">gambit-list-request@iro.umontreal.ca</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">Send Gambit-list mailing list submissions to<br>
        <a href="mailto:gambit-list@iro.umontreal.ca">gambit-list@iro.umontreal.ca</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list" target="_blank">https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:gambit-list-request@iro.umontreal.ca">gambit-list-request@iro.umontreal.ca</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:gambit-list-owner@iro.umontreal.ca">gambit-list-owner@iro.umontreal.ca</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Gambit-list digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Foreign object printers? (Marc Feeley)<br>
   2. Re: Your feedback would be much appreciated re: Proposal for<br>
      enabling IO errors to be reported through returning of a custom<br>
      value instead of by throwing exception, through DSL with exports:<br>
      ##io-error-behavior param, ##default-io-error-behavior unique<br>
      value, ##last-io-error param. (Mikael)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 24 Mar 2013 13:43:38 -0400<br>
From: Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>><br>
Subject: Re: [gambit-list] Foreign object printers?<br>
To: Jason Felice <<a href="mailto:jason.m.felice@gmail.com">jason.m.felice@gmail.com</a>><br>
Cc: Gambit List <<a href="mailto:gambit-list@iro.umontreal.ca">gambit-list@iro.umontreal.ca</a>><br>
Message-ID: <<a href="mailto:4EA356E8-06FB-477A-9E97-D932618035DB@iro.umontreal.ca">4EA356E8-06FB-477A-9E97-D932618035DB@iro.umontreal.ca</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
<br>
On 2013-03-24, at 1:16 PM, Jason Felice <<a href="mailto:jason.m.felice@gmail.com">jason.m.felice@gmail.com</a>> wrote:<br>
<br>
> Whats macro-writeenv-style and ##wr-mark about?<br>
<br>
The style field of a writeenv indicates the style in which the object is to be written.  Currently the style can be<br>
<br>
- write           (11 "abc" 22) is written as: (11 "abc" 22)<br>
- display         (11 "abc" 22) is written as: (11 abc 22)<br>
- print           (11 "abc" 22) is written as: 11abc22<br>
- pretty-print    uses indentation/line breaks for pretty printing<br>
- mark            used by #n=... notation<br>
<br>
So the mark style is special in that it does not produce output.  It is used when the readtable-sharing-allowed? flag is set:<br>
<br>
  > (define (wr obj allow?)<br>
      (call-with-output-string<br>
        '()<br>
        (lambda (p)<br>
          (output-port-readtable-set!<br>
            p<br>
            (readtable-sharing-allowed?-set<br>
              (output-port-readtable p)<br>
              allow?))<br>
          (write obj p))))<br>
  > (wr (let ((x (cons 11 22))) (list x x)) #f)<br>
  "((11 . 22) (11 . 22))"<br>
  > (wr (let ((x (cons 11 22))) (list x x)) #t)<br>
  "(#0=(11 . 22) #0#)"<br>
<br>
The write/display/print/pretty-print procedures will make a first pass over the object/subobjects with style=mark.  This is to gather in a table all the subobjects to write.  Then, during the second pass, the #n=... notation will be used when an object has been marked more than once during the mark pass.<br>

<br>
Marc<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 24 Mar 2013 20:12:33 +0200<br>
From: Mikael <<a href="mailto:mikael.rcv@gmail.com">mikael.rcv@gmail.com</a>><br>
Subject: Re: [gambit-list] Your feedback would be much appreciated re:<br>
        Proposal for enabling IO errors to be reported through returning of a<br>
        custom value instead of by throwing exception, through DSL with<br>
        exports: ##io-error-behavior param, ##default-io-error-behavior unique<br>
        value, ##last-io-error param.<br>
To: Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>>,<br>
        <a href="mailto:gambit-list@iro.umontreal.ca">gambit-list@iro.umontreal.ca</a><br>
Message-ID:<br>
        <<a href="mailto:CACbx-M-N%2BuhevRW9kiY0F6P9NfqqcsGS5X1bqukqbtHChcxwyA@mail.gmail.com">CACbx-M-N+uhevRW9kiY0F6P9NfqqcsGS5X1bqukqbtHChcxwyA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Marc!<br>
<br>
Ah, one thing struck me: in some cases, IO primitives don't raise an<br>
exception on error but instead return a special value, I think it's #!eof<br>
always.<br>
<br>
This would not transform to returning #f by a with-exception-handler<br>
wrapper, but it could with a port specific flag |io-error| or |eof-value|<br>
or |treat-eof-as-error|.<br>
<br>
<br>
<br>
Do you have any thoughts on the previous email on with-exception-handler<br>
and IO error semantics yet?<br>
<br>
Of course there's time though would be great to get this question about how<br>
to reliably do general IO error handling settled.<br>
<br>
<br>
The two possible ways I have the impression that there are now are<br>
<br>
1) By:<br>
 * Add a |treat-eof-as-error| port flag<br>
 * Add an optional third arg |first?| to |with-exception-catcher| and<br>
-handler that makes the thunk be invoked first in case of exception.<br>
   Internally there's two exception handler chains, the non-first that<br>
works just like the one today - an exception handler added makes it be<br>
invoked as first line in case of exception, and another chain that has<br>
priority over the non-first chain, that's invoked before it and where new<br>
handlers are added at the end and not at the beginning. (Perhaps internally<br>
they can be implemented as one chain only.)<br>
 * Make |with-exception-handler| exception handlers recursive (now they<br>
make an infinite loop).<br>
<br>
or<br>
<br>
2): (Less general solution, so probably not desirable) By:<br>
 * Add a port-specific flag |io-error| to IO ports that's invoked in the<br>
current place of both |raise| and eof.<br>
<br>
In either of these two, the IO primitives need to be checked so that the IO<br>
error handling/|raise| calls are done in tail position / place that<br>
produces the primitive's return value anyhow.<br>
<br>
Thanks and best regards,<br>
Mikael<br>
<br>
2013/3/22 Mikael <<a href="mailto:mikael.rcv@gmail.com">mikael.rcv@gmail.com</a>><br>
<br>
> Dear Marc,<br>
><br>
> Spontaneously I think that the prospect of using with-exception-handler as<br>
> you propose sounds better than adding custom error behavior code to the IO,<br>
> as, the w.e.h. route would be more holistic in that it maintains the error<br>
> handling mechanism in Gambit one in total in number; also,<br>
><br>
> It would work from a performance point of view as there is no overhead per<br>
> IO primitive call that's successful, which accounts for almost all of them.<br>
> The only potential issue with performance would be if the exception handler<br>
> part would take a lot of time, though I guess it can be generalized that<br>
> that is not an issue.<br>
><br>
> Then I guess the last point would be the design aspect that if somehow IO<br>
> code would be run outside the current environment that the w.e.h. is<br>
> installed in, the custom error behavior would disappear; that would indeed<br>
> be a benefit with a port specific flag, that it's not subject to the same<br>
> limitation. Though, from the practical use I see today, that more or less<br>
> does not happen so it's fine.<br>
><br>
><br>
> I didn't think deeper about the possibility of w.e.h. before as I found<br>
> myself without clarity on how the things I addressed in the previous email<br>
> could be solved, as they need to be solved for it to be a practically<br>
> viable solution.<br>
><br>
><br>
> Looking forward a lot to hear your take on those two-three things and<br>
> hopefully get to a reliable io-error => #f soon =)<br>
><br>
> Thanks,<br>
> Mikael<br>
><br>
><br>
><br>
> 2013/3/20 Mikael<br>
><br>
> Hi Marc!<br>
>><br>
>><br>
>> 2013/3/18 Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>><br>
>><br>
>>> The problem I see with the approach you propose (whether it uses a<br>
>>> parameter or a port specific flag) is that the semantics of an "io-error"<br>
>>> is vague.  What is an IO error?  The definition is important because<br>
>>> exceptions that are IO errors are going to be processed using this new<br>
>>> mechanism, and non-IO exceptions will use a different mechanism (normal<br>
>>> exception handling).<br>
>>><br>
>>> The approach I propose does not have this problem because the programmer<br>
>>> has complete control over the definition of an IO error.  The exception<br>
>>> object can be inspected to see if it qualifies as an IO error and an<br>
>>> appropriate action can be taken.  The definition of IO error can depend on<br>
>>> the type of port, the type of primitive which caused the exception<br>
>>> (read-u8, read-char, read), etc.<br>
>>><br>
>>> Marc<br>
>>><br>
>>><br>
>> Aha. To really get this, there are two quite fundamental things about the<br>
>> applicability of the with-exception-handler possibility that I maybe don't<br>
>> get yet or at least would benefit of clarification, can we have a look at<br>
>> it?<br>
>><br>
>> Also last a question re semantics of io-error.<br>
>><br>
>><br>
>><br>
>> So, for the with-exception-handler mechanism to work out, it needs to go<br>
>> together with other use of exception handling use that's being done in the<br>
>> same scope.<br>
>><br>
>> In a setup where there's another exception handler *outside* the IO<br>
>> with-exception-handler, there would be no issue as the IO w.e.h. 's handler<br>
>> would be invoked first for any exception that occurs, and do its matching<br>
>> and handling.<br>
>><br>
>> In a setup where the other exception handler is made *inside* the IO<br>
>> w.e.h. though, any IO exception that arises within that exception handler<br>
>> will be picked up by it first, and for the IO w.e.h. thing to work out,<br>
>> that handler needs to be able to pass on the exception to the parent<br>
>> exception handler (which is the IO w.e.h.) completely in its original<br>
>> shape, in such a way that if the IO w.e.h. handler returns a value, that<br>
>> will be passed as return value to the original |raise| call.<br>
>><br>
>> An example of this would be a web-based PI calculator that uses exception<br>
>> handling locally in its PI calculate request thunk to pick up invalid user<br>
>> input.<br>
>><br>
>> So let's ask how this could be done.<br>
>><br>
>> Let's say below that we have a procedure (install-io-w.e.h. port thunk) that<br>
>> installs the IO w.e.h. that makes IO primitives return #f on exception, so<br>
>> that thunk is invoked with that w.e.h. installed.<br>
>><br>
>> Then, we have application logics (logics) that, aside from using IO,<br>
>> internally uses exception handling.<br>
>><br>
>> So a setup something like,<br>
>><br>
>> (define (logics)<br>
>>   (with-exception-catcher<br>
>>     (lambda (e) "Logics failed due to invalid user input!")<br>
>>     (lambda ()<br>
>>       (pp (read-u8 broken-port))<br>
>>       (/ 0 0) ; This is to simulate an exception due to invalid user<br>
>> input.<br>
>>       )))<br>
>> (install-io-w.e.h. broken-port logics)<br>
>><br>
>><br>
>> The desired behavior here is to print #f to the console and for logics<br>
>> to then return "Logics failed due to invalid user input!".<br>
>><br>
>> The issue now becomes, how would this local exception handler need to be<br>
>> implemented as for this to work out.<br>
>><br>
>><br>
>> The local exception handler needs to be specific about what kind of error<br>
>> it looks for as to know which to handle locally and which to re-raise. This<br>
>> might be a complete PITA in some situations as you're looking for a<br>
>> catch-all behavior, as in the example above!<br>
>><br>
>> Perhaps the order of exception handlers could be tweaked somehow, so that<br>
>> the IO w.e.h. would get highest priority or something, though how could<br>
>> that be made as a 'clean' abstraction? I mean, who's in a place to claim at<br>
>> a general level that one exception is of higher prio than another? -<br>
>> different classes could be introduced, like, "user exceptions" and "io<br>
>> exceptions" or "system exception" (this would lead to an at least almost<br>
>> functional equivalent of the port specific flag solution, just with a more<br>
>> indirect code path!), or, the exception matching procedure could be<br>
>> exported to a separate mechanism, and the exception handler claiming the<br>
>> highest specificity in the matching would get to handle it e.g. (with-exception-handler<br>
>> exception-match exception-handler thunk) where exception-match takes an<br>
>> exception argument e and returns how well it matches the exception, i duno<br>
>> as a boolean or 0-10 or a symbol.<br>
>><br>
>> Or, a global parameter object |is-nonlocal-exception?| could be<br>
>> introduced that any exception handler is free to invoke as to check if it<br>
>> should re-raise the exception, and to overlap.. hmm, a more general<br>
>> solution would be better.<br>
>><br>
>> Do you see any general solution to this specificity problem?<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Now to get to the next thing, let's just presume there's a solution to<br>
>> this and we represent it in this example as a (if<br>
>> (is-nonlocal-exception? e) (raise e) condition in the local exception<br>
>> handler, again not because this would necessarily represent a general<br>
>> solution but just to get on to the next thing in the reasoning; so now we<br>
>> have<br>
>><br>
>> (define (logics)<br>
>>   (with-exception-catcher<br>
>>     (lambda (e) (if (is-nonlocal-exception? e) (raise e) "Logics failed<br>
>> due to invalid user input!"))<br>
>>     (lambda ()<br>
>>       (pp (read-u8 broken-port))<br>
>>       (/ 0 0) ; This is to simulate an exception due to invalid user<br>
>> input.<br>
>>       )))<br>
>> (install-io-w.e.h. broken-port logics)<br>
>><br>
>><br>
>> Now, how do you make this *parent* exception handler (the IO w.e.h.) that<br>
>> got the exception passed to it, able to pass a return value to the original<br>
>> |raise| call?<br>
>><br>
>> This is required for the exception handling-based IO error handling<br>
>> behavior we're looking for to work.<br>
>><br>
>> The problem reduces to<br>
>><br>
>> (define (logics) (raise "Please return 'properly-handled!"))<br>
>><br>
>> (define (proxy-exception-handler/catcher2 thunk) (lambda ()<br>
>> (with-exception-catcher (lambda (e) (raise e)) thunk)))<br>
>><br>
>> (define (proxy-exception-handler/catcher1 thunk) (lambda ()<br>
>> (with-exception-handler (lambda (e) (raise e)) thunk)))<br>
>><br>
>> (define (parent-exception-handler thunk) (continuation-capture (lambda<br>
>> (cont) (with-exception-handler (lambda (e) 'properly-handled!) thunk))))<br>
>><br>
>> where proxy-exception-handler/catcher 1 & 2 are to represent an arbitrary<br>
>> chain of exception handlers that logics code may come up with. The intended<br>
>> behavior is<br>
>><br>
>><br>
>> (parent-exception-handler (proxy-exception-handler/catcher1 (proxy-exception-handler/catcher2<br>
>> logics))) => 'properly-handled!<br>
>><br>
>> (parent-exception-handler (proxy-exception-handler/catcher1 logics)) =><br>
>> 'properly-handled!<br>
>><br>
>> (parent-exception-handler (proxy-exception-handler/catcher2 logics)) =><br>
>> 'properly-handled!<br>
>><br>
>><br>
>><br>
>> Actually evaluating these three tests showed:<br>
>><br>
>> (parent-exception-handler (proxy-exception-handler/catcher1 (proxy-exception-handler/catcher2<br>
>> logics))) => infinite loop (!)<br>
>><br>
>> (parent-exception-handler (proxy-exception-handler/catcher1 logics)) => infinite<br>
>> loop (!)<br>
>><br>
>> (parent-exception-handler (proxy-exception-handler/catcher2 logics)) =><br>
>> 'properly-handled!<br>
>><br>
>><br>
>> To start with, great that we see that with-exception-catcher delivers out<br>
>> of the box for this usecase!<br>
>><br>
>> Thus we have with-exception-handler left. I guess the best way would be<br>
>> if with-exception-handler inherently somehow would deliver for this, so<br>
>> that support for this kind of use would be transparent and not require<br>
>> possible updates of user code (e.g. any typical user code such as a PI<br>
>> calculator etc. could without needing code review just be run within a web<br>
>> server that uses this special IO error handling).<br>
>><br>
>> Is there any way to make with-exception-handler deliver for this usecase?<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Last, what about that for introducing a port specific flag there would be<br>
>> the issue that the semantics of an IO error is vague -<br>
>><br>
>> Maybe you see something here I didn't get. As IO error for a port would<br>
>> count any error reported from the OS about the port, as well as timeouts<br>
>> within Gambit's IO system.<br>
>><br>
>> So this would correspond to any OS IO primitive invocation that gives an<br>
>> error return value (other than one that asks for a reiteration of the<br>
>> procedure, which some of them come with).<br>
>><br>
>> Another way to relate to it would be that such a port specific flag would<br>
>> serve to protect from requirement of programmer or admin intervention for<br>
>> any IO error that could possibly come up regarding the addressed ports.<br>
>><br>
>> What do you see here?<br>
>><br>
>><br>
>><br>
>> Best regards,<br>
>> Mikael<br>
>><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20130324/e239585d/attachment.html" target="_blank">http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20130324/e239585d/attachment.html</a><br>

<br>
------------------------------<br>
<br>
_______________________________________________<br>
Gambit-list mailing list<br>
<a href="mailto:Gambit-list@iro.umontreal.ca">Gambit-list@iro.umontreal.ca</a><br>
<a href="https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list" target="_blank">https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list</a><br>
<br>
<br>
End of Gambit-list Digest, Vol 102, Issue 28<br>
********************************************<br>
</blockquote></div><br>