Hi,
If that's not too difficult to do (maybe automatically), it would be nice
if the docs could tell if a function/form has changed or has been added
recently.
Maybe a note in the margin like Added in 5.2.1 or Changed in 5.3.0.
It would be helpful for backward compatibility.
Laurent
+1
On 04/27/2012 11:25 AM, Laurent wrote:
Hi,
If that's not too difficult to do (maybe automatically), it would be nice if
the docs could tell if a function/form has changed or has been added recently.
Maybe a note in the margin like Added in 5.2.1 or Changed in 5.3.0.
It would be helpful
Hi all,
Recently I have been adding class contracts to parts of the GUI system.
In tandem, I've also added a new feature to `class/c` that allows a
contract to be opaque, which means that the contract requires that *all*
public methods fields in the contracted class are themselves
contracted.
I'm not seeing why a notion of opaque like this is valuable, but
maybe I don't understand what s going on. Specifically, it seems like
I can add the contract (unconstrained-domain- any) to each method to
get it to be opaque without actually contributing anything of value.
It seems better to let
On 2012-04-27 13:17:36 -0500, Robby Findler wrote:
Specifically, it seems like I can add the contract
(unconstrained-domain- any) to each method to get it to be opaque
without actually contributing anything of value.
[...]
Or is there something else going on there that I'm missing?
The
On Fri, Apr 27, 2012 at 1:27 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
On 2012-04-27 13:17:36 -0500, Robby Findler wrote:
Specifically, it seems like I can add the contract
(unconstrained-domain- any) to each method to get it to be opaque
without actually contributing anything of value.
On 2012-04-27 13:37:02 -0500, Robby Findler wrote:
I think that maybe I still misunderstand? Specifically, if I put an
opaque object contract on a value and the contract does not mention
'm', then (send ... m) will be a runtime error
The opaque class contract wouldn't produce an error on (send
Oh, I see. Yes, this seems like a fine thing to me (making class
contracts be opaque).
Robby
On Fri, Apr 27, 2012 at 1:51 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
On 2012-04-27 13:37:02 -0500, Robby Findler wrote:
I think that maybe I still misunderstand? Specifically, if I put an
opaque
On Apr 27, 2012, at 1:48 PM, Asumu Takikawa wrote:
* Composability: opaque class contracts are not composable since each
one requires the entire specification. This shouldn't be a problem
since the individual class/c clauses can be composed/reused (e.g., -m
contracts).
[[If you
On 2012-04-27 17:44:06 -0400, Matthias Felleisen wrote:
[[If you mentioned this issue in my office yesterday, I failed to catch it.]]
I remembered/thought it as I was composing the e-mail.
In the old world, I could write contracts such as
(and/c (class/cc ...) (class/c ...))
and that was
6 hours ago, Asumu Takikawa wrote:
The primary reason that I added opaque contracts is that they are
needed for Typed Racket's eventual class/object support.
[If that's the motivation, then it sounds like these opaque contracts
are similar to TR forcing you to write types for all (toplevel)
11 matches
Mail list logo
