Re: [racket-users] Advantage of ->d over ->i

2017-12-01 Thread Philip McGrath
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? . <-> .

Re: [racket-users] Advantage of ->d over ->i

2017-12-01 Thread Ben Greenman
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

[racket-users] Advantage of ->d over ->i

2017-12-01 Thread Philip McGrath
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;

Re: [racket-users] Raising arbitrary errors in Typed Racket

2017-12-01 Thread Robby Findler
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

Re: [racket-users] Raising arbitrary errors in Typed Racket

2017-12-01 Thread Sam Tobin-Hochstadt
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`.

Re: [racket-users] Raising arbitrary errors in Typed Racket

2017-12-01 Thread Ben Greenman
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

Re: [racket-users] Raising arbitrary errors in Typed Racket

2017-12-01 Thread HiPhish
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

Re: [racket-users] Raising arbitrary errors in Typed Racket

2017-12-01 Thread Ben Greenman
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

[racket-users] Raising arbitrary errors in Typed Racket

2017-12-01 Thread HiPhish
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