[racket] Saving and restoring many parameters

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
>>
>> On Thu, Oct 20, 2011 at 10:54 AM, Neil Toronto<neil.toronto at gmail.com>
>>  wrote:
>>>
>>> On 10/20/2011 08:08 AM, Robby Findler wrote:
>>>>
>>>> Well, what about the current-namespace? The output ports? It seems
>>>> dangerous and leak introducing (possibly).
>>>>
>>>> I don't actually have an example where it could cause a problem tho. But
>>>> you might try to think thru the ramifications by searing for "current-"
>>>> in the docs.
>>>
>>> I still think using a thread wouldn't be a problem. But you convinced me
>>> yesterday that it could become a problem in the future.
>>>
>>> So I invented parameter lists. Creating a plot pict looks like this now:
>>>
>>>    (define saved-parameters (plot-parameters))
>>>    (dc (λ (dc x y)
>>>          (parameterize/list ([plot-parameters  saved-parameters])
>>>            (plot/dc renderer-tree dc x y width height ...)))
>>>        width height)
>>>
>>> Some example tests:
>>>
>>>    (define p1 (make-parameter 1))
>>>    (define p2 (make-parameter 2))
>>>    (define ps1 (parameter-list p1 p2))
>>>
>>>    (check-equal? (ps1) (list 1 2))
>>>    (check-equal? (parameterize/list ([ps1  (list 10 20)]) (ps1))
>>>                  (list 10 20))
>>>    (check-equal? (parameterize ([p1 10] [p2 20]) (ps1))
>>>                  (list 10 20))
>>>    (check-equal? (parameterize/list ([ps1  (list 10 20)])
>>>                    (list (p1) (p2)))
>>>                  (list 10 20))
>>>
>>>    (ps1 (list 10 20))
>>>
>>>    (check-equal? (ps1) (list 10 20))
>>>
>>> Rules:
>>>
>>>    ((parameter-list p ...)) = (list (p) ...)
>>>
>>>    ((parameter-list p ...) (list v ...)) = (begin (p v) ...)
>>>
>>>    (parameterize/list ([(parameter-list p ...)  (list v ...)]) e ...)
>>>     = (parameterize ([p v] ...) e ...)
>>>
>>>    ((parameter-list* p ... pl)) = (list* (p) ... (pl))
>>>
>>>    ((parameter-list-append pl ...)) = (append (pl) ...)
>>>
>>> I know Blake has wanted these before, so I might throw them into
>>> unstable.
>>>
>>> Neil T
>>>
>
>