[racket] Creating a #lang language, and modifying contract system

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Wed Aug 10 13:24:34 EDT 2011

They are continuation-local state.

On Wednesday, August 10, 2011, Ismael Figueroa Palet <ifigueroap at gmail.com>
wrote:
> Are continuation marks thread- and continuation- safe as parameters?
>
> 2011/8/10 Robby Findler <robby at eecs.northwestern.edu>
>
> A parameter is implementing using continuation marks (and other things).
>
> The short version of the story is that you want to say
>
>  (with-continuation-mark 'key 'value e)
>
> instead of
>
>  (parameterize ([param 'value]) e)
>
> and then when the exception is raised, you'll find that it has a field
> that holds the continuation marks in effect at the point where the
> value was raised. You can then use that to extract the 'value you
> stored with the 'key.
>
> There is more information in the manuals about these primitives that
> you'll want to read but don't hesitate to ask if you get stuck.
> (Overall, it sounds like it should be much easier to use this approach
> than the one you were thinking of before.)
>
> Robby
>
> On Wed, Aug 10, 2011 at 11:25 AM, Ismael Figueroa Palet
> <ifigueroap at gmail.com> wrote:
>> Hi again Robby,
>> I really don't know much about continuation marks. I want the value A to
be
>> embedded on the exception structure, because I check that value with a
>> modified with-handlers macro. I thought that using parameters A will
behave
>> like a dynamically scoped identifier.
>> What are the differences, if any, of using continuation marks versus
using
>> parameters??
>> Thanks
>>
>> 2011/8/9 Robby Findler <robby at eecs.northwestern.edu>
>>>
>>> Could you put the value into a continuation mark and then, when you
>>> catch the exception, look in the continuation marks to get it out
>>> again?
>>>
>>> Robby
>>>
>>> On Tue, Aug 9, 2011 at 3:56 PM, Ismael Figueroa Palet
>>> <ifigueroap at gmail.com> wrote:
>>> >
>>> >
>>> > 2011/8/9 Robby Findler <robby at eecs.northwestern.edu>
>>> >>
>>> >> On Tue, Aug 9, 2011 at 3:01 PM, Ismael Figueroa Palet
>>> >> <ifigueroap at gmail.com> wrote:
>>> >> > 2011/8/4 Robby Findler <robby at eecs.northwestern.edu>
>>> >> >>
>>> >> >> The blame assignment stuff is wired pretty deep into the contract
>>> >> >> system. There isn't currently any way to change that aspect of the
>>> >> >> system without doing what you've done below.
>>> >> >>
>>> >> >> If you can say more about how/why you want to change it, tho,
there
>>> >> >> maybe some extension to the current API that would work for you
and
>>> >> >> that we'd be willing to maintain going forward.
>>> >> >
>>> >> > I defined a new-exn struct to represent exceptions and defined a
>>> >> > raise
>>> >> > macro
>>> >> > that wraps Racket's raise to throw a new-exn value. Also, I need to
>>> >> > raise
>>> >> > the exception thrown by raise-blame-error inside a parameterize
>>> >> > expression.
>>> >> > I want to access and modify a parameter that will be used to
>>> >> > construct
>>> >> > the
>>> >> > new-exn value.
>>> >>
>>> >> It sounds like you're maybe adding a field to the exn record? Can you
>>> >> say more about what that field is and how you compute its value? (Or
>>> >> if I'm just wrong about that?)
>>> >
>>> > Yes, the end result I want is to tag the exn record with a value. That
>>> > value
>>> > is stored in a parameter A. I want to make raise-blame-error to always
>>> > raise
>>> > an exception tagged with A+1.
>>> >
>>> > --
>>> > Ismael
>>> >
>>> >
>>
>>
>>
>> --
>> Ismael
>>
>>
>
> --
> Ismael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110810/ceff5ced/attachment.html>

Posted on the users mailing list.