[racket] Saving and restoring many parameters

From: Neil Toronto (neil.toronto at gmail.com)
Date: Fri Oct 21 10:38:37 EDT 2011

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)

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.toronto at 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

Posted on the users mailing list.