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

Reply via email to