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 25, 2012, at 4:34 PM, Matthias Felleisen wrote:
>
> The largest part of my commit today concerns a re-organization of
> the documentation for lang/htdp* functions. In the past we lived with
> lists of strings that were eventually turned into a quasi-defproc.
>
> I have scribblized the
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/24/2012 10:40 AM, Antonio Menezes Leitao wrote:
Hi,
Given that Racket implements the hyperbolic functions
sinh, cosh, and tanh, I would like to suggest that it also
provides the inverse functions asinh, acosh and atanh.
For the moment, I'm living with my own definitions but
it would be ni
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
The largest part of my commit today concerns a re-organization of
the documentation for lang/htdp* functions. In the past we lived with
lists of strings that were eventually turned into a quasi-defproc.
I have scribblized the docs BUT this means having one set of defprocs
kind of abstracted ov
On Mon, Jun 25, 2012 at 6:53 PM, Matthias Felleisen
wrote:
>
> Sam, can you focus on cases of submodules for which you can guarantee that
> #%module-begin is okay and reject others [with an explicit, informative error
> message]? -- Matthias
I'm not entirely sure what you mean here, but:
(a) t
Sam, can you focus on cases of submodules for which you can guarantee that
#%module-begin is okay and reject others [with an explicit, informative error
message]? -- Matthias
On Jun 25, 2012, at 6:47 PM, Matthew Flatt wrote:
> At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote:
>>
At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote:
> The problem (I
> think) is that the implicit `require` of `(submod "..")` happens
> *before* the expansion of `#%module-begin` inside the submodule.
That's the same for a top-level module M whose initial language is some
other module
On Mon, Jun 25, 2012 at 5:38 PM, Matthew Flatt wrote:
> I think I misunderstood your complaint. If you change the example to
>
> (module+ sub
> (#%module-begin (m)))
>
> then there's no error. So, I think you're running into the old
> only-form-in-module-just-might-expand-to-#%module-begin pro
I think I misunderstood your complaint. If you change the example to
(module+ sub
(#%module-begin (m)))
then there's no error. So, I think you're running into the old
only-form-in-module-just-might-expand-to-#%module-begin problem.
The usual solution is form `m' to check whether it's being
Hi,
Given that Racket implements the hyperbolic functions
sinh, cosh, and tanh, I would like to suggest that it also
provides the inverse functions asinh, acosh and atanh.
For the moment, I'm living with my own definitions but
it would be nicer if these were pre-defined.
Best,
Antonio.
_
>
>
> Did you use `raco docs' to open the documentation page?
>
No.
All I did was to access the Help Desk from DrRacket's Help menu.
BTW, this is a fresh install, after uninstalling the previous version.
I can see the wrong links in the file index.html, in
AppData/Roaming/Racket/5.3.0.11/doc/
On Mon, Jun 25, 2012 at 5:14 PM, Matthew Flatt wrote:
> The expansion of submodules is intended to have a fresh store, just
> like the expansion of any module. The `#f' initial import is intended
> to be something like using `(submod "..")' as the initial language,
> except importing all internal
The expansion of submodules is intended to have a fresh store, just
like the expansion of any module. The `#f' initial import is intended
to be something like using `(submod "..")' as the initial language,
except importing all internal bindings of the module instead of its
exports.
Can Typed Racke
It appears that the expansion of (module* m #f ...) occurs in a fresh
store, but before running the inner module's `#%module-begin` binding.
To see this, run the program at https://gist.github.com/2991214 , and
note that ">> in module-begin" is printed only once, but the expansion
of `m` fails, ind
31 matches
Mail list logo