On Sun, Jan 16, 2011 at 10:03 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 15, 2011, at 5:05 PM, Casey Klein wrote:
On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 12:19 PM, Robby Findler wrote:
I think that we are just
On Sun, Jan 16, 2011 at 10:03 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 15, 2011, at 5:05 PM, Casey Klein wrote:
On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 12:19 PM, Robby Findler wrote:
I think that we are just
On Jan 17, 2011, at 9:00 AM, Robby Findler wrote:
The redex module does an all-from-out provide on what it gets from
redex/reduction-semantics and redex/pict, making it the negative party
on the contracts. When a redex client breaks one of the contracts,
redex gets blamed instead of the
So far as I understand it, we have: Stevie opposed, Matthias neutral,
Robby and Casey for, with everyone agreeing that we should try to
preserve the Carl constraints of 'single contract wrapper' and 'same
identifier-ness'.
Note that in the current world we are *forced* to break the first of
the
On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
So far as I understand it, we have: Stevie opposed, Matthias neutral,
Robby and Casey for, with everyone agreeing that we should try
On Jan 17, 2011, at 10:10 AM, Robby Findler wrote:
On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
So far as I understand it, we have: Stevie opposed, Matthias neutral,
Robby
On Mon, Jan 17, 2011 at 9:28 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 17, 2011, at 10:10 AM, Robby Findler wrote:
On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
On Mon, Jan 17, 2011 at 9:49 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
[...] remove the
contracts from 'private' modules to reduce the double hit.
Let me summarize what was important in Casey's message that relates to
this. He has these files:
redex/gui.rkt
On Jan 17, 2011, at 10:53 AM, Robby Findler wrote:
Let me summarize what was important in Casey's message that relates to
this. He has these files:
redex/gui.rkt
redex/reduction-semantics.rkt
redex/main.rkt
The first two export subsets of the Redex library (in order to make it
On Mon, Jan 17, 2011 at 10:10 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 17, 2011, at 10:53 AM, Robby Findler wrote:
Let me summarize what was important in Casey's message that relates to
this. He has these files:
redex/gui.rkt
redex/reduction-semantics.rkt
On Jan 15, 2011, at 5:05 PM, Casey Klein wrote:
On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 12:19 PM, Robby Findler wrote:
I think that we are just throwing up stumbling blocks. It is really a
design choice (does a reprovide carry over
On Sun, Jan 16, 2011 at 11:03 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 15, 2011, at 5:05 PM, Casey Klein wrote:
On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 12:19 PM, Robby Findler wrote:
I think that we are just
But Casey says the _client_ broke the contract. It's irrelevant where things
come from when the client breaks the contracts.
On Jan 16, 2011, at 11:06 PM, Carl Eastlund wrote:
On Sun, Jan 16, 2011 at 11:03 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 15, 2011, at 5:05 PM,
This sentence makes no sense to me. Contracts are all about where
things come from. How can it be irrelevant?
On Sun, Jan 16, 2011 at 11:12 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
But Casey says the _client_ broke the contract. It's irrelevant where things
come from when the
On Fri, Jan 14, 2011 at 9:13 PM, Carl Eastlund c...@ccs.neu.edu wrote:
I think that most of the time that you re-provide something you really
wanted to put the same contract on it, so it seems like we should make
that easy.
Robby
On the other hand, that means the number of requires and
On Sat, Jan 15, 2011 at 6:53 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
On Fri, Jan 14, 2011 at 9:13 PM, Carl Eastlund c...@ccs.neu.edu wrote:
I think that most of the time that you re-provide something you really
wanted to put the same contract on it, so it seems like we should make
On Sat, Jan 15, 2011 at 7:21 AM, Carl Eastlund c...@ccs.neu.edu wrote:
On Sat, Jan 15, 2011 at 6:53 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
On Fri, Jan 14, 2011 at 9:13 PM, Carl Eastlund c...@ccs.neu.edu wrote:
I think that most of the time that you re-provide something you really
I think the bottom line is that we should stick to the explicit notion of
re-exporting and this 'feels' right given the general eq? problem.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
This means you think that re-providing should act like a
provide/contract with the any/c contract (as it is currently
(attempting) to do)?
Robby
On Sat, Jan 15, 2011 at 11:14 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
I think the bottom line is that we should stick to the explicit
Yes, I think that is correct and somehow in line with our 'market force'
thinking.
On Jan 15, 2011, at 12:15 PM, Robby Findler wrote:
This means you think that re-providing should act like a
provide/contract with the any/c contract (as it is currently
(attempting) to do)?
Robby
On
I think that we are just throwing up stumbling blocks. It is really a
design choice (does a reprovide carry over the contract or does it
put a new one on there?) and I seriously doubt there are any places
where someone does a reprovide intending to change the contract in
this manner. To the
On Jan 15, 2011, at 12:26 PM, Stevie Strickland wrote:
On Jan 15, 2011, at 12:19 PM, Robby Findler wrote:
I think that we are just throwing up stumbling blocks. It is really a
design choice (does a reprovide carry over the contract or does it
put a new one on there?) and I seriously doubt
On Jan 15, 2011, at 12:32 PM, Robby Findler wrote:
But I don't think we should think of it as 'changing the positive
blame information' -- I agree anything phrased like that sounds wrong.
But I think you _do_ want this in some cases, where you're reproviding
internally contracted things to an
I am totally with you. (I don't understand how you can satisfy Carl's scenario
and keep it inexpensive but all the power to you.)
On Jan 15, 2011, at 12:42 PM, Stevie Strickland wrote:
On Jan 15, 2011, at 12:32 PM, Robby Findler wrote:
But I don't think we should think of it as 'changing
I'm not completely clear here: Stevie seems to be talking about some
more general purpose operation and I don't see much of a connection to
the issue of what happens with re-provided bindings. While I agree
that other operation is what happens under the hood for my proposed
change to re-provided
On Jan 15, 2011, at 1:12 PM, Robby Findler wrote:
do you think this change I'm suggesting (act as if the contract were written
a second time) is the right behavior
1. My personal preference is to ask programmers to re-provide identifiers with
explicit contracts that are ideally stated and
On Jan 15, 2011, at 1:19 PM, Matthias Felleisen wrote:
2. I am not strictly opposed to your suggestion because I see value in your
reasoning. If we go with re-providing the identifier with its contract, I
would like to see the blame assignment shifted to the re-exporting module.
This does
On Sat, Jan 15, 2011 at 12:22 PM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 1:19 PM, Matthias Felleisen wrote:
2. I am not strictly opposed to your suggestion because I see value in your
reasoning. If we go with re-providing the identifier with its contract, I
would
On Sat, Jan 15, 2011 at 12:19 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jan 15, 2011, at 1:12 PM, Robby Findler wrote:
do you think this change I'm suggesting (act as if the contract were written
a second time) is the right behavior
1. My personal preference is to ask
On Jan 15, 2011, at 1:24 PM, Robby Findler wrote:
On Sat, Jan 15, 2011 at 12:22 PM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 1:19 PM, Matthias Felleisen wrote:
2. I am not strictly opposed to your suggestion because I see value in your
reasoning. If we go with
On Sat, Jan 15, 2011 at 12:26 PM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 1:24 PM, Robby Findler wrote:
On Sat, Jan 15, 2011 at 12:22 PM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 1:19 PM, Matthias Felleisen wrote:
2. I am not strictly opposed
On Jan 15, 2011, at 1:26 PM, Stevie Strickland wrote:
I assumed that Matthias meant that he'd like to see the _positive_ blame
shifted to the re-exporting module, which would cause the issue.
yes.
_
For list-related administrative tasks:
On Jan 15, 2011, at 1:12 PM, Robby Findler wrote:
So, let me ask this: Stevie, do you think that the current world for
re-provided bindings is the right design decision (ie act as if they
were all written like (provide/contract [f any/c])), or do you think
this change I'm suggesting (act as if
On Jan 15, 2011, at 1:25 PM, Robby Findler wrote:
1. My personal preference is to ask programmers to re-provide identifiers
with explicit contracts that are ideally stated and specified in a separate
'contracts.rkt' file per collects/project basis. I.e., the current world is
my
On Jan 15, 2011, at 1:30 PM, Robby Findler wrote:
Are you saying that it is somehow less bad if the only indeterminate
aspect of the use of the variable is whether or not the 'via' shows
up?
There the information is taken from the context of the _use_ of the variable,
which is calculated when
On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland
sstri...@ccs.neu.edu wrote:
On Jan 15, 2011, at 12:19 PM, Robby Findler wrote:
I think that we are just throwing up stumbling blocks. It is really a
design choice (does a reprovide carry over the contract or does it
put a new one on there?)
FWIW, Casey and I talked about this in my office and I've long advocated that
(require f.rkt) ;; provide/contract's f with some contract
(provide f)
or
(require f.rkt) ;; provide/contract's f with some contract
(provide (all-from-out f.rkt))
should be the equivalent of:
(require
The first problem is a variant of PR 11084, I think.
Ryan
On 01/14/2011 12:40 PM, Casey Klein wrote:
The new, nicely formatted blame messages helped me discover that every
single Redex contract has the wrong negative party. (Admittedly, the
commonly used Redex provides are macros.) There are
On Jan 14, 2011, at 2:44 PM, Robby Findler wrote:
as far as the contract library is concerned, but now I'm starting to
think that that is not convenient enough. Instead, we should really
default to 'provide f with the same contract it had before, as if the
programmer had copied and pasted the
No, actually in this case the user message is also wrong. If you trace
thru the module dag, you'll see it.
Robby
On Fri, Jan 14, 2011 at 1:53 PM, Stevie Strickland sstri...@ccs.neu.edu wrote:
On Jan 14, 2011, at 2:44 PM, Robby Findler wrote:
as far as the contract library is concerned, but now
The first. I think you've got it.
Robby
On Fri, Jan 14, 2011 at 3:28 PM, Stevie Strickland sstri...@ccs.neu.edu wrote:
On Jan 14, 2011, at 4:22 PM, Robby Findler wrote:
No, actually in this case the user message is also wrong. If you trace
thru the module dag, you'll see it.
Just to check,
On Fri, Jan 14, 2011 at 3:28 PM, Stevie Strickland sstri...@ccs.neu.edu wrote:
On Jan 14, 2011, at 4:22 PM, Robby Findler wrote:
No, actually in this case the user message is also wrong. If you trace
thru the module dag, you'll see it.
Just to check, are you talking about the second series of
Two complaints in one day about the wording of these clauses. Let's do
something about the English.
I have another one, unrelated: I don't like the 'self-blame'. I have
encountered this now a couple of times, and I think we should use the Eiffel
terminology of
promised
required
On Jan 14, 2011, at 5:24 PM, Casey Klein wrote:
FWIW, I had no idea what the message's via clause meant.
Truthfully, I was guessing that via = user blame. If I didn't know the
internals, I wouldn't have known what that meant either. I think it needs to
be rewritten, but I haven't thought
On Jan 14, 2011, at 5:33 PM, Matthias Felleisen wrote:
Two complaints in one day about the wording of these clauses. Let's do
something about the English.
Agreed.
I have another one, unrelated: I don't like the 'self-blame'. I have
encountered this now a couple of times, and I think we
45 matches
Mail list logo
