Re: [racket-users] opinion needed on best fix for handin-server problem

[Eli Barzilay]

On Wed, May 4, 2016 at 5:36 PM, Sam Tobin-Hochstadt
 wrote:
> On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users
>  wrote:
>>
>> IIUC, it sounds like both you and Sam are suggesting the same
>> thing. I think this *could* cause backward incompatibility for the
>> *probably empty* set of handin checkers that use tests for
>> non-transparent exceptions, but I’m happy to make this change if it
>> makes sense to you guys.
>
> But don't those programs break now, with the error that led you to
> originally start this discussion?

[FWIW, yes, I'm completely with Sam -- including this confusion.]

-- 
((x=>x(x))(x=>x(x)))   Eli Barzilay:
http://barzilay.org/   Maze is Life!

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

> On May 4, 2016, at 2:36 PM, Sam Tobin-Hochstadt  wrote:
> 
> On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users
>  wrote:
>> 
>>> On May 4, 2016, at 2:24 PM, Eli Barzilay  wrote:
>>> 
>>> On Wed, May 4, 2016 at 5:12 PM, John Clements  
>>> wrote:
 
 So, I’d say this is basically an ergonomics issue. If we change this
 code to raise a new exception, then it might potentially confuse a
 handin-server-checker-writer, who expects (e.g.) to see a
 ‘exn:fail:contract:variable?’ but actually gets back a
 ‘exn:fail:handin-server?’.  IIUC, clear documentation could resolve
 this.
>>> 
>>> I have no opinion on breaking backward compatibility on expectations of
>>> user-code (I might have some but I can adjust), but things like
>>> `!defined`, `!bound`, and `!syntax` should definitely continue working
>>> -- and it seems worse to fix them by looking at the exception message.
>>> 
>>> Another option to fix it would be to make it keep doing what it does now
>>> if the exceptions are transparent, and switch to some wrapper exception
>>> otherwise.  This way you're only breaking hypothetical code that expects
>>> exceptions that make it fail now anyway, IOW -- there's no breaking...
>>> (And also document the fact that not all of the builtin exceptions are
>>> transparent, unless it's already done somewhere.)
>> 
>> IIUC, it sounds like both you and Sam are suggesting the same thing. I think 
>> this *could* cause backward incompatibility for the *probably empty* set of 
>> handin checkers that use tests for non-transparent exceptions, but I’m happy 
>> to make this change if it makes sense to you guys.
> 
> But don't those programs break now, with the error that led you to
> originally start this discussion?

No, because the error-handling code falls back to simply re-raising the 
exception as it exists. This is why my students still got match failures, but 
they didn’t get the source text that caused them.

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] opinion needed on best fix for handin-server problem

[Sam Tobin-Hochstadt]

On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users
 wrote:
>
>> On May 4, 2016, at 2:24 PM, Eli Barzilay  wrote:
>>
>> On Wed, May 4, 2016 at 5:12 PM, John Clements  
>> wrote:
>>>
>>> So, I’d say this is basically an ergonomics issue. If we change this
>>> code to raise a new exception, then it might potentially confuse a
>>> handin-server-checker-writer, who expects (e.g.) to see a
>>> ‘exn:fail:contract:variable?’ but actually gets back a
>>> ‘exn:fail:handin-server?’.  IIUC, clear documentation could resolve
>>> this.
>>
>> I have no opinion on breaking backward compatibility on expectations of
>> user-code (I might have some but I can adjust), but things like
>> `!defined`, `!bound`, and `!syntax` should definitely continue working
>> -- and it seems worse to fix them by looking at the exception message.
>>
>> Another option to fix it would be to make it keep doing what it does now
>> if the exceptions are transparent, and switch to some wrapper exception
>> otherwise.  This way you're only breaking hypothetical code that expects
>> exceptions that make it fail now anyway, IOW -- there's no breaking...
>> (And also document the fact that not all of the builtin exceptions are
>> transparent, unless it's already done somewhere.)
>
> IIUC, it sounds like both you and Sam are suggesting the same thing. I think 
> this *could* cause backward incompatibility for the *probably empty* set of 
> handin checkers that use tests for non-transparent exceptions, but I’m happy 
> to make this change if it makes sense to you guys.

But don't those programs break now, with the error that led you to
originally start this discussion?

Sam

> John
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

> On May 4, 2016, at 2:24 PM, Eli Barzilay  wrote:
> 
> On Wed, May 4, 2016 at 5:12 PM, John Clements  
> wrote:
>> 
>> So, I’d say this is basically an ergonomics issue. If we change this
>> code to raise a new exception, then it might potentially confuse a
>> handin-server-checker-writer, who expects (e.g.) to see a
>> ‘exn:fail:contract:variable?’ but actually gets back a
>> ‘exn:fail:handin-server?’.  IIUC, clear documentation could resolve
>> this.
> 
> I have no opinion on breaking backward compatibility on expectations of
> user-code (I might have some but I can adjust), but things like
> `!defined`, `!bound`, and `!syntax` should definitely continue working
> -- and it seems worse to fix them by looking at the exception message.
> 
> Another option to fix it would be to make it keep doing what it does now
> if the exceptions are transparent, and switch to some wrapper exception
> otherwise.  This way you're only breaking hypothetical code that expects
> exceptions that make it fail now anyway, IOW -- there's no breaking...
> (And also document the fact that not all of the builtin exceptions are
> transparent, unless it's already done somewhere.)

IIUC, it sounds like both you and Sam are suggesting the same thing. I think 
this *could* cause backward incompatibility for the *probably empty* set of 
handin checkers that use tests for non-transparent exceptions, but I’m happy to 
make this change if it makes sense to you guys.

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

> On May 4, 2016, at 2:20 PM, Sam Tobin-Hochstadt  wrote:
> 
> I am opposed to breaking backwards compatibility for this.
> 
> However, one possibility would be to do the thing I suggested _iff_
> the exception is non-transparent. Then everything that works would
> keep working, and future issues like this would not arise.

I’m probably misunderstanding you, but that doesn’t sound right to me.

First, I’m imagining that you’re referring to the idea of re-raising a 
different exception that contains the original one as a field. If that’s the 
case, and if we do this for non-transparent exceptions (e.g. exn:misc:match), 
then in principle anyone who has already written a checker that checks for 
exn:misc:match failures will stop working, because these will now have been 
re-raised as exn:fail:handin-server exns.

What am I missing?

John

> 
> Sam
> 
> On Wed, May 4, 2016 at 5:12 PM, 'John Clements' via Racket Users
>  wrote:
>> 
>>> On May 4, 2016, at 12:48 PM, Eli Barzilay  wrote:
>>> 
>>> On Wed, May 4, 2016 at 1:14 PM, John Clements  
>>> wrote:
 
> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt  
> wrote:
> 
> That seems fine, but the general approach the handin-server is taking
> seems wrong to me. If it wants an exception with a different message,
> it should just create that, rather than assuming that all exception
> structures are reasonable to modify.
 
 Well, I can certainly do both.
 
 In general, perhaps the right solution for the handin server would be
 to deliver an exn:fail:handin-server with an additional field
 containing the original exception. That way, no information is lost.
 
 The danger, of course, is that this might break code that depends on
 the exception satisfying some predicate (the filesystem and network
 exceptions are the ones that worry me). Perhaps Eli can comment on
 this?
>>> 
>>> TBH, I have no memory of this -- and looking at the code (I'm assuming
>>> it's the `reraise` bit in `wrap-evaluator`??) I'm not sure that I wrote
>>> it.
>>> 
>>> [...Doing some archaeological digging...]
>>> 
>>> OK, I think that the following is everything that I can say about it,
>>> and let you judge what would be the best way to re-solve it.  I think
>>> that the main thing that changed that you're talking about is Matthew's
>>> comment that "All the built-in exn structs are fully transparent,
>>> though".  Also, there's the motivation for doing this: "It's important
>>> to keep the same exception, because ...".  (And both of these might be a
>>> justification to make it transparent, or to fix it in a different way
>>> that makes the "because" thing work, and maybe make a note of the lack
>>> of transparency somewhere; I have no significant opinion about it.)
>> 
>> So, I’d say this is basically an ergonomics issue. If we change this code to 
>> raise a new exception, then it might potentially confuse a 
>> handin-server-checker-writer, who expects (e.g.) to see a 
>> ‘exn:fail:contract:variable?’ but actually gets back a 
>> ‘exn:fail:handin-server?’.  IIUC, clear documentation could resolve this.
>> 
>> Of course, this would be a breaking change for people who currently use the 
>> handin-server with such tests, but I’m generally in favor of breaking 
>> backward compatibility to make the world a better place.
>> 
>> Is this change making the world a better place?
>> 
>> John
>> 
>>> 
>>> So -- assuming that function is the right place that you're talking
>>> about, I see that this is code that I committed in:
>>> 
 commit fd858f081c564a3c94a682aee5896bc535fd9956
 Author: Eli Barzilay 
 Date:   2007-01-24 07:52:51 +
 
   removed the tweaker hack for a solution that creates a new exception
 
   svn: r5446
>>> 
>>> and it removes a simple hack that uses a `current-error-message-tweaker`
>>> ("tweaker" is surely mine...) and adds instead the code that assembles a
>>> new exception.
>>> 
>>> I then did some more digging in my mail, and found this email exchange
>>> between me and Matthew about this:
>>> 
>>> [Eli]
 For some corner of the handin server I wanted to capture exceptions,
 then reraise a modified version of the exception (basically turn any
 exn to one that has " while evaluating ").
 It's important to keep the same exception, because some tests rely
 on it (like catching an `exn:fail:contract:variable?' when testing
 for a bound identifier).
 
 Looks like `copy-struct' is not enough, because it wants a struct-id.
 Is there some easy way to do that?  (I know that it's possible,
 because I did similar stuff in reflecting mzscheme structs as swindle
 classes, but I'm looking for a simple solution.)
>>> 
>>> [Matthew]
 If you have a sufficiently powerful inspector, then `struct-info'

Re: [racket-users] opinion needed on best fix for handin-server problem

[Eli Barzilay]

On Wed, May 4, 2016 at 5:12 PM, John Clements  wrote:
>
> So, I’d say this is basically an ergonomics issue. If we change this
> code to raise a new exception, then it might potentially confuse a
> handin-server-checker-writer, who expects (e.g.) to see a
> ‘exn:fail:contract:variable?’ but actually gets back a
> ‘exn:fail:handin-server?’.  IIUC, clear documentation could resolve
> this.

I have no opinion on breaking backward compatibility on expectations of
user-code (I might have some but I can adjust), but things like
`!defined`, `!bound`, and `!syntax` should definitely continue working
-- and it seems worse to fix them by looking at the exception message.

Another option to fix it would be to make it keep doing what it does now
if the exceptions are transparent, and switch to some wrapper exception
otherwise.  This way you're only breaking hypothetical code that expects
exceptions that make it fail now anyway, IOW -- there's no breaking...
(And also document the fact that not all of the builtin exceptions are
transparent, unless it's already done somewhere.)

-- 
((x=>x(x))(x=>x(x)))   Eli Barzilay:
http://barzilay.org/   Maze is Life!

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] opinion needed on best fix for handin-server problem

[Sam Tobin-Hochstadt]

I am opposed to breaking backwards compatibility for this.

However, one possibility would be to do the thing I suggested _iff_
the exception is non-transparent. Then everything that works would
keep working, and future issues like this would not arise.

Sam

On Wed, May 4, 2016 at 5:12 PM, 'John Clements' via Racket Users
 wrote:
>
>> On May 4, 2016, at 12:48 PM, Eli Barzilay  wrote:
>>
>> On Wed, May 4, 2016 at 1:14 PM, John Clements  
>> wrote:
>>>
 On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt  
 wrote:

 That seems fine, but the general approach the handin-server is taking
 seems wrong to me. If it wants an exception with a different message,
 it should just create that, rather than assuming that all exception
 structures are reasonable to modify.
>>>
>>> Well, I can certainly do both.
>>>
>>> In general, perhaps the right solution for the handin server would be
>>> to deliver an exn:fail:handin-server with an additional field
>>> containing the original exception. That way, no information is lost.
>>>
>>> The danger, of course, is that this might break code that depends on
>>> the exception satisfying some predicate (the filesystem and network
>>> exceptions are the ones that worry me). Perhaps Eli can comment on
>>> this?
>>
>> TBH, I have no memory of this -- and looking at the code (I'm assuming
>> it's the `reraise` bit in `wrap-evaluator`??) I'm not sure that I wrote
>> it.
>>
>> [...Doing some archaeological digging...]
>>
>> OK, I think that the following is everything that I can say about it,
>> and let you judge what would be the best way to re-solve it.  I think
>> that the main thing that changed that you're talking about is Matthew's
>> comment that "All the built-in exn structs are fully transparent,
>> though".  Also, there's the motivation for doing this: "It's important
>> to keep the same exception, because ...".  (And both of these might be a
>> justification to make it transparent, or to fix it in a different way
>> that makes the "because" thing work, and maybe make a note of the lack
>> of transparency somewhere; I have no significant opinion about it.)
>
> So, I’d say this is basically an ergonomics issue. If we change this code to 
> raise a new exception, then it might potentially confuse a 
> handin-server-checker-writer, who expects (e.g.) to see a 
> ‘exn:fail:contract:variable?’ but actually gets back a 
> ‘exn:fail:handin-server?’.  IIUC, clear documentation could resolve this.
>
> Of course, this would be a breaking change for people who currently use the 
> handin-server with such tests, but I’m generally in favor of breaking 
> backward compatibility to make the world a better place.
>
> Is this change making the world a better place?
>
> John
>
>>
>> So -- assuming that function is the right place that you're talking
>> about, I see that this is code that I committed in:
>>
>>> commit fd858f081c564a3c94a682aee5896bc535fd9956
>>> Author: Eli Barzilay 
>>> Date:   2007-01-24 07:52:51 +
>>>
>>>removed the tweaker hack for a solution that creates a new exception
>>>
>>>svn: r5446
>>
>> and it removes a simple hack that uses a `current-error-message-tweaker`
>> ("tweaker" is surely mine...) and adds instead the code that assembles a
>> new exception.
>>
>> I then did some more digging in my mail, and found this email exchange
>> between me and Matthew about this:
>>
>> [Eli]
>>> For some corner of the handin server I wanted to capture exceptions,
>>> then reraise a modified version of the exception (basically turn any
>>> exn to one that has " while evaluating ").
>>> It's important to keep the same exception, because some tests rely
>>> on it (like catching an `exn:fail:contract:variable?' when testing
>>> for a bound identifier).
>>>
>>> Looks like `copy-struct' is not enough, because it wants a struct-id.
>>> Is there some easy way to do that?  (I know that it's possible,
>>> because I did similar stuff in reflecting mzscheme structs as swindle
>>> classes, but I'm looking for a simple solution.)
>>
>> [Matthew]
>>> If you have a sufficiently powerful inspector, then `struct-info'
>>> and `struct-type-info' let you do what you want, and that's the only
>>> possibility that I see.
>>
>> [Eli]
>>> Does the code below look reasonable?  -- I'm using struct-info just
>>> to make sure that struct->vector does return all the field values.
>>> (I think that this code will break with auto fields, but it should
>>> be fine with the exn hierarchy.)
>>>
>>>  (define ((make-chatty-eval eval) expr)
>>>(define (reraise exn)
>>>  (raise
>>>   (let-values ([(struct-type skipped?) (struct-info exn)])
>>> (if (and struct-type (not skipped?))
>>>   (let ([vals (vector->list (struct->vector exn))])
>>> (apply (struct-type-make-constructor struct-type)
>>>

Re: [racket-users] opinion needed on best fix for handin-server problem

[Eli Barzilay]

On Wed, May 4, 2016 at 1:14 PM, John Clements  wrote:
>
>> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt  wrote:
>>
>> That seems fine, but the general approach the handin-server is taking
>> seems wrong to me. If it wants an exception with a different message,
>> it should just create that, rather than assuming that all exception
>> structures are reasonable to modify.
>
> Well, I can certainly do both.
>
> In general, perhaps the right solution for the handin server would be
> to deliver an exn:fail:handin-server with an additional field
> containing the original exception. That way, no information is lost.
>
> The danger, of course, is that this might break code that depends on
> the exception satisfying some predicate (the filesystem and network
> exceptions are the ones that worry me). Perhaps Eli can comment on
> this?

TBH, I have no memory of this -- and looking at the code (I'm assuming
it's the `reraise` bit in `wrap-evaluator`??) I'm not sure that I wrote
it.

[...Doing some archaeological digging...]

OK, I think that the following is everything that I can say about it,
and let you judge what would be the best way to re-solve it.  I think
that the main thing that changed that you're talking about is Matthew's
comment that "All the built-in exn structs are fully transparent,
though".  Also, there's the motivation for doing this: "It's important
to keep the same exception, because ...".  (And both of these might be a
justification to make it transparent, or to fix it in a different way
that makes the "because" thing work, and maybe make a note of the lack
of transparency somewhere; I have no significant opinion about it.)

So -- assuming that function is the right place that you're talking
about, I see that this is code that I committed in:

  > commit fd858f081c564a3c94a682aee5896bc535fd9956
  > Author: Eli Barzilay 
  > Date:   2007-01-24 07:52:51 +
  >
  > removed the tweaker hack for a solution that creates a new exception
  >
  > svn: r5446

and it removes a simple hack that uses a `current-error-message-tweaker`
("tweaker" is surely mine...) and adds instead the code that assembles a
new exception.

I then did some more digging in my mail, and found this email exchange
between me and Matthew about this:

[Eli]
  > For some corner of the handin server I wanted to capture exceptions,
  > then reraise a modified version of the exception (basically turn any
  > exn to one that has " while evaluating ").
  > It's important to keep the same exception, because some tests rely
  > on it (like catching an `exn:fail:contract:variable?' when testing
  > for a bound identifier).
  >
  > Looks like `copy-struct' is not enough, because it wants a struct-id.
  > Is there some easy way to do that?  (I know that it's possible,
  > because I did similar stuff in reflecting mzscheme structs as swindle
  > classes, but I'm looking for a simple solution.)

[Matthew]
  > If you have a sufficiently powerful inspector, then `struct-info'
  > and `struct-type-info' let you do what you want, and that's the only
  > possibility that I see.

[Eli]
  > Does the code below look reasonable?  -- I'm using struct-info just
  > to make sure that struct->vector does return all the field values.
  > (I think that this code will break with auto fields, but it should
  > be fine with the exn hierarchy.)
  >
  >   (define ((make-chatty-eval eval) expr)
  > (define (reraise exn)
  >   (raise
  >(let-values ([(struct-type skipped?) (struct-info exn)])
  >  (if (and struct-type (not skipped?))
  >(let ([vals (vector->list (struct->vector exn))])
  >  (apply (struct-type-make-constructor struct-type)
  > (string->immutable-string
  >  (format "while evaluating ~s:\n  ~a" expr (cadr vals)))
  > (cddr vals)))
  >e
  > (with-handlers ([exn? reraise]) (eval expr)))

[Matthew]
  > Looks fine to me.
  >
  > I don't think the use of `struct-type' ensures that `struct->vector'
  > returns all the fields. The immediate struct could be transparentand
  > the next one opaque. All the built-in exn structs are fully
  > transparent, though.

[Eli]
  > OK -- so I thought that a proper solution would be to check the
  > chain up the all the way (and just mention that in a comment in case
  > someone uses this code), but then I realized that there is a much
  > simpler way: simply define a local unique value, hand that as the
  > second argument to struct->vector, and make sure that the unique
  > value is not a memq of the result.

-- 
((x=>x(x))(x=>x(x)))   Eli Barzilay:
http://barzilay.org/   Maze is Life!

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails 

Re: [racket-users] opinion needed on best fix for handin-server problem

[Sam Tobin-Hochstadt]

On Wed, May 4, 2016 at 1:14 PM, 'John Clements' via Racket Users
 wrote:
>
>> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt  wrote:
>>
>> That seems fine, but the general approach the handin-server is taking seems 
>> wrong to me. If it wants an exception with a different message, it should 
>> just create that, rather than assuming that all exception structures are 
>> reasonable to modify.
>
> Well, I can certainly do both.
>
> In general, perhaps the right solution for the handin server would be to 
> deliver an exn:fail:handin-server with an additional field containing the 
> original exception. That way, no information is lost.
>
> The danger, of course, is that this might break code that depends on the 
> exception satisfying some predicate (the filesystem and network exceptions 
> are the ones that worry me). Perhaps Eli can comment on this?

Right, something like that was my thought. Who ends up consuming these
exceptions, other than the printer?

Sam

>
> John
>
>>
>> Sam
>>
>> On Wed, May 4, 2016, 12:52 PM 'John Clements' via Racket Users 
>>  wrote:
>> Bump.
>>
>> Okay if I make a pull request to make ‘match’ exceptions transparent? I see 
>> that all of the ones listed in 10.2.5 are transparent.
>>
>> John
>>
>> > On Apr 27, 2016, at 3:08 PM, John Clements  
>> > wrote:
>> >
>> >
>> >> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt  
>> >> wrote:
>> >>
>> >> The exceptions raised by `match` are indeed not transparent. But I
>> >> don't understand why they need to be in order for the handin server to
>> >> handle them properly.
>> >
>> > (caveat: this is my reading of the code below)
>> >
>> > The handin server wants to add information to the exn-message part, in 
>> > order to indicate what handin test triggered the error.
>> >
>> > Doing this involves converting the exception to a vector, adding text to 
>> > the message part, and then reassembling and re-raising the error. The code 
>> > below therefore bails out when either “skipped?” turns out to be true or 
>> > when one or when struct->vector produces a vector with opaque fields.
>> >
>> > This doesn’t appear to be a problem for any of the other exceptions that 
>> > the handin server encounters (well, this is the first time I’ve seen this 
>> > problem, anyhow).
>> >
>> > I can hack the handin server to treat match exceptions specially, but that 
>> > definitely doesn’t seem like the right solution.
>> >
>> > John
>> >
>> >
>> >
>> >
>> > (define ((wrap-evaluator eval) expr)
>> >  (define unknown "unknown")
>> >  (define (reraise exn)
>> >(raise
>> > (let-values ([(struct-type skipped?) (struct-info exn)])
>> >   (if (and struct-type (not skipped?))
>> > (let ([vals (cdr (vector->list (struct->vector exn unknown)))])
>> >   (if (memq unknown vals)
>> > exn
>> > (apply (struct-type-make-constructor struct-type)
>> >(format "while evaluating ~s:\n  ~a" expr (car vals))
>> >(cdr vals
>> > exn
>> >  (with-handlers ([exn? reraise]) (eval expr)))
>> >
>> >>
>> >> Sam
>> >>
>> >> On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
>> >>  wrote:
>> >>>
>>  On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users 
>>   wrote:
>> 
>>  Currently, the handin-server runs student expressions in an ‘eval’ 
>>  which intercepts errors and re-raises them with a message that includes 
>>  the failing expression. All good.
>> 
>>  However, it doesn’t catch all of them. Specifically, if the exception 
>>  contains any values that are opaque to struct->vector, it gives up and 
>>  re-raises the exception as-is.
>> 
>>  This turns out to cause a problem with “match” failures, which include 
>>  such values. This causes a problem for my students, because they’re 
>>  unable to see the text of the test cases that they failed.
>> 
>>  It’s easy enough to hack around this in my code by re-wording ‘match’ 
>>  failures in the same way that wrap-evaluator does. In general, though, 
>>  it seems like there’s no good reason that ‘match’ failures shouldn’t go 
>>  into the same bin as division by zero, applying a non-function, and all 
>>  of the other things that can go wrong during evaluation.
>> 
>>  In order to fix this, then, I’m trying to determine why this check 
>>  exists: what exceptions do you *not* want to re-word here?
>> >>>
>> >>> Okay, answering my own question and asking another:
>> >>>
>> >>> The fundamental reason for the existence of this logic is that the 
>> >>> handin-engine is trying to be careful, and modify exceptions that can 
>> >>> safely be reconstructed. If the “skipped” value is #t, or if one or more 
>> >>> of the values in 

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt  wrote:
> 
> That seems fine, but the general approach the handin-server is taking seems 
> wrong to me. If it wants an exception with a different message, it should 
> just create that, rather than assuming that all exception structures are 
> reasonable to modify.

Well, I can certainly do both. 

In general, perhaps the right solution for the handin server would be to 
deliver an exn:fail:handin-server with an additional field containing the 
original exception. That way, no information is lost.

The danger, of course, is that this might break code that depends on the 
exception satisfying some predicate (the filesystem and network exceptions are 
the ones that worry me). Perhaps Eli can comment on this?

John

> 
> Sam
> 
> On Wed, May 4, 2016, 12:52 PM 'John Clements' via Racket Users 
>  wrote:
> Bump.
> 
> Okay if I make a pull request to make ‘match’ exceptions transparent? I see 
> that all of the ones listed in 10.2.5 are transparent.
> 
> John
> 
> > On Apr 27, 2016, at 3:08 PM, John Clements  
> > wrote:
> >
> >
> >> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt  
> >> wrote:
> >>
> >> The exceptions raised by `match` are indeed not transparent. But I
> >> don't understand why they need to be in order for the handin server to
> >> handle them properly.
> >
> > (caveat: this is my reading of the code below)
> >
> > The handin server wants to add information to the exn-message part, in 
> > order to indicate what handin test triggered the error.
> >
> > Doing this involves converting the exception to a vector, adding text to 
> > the message part, and then reassembling and re-raising the error. The code 
> > below therefore bails out when either “skipped?” turns out to be true or 
> > when one or when struct->vector produces a vector with opaque fields.
> >
> > This doesn’t appear to be a problem for any of the other exceptions that 
> > the handin server encounters (well, this is the first time I’ve seen this 
> > problem, anyhow).
> >
> > I can hack the handin server to treat match exceptions specially, but that 
> > definitely doesn’t seem like the right solution.
> >
> > John
> >
> >
> >
> >
> > (define ((wrap-evaluator eval) expr)
> >  (define unknown "unknown")
> >  (define (reraise exn)
> >(raise
> > (let-values ([(struct-type skipped?) (struct-info exn)])
> >   (if (and struct-type (not skipped?))
> > (let ([vals (cdr (vector->list (struct->vector exn unknown)))])
> >   (if (memq unknown vals)
> > exn
> > (apply (struct-type-make-constructor struct-type)
> >(format "while evaluating ~s:\n  ~a" expr (car vals))
> >(cdr vals
> > exn
> >  (with-handlers ([exn? reraise]) (eval expr)))
> >
> >>
> >> Sam
> >>
> >> On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
> >>  wrote:
> >>>
>  On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users 
>   wrote:
> 
>  Currently, the handin-server runs student expressions in an ‘eval’ which 
>  intercepts errors and re-raises them with a message that includes the 
>  failing expression. All good.
> 
>  However, it doesn’t catch all of them. Specifically, if the exception 
>  contains any values that are opaque to struct->vector, it gives up and 
>  re-raises the exception as-is.
> 
>  This turns out to cause a problem with “match” failures, which include 
>  such values. This causes a problem for my students, because they’re 
>  unable to see the text of the test cases that they failed.
> 
>  It’s easy enough to hack around this in my code by re-wording ‘match’ 
>  failures in the same way that wrap-evaluator does. In general, though, 
>  it seems like there’s no good reason that ‘match’ failures shouldn’t go 
>  into the same bin as division by zero, applying a non-function, and all 
>  of the other things that can go wrong during evaluation.
> 
>  In order to fix this, then, I’m trying to determine why this check 
>  exists: what exceptions do you *not* want to re-word here?
> >>>
> >>> Okay, answering my own question and asking another:
> >>>
> >>> The fundamental reason for the existence of this logic is that the 
> >>> handin-engine is trying to be careful, and modify exceptions that can 
> >>> safely be reconstructed. If the “skipped” value is #t, or if one or more 
> >>> of the values in the structure are opaque, this is impossible. At this 
> >>> point, the handin engine just throws up its hands and decides to follow 
> >>> the hippocratic oath, “first do no harm,” and let the exception continue 
> >>> as is.
> >>>
> >>> So, this leads to a different question: *why* is the match exception 
> >>> different from all 

Re: [racket-users] opinion needed on best fix for handin-server problem

[Sam Tobin-Hochstadt]

That seems fine, but the general approach the handin-server is taking seems
wrong to me. If it wants an exception with a different message, it should
just create that, rather than assuming that all exception structures are
reasonable to modify.

Sam

On Wed, May 4, 2016, 12:52 PM 'John Clements' via Racket Users <
racket-users@googlegroups.com> wrote:

> Bump.
>
> Okay if I make a pull request to make ‘match’ exceptions transparent? I
> see that all of the ones listed in 10.2.5 are transparent.
>
> John
>
> > On Apr 27, 2016, at 3:08 PM, John Clements 
> wrote:
> >
> >
> >> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt 
> wrote:
> >>
> >> The exceptions raised by `match` are indeed not transparent. But I
> >> don't understand why they need to be in order for the handin server to
> >> handle them properly.
> >
> > (caveat: this is my reading of the code below)
> >
> > The handin server wants to add information to the exn-message part, in
> order to indicate what handin test triggered the error.
> >
> > Doing this involves converting the exception to a vector, adding text to
> the message part, and then reassembling and re-raising the error. The code
> below therefore bails out when either “skipped?” turns out to be true or
> when one or when struct->vector produces a vector with opaque fields.
> >
> > This doesn’t appear to be a problem for any of the other exceptions that
> the handin server encounters (well, this is the first time I’ve seen this
> problem, anyhow).
> >
> > I can hack the handin server to treat match exceptions specially, but
> that definitely doesn’t seem like the right solution.
> >
> > John
> >
> >
> >
> >
> > (define ((wrap-evaluator eval) expr)
> >  (define unknown "unknown")
> >  (define (reraise exn)
> >(raise
> > (let-values ([(struct-type skipped?) (struct-info exn)])
> >   (if (and struct-type (not skipped?))
> > (let ([vals (cdr (vector->list (struct->vector exn unknown)))])
> >   (if (memq unknown vals)
> > exn
> > (apply (struct-type-make-constructor struct-type)
> >(format "while evaluating ~s:\n  ~a" expr (car vals))
> >(cdr vals
> > exn
> >  (with-handlers ([exn? reraise]) (eval expr)))
> >
> >>
> >> Sam
> >>
> >> On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
> >>  wrote:
> >>>
>  On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users <
> racket-users@googlegroups.com> wrote:
> 
>  Currently, the handin-server runs student expressions in an ‘eval’
> which intercepts errors and re-raises them with a message that includes the
> failing expression. All good.
> 
>  However, it doesn’t catch all of them. Specifically, if the exception
> contains any values that are opaque to struct->vector, it gives up and
> re-raises the exception as-is.
> 
>  This turns out to cause a problem with “match” failures, which
> include such values. This causes a problem for my students, because they’re
> unable to see the text of the test cases that they failed.
> 
>  It’s easy enough to hack around this in my code by re-wording ‘match’
> failures in the same way that wrap-evaluator does. In general, though, it
> seems like there’s no good reason that ‘match’ failures shouldn’t go into
> the same bin as division by zero, applying a non-function, and all of the
> other things that can go wrong during evaluation.
> 
>  In order to fix this, then, I’m trying to determine why this check
> exists: what exceptions do you *not* want to re-word here?
> >>>
> >>> Okay, answering my own question and asking another:
> >>>
> >>> The fundamental reason for the existence of this logic is that the
> handin-engine is trying to be careful, and modify exceptions that can
> safely be reconstructed. If the “skipped” value is #t, or if one or more of
> the values in the structure are opaque, this is impossible. At this point,
> the handin engine just throws up its hands and decides to follow the
> hippocratic oath, “first do no harm,” and let the exception continue as is.
> >>>
> >>> So, this leads to a different question: *why* is the match exception
> different from all the other exceptions? Based on my reading of the
> struct-info documentation, it appears that the ‘match’ form constructs
> exceptions whose inspector is not the current one, or perhaps that it fails
> to declare itself as transparent.
> >>>
> >>> My guess is that this is just an oversight, and that a ‘match’
> exception should be just as transparent as, say, a division by zero
> exception. Here’s code that illustrates the difference:
> >>>
> >>> #lang racket
> >>>
> >>> (with-handlers ([exn:fail?
> >>>(λ (exn)
> >>>  (struct-info exn))])
> >>> (/ 1 0))
> >>>
> >>> (with-handlers ([exn:fail?
> >>>(λ (exn)
> >>>  (struct-info 

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

Bump. 

Okay if I make a pull request to make ‘match’ exceptions transparent? I see 
that all of the ones listed in 10.2.5 are transparent.

John

> On Apr 27, 2016, at 3:08 PM, John Clements  wrote:
> 
> 
>> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt  
>> wrote:
>> 
>> The exceptions raised by `match` are indeed not transparent. But I
>> don't understand why they need to be in order for the handin server to
>> handle them properly.
> 
> (caveat: this is my reading of the code below)
> 
> The handin server wants to add information to the exn-message part, in order 
> to indicate what handin test triggered the error.
> 
> Doing this involves converting the exception to a vector, adding text to the 
> message part, and then reassembling and re-raising the error. The code below 
> therefore bails out when either “skipped?” turns out to be true or when one 
> or when struct->vector produces a vector with opaque fields.
> 
> This doesn’t appear to be a problem for any of the other exceptions that the 
> handin server encounters (well, this is the first time I’ve seen this 
> problem, anyhow).
> 
> I can hack the handin server to treat match exceptions specially, but that 
> definitely doesn’t seem like the right solution.
> 
> John
> 
> 
> 
> 
> (define ((wrap-evaluator eval) expr)
>  (define unknown "unknown")
>  (define (reraise exn)
>(raise
> (let-values ([(struct-type skipped?) (struct-info exn)])
>   (if (and struct-type (not skipped?))
> (let ([vals (cdr (vector->list (struct->vector exn unknown)))])
>   (if (memq unknown vals)
> exn
> (apply (struct-type-make-constructor struct-type)
>(format "while evaluating ~s:\n  ~a" expr (car vals))
>(cdr vals
> exn
>  (with-handlers ([exn? reraise]) (eval expr)))
> 
>> 
>> Sam
>> 
>> On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
>>  wrote:
>>> 
 On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users 
  wrote:
 
 Currently, the handin-server runs student expressions in an ‘eval’ which 
 intercepts errors and re-raises them with a message that includes the 
 failing expression. All good.
 
 However, it doesn’t catch all of them. Specifically, if the exception 
 contains any values that are opaque to struct->vector, it gives up and 
 re-raises the exception as-is.
 
 This turns out to cause a problem with “match” failures, which include 
 such values. This causes a problem for my students, because they’re unable 
 to see the text of the test cases that they failed.
 
 It’s easy enough to hack around this in my code by re-wording ‘match’ 
 failures in the same way that wrap-evaluator does. In general, though, it 
 seems like there’s no good reason that ‘match’ failures shouldn’t go into 
 the same bin as division by zero, applying a non-function, and all of the 
 other things that can go wrong during evaluation.
 
 In order to fix this, then, I’m trying to determine why this check exists: 
 what exceptions do you *not* want to re-word here?
>>> 
>>> Okay, answering my own question and asking another:
>>> 
>>> The fundamental reason for the existence of this logic is that the 
>>> handin-engine is trying to be careful, and modify exceptions that can 
>>> safely be reconstructed. If the “skipped” value is #t, or if one or more of 
>>> the values in the structure are opaque, this is impossible. At this point, 
>>> the handin engine just throws up its hands and decides to follow the 
>>> hippocratic oath, “first do no harm,” and let the exception continue as is.
>>> 
>>> So, this leads to a different question: *why* is the match exception 
>>> different from all the other exceptions? Based on my reading of the 
>>> struct-info documentation, it appears that the ‘match’ form constructs 
>>> exceptions whose inspector is not the current one, or perhaps that it fails 
>>> to declare itself as transparent.
>>> 
>>> My guess is that this is just an oversight, and that a ‘match’ exception 
>>> should be just as transparent as, say, a division by zero exception. Here’s 
>>> code that illustrates the difference:
>>> 
>>> #lang racket
>>> 
>>> (with-handlers ([exn:fail?
>>>(λ (exn)
>>>  (struct-info exn))])
>>> (/ 1 0))
>>> 
>>> (with-handlers ([exn:fail?
>>>(λ (exn)
>>>  (struct-info exn))])
>>> (match 13
>>>   ['a 4]))
>>> 
>>> So, here’s my question:
>>> 
>>> Is there a good reason for the difference between the `match` exception 
>>> (skipped is #t) and the division-by-zero exception (skipped is #f) ?
>>> 
>>> John
>>> 
>>> 
>>> 
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this 

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt  wrote:
> 
> The exceptions raised by `match` are indeed not transparent. But I
> don't understand why they need to be in order for the handin server to
> handle them properly.

(caveat: this is my reading of the code below)

The handin server wants to add information to the exn-message part, in order to 
indicate what handin test triggered the error.

Doing this involves converting the exception to a vector, adding text to the 
message part, and then reassembling and re-raising the error. The code below 
therefore bails out when either “skipped?” turns out to be true or when one or 
when struct->vector produces a vector with opaque fields.

This doesn’t appear to be a problem for any of the other exceptions that the 
handin server encounters (well, this is the first time I’ve seen this problem, 
anyhow).

I can hack the handin server to treat match exceptions specially, but that 
definitely doesn’t seem like the right solution.

John




(define ((wrap-evaluator eval) expr)
  (define unknown "unknown")
  (define (reraise exn)
(raise
 (let-values ([(struct-type skipped?) (struct-info exn)])
   (if (and struct-type (not skipped?))
 (let ([vals (cdr (vector->list (struct->vector exn unknown)))])
   (if (memq unknown vals)
 exn
 (apply (struct-type-make-constructor struct-type)
(format "while evaluating ~s:\n  ~a" expr (car vals))
(cdr vals
 exn
  (with-handlers ([exn? reraise]) (eval expr)))

> 
> Sam
> 
> On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
>  wrote:
>> 
>>> On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users 
>>>  wrote:
>>> 
>>> Currently, the handin-server runs student expressions in an ‘eval’ which 
>>> intercepts errors and re-raises them with a message that includes the 
>>> failing expression. All good.
>>> 
>>> However, it doesn’t catch all of them. Specifically, if the exception 
>>> contains any values that are opaque to struct->vector, it gives up and 
>>> re-raises the exception as-is.
>>> 
>>> This turns out to cause a problem with “match” failures, which include such 
>>> values. This causes a problem for my students, because they’re unable to 
>>> see the text of the test cases that they failed.
>>> 
>>> It’s easy enough to hack around this in my code by re-wording ‘match’ 
>>> failures in the same way that wrap-evaluator does. In general, though, it 
>>> seems like there’s no good reason that ‘match’ failures shouldn’t go into 
>>> the same bin as division by zero, applying a non-function, and all of the 
>>> other things that can go wrong during evaluation.
>>> 
>>> In order to fix this, then, I’m trying to determine why this check exists: 
>>> what exceptions do you *not* want to re-word here?
>> 
>> Okay, answering my own question and asking another:
>> 
>> The fundamental reason for the existence of this logic is that the 
>> handin-engine is trying to be careful, and modify exceptions that can safely 
>> be reconstructed. If the “skipped” value is #t, or if one or more of the 
>> values in the structure are opaque, this is impossible. At this point, the 
>> handin engine just throws up its hands and decides to follow the hippocratic 
>> oath, “first do no harm,” and let the exception continue as is.
>> 
>> So, this leads to a different question: *why* is the match exception 
>> different from all the other exceptions? Based on my reading of the 
>> struct-info documentation, it appears that the ‘match’ form constructs 
>> exceptions whose inspector is not the current one, or perhaps that it fails 
>> to declare itself as transparent.
>> 
>> My guess is that this is just an oversight, and that a ‘match’ exception 
>> should be just as transparent as, say, a division by zero exception. Here’s 
>> code that illustrates the difference:
>> 
>> #lang racket
>> 
>> (with-handlers ([exn:fail?
>> (λ (exn)
>>   (struct-info exn))])
>>  (/ 1 0))
>> 
>> (with-handlers ([exn:fail?
>> (λ (exn)
>>   (struct-info exn))])
>>  (match 13
>>['a 4]))
>> 
>> So, here’s my question:
>> 
>> Is there a good reason for the difference between the `match` exception 
>> (skipped is #t) and the division-by-zero exception (skipped is #f) ?
>> 
>> John
>> 
>> 
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [racket-users] opinion needed on best fix for handin-server problem

[Sam Tobin-Hochstadt]

The exceptions raised by `match` are indeed not transparent. But I
don't understand why they need to be in order for the handin server to
handle them properly.

Sam

On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
 wrote:
>
>> On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users 
>>  wrote:
>>
>> Currently, the handin-server runs student expressions in an ‘eval’ which 
>> intercepts errors and re-raises them with a message that includes the 
>> failing expression. All good.
>>
>> However, it doesn’t catch all of them. Specifically, if the exception 
>> contains any values that are opaque to struct->vector, it gives up and 
>> re-raises the exception as-is.
>>
>> This turns out to cause a problem with “match” failures, which include such 
>> values. This causes a problem for my students, because they’re unable to see 
>> the text of the test cases that they failed.
>>
>> It’s easy enough to hack around this in my code by re-wording ‘match’ 
>> failures in the same way that wrap-evaluator does. In general, though, it 
>> seems like there’s no good reason that ‘match’ failures shouldn’t go into 
>> the same bin as division by zero, applying a non-function, and all of the 
>> other things that can go wrong during evaluation.
>>
>> In order to fix this, then, I’m trying to determine why this check exists: 
>> what exceptions do you *not* want to re-word here?
>
> Okay, answering my own question and asking another:
>
> The fundamental reason for the existence of this logic is that the 
> handin-engine is trying to be careful, and modify exceptions that can safely 
> be reconstructed. If the “skipped” value is #t, or if one or more of the 
> values in the structure are opaque, this is impossible. At this point, the 
> handin engine just throws up its hands and decides to follow the hippocratic 
> oath, “first do no harm,” and let the exception continue as is.
>
> So, this leads to a different question: *why* is the match exception 
> different from all the other exceptions? Based on my reading of the 
> struct-info documentation, it appears that the ‘match’ form constructs 
> exceptions whose inspector is not the current one, or perhaps that it fails 
> to declare itself as transparent.
>
> My guess is that this is just an oversight, and that a ‘match’ exception 
> should be just as transparent as, say, a division by zero exception. Here’s 
> code that illustrates the difference:
>
> #lang racket
>
> (with-handlers ([exn:fail?
>  (λ (exn)
>(struct-info exn))])
>   (/ 1 0))
>
> (with-handlers ([exn:fail?
>  (λ (exn)
>(struct-info exn))])
>   (match 13
> ['a 4]))
>
> So, here’s my question:
>
> Is there a good reason for the difference between the `match` exception 
> (skipped is #t) and the division-by-zero exception (skipped is #f) ?
>
> John
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

> On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users 
>  wrote:
> 
> Currently, the handin-server runs student expressions in an ‘eval’ which 
> intercepts errors and re-raises them with a message that includes the failing 
> expression. All good.
> 
> However, it doesn’t catch all of them. Specifically, if the exception 
> contains any values that are opaque to struct->vector, it gives up and 
> re-raises the exception as-is.
> 
> This turns out to cause a problem with “match” failures, which include such 
> values. This causes a problem for my students, because they’re unable to see 
> the text of the test cases that they failed.
> 
> It’s easy enough to hack around this in my code by re-wording ‘match’ 
> failures in the same way that wrap-evaluator does. In general, though, it 
> seems like there’s no good reason that ‘match’ failures shouldn’t go into the 
> same bin as division by zero, applying a non-function, and all of the other 
> things that can go wrong during evaluation.
> 
> In order to fix this, then, I’m trying to determine why this check exists: 
> what exceptions do you *not* want to re-word here? 

Okay, answering my own question and asking another:

The fundamental reason for the existence of this logic is that the 
handin-engine is trying to be careful, and modify exceptions that can safely be 
reconstructed. If the “skipped” value is #t, or if one or more of the values in 
the structure are opaque, this is impossible. At this point, the handin engine 
just throws up its hands and decides to follow the hippocratic oath, “first do 
no harm,” and let the exception continue as is.

So, this leads to a different question: *why* is the match exception different 
from all the other exceptions? Based on my reading of the struct-info 
documentation, it appears that the ‘match’ form constructs exceptions whose 
inspector is not the current one, or perhaps that it fails to declare itself as 
transparent.

My guess is that this is just an oversight, and that a ‘match’ exception should 
be just as transparent as, say, a division by zero exception. Here’s code that 
illustrates the difference:

#lang racket

(with-handlers ([exn:fail?
 (λ (exn)
   (struct-info exn))])
  (/ 1 0))

(with-handlers ([exn:fail?
 (λ (exn)
   (struct-info exn))])
  (match 13
['a 4]))

So, here’s my question:

Is there a good reason for the difference between the `match` exception 
(skipped is #t) and the division-by-zero exception (skipped is #f) ?

John 




-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] opinion needed on best fix for handin-server problem

['John Clements' via Racket Users]

Currently, the handin-server runs student expressions in an ‘eval’ which 
intercepts errors and re-raises them with a message that includes the failing 
expression. All good.

However, it doesn’t catch all of them. Specifically, if the exception contains 
any values that are opaque to struct->vector, it gives up and re-raises the 
exception as-is.

This turns out to cause a problem with “match” failures, which include such 
values. This causes a problem for my students, because they’re unable to see 
the text of the test cases that they failed.

It’s easy enough to hack around this in my code by re-wording ‘match’ failures 
in the same way that wrap-evaluator does. In general, though, it seems like 
there’s no good reason that ‘match’ failures shouldn’t go into the same bin as 
division by zero, applying a non-function, and all of the other things that can 
go wrong during evaluation.

In order to fix this, then, I’m trying to determine why this check exists: what 
exceptions do you *not* want to re-word here? 

John

(define ((wrap-evaluator eval) expr)
  (define unknown "unknown")
  (define (reraise exn)
(raise
 (let-values ([(struct-type skipped?) (struct-info exn)])
   (if (and struct-type (not skipped?))
 (let ([vals (cdr (vector->list (struct->vector exn unknown)))])
   (if (memq unknown vals)
 exn
 (apply (struct-type-make-constructor struct-type)
(format "while evaluating ~s:\n  ~a" expr (car vals))
(cdr vals
 exn
  (with-handlers ([exn? reraise]) (eval expr)))

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.