Re: cast on mutable hash table...

Yes, I’ll add this. It slightly increases the pain density, especially since I think students likely to mistakenly write

(list (? symbol? #{s : Symbol}) …)

instead of the correct

(list (? symbol? #{s : (Listof Symbol)}) …)

… but it’s probably better than having to cast.

Thanks!

John


> On Feb 15, 2020, at 10:33, Sam Tobin-Hochstadt <[email protected]> wrote:
> 
> You can annotate variables like that in match patterns using #{s : Symbol}, which ought to work in common cases. 
> 
> On Sat, Feb 15, 2020, 1:23 PM 'John Clements' via users-redirect <[email protected]> wrote:
> Yes, absolutely. One reason that students in my class wind up using cast quite frequently in their parsers is that they use patterns like (list (? symbol s) …) which (as I recall) expand into unannotated lambda’s, and always require a cast. I write that up here:
> 
> https://www.brinckerhoff.org/clements/2202-csc430/Assignments/tr-notes.html#%28part._.Predicate_.Patterns_with_.Dot-dot-dot%29
> 
> Beyond that, though, I tell them never to use cast:
> 
> https://www.brinckerhoff.org/clements/2202-csc430/Assignments/tr-notes.html#%28part._.Other_.Casting%29
> 
> The text I came up with for mutable hash tables is here:
> 
> https://www.brinckerhoff.org/clements/2202-csc430/Assignments/tr-notes.html#%28part._.Mutable_.Hash_.Table_.Construction%29
> 
> Many thanks to all of you!
> 
> John
> 
> > On Feb 14, 2020, at 12:32, Sam Tobin-Hochstadt <[email protected]> wrote:
> > 
> > The advice I would really give is to give a name and a type annotation to any mutable data structure you create. 
> > 
> > Also, cast is almost never what you want. I see lots of people (maybe including this student) using it as a substitute for type annotation but it really isn't. 
> > 
> > Sam
> > 
> > On Fri, Feb 14, 2020, 2:41 PM 'John Clements' via users-redirect <[email protected]> wrote:
> > I think I may understand what’s going on here, but a student and I worked on this for quite a while today before I found the problem.
> > 
> > Here’s a program:
> > 
> > #lang typed/racket
> > 
> > (define-type Store (Mutable-HashTable Integer Value))
> > (define-type Value (U Real Boolean String))
> > 
> > (define top-store (cast (make-hash (list
> >                                     (cons -1 14)
> >                                     (cons 1 #t)
> >                                     (cons 2 #f)))
> >                         Store))
> > 
> > (hash-set! top-store 5 1234)
> > 
> > It fails with this error:
> > 
> > contract violation
> >   expected: (or/c (and/c byte? positive?) #t #f)
> >   given: 1234
> >   in: the values of
> >       the 3rd conjunct of
> >       (and/c
> >        hash?
> >        hash-mutable?
> >        (hash/c
> >         exact-integer?
> >         (or/c (and/c byte? positive?) #t #f)
> >         #:immutable
> >         #f))
> >   contract from: typed-world
> >   blaming: cast
> >    (assuming the contract is correct)
> >   at: unsaved-editor:6.18
> > 
> > If I understand what’s going on here, the basic issue is that the mutable hash table’s type is being inferred as (Immutable-HashTable Exact-Integer (U Boolean Positive-Byte)), and then as part of the cast, a contract is being inserted, which checks that all added values match the expected value type. The outer cast allows type checking to proceed, but then at runtime it fails because the given value doesn’t match the inferred value type.
> > 
> > This error doesn’t occur with immutable hash tables, because it’s fine to extend an immutable hash table to a larger one that contains it; the original one’s contract isn’t violated.
> > 
> > In this case, one easy error is to change the ‘cast’ into an ‘ann’, which works fine.
> > 
> > This is the first time I’ve encouraged my students to use a mutable hash, which is presumably why I haven’t encountered this before.
> > 
> > I’m trying to formulate a solution that I can put in a Hints for TR file, and I think the answer is probably this:
> > 
> > - When you use “make-hash” in TR, you should always specify the types explicitly using an “inst”.
> > or maybe
> > - When you call “make-hash” in TR, the call should be immediately wrapped with an “ann” type annotation.
> > 
> > In a perfect world, I think I would ask for a warning when casting a mutable hash table. It could go in that nice “warnings” box. Oh, wait…
> > 
> > … joking aside, actually I just did turn on the “log” window and I don’t see any warning about this, which is not too surprising. Oh, wait, I see another bug…
> > 
> > Thanks for reading, let me know if there’s any more obvious solution.
> > 
> > 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> > To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/f24851ca-32aa-40e1-9db4-691da815ebe7%40mtasv.net.
> 
> 
> 
> -- 
> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/f1cdb734-cb79-4a1a-8bb8-3bf3d4a425b4%40mtasv.net.



-- 
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/4015389e-9b63-4189-88e6-28ee3f188e75%40mtasv.net.