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.
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? I'm very sure there are lots of considerations in the design of structs for Typed Racket that haven't even crossed my mind, but, from my naïve perspective, it seems like one option would be to have TR's `struct` form include information about the type, in some private-to-TR way, in the compile-time record it binds to the struct name, even if, in the presence of the `#:type-name` option, the struct name can't be used as a type. Then a `struct` form declaring a subtype could find the type information for the parent regardless of whether the parent struct name also serves as the type name for the parent. But I could well imagine that there might be something subtle about either encapsulation or the interaction of the type layer with the underlying struct form that would make this not work. > 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? > > 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? 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. I unfortunately don't remember the specifics, but I believe I once tried to port a module that was part of a larger untyped program to Typed Racket and gave up when I discovered that TR couldn't generate a contract for the type of some value I needed to export to untyped code. Obviously there are a number of considerations in creating a mixed typed/untyped program, and I know that if performance is crucial there's no substitute for trying it and seeing if the result is acceptable, but being able to know before porting the code that you at least will be able to move the values you need to across the typed/untyped boundary would be a big help in decision making. -Philip -- 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.
