They are continuation-local state. On Wednesday, August 10, 2011, Ismael Figueroa Palet <<a href="mailto:ifigueroap@gmail.com">ifigueroap@gmail.com</a>> wrote: > Are continuation marks thread- and continuation- safe as parameters? > > 2011/8/10 Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> > > 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 > <<a href="mailto:ifigueroap@gmail.com">ifigueroap@gmail.com</a>> 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 <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> >>> >>> 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 >>> <<a href="mailto:ifigueroap@gmail.com">ifigueroap@gmail.com</a>> wrote: >>> > >>> > >>> > 2011/8/9 Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> >>> >> >>> >> On Tue, Aug 9, 2011 at 3:01 PM, Ismael Figueroa Palet >>> >> <<a href="mailto:ifigueroap@gmail.com">ifigueroap@gmail.com</a>> wrote: >>> >> > 2011/8/4 Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> >>> >> >> >>> >> >> 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 > >