Re: [racket-dev] [plt] Push #29677: master branch updated

[Eric Dobson]

This change seemed to change the format of .dep files, likely as intended
to add the indirect dependencies. Is there any documentation of what the
format is supposed to be? Currently I've just been trying to read cm.rkt
and understand how it treats them.

On Thu, Jan 8, 2015 at 9:31 AM,  wrote:

> mflatt has updated `master' from c56c9250f1 to 95e85ec5bd.
>   http://git.racket-lang.org/plt/c56c9250f1..95e85ec5bd
>
> =[ 2 Commits ]==
> Directory summary:
>   45.1% pkgs/racket-doc/scribblings/raco/
>4.7% pkgs/racket-doc/scribblings/reference/
>   47.5% racket/collects/compiler/
>
> ~~
>
> fe9a04d Matthew Flatt  2015-01-08 09:11
> :
> | doc tweaks for `raco {setup,make}`
> :
>   M pkgs/racket-doc/scribblings/raco/make.scrbl  |  4 ++--
>   M pkgs/racket-doc/scribblings/raco/setup.scrbl | 22
> --
>
> ~~
>
> 95e85ec Matthew Flatt  2015-01-08 09:57
> :
> | add support for indirect CM dependencies; use in `lazy-require`
> |
> | If module M in package P imports module N from package Q,
> | and if N has a `lazy-require` for a module in R that is
> | triggered during the compilation of M, then P doesn't really
> | depend on R; P depends on Q, and Q depends on R, and P
> | shoudn't necessarily know anything about Q. At the same time,
> | a change to the file in R means that M must be recompiled.
> | So, continue to track the compilation dependency, but mark
> | it as "indirect" so that the package-dependency checker can
> | ignore the dependency.
> :
>   M pkgs/racket-doc/scribblings/raco/make.scrbl   | 33 -
>   M racket/collects/compiler/cm-accomplice.rkt| 14 +++---
>   M racket/collects/compiler/cm.rkt   | 49
> ++--
>   M racket/collects/racket/lazy-require.rkt   |  2 +-
>   M racket/collects/setup/private/pkg-deps.rkt|  1 +
>   M .../racket-doc/scribblings/reference/syntax.scrbl |  8 ++--
>
> =[ Overall Diff ]===
>
> pkgs/racket-doc/scribblings/raco/make.scrbl
> ~~~
> --- OLD/pkgs/racket-doc/scribblings/raco/make.scrbl
> +++ NEW/pkgs/racket-doc/scribblings/raco/make.scrbl
> @@ -123,7 +123,7 @@ would create only @filepath{compiled/b_rkt.zo} and
>
>  @; --
>
> -@section{Dependency Files}
> +@section[#:tag "Dependency Files"]{Dependency Files}
>
>  In addition to a bytecode file, @exec{raco make} creates a file
>  @filepath{compiled/@nonterm{name}_@nonterm{ext}.dep} that records
> @@ -538,7 +538,7 @@ messages are instances of a
> @racket[parallel-compile-event] prefab structure:
>
>  @racketblock[
>(struct parallel-compile-event (worker event) #:prefab)
> -].
> +]
>
>  The worker field is the index of the worker that the created the event.
> The event
>  field is a @racket[compile-event] as document in
> @@ -550,25 +550,36 @@ field is a @racket[compile-event] as document in
>
>  @defmodule[compiler/cm-accomplice]
>
> -@defproc[(register-external-file [file (and path? complete-path?)])
> void?]{
> +@defproc[(register-external-file [file (and path? complete-path?)]
> + [#:indirect? indirect? any/c #f])
> + void?]{
>
> -Logs a message (see @racket[log-message]) at level @racket['info] to
> -a logger named @racket['cm-accomplice]. The
> -message data is a @racketidfont{file-dependency} prefab structure type
> -with two fields; the first field's value is @racket[file] and the second
> -field's value is @racket[#f] (to indicate a non-module dependency).
> +Logs a message (see @racket[log-message]) at level @racket['info] to a
> +logger named @racket['cm-accomplice]. The message data is a
> +@racketidfont{file-dependency} prefab structure type with two fields;
> +the first field's value is @racket[file] and the second field's value
> +is @racket[#f] (to indicate a non-module dependency). If the
> +@racket[indirect?] argument is true, the data is more specifically an
> +instance of a @racketidfont{file-dependency/indirect} prefab structure
> +type that is a subtype of @racketidfont{file-dependency} with no new
> +fields.
>
>  A compilation manager implemented by @racketmodname[compiler/cm] looks
> -for such messages to register an external dependency. The compilation
> -manager records (in a @filepath{.dep} file) the path as contributing
> -to the implementation of the module currently being
> +for such messages to register an external dependency. In response, the
> +compilation manager records (in a @filepath{.dep} file) the path as
> +contributing to the implementation of the module currently being
>  compiled. Afterward, if the registered file is modified, the
> -compilation manager will know to recompile the module.
> +compilation manager will know to recompile the module. An ``indirect''
> +dependency has no effect on recompilation, but it can signal to ot

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

[Alexis King]

Okay, now I see what you’re saying. That’s a reasonable point, and it’s worth 
considering. Thanks for bearing with me.

> On Jan 30, 2015, at 13:24, Alexander D. Knauth  wrote:
> 
> 
> On Jan 30, 2015, at 3:59 PM, Alexis King  > 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 
>> as (U 1 2), though, and obviously it would need to ensure that remains 
>> invariant.
> 
> How about this program:
> untyped.rkt:
> #lang racket
> (provide (all-defined-out))
> (define (make-posn x y) (list 3 y)) ; bad
> typed.rkt:
> #lang typed/racket
> ; make Posn parametric
> (define-type (Posn X Y) (List X Y))
> (require/typed "untyped.rkt"
>[make-posn (All (X Y) X Y -> (Posn X Y))])
> (: p : (Posn Real Real))
> (define p (make-posn 1 2))
> This gives this error:
> . . make-posn: broke its contract
>   promised: X3
>   produced: 3
>   in: the car of
>   the range of
>   (parametric->/c
>(X3 Y4)
>(->*
> (X3 Y4)
> ()
> (values (cons/c X3 (cons/c Y4 g6)
>   contract from: (interface for make-posn)
>   blaming: (interface for make-posn)
>(assuming the contract is correct)
>   at: …./typed.rkt:5.16
> 
> I think it’s a good thing that it checks that it actually gives you the value 
> that you gave it, and not just something like 3 even if it happens to match 
> the type you want.  And I think parametric opaque types should behave in a 
> similar way, and to do that you would need the opaque value to be wrapped in 
> another opaque structure, which would store either the contracts or the set 
> of values that would pass the contracts or something like that.  
> 
>> 
>>> On Jan 30, 2015, at 12:30, Alexander D. Knauth >> > wrote:
>>> 
>>> 
>>> On Jan 30, 2015, at 1:53 PM, Alexis King >> > 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 way typed code can manipulate the value is by passing it to other 
 functions imported via require/typed.
 
 This means that contracts only need to be generated wherever those 
 functions are called. This can be done without wrapping or unwrapping 
 anything because all the information required to generate those contracts 
 is known at expansion-time. The typechecker simply needs to insert the 
 relevant contracts at the relevant locations.
>>> 
>>> Imagine a program like this:
>>> #lang typed/racket
>>> (require typed/lang/posn)
>>> (: p : (Posn Real Real)) ; I’m assuming Posn is parametric over 2 tvars, 
>>> not 1
>>> (define p (posn 1 2))
>>> (: x : Real)
>>> (define x (posn-x p))
>>> As far as the type checker would check, it would check that the result of 
>>> posn-x is a Real, but I think that the runtime contract it should also 
>>> check that it returns 1, because posn could have been instantiated as (Posn 
>>> 1 2).
>>> #lang typed/racket
>>> (require typed/lang/posn/mutable) ; like typed/lang/posn, but providing 
>>> mutation too
>>> (: p : (Posn Real Real))
>>> (define p (posn 1 2))
>>> (: x : Real)
>>> (define x (posn-x p))
>>> (set-posn-x! p 3)
>>> (: x2 : Real)
>>> (define x2 (posn-x p))
>>> Here, even though the type checker only cares that it’s a number, it should 
>>> check that x2 definition returns either 1 or 3, since both were provided as 
>>> x values for the posn p.
>>> 
>>> For it to keep track of these at runtime, (and it would have to be runtime) 
>>> the contracts would have to be with the actual posn value in an opaque 
>>> structure, which would have contracts sort of like (new-∀/c) that would 
>>> check these things, although I don’t think it would have to wrap the inner 
>>> values, but just record them so that when posn-x is called on one of these 
>>> things, it checks that it was one of the values that was passed in to 
>>> either a constructor or setter function.  
>>> 
> On Jan 30, 2015, at 07:27, Alexander D. Knauth  > wrote:
>  
> On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote:
>> 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.
>  
> I think the opaque structures would be necessary for the kind of "sharing 
> wrappers between functions" that you describe just before section 2.1, 
> except that instead of the sub-values being wrapped on the untyped side, 
> the whole thing is wrapped on the typed side, and there is a contract 
> that wraps it and unw

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

[Alexander D. Knauth]

On Jan 30, 2015, at 3:59 PM, Alexis King  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 
> as (U 1 2), though, and obviously it would need to ensure that remains 
> invariant.

How about this program:
untyped.rkt:
#lang racket
(provide (all-defined-out))
(define (make-posn x y) (list 3 y)) ; bad
typed.rkt:
#lang typed/racket
; make Posn parametric
(define-type (Posn X Y) (List X Y))
(require/typed "untyped.rkt"
   [make-posn (All (X Y) X Y -> (Posn X Y))])
(: p : (Posn Real Real))
(define p (make-posn 1 2))
This gives this error:
. . make-posn: broke its contract
  promised: X3
  produced: 3
  in: the car of
  the range of
  (parametric->/c
   (X3 Y4)
   (->*
(X3 Y4)
()
(values (cons/c X3 (cons/c Y4 g6)
  contract from: (interface for make-posn)
  blaming: (interface for make-posn)
   (assuming the contract is correct)
  at: …./typed.rkt:5.16

I think it’s a good thing that it checks that it actually gives you the value 
that you gave it, and not just something like 3 even if it happens to match the 
type you want.  And I think parametric opaque types should behave in a similar 
way, and to do that you would need the opaque value to be wrapped in another 
opaque structure, which would store either the contracts or the set of values 
that would pass the contracts or something like that.  

> 
>> On Jan 30, 2015, at 12:30, Alexander D. Knauth  wrote:
>> 
>> 
>> On Jan 30, 2015, at 1:53 PM, Alexis King  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 way 
>>> typed code can manipulate the value is by passing it to other functions 
>>> imported via require/typed.
>>> 
>>> This means that contracts only need to be generated wherever those 
>>> functions are called. This can be done without wrapping or unwrapping 
>>> anything because all the information required to generate those contracts 
>>> is known at expansion-time. The typechecker simply needs to insert the 
>>> relevant contracts at the relevant locations.
>> 
>> Imagine a program like this:
>> #lang typed/racket
>> (require typed/lang/posn)
>> (: p : (Posn Real Real)) ; I’m assuming Posn is parametric over 2 tvars, not 
>> 1
>> (define p (posn 1 2))
>> (: x : Real)
>> (define x (posn-x p))
>> As far as the type checker would check, it would check that the result of 
>> posn-x is a Real, but I think that the runtime contract it should also check 
>> that it returns 1, because posn could have been instantiated as (Posn 1 2).
>> #lang typed/racket
>> (require typed/lang/posn/mutable) ; like typed/lang/posn, but providing 
>> mutation too
>> (: p : (Posn Real Real))
>> (define p (posn 1 2))
>> (: x : Real)
>> (define x (posn-x p))
>> (set-posn-x! p 3)
>> (: x2 : Real)
>> (define x2 (posn-x p))
>> Here, even though the type checker only cares that it’s a number, it should 
>> check that x2 definition returns either 1 or 3, since both were provided as 
>> x values for the posn p.
>> 
>> For it to keep track of these at runtime, (and it would have to be runtime) 
>> the contracts would have to be with the actual posn value in an opaque 
>> structure, which would have contracts sort of like (new-∀/c) that would 
>> check these things, although I don’t think it would have to wrap the inner 
>> values, but just record them so that when posn-x is called on one of these 
>> things, it checks that it was one of the values that was passed in to either 
>> a constructor or setter function.  
>> 
 On Jan 30, 2015, at 07:27, Alexander D. Knauth  
 wrote:
  
 On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote:
> 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.
  
 I think the opaque structures would be necessary for the kind of "sharing 
 wrappers between functions" that you describe just before section 2.1, 
 except that instead of the sub-values being wrapped on the untyped side, 
 the whole thing is wrapped on the typed side, and there is a contract that 
 wraps it and unwraps it when it goes from untyped to typed and back.  
  
 For parametric types, they have to also work if the type was constrained 
 to the exact set of values that were provided, which means that if you 
 provide two numbers, say 1 and 2, it has to return a posn with not just 
 any two numbers, but values of the type (U 1 2), since A could have been 
 constrained to (U 1 2).  So it has to be wrapped somehow, and I think 
 wrapping

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

[Alexander D. Knauth]

On Jan 30, 2015, at 1:53 PM, Alexis King  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 way 
> typed code can manipulate the value is by passing it to other functions 
> imported via require/typed.
> 
> This means that contracts only need to be generated wherever those functions 
> are called. This can be done without wrapping or unwrapping anything because 
> all the information required to generate those contracts is known at 
> expansion-time. The typechecker simply needs to insert the relevant contracts 
> at the relevant locations.

Imagine a program like this:
#lang typed/racket
(require typed/lang/posn)
(: p : (Posn Real Real)) ; I’m assuming Posn is parametric over 2 tvars, not 1
(define p (posn 1 2))
(: x : Real)
(define x (posn-x p))
As far as the type checker would check, it would check that the result of 
posn-x is a Real, but I think that the runtime contract it should also check 
that it returns 1, because posn could have been instantiated as (Posn 1 2).
#lang typed/racket
(require typed/lang/posn/mutable) ; like typed/lang/posn, but providing 
mutation too
(: p : (Posn Real Real))
(define p (posn 1 2))
(: x : Real)
(define x (posn-x p))
(set-posn-x! p 3)
(: x2 : Real)
(define x2 (posn-x p))
Here, even though the type checker only cares that it’s a number, it should 
check that x2 definition returns either 1 or 3, since both were provided as x 
values for the posn p.

For it to keep track of these at runtime, (and it would have to be runtime) the 
contracts would have to be with the actual posn value in an opaque structure, 
which would have contracts sort of like (new-∀/c) that would check these 
things, although I don’t think it would have to wrap the inner values, but just 
record them so that when posn-x is called on one of these things, it checks 
that it was one of the values that was passed in to either a constructor or 
setter function.  

>> On Jan 30, 2015, at 07:27, Alexander D. Knauth  wrote:
>>  
>> On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote:
>>> 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.
>>  
>> I think the opaque structures would be necessary for the kind of "sharing 
>> wrappers between functions" that you describe just before section 2.1, 
>> except that instead of the sub-values being wrapped on the untyped side, the 
>> whole thing is wrapped on the typed side, and there is a contract that wraps 
>> it and unwraps it when it goes from untyped to typed and back.  
>>  
>> For parametric types, they have to also work if the type was constrained to 
>> the exact set of values that were provided, which means that if you provide 
>> two numbers, say 1 and 2, it has to return a posn with not just any two 
>> numbers, but values of the type (U 1 2), since A could have been constrained 
>> to (U 1 2).  So it has to be wrapped somehow, and I think wrapping it on the 
>> typed side makes more sense.  
>>  
>>> Perhaps I’m not understanding you properly, but your “one-length string” 
>>> idea sounds like it has little to do with this opaque type problem and more 
>>> to do with the fact that you want refinement types in Typed Racket. I do, 
>>> too! But I don’t think hacking the opaque type system is going to help you 
>>> with that.
>>  
>> Well, yeah, refinement types would be the "real" solution for this 
>> particular example, but if I do want to constrain it to strings of length 1, 
>> opaque types are the only option for now, and they actually work fine.  My 
>> point was you couldn't do this type of thing with the opaque structures and 
>> you would probably get weird errors if you tried.  (See below because there 
>> might be a solution?)
>>  
>>> (Also, as for the box example, I’m actually a little surprised that doesn’t 
>>> contract error. Seems like a bug to me, but perhaps I’m missing some 
>>> idiosyncrasies of the type system. Either way, it’s precisely that kind of 
>>> craziness I was referring to when I compared casting parametric opaque 
>>> types to casting mutable types.)
>>  
>> There is a bug report for it here, and the solution proposed by Sam 
>> Tobin-Hochstadt would be for cast to generate 2 contracts, one for the 
>> original type, one for the new type, but that never got implemented.  
>> http://bugs.racket-lang.org/query/?cmd=view&pr=13626
>>  
>> Actually now that I think about it the two-contract solution might be able 
>> to solve the previous problem, since the original contract could unwrap the 
>> value before it is passed to the new contract?  I'm not sure though.  The 
>> value inside the cast would be from the typed side, then it is passed 
>> through the orig contract as if it were going

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

[Alexis King]

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 functions 
imported via require/typed.

This means that contracts only need to be generated wherever those functions 
are called. This can be done without wrapping or unwrapping anything because 
all the information required to generate those contracts is known at 
expansion-time. The typechecker simply needs to insert the relevant contracts 
at the relevant locations.

> On Jan 30, 2015, at 07:27, Alexander D. Knauth  wrote:
> 
>  
>  
>  
> On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote:
>> 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.
>  
> I think the opaque structures would be necessary for the kind of "sharing 
> wrappers between functions" that you describe just before section 2.1, except 
> that instead of the sub-values being wrapped on the untyped side, the whole 
> thing is wrapped on the typed side, and there is a contract that wraps it and 
> unwraps it when it goes from untyped to typed and back.  
>  
> For parametric types, they have to also work if the type was constrained to 
> the exact set of values that were provided, which means that if you provide 
> two numbers, say 1 and 2, it has to return a posn with not just any two 
> numbers, but values of the type (U 1 2), since A could have been constrained 
> to (U 1 2).  So it has to be wrapped somehow, and I think wrapping it on the 
> typed side makes more sense.  
>  
>> Perhaps I’m not understanding you properly, but your “one-length string” 
>> idea sounds like it has little to do with this opaque type problem and more 
>> to do with the fact that you want refinement types in Typed Racket. I do, 
>> too! But I don’t think hacking the opaque type system is going to help you 
>> with that.
>  
> Well, yeah, refinement types would be the "real" solution for this particular 
> example, but if I do want to constrain it to strings of length 1, opaque 
> types are the only option for now, and they actually work fine.  My point was 
> you couldn't do this type of thing with the opaque structures and you would 
> probably get weird errors if you tried.  (See below because there might be a 
> solution?)
>  
>> (Also, as for the box example, I’m actually a little surprised that doesn’t 
>> contract error. Seems like a bug to me, but perhaps I’m missing some 
>> idiosyncrasies of the type system. Either way, it’s precisely that kind of 
>> craziness I was referring to when I compared casting parametric opaque types 
>> to casting mutable types.)
>  
> There is a bug report for it here, and the solution proposed by Sam 
> Tobin-Hochstadt would be for cast to generate 2 contracts, one for the 
> original type, one for the new type, but that never got implemented.  
> http://bugs.racket-lang.org/query/?cmd=view&pr=13626 
> 
>  
> Actually now that I think about it the two-contract solution might be able to 
> solve the previous problem, since the original contract could unwrap the 
> value before it is passed to the new contract?  I'm not sure though.  The 
> value inside the cast would be from the typed side, then it is passed through 
> the orig contract as if it were going to the typed side, which would unwrap 
> it, and then that unwrapped value would be passed to the new contract as if 
> it were flowing from the untyped side to the typed side.  
>  
>>  
>>> On Jan 29, 2015, at 20:50, Alexander D. Knauth >> > wrote:
>>>  
>>>  
>>> On Jan 29, 2015, at 11:34 PM, Alexis King >> > 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 the typed side is an interesting 
 one, though I don’t think it ultimately solves any problems. The fact that 
 the typed side knowsnothingabout the contents of the value is what makes 
 this such a tricky problem.
  
 As for this:
  
> But then you couldn’t do any operations on it except those that you use 
> import with require/typed, right?
  
 That’s completely correct. That’s why it’s “opaque.”
  
> And what happens if you use cast on one of these things?
  
 That’s a little more interesting. Usingcaston an object of this type would 
 never fail (unless, of course, it didn’t actually satisfy the 
 basicposn?predicate), but it would possibly introduce failures in the 
 future since it w

[racket-dev] Switching to Google groups: many thanks, keep it coming

[John Clements]

I want to thank 60 of you for signing up for the new google group manually;
limitations on bulk adds and bulk invites mean that transferring people by
hand will be time-consuming. (On the other hand, I'll probably get really
good at google's CAPTCHAs...)

Anyhow, if you have a moment and haven't yet done so, visit this link

https://groups.google.com/forum/#!forum/racket-dev/join

to sign up for the new group. At the urging of several list participants,
I'm going to wait a few more days for people to add themselves.

Thanks again!

John Clements
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

[Alexander D. Knauth]

On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote:
> 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.

I think the opaque structures would be necessary for the kind of
"sharing wrappers between functions" that you describe just before
section 2.1, except that instead of the sub-values being wrapped on the
untyped side, the whole thing is wrapped on the typed side, and there is
a contract that wraps it and unwraps it when it goes from untyped to
typed and back.

For parametric types, they have to also work if the type was constrained
to the exact set of values that were provided, which means that if you
provide two numbers, say 1 and 2, it has to return a posn with not just
any two numbers, but values of the type (U 1 2), since A could have been
constrained to (U 1 2). So it has to be wrapped somehow, and I think
wrapping it on the typed side makes more sense.

> Perhaps I’m not understanding you properly, but your “one-length
> string” idea sounds like it has little to do with this opaque type
> problem and more to do with the fact that you want refinement types in
> Typed Racket. I do, too! But I don’t think hacking the opaque type
> system is going to help you with that.

Well, yeah, refinement types would be the "real" solution for this
particular example, but if I do want to constrain it to strings of
length 1, opaque types are the only option for now, and they actually
work fine. My point was you couldn't do this type of thing with the
opaque structures and you would probably get weird errors if you tried.
(See below because there might be a solution?)

> (Also, as for the box example, I’m actually a little surprised that
> doesn’t contract error. Seems like a bug to me, but perhaps I’m
> missing some idiosyncrasies of the type system. Either way, it’s
> precisely that kind of craziness I was referring to when I compared
> casting parametric opaque types to casting mutable types.)

There is a bug report for it here, and the solution proposed by Sam
Tobin-Hochstadt would be for cast to generate 2 contracts, one for the
original type, one for the new type, but that never got implemented.
http://bugs.racket-lang.org/query/?cmd=view&pr=13626

Actually now that I think about it the two-contract solution might be
able to solve the previous problem, since the original contract could
unwrap the value before it is passed to the new contract? I'm not sure
though. The value inside the cast would be from the typed side, then it
is passed through the orig contract as if it were going to the typed
side, which would unwrap it, and then that unwrapped value would be
passed to the new contract as if it were flowing from the untyped side
to the typed side.

>
>> On Jan 29, 2015, at 20:50, Alexander D. Knauth
>>  wrote:
>>
>>
>> On Jan 29, 2015, at 11:34 PM, Alexis King
>>  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 the typed side is an
>>> interesting one, though I don’t think it ultimately solves any
>>> problems. The fact that the typed side knows*nothing*about the
>>> contents of the value is what makes this such a tricky problem.
>>>
>>> As for this:
>>>
 But then you couldn’t do any operations on it except those that you
 use import with require/typed, right?
>>>
>>> That’s completely correct. That’s why it’s “opaque.”
>>>
 And what happens if you use cast on one of these things?
>>>
>>> That’s a little more interesting. Usingcaston an object of this type
>>> would never fail (unless, of course, it didn’t actually satisfy the
>>> basicposn?predicate), but it would possibly introduce failures in
>>> the future since it would affect the contracts generated
>>> forposn-xandposn-y, for example.
>>>
>>> To make that more clear, casting a(Posn Real)to a(Posn String)would
>>> work fine until you tried to callposn-xon the instance, in which
>>> case it would raise a contract error. Note that this isn’t really
>>> any different from casting mutable data types.
>>
>> But if it were wrapped in an opaque structure, then that structure
>> wouldn’t satisfy the posn? predicate, unless of course the posn?
>> predicate has a contract that unwraps it. So all of the operations on
>> it would have to have contracts that would unwrap it. This might
>> actually make sense if the type is meant to be actually opaque, but
>> if it’s an opaque type that represents a normal non-opaque value,
>> then it will still work as an opaque type, but it won’t be a normal
>> non-opaque value anymore on the typed side.
>>
>> But the reason I asked about cast was because normally I can use cast
>> with a value that has an opaque type, but it’s wrapped on the typed
>> side in this opa

Re: [racket-dev] feature request: thread-safe memoize-evt

[Jan Dvořák]

Thanks for your time.

On Thu, 2015-01-29 at 12:55 -0700, Matthew Flatt wrote:
> Would the simpler `once-evt` work in your situation, or do you need the
> guarantee that only one wait of E happens at a time?

OK, my original goal is to implement a remote method call multiplexer.
The kind where you send a message with an identifier and the remote
party eventually replies with the same identifier or possibly with a
well-known one to indicate an out-of-bound notification.

So, I'd like to end up with (something-receive-evt something key) and
(something-call-evt something key request).

I can see two ways to do that;

 1.  Have a dispatch table with pending messages.
 2.  Broadcast all incoming messages to all waiters.

Dispatch table requires non-racy invalidation of pending requests to
prevent resource leaks.

Broadcasting messages requires construction of a thread-safe memoizing
event combinator (produces next-evt and a single result).

Also, I have a feeling that I could get close to (1) if I keep some
cleanup thread and utilize nack-guard-evt, but something tells me it
might be racy.

Best regards,
Jan Dvorak

_
  Racket Developers list:
  http://lists.racket-lang.org/dev