Don't apologize, I'm very grateful for your help :-)<div>I'll take a look at the paper and the documentation</div><div> </div><div>Cheers <div class="gmail_quote">2011/8/11 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;">Well, continuation-marks are a lower-level, lighter-weight construct than parameters. Sometimes you have to use parameters because that's the api you get to work with (current-output-port being a popular example of that) and sometimes you have to use continuation-marks because that's the api you get to work with (the exn field that you're using, altho this is a much rarer case). Featurewise, parameters have guards, they work with parameterizations, they can be set directly (as opposed to stored as part of a continuation) and they behave differently write to the interactions with threads. Continuation marks don't do any of that. Overall, I guess, the best answer is "it depends" and I'm sorry to say it, but I think that your best bet is to study the constructs yourself to try to understand them. Matthew recently wrote an excellent note about the interactions with eval and namespaces and why you should or shouldn't use one and I would love to be able to provide you with the same, but I don't have such an essay yet. I'm sorry. The best I can offer you is the documentation and this paper: <a href="http://www.eecs.northwestern.edu/~robby/pubs/papers/icfp2007-fyff.pdf" target="_blank">http://www.eecs.northwestern.edu/~robby/pubs/papers/icfp2007-fyff.pdf</a> I apologize in advance if this is too researchy for what you're looking for. Perhaps others have more practical experience and would like to chime in. Robby On Thu, Aug 11, 2011 at 8:55 AM, Ismael Figueroa Palet <div><div></div><div class="h5"><<a href="mailto:ifigueroap@gmail.com">ifigueroap@gmail.com</a>> wrote: > 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? > Thanks > > 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 > > </div></div></blockquote></div> -- Ismael </div>