I like that better. :) A minor thing: you could use multiple values and multiple arguments, ie
> (ps1) 1 2 > (ps1 2 3) > (ps1) 2 3 > (ps1 5) ... arity error (You'd still have to use your own version of parameterize, tho, I think.) Robby On Fri, Oct 21, 2011 at 9:38 AM, Neil Toronto <neil.toro...@gmail.com> wrote: > How about this? This code: > > (define p1 (make-parameter 1)) > (define p2 (make-parameter 2)) > (define-parameter-group ps1 (p1 p2)) > > defines a parameter-like group as before, and also defines a 'ps1-value' > struct. Interaction: > > > (ps1) > (ps1-value 1 2) > > (ps1 (ps1-value 10 20)) > > (ps1) > (ps1-value 10 20) > > (p1) > 10 > > Because parameter groups act like a parameter, they can be contained in > other parameter groups. So the extension mechanism is containment. > > You can optionally provide a struct name, and it'll use that instead of > creating a '<name>-value' struct. (Funny thing: I just discovered it'll take > 'list' as the struct name, or anything else for which the constructor > signature and match pattern are the same.) > > Is that better? > > Neil T > > On 10/20/2011 12:36 PM, Robby Findler wrote: >> >> What I'm saying is that parameter-list* and parameter-list-append do >> not seem like things that belong in this API. And it isn't really a >> "list" in the sense that it is least fixed point of an inductive >> definition like X = nil | (cons parameter X). >> >> Really, there is a new type of data whose purpose is to group together >> parameters for the purpose of saving and restoring groups of them. So, >> I think you want one new kind of value (implemented with an opaque >> struct) that supports those operations (and the name should not >> include the word "list"). You may also wish to have a way to convert >> one of these things into a list of parameters, in which case that >> conversion function would probably have the word "list" in its name, >> but that'd be a separate thing. >> >> Robby >> >> On Thu, Oct 20, 2011 at 11:34 AM, Neil Toronto<neil.toro...@gmail.com> >> wrote: >>> >>> Is there a better data type to tangle them with? >>> >>> I considered multiple values, but those were cumbersome to save because >>> (values v ...) isn't a first-class value. Saving and restoring multiple >>> parameters is the main reason to use a parameter list. >>> >>> I tried making structs, but that forced me into making a >>> 'define-parameter-list' macro instead of a 'parameter-list' function. I >>> wanted as much similarity with parameters as possible. >>> >>> It turned out that 'list*' and 'append' have well-known semantics that >>> correspond nicely with extending and combining parameter lists. >>> >>> I suppose I could use a prefab struct instead. >>> >>> Neil T >>> >>> On 10/20/2011 09:59 AM, Robby Findler wrote: >>>> >>>> Good. I'm glad we avoided the unknown boogeyman. >>>> >>>> But I don't see why you need tangle lists and these things. >>>> >>>> Robby > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
