I'll try that in my particular case, however, what is the main difference and how do I decide whether to use continuation marks or parameters?? what are the advantages/disadvantages of choosing one over the other?<div> </div><div>Thanks <div class="gmail_quote">2011/8/10 Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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 <div><div></div><div class="h5"><<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 > > </div></div></blockquote></div> -- Ismael </div>