[racket-dev] Blame and re-provided bindings

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 bindings, I don't see why that is relevant to
the design decision of how re-provided bindings should behave.

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 the contract were written a
second time) is the right behavior (assuming we can solve the
performance and single-binding issues Carl raised).

Matthias: ditto.

Robby

On Sat, Jan 15, 2011 at 11:49 AM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> 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 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 outside world, and don't want specifics of your implementation to leak.  Again, this seems to be what you'd actually want for redex, right?  You're reproviding things you've contracted internally (to make sure you are using them appropriately in your implementation) to the outside world, and at this point there's no reason for the outside world to know that the function `redex-mangle-names' is defined in the module contained in the file $PLTHOME/collects/redex/private/mangler/nomnomnom.rkt; it'd be better for the user if the blame was just the current blame you'd get if it were contracted in the external interface, or maybe even something like `(collection redex)'.
>>
>>> Instead, I think we should be thinking "what is (provide f) shorthand
>>> for?". In the past I argued it was shorthand for "(provide/contract [f
>>> any/c])" but now I think that maybe we should be thinking of it as
>>> "(provide/contract [f
>>> <the-contract-f-was-imported-with-or-any/c-if-there-wasn't-one>])".
>>>
>>> Does that make more sense?
>>
>> I do understand what you're saying.  Whether or not we made that change (which pretty much puts us back in the old negative blame calculation world), I'm just wondering whether we also want an operation like that I've described above for use in collects, PLaneT packages, and the like.  However, that one really would need to be explicit, since you wouldn't want it to happen all the time.  (And to be fair, I'd still argue it'd be the right thing for the re-exporting that you're describing for redex, where you're re-exporting internal values to the outside world for use.)
>>
>> Stevie
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>
>