On Jun 26, 2012, at 2:32 AM, Ryan Culpepper wrote:
> On 06/25/2012 11:53 PM, Stevie Strickland wrote:
>>
>> On Jun 26, 2012, at 1:30 AM, Ryan Culpepper wrote:
>>
>>> On 06/25/2012 10:25 PM, Stevie Strickland wrote:
As for the negative blame, who should be responsible? Who's
responsib
On 06/25/2012 11:53 PM, Stevie Strickland wrote:
On Jun 26, 2012, at 1:30 AM, Ryan Culpepper wrote:
On 06/25/2012 10:25 PM, Stevie Strickland wrote:
[Hit Reply instead of Reply All, so fixing that here.]
On Jun 25, 2012, at 11:53 PM, Ryan Culpepper wrote:
On 06/25/2012 09:27 PM, Stevie Str
On Jun 26, 2012, at 1:30 AM, Ryan Culpepper wrote:
> On 06/25/2012 10:25 PM, Stevie Strickland wrote:
>> [Hit Reply instead of Reply All, so fixing that here.]
>>
>> On Jun 25, 2012, at 11:53 PM, Ryan Culpepper wrote:
>>
>>> On 06/25/2012 09:27 PM, Stevie Strickland wrote:
On Jun 25, 2012,
On 06/25/2012 10:25 PM, Stevie Strickland wrote:
[Hit Reply instead of Reply All, so fixing that here.]
On Jun 25, 2012, at 11:53 PM, Ryan Culpepper wrote:
On 06/25/2012 09:27 PM, Stevie Strickland wrote:
On Jun 25, 2012, at 11:21 PM, Ryan Culpepper wrote:
On 06/25/2012 09:04 PM, Asumu Taki
[Hit Reply instead of Reply All, so fixing that here.]
On Jun 25, 2012, at 11:53 PM, Ryan Culpepper wrote:
> On 06/25/2012 09:27 PM, Stevie Strickland wrote:
>> On Jun 25, 2012, at 11:21 PM, Ryan Culpepper wrote:
>>
>>> On 06/25/2012 09:04 PM, Asumu Takikawa wrote:
On 2012-06-25 20:17:33 -0
On 06/25/2012 09:27 PM, Stevie Strickland wrote:
On Jun 25, 2012, at 11:21 PM, Ryan Culpepper wrote:
On 06/25/2012 09:04 PM, Asumu Takikawa wrote:
On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote:
IIUC from your later message, you've implemented the generics
analogue of object/c (per-instan
On Jun 25, 2012, at 11:27 PM, Stevie Strickland wrote:
> Much like interface contracts mediate between the creator of a class (that
> implements the interface) and the client of that class (that instantiates
> objects from that interface),
Of course I meant the client that instantiates objects f
On Jun 25, 2012, at 11:21 PM, Ryan Culpepper wrote:
> On 06/25/2012 09:04 PM, Asumu Takikawa wrote:
>> On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote:
>>> IIUC from your later message, you've implemented the generics
>>> analogue of object/c (per-instance contract), whereas
>>> prop:dict/contr
On 06/25/2012 09:04 PM, Asumu Takikawa wrote:
On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote:
IIUC from your later message, you've implemented the generics
analogue of object/c (per-instance contract), whereas
prop:dict/contract is closer to class/c (per-type contract). It's a
little fuzzy b
On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote:
> IIUC from your later message, you've implemented the generics
> analogue of object/c (per-instance contract), whereas
> prop:dict/contract is closer to class/c (per-type contract). It's a
> little fuzzy because prop:dict/contract hacks in per-in
Oh, I see what you mean now. Thanks.
And yes, if you can't "catch" the values passed to the constructor,
then you aren't going to be guaranteeing that the implementation
behaves parametrically anyways!
Robby
On Mon, Jun 25, 2012 at 9:27 PM, Asumu Takikawa wrote:
> On 2012-06-25 21:19:33 -0500,
On 2012-06-25 21:19:33 -0500, Robby Findler wrote:
> What do you mean by "made opaque by key/c"?
The prototype I wrote would bind the parameters provided in the
`#:params` argument to contracts produced by `new-∀/c`. If `key/c` is
one of the parameters, then `dict-ref` with a key argument wraps it
Great, thanks!
Robby
On Mon, Jun 25, 2012 at 8:28 PM, Asumu Takikawa wrote:
> On 2012-06-25 20:15:49 -0500, Robby Findler wrote:
>> This is not directly related to your particular commit, but if I make
>> a make-prime-dict, does apply a contract at that point (using
>> 'contract')? If so, who ar
What do you mean by "made opaque by key/c"?
Robby
On Mon, Jun 25, 2012 at 9:05 PM, Asumu Takikawa wrote:
> On 2012-06-25 21:28:52 -0400, Asumu Takikawa wrote:
>> (provide/contract
>> [make-int-dict
>> (-> key-value-list?
>> (simple-dict/c
>> [dict-ref (->* (simple-dict?
On 06/25/2012 06:57 PM, Asumu Takikawa wrote:
On 2012-06-25 20:35:21 -0400, as...@racket-lang.org wrote:
| racket/generics: add contract combinator
|
| The generics library now generates a `name/c` macro
| for a generic interface `name`. The combinator can be
| used to contract instances (or con
On 2012-06-25 21:28:52 -0400, Asumu Takikawa wrote:
> (provide/contract
>[make-int-dict
> (-> key-value-list?
> (simple-dict/c
> [dict-ref (->* (simple-dict? symbol?) (any/c) integer?)]
> [dict-set (-> simple-dict? symbol? integer? simple-dict?)]
> [dict
On 2012-06-25 20:15:49 -0500, Robby Findler wrote:
> This is not directly related to your particular commit, but if I make
> a make-prime-dict, does apply a contract at that point (using
> 'contract')? If so, who are the parties that get blamed?
The short answer is: the generated contract can be a
This is not directly related to your particular commit, but if I make
a make-prime-dict, does apply a contract at that point (using
'contract')? If so, who are the parties that get blamed?
Robby
On Mon, Jun 25, 2012 at 7:57 PM, Asumu Takikawa wrote:
> On 2012-06-25 20:35:21 -0400, as...@racket-l
On 2012-06-25 20:35:21 -0400, as...@racket-lang.org wrote:
> | racket/generics: add contract combinator
> |
> | The generics library now generates a `name/c` macro
> | for a generic interface `name`. The combinator can be
> | used to contract instances (or constructors) of a
> | generic interface a
19 matches
Mail list logo
