If it is only for type coverage, theb why not name it as such? There
will probably be other kinds of errors in the future.
On 2011-10-25, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 23, 2011 at 1:39 PM, Sam Tobin-Hochstadt
> wrote:
>>
>> Yes, I have planned to do this for a while. Probably the fo
Wonderful!!!
Thanks Sam,
-- Éric
On Oct 25, 2011, at 5:17 PM, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 23, 2011 at 1:39 PM, Sam Tobin-Hochstadt
> wrote:
>>
>> Yes, I have planned to do this for a while. Probably the form it will
>> take will be a macro that always produces a type error whe
On Sun, Oct 23, 2011 at 1:39 PM, Sam Tobin-Hochstadt wrote:
>
> Yes, I have planned to do this for a while. Probably the form it will
> take will be a macro that always produces a type error when checked,
> rather than a new type. Then macros could use this form to ensure
> exhaustiveness.
This
On Oct 23, 2011, at 5:39 PM, Sam Tobin-Hochstadt wrote:
> Yes, I have planned to do this for a while. Probably the form it will
> take will be a macro that always produces a type error when checked,
> rather than a new type. Then macros could use this form to ensure
> exhaustiveness.
Great! Look
On Sun, Oct 23, 2011 at 11:03 AM, Eric Tanter wrote:
> So this seems the good way to go.
>
> However, of course, this does not work if the return type is compatible with
> Void:
>
> (: f ((U String Integer) -> Any))
> (define (f x)
> (cond
> [(string? x) (string=? x "hi")]
> [(exact-nonneg
On Oct 23, 2011, at 12:39 PM, Vincent St-Amour wrote:
> Using `Any' as a return type is something I only do as a quick and
> dirty solution. I assume that if you care enough to want case
> exhaustiveness checking, you probably care enough to nail down your
> return types precisely.
Ok for Any. But
At Sun, 23 Oct 2011 12:03:23 -0300,
Eric Tanter wrote:
> However, of course, this does not work if the return type is compatible with
> Void:
>
> (: f ((U String Integer) -> Any))
> (define (f x)
> (cond
> [(string? x) (string=? x "hi")]
> [(exact-nonnegative-integer? x) (= x 7)]))
>
>
Tobin-Hochstadt
>> To: Eric Tanter
>> Cc: Racket Users
>> Sent: Thu, 20 Oct 2011 14:39:19 -0400 (EDT)
>> Subject: Re: [racket] [typed racket] type case
>>
>> There are basically two options here:
>>
>> 1. If you just use `cond' with no `else'
Thanks Sam, that clears things up!
-- Éric
On Oct 22, 2011, at 6:25 PM, Sam Tobin-Hochstadt wrote:
> On Sat, Oct 22, 2011 at 2:20 PM, Eric Tanter wrote:
>> On Oct 21, 2011, at 1:55 PM, Sam Tobin-Hochstadt wrote:
>>> On Fri, Oct 21, 2011 at 12:44 PM, Eric Tanter wrote:
In that sense, un
On Sat, Oct 22, 2011 at 2:20 PM, Eric Tanter wrote:
> On Oct 21, 2011, at 1:55 PM, Sam Tobin-Hochstadt wrote:
>> On Fri, Oct 21, 2011 at 12:44 PM, Eric Tanter wrote:
>>> In that sense, union types are a particularly good example. They are
>>> necessary to support the kind of patterns found in pr
On Oct 21, 2011, at 1:55 PM, Sam Tobin-Hochstadt wrote:
> On Fri, Oct 21, 2011 at 12:44 PM, Eric Tanter wrote:
>> In that sense, union types are a particularly good example. They are
>> necessary to support the kind of patterns found in previously-untyped code.
>> But if I'm writing typed code,
On Fri, Oct 21, 2011 at 12:44 PM, Eric Tanter wrote:
> To come back on this: I understand that Typed Racket's prime objective is
> that the type system should adapt to existing programming idioms as much as
> possible. But does this prevent new type-related idioms to be used?
>
> In that sense,
To come back on this: I understand that Typed Racket's prime objective is that
the type system should adapt to existing programming idioms as much as
possible. But does this prevent new type-related idioms to be used?
In that sense, union types are a particularly good example. They are necessar
Thanks for the answers.
I am very interested in Eli's extension, because my scenario is basically the
same: I teach PLAI, and I am considering to do it with typed racket.
But, type-case is pervasively used in the book, and students like it ;)
-- Éric
On Oct 20, 2011, at 3:39 PM, Sam Tobin-Ho
;core" Racket, it's
not even clear what exhaustiveness would mean in that case.
> -Ian
> - Original Message -
> From: Sam Tobin-Hochstadt
> To: Eric Tanter
> Cc: Racket Users
> Sent: Thu, 20 Oct 2011 14:39:19 -0400 (EDT)
> Subject: Re: [racket] [typed rac
(EDT)
Subject: Re: [racket] [typed racket] type case
There are basically two options here:
1. If you just use `cond' with no `else', you get a type error when
your cases are not exhaustive. For example:
(: f ((U String Integer) -> Boolean))
(define (f x)
[(string? x) (s
There are basically two options here:
1. If you just use `cond' with no `else', you get a type error when
your cases are not exhaustive. For example:
(: f ((U String Integer) -> Boolean))
(define (f x)
[(string? x) (string=? x "hi")]
[(exact-nonnegative-integer? x) (= x 7)])
This program wil
-
From: Eric Tanter
To: Racket Users
Sent: Thu, 20 Oct 2011 10:48:22 -0400 (EDT)
Subject: [racket] [typed racket] type case
Hi again,
Is there a mechanism to do an exhaustive type case?
I know I can use (cond [(type-pred? v) ...]
[...])
but of course I have no guarantee
Hi again,
Is there a mechanism to do an exhaustive type case?
I know I can use (cond [(type-pred? v) ...]
[...])
but of course I have no guarantee that I am exhaustive (and of course, doing
pattern matching to destruct the value would be even nicer).
Basically, I guess
19 matches
Mail list logo
