Re: gv-exander for 'list'

[Stefan Monnier]

> while I was trying to understand the "debatable" gv expanders (`if',
> `cond' etc.) I had the idea of adding an expander for `list':

[ Ahem!  `if` and `cond` aren't in the "debatable" category.
  `cons` and logand` are!
  BTW, I think the unifying "feature" of the debatable category is that
  these GVs impose constraints on the value that can be assigned.  ]

> +(put 'list 'gv-expander
> +     (lambda (do &rest elt-places)
> +       ;; FIXME: when using this with letf people would expect this to
> +       ;; create local bindings

Not sure what you mean by this FIXME.

> +       (let ((getters+setters
> +              (mapcar (lambda (place)
> +                        (gv-get place (lambda (g s) (cons g s))))
> +                      elt-places)))
> +         (funcall do `(list ,@(mapcar #'car getters+setters))
> +                  (lambda (v)
> +                    (macroexp-let2 macroexp-copyable-p v v
> +                      (macroexp-progn
> +                       (mapcar (lambda (x) (funcall (cdr x) `(pop ,v)))
> +                               getters+setters))))))))

This expands to incorrect code: (macroexpand '(setf (list a b) x))
You should probably replace `macroexp-copyable-p` with `ignore`.

> It could be an alternative to `progv', where the variable list isn't
> computed dynamically (the values list still is), but OTOH allows
> generalized variables.  Would that make sense?

I don't see why it wouldn't do what you say, but I'm not sure how often
that would be usable (and preferable to an alternative).

Also, as a replacement for cl-progv it will suffer from the fact that
instead of using the built-in C code for dynamic scoping, it will mimic
it via unwind-protect, which means that it will misbehave in the
presence of buffer-local values:

    (let ((buf (current-buffer)))
      (with-temp-buffer
        (setq default-directory "/bar/")
        (cl-letf (((list default-directory) '("/foo/")))
          (set-buffer buf))))

There are a few other similar cases that we slowly
patched over the years ;-)

[ Note that it's one of the reasons (beside efficiency) why `cl-letf` is
  careful to treat simple variables specially, thus taking advantage of
  the built-in handling of dynamically-scoped vars.  ]

        Stefan