Don't apologize, I'm very grateful for your help :-) I'll take a look at the paper and the documentation
Cheers 2011/8/11 Robby Findler <ro...@eecs.northwestern.edu> > 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: > > http://www.eecs.northwestern.edu/~robby/pubs/papers/icfp2007-fyff.pdf > > 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 > <ifiguer...@gmail.com> 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 <ro...@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 > >> <ifiguer...@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 <ro...@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 > >> >> <ifiguer...@gmail.com> wrote: > >> >> > > >> >> > > >> >> > 2011/8/9 Robby Findler <ro...@eecs.northwestern.edu> > >> >> >> > >> >> >> On Tue, Aug 9, 2011 at 3:01 PM, Ismael Figueroa Palet > >> >> >> <ifiguer...@gmail.com> wrote: > >> >> >> > 2011/8/4 Robby Findler <ro...@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 > > > > > -- Ismael
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
