0. #lang typed/racket/base
1.  
2. ;;; Parametric import styles
3.  
4. ;; style 1: separate form
5. ;; *************************************
6. ;; This is sort of nice in the sense that it would likely be extremely easy to
7. ;; implement. It also makes it very clear what's happening. The downside is that
8. ;; introducing an entirely new require form is a real pain from a lot of other
9. ;; perspectives. Do we need require/typed/parametric/provide? That's a mouthful.
10. ;; Plus, it's not composable, so we'd need to port all the changes from
11. ;; require/typed to this form manually.
12.  
13. #;(require/typed/parametric
14.    (A)
15.    [#:opaque (Posn A) posn?]
16.    [make-posn (A A -> (Posn A))]
17.    [posn-x ((Posn A) -> A)]
18.    [posn-y ((Posn A) -> A)])
19.  
20.  
21. ;; style 2: nested clause
22. ;; *************************************
23. ;; This maintains most of the simplicity from the first example while reducing
24. ;; the downsides. This is a good compromise if a nicer style isn't easy to
25. ;; implement.
26.  
27. #;(require/typed
28.    [#:parametric
29.     (A)
30.     [#:opaque (Posn A) posn?]
31.     [make-posn (A A -> (Posn A))]
32.     [posn-x ((Posn A) -> A)]
33.     [posn-y ((Posn A) -> A)]])
34.  
35.  
36. ;; style 3: internal type definition
37. ;; *************************************
38. ;; This is the parametric style provided by contract-out. This is especially
39. ;; nice since it doesn't introduce any addition nesting levels and it's fairly
40. ;; transparent to a user. The only question is how easy it would be to create a
41. ;; local parametric type definition and then use that in the generated
42. ;; contracts. This also maintains consistency with other areas of TR.
43.  
44. #;(require/typed
45.    #:forall [A] ; or #:∀ [A]
46.    [#:opaque (Posn A) posn?]
47.    [make-posn (A A -> (Posn A))]
48.    [posn-x ((Posn A) -> A)]
49.    [posn-y ((Posn A) -> A)])

=>