Hello Racketeers,
I have been trying to port a module over to Typed Racket, and I have almost
succeeded except for one issue: raising an arbitrary object as an error.
Compare the following code:
;; Works fine
(raise 3)
;; Does not work
(raise (vector 1 2 3))
The error I get is
The error is because type signature of `raise` doesn't allow
"non-flat" values like functions and mutable vectors.
It might not be safe to allow `(raise (vector 1 2 3))` in Typed Racket
... I'm not sure.
For now I think you should make a new exception type. Example:
```
#lang typed/racket/base
Thank you, I have made my own exception type now. Is `exn:fail:rpc`
appropriate or should I use a different name? Using that name looks like
I'm inserting it into Racket's own exception type hierarchy.
On Friday, December 1, 2017 at 8:11:27 PM UTC+1, Ben Greenman wrote:
>
> ...
>
--
You receiv
That name sounds good to me.
--
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.go
Two notes:
1. It is unsafe to expose mutable data to untyped code via exceptions
without wrapping them. If you `(raise f)`, then untyped code could
catch the exception and call `f`.
2. You should inherit from `exn:fail` -- other `exn` types are for
non-standard exceptions such as `exn:break`.
Sa
Why not use any-wrap/c?
Robby
On Fri, Dec 1, 2017 at 8:39 PM Sam Tobin-Hochstadt
wrote:
> Two notes:
>
> 1. It is unsafe to expose mutable data to untyped code via exceptions
> without wrapping them. If you `(raise f)`, then untyped code could
> catch the exception and call `f`.
>
> 2. You shou
I recently encountered a case where a contract that (as far as I can tell)
cannot be written using ->i can be easily expressed using ->d. This
surprised me, since I thought that ->i was strictly better than ->d (given
that the docs for ->d say, "This contract is here for backwards
compatibility; an
Let me make sure I understand:
1. A converter is like a two-way function, lets say (A . <-> . B)
2. If someone composes two incompatible converters, like (integer? .
<-> . symbol?) and (string? . <-> . boolean?) then they should get an
error that points to the place where they tried to do the comp
On Fri, Dec 1, 2017 at 10:08 PM, Ben Greenman
wrote:
> Let me make sure I understand:
>
> 1. A converter is like a two-way function, lets say (A . <-> . B)
> 2. If someone composes two incompatible converters, like (integer? .
> <-> . symbol?) and (string? . <-> . boolean?) then they should get a
9 matches
Mail list logo