Thanks for your helpful reply. I've created GitHub issues and 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 <>

> 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.


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 
For more options, visit

Reply via email to