On Jan 30, 2015, at 3:59 PM, Alexis King lexi.lam...@gmail.com wrote:
No, the typechecker can’t make any assumptions about the results of opaque
types. If you explicitly instantiate a Posn with the type Real, the
typechecker should only guarantee the result will be Real. Annotate the type
No, it doesn’t need to be wrapped in an opaque structure. Wrapping it in an
opaque structure would add a layer of indirection for absolutely no gain.
Remember, the value itself is already, by definition, opaque. The only way
typed code can manipulate the value is by passing it to other
On Jan 30, 2015, at 1:53 PM, Alexis King lexi.lam...@gmail.com wrote:
No, it doesn’t need to be wrapped in an opaque structure. Wrapping it in an
opaque structure would add a layer of indirection for absolutely no gain.
Remember, the value itself is already, by definition, opaque. The only
I recently ran into a problem in which opaque types (types imported from
untyped code) cannot by parameterized by Typed Racket. I initially encountered
this problem in my attempt to port 2htdp/image to TR
https://github.com/lexi-lambda/racket-2htdp-typed/issues/1.
After some further
I think you’re reading too far into what I’m proposing, though I admit I
probably didn’t give enough context. I’ve been talking with Sam about this
issue on IRC, so he knows what I’m talking about, but I’ll try and clarify here.
This entire thing is just a fix for the problem described in
On Jan 29, 2015, at 11:34 PM, Alexis King lexi.lam...@gmail.com wrote:
But the problem is that if it’s an opaque type then it can’t unwrap it once
the value is returned from make-posn.
Yes, that’s precisely the problem. Your point about implementing everything
as single-valued structs on
Um, for this:
(module typed typed/racket/base
(provide (struct-out Foo))
(struct [A] Foo ([x : A] [y : A]) #:transparent))
(Foo a 'b)
Should be fine because Foo could be instantiated at the type (U String Symbol).
On Jan 29, 2015, at 9:25 PM, Alexis King lexi.lam...@gmail.com wrote:
I
But the problem is that if it’s an opaque type then it can’t unwrap it once
the value is returned from make-posn.
Yes, that’s precisely the problem. Your point about implementing everything as
single-valued structs on the typed side is an interesting one, though I don’t
think it ultimately
This has bothered me too, but I've realized that I was on the wrong track.
The string a and symbol 'b are not different types. A struct (Foo a
'b), or (list a 'b), is a homogeneous data structure of type (U String
Symbol) just like Alexander said. This really upsets me -- I like the
Hindley
Furthermore, even if the wrappers were shared between functions, untyped code
would recieved wrapped values, which would render them quite useless.
If it’s not an opaque type, but something like a list, then this works, and the
untyped code receiving wrapped values isn’t a problem here:
#lang
Or Any for that matter. I know. The fact that it could be literally anything
was sort of the point.
On Jan 29, 2015, at 19:10, Alexander D. Knauth alexan...@knauth.org wrote:
Um, for this:
(module
It isn’t wrapped in an opaque structure. That wasn’t a part of my proposal, and
while I didn’t think of it until you brought it up, I still think it’s
unnecessary and doesn’t add any convenience.
Perhaps I’m not understanding you properly, but your “one-length string” idea
sounds like it has
12 matches
Mail list logo
