On Mon, Apr 9, 2018 at 5:08 PM, Philip McGrath <phi...@philipmcgrath.com> wrote: > Thanks for your helpful reply. I've created GitHub issues > https://github.com/racket/typed-racket/issues/691 and > https://github.com/racket/typed-racket/issues/692 to track the bugs, and I > will try my hand at a pull request for `parse-command-line` if I have time > before you do.
Great, thanks! > On Fri, Apr 6, 2018 at 10:12 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> > wrote: >> >> This is in some ways a weakness in the concept for `#:type-name`. The >> `struct` form relies on the parent struct to both find the type and to >> find the parent struct in the underlying `struct` macro. We could add >> a `#:parent-type-name` option to use here, but then we'd have to >> enforce that they go together in some way. I'm not sure what the best >> design is here. > > > This explanation makes sense—should something about this limitation be added > to the reference? Yes, it should -- or maybe `#:type-name` should behave like one of my workarounds. >> >> To work around this, try: >> >> #lang typed/racket >> (struct animal () #:transparent) >> (struct dog animal () #:transparent) >> (define-type Animal animal) > > > This seems like a very good work-around. Other than the fact that using > `#:type-name` would mean that `animal` could not be used as a type, is there > any difference between the result of this and what `#:type-name` does? That's the difference. > >> >> > 3. parse-command-line doesn't support usage-help, help-labels, >> > help-proc, or >> > unknown-proc > > > A part of this that particularly surprised me was that the built-in type > didn't work with `require/typed` because Typed Racket couldn't generate a > contract for it. Is the generation of contracts for built-in types handled > differently than for programmer-specified types? Yes, it's quite different -- Typed Racket doesn't actually generate a contract for `parse-command-line` (or for other built-in functions like `+` or `list`). > More broadly, I don't feel like I have very strong intuitions about what > types Typed Racket can and can't generate contracts for. I believe the Typed > Racket team is working to be able to generate contracts for more and more > types, so maybe you are avoiding specifics in the documentation for that > reason, but I think it would be valuable to have some more detail about what > is currently possible. Yes, I think more documentation on this would be an improvement. This section has a bit of that http://docs.racket-lang.org/ts-guide/caveats.html but we should add more. The part that doesn't work is the type for `finish-proc`, which uses `...` in the type in a way that Typed Racket can't automatically generate a contract for. Sam -- 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.google.com/d/optout.
