On Saturday, December 7, 2019 at 3:04:25 PM UTC+1, Ben Greenman wrote: > > On 12/7/19, Marc Kaufmann <marc.ka...@gmail.com <javascript:>> wrote: > > Thanks Ben and Jon, that did the trick. > > > > I realized when following the code that the structure wasn't exported - > but > > > > I didn't know how to work around that. I now also checked the > > documentation, and the only thing I found on opaque types is > > > https://docs.racket-lang.org/ts-reference/special-forms.html?q=opaque#%28form._%28%28lib._typed-racket%2Fbase-env%2Fprims..rkt%29._require%2Ftyped%29%29. > > > > > > What it says about opaque types is: > > > > "Opaque types must be required lexically before they are used." > > The docs says a little more --- there are 4 sentences that come right > before this one. > > I think those sentences would be better off with: > 1. a link to `make-predicate` > 2. and English words at the start & end of each sentence > > Let me know if you have other suggestions >
So here is the paragraph: > The fourth case defines a new type t. pred, imported from module m, is a predicate for this type. The type is defined as precisely those values to which pred produces #t. pred must have type (Any -> Boolean). Opaque types must be required lexically before they are used. When I came to the documentation, I was skimming, in part because I didn't know whether this would be helpful or not. I am not a fan of the "The first/second/... case..." when there are many cases and I can no longer see what the cases were - and in fact I miscounted the rows, so I thought this applied to something else for a while. Or rather, I like it, but only if it is "The fourth case defines a new *opaque* type t. ..." When I got to the last sentence starting with 'Opaque types...', I had to think again to realize this is the fourth case talked about - even though no one at any point talked about opaque types, so I was wondering where I'd missed them. Second sentence "This type t is defined via the predicate `pred`, imported from module m. More precisely, it is defined as precisely ... . > > > followed by an example that is even now non-trivial for me to parse and > > figure out. (I started going down the rabbit hole when the `->` was not > > used in the first position of the definition, nor written as `. -> .` > Turns > > out types can be defined via infix notation, which is nice but > unexpected.) > > The docs for -> show the infix notation. > Yeah, I followed that and therefore realized that it was infix notation. Just to explain why I said it, even though I do *not* think that this particular instance should get changed: The point I was making is that for someone like me who doesn't live and breathe Racket, any extra layer of abstraction that isn't the same everywhere is extra cognitive load. Imagine me replacing every few words by a French word. I guess the fact that Racket contracts and Typed Racket don't use exactly the same notation is just a (very minor) nuisance. And I realize that it is incredibly hard to write helpful and clear documentation, so I'm not saying that I'd do a better job. I only very recently started to be able to read and understand the Racket reference, while before I skipped all the arrow bits (and hence higher-order functions) and used the examples to reverse-engineer what form the arguments must take. That means that often I can't figure out what I need from the reference even when it's there. > Is the example still difficult to figure out? We could replace it, but > I'm not sure what could be better > > I think what I'd suggest is to add an example with #:opaque to the Typed Racket Guide, part 6 (https://docs.racket-lang.org/ts-guide/typed-untyped-interaction.html). (if want to stop using infix notation here, then the other uses on the > same page need to change too) > > No, I think it's fine. > > > So there are two questions: > > > > 1. What does #:opaque do? > > 2. How could I have found that out by searching - or essentially the way > to > > > > do it was "Email the list". If the latter, that's fine, the email list > is > > very helpful and it would be good to add some additional explanation of > > opaque types to the documentation of `require-typed`, and possibly even > to > > the typed racket reference. Probably the part talking about typed-racket > > untyped racket interaction. > > > > Let me try answering my first question: #:opaque defines a new type via > a > > predicate function -- here `time?` -- that is being imported (can I use > it > > without require-typed? I guess there would be no point, but I haven't > > thought this through). This is not based on the usual type constructors > > using other types, but based on whether a thing returns `#true` when > passed > > to the predicate, in my case `time?`. I assume this means that the type > is > > verified via contracts, so if I do this a lot I should expect some > run-time > > performance hits (if I call this function a bunch, which isn't an issue > in > > my case). > > Right, a `Time` is any value that `time?` says yes to. > > About performance: in type-checked code, you can expect to pay for > every call to `time?` and nothing else. The run-time hit should be the > same as using cond/if with any simple predicate. > Great. Thanks a lot Ben. Cheers, Marc -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/14619aa7-062a-4d9a-92c6-43cfbbb70aa6%40googlegroups.com.
