[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why is FUNC in cl-callf not allowed to be an expression?
From: |
Stefan Monnier |
Subject: |
Re: Why is FUNC in cl-callf not allowed to be an expression? |
Date: |
Sat, 18 May 2019 10:09:41 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> (defmacro gv-place-bind (bindings &rest body)
Hmm... "bind", eh? I don't think that's different enough.
How 'bout something more like a "gv-alias"?
> Writing the docstring made me thoughtful though - how is this different
> from symbol-macrolet?
Indeed, they're closely related but symbol-macrolet does not "evaluates"
anything at the "binding" site. Also it can also be used for purposes
different from "places", e.g. to keep a log of all the accessed to
a "variable" (tho, we could just as well create a (journaled PLACE)
pseudo place which would record accesses in the very same way).
Yeah, maybe a "place alias" is a generalization of symbol-macro.
Actually, no: symbol-macro can also expand to other macro-calls which
are supposed to be re-expanded at each use-site, AFAIK, so it can
macro-expand to something different every time the "variable" is
referenced, which is not the case of places, I think.
Maybe people over on comp.lang.lisp (or other Lisp discussion area)
would have some insight about this.
> My second point in this message: thinking once more about callf, we
> could also support a syntax like (callf (with EXPR) PLACE ARG) or
> something like that to support expressions as first arg.
You can already do that, except that `with` is spelled `lambda (it)`:
(cl-callf (lambda (it) EXPR) PLACE)
Notice that the gv-callf we discussed are equivalent to the above rather
than to something where the EXPR is evaluated to decide which function
to call. To me, the benefit of
(gv-modify it PLACE EXPR)
[with or without the `it`] is that expressions appear in the order in
which they're evaluated, and also that it looks more like `setf`, which
is right since this is about doing a `setf` just with the added twist
that it can refer to the old value of the variable to compute the
new one.
Stefan
- Re: Why is FUNC in cl-callf not allowed to be an expression?, (continued)
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Stefan Monnier, 2019/05/16
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/16
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/16
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Stefan Monnier, 2019/05/16
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/16
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Stefan Monnier, 2019/05/16
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/17
- Re: Why is FUNC in cl-callf not allowed to be an expression?,
Stefan Monnier <=
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/20
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Stefan Monnier, 2019/05/20
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/20
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Noam Postavsky, 2019/05/21
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/21
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Stefan Monnier, 2019/05/21
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Andy Moreton, 2019/05/21
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/23
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/21
- Re: Why is FUNC in cl-callf not allowed to be an expression?, Michael Heerdegen, 2019/05/22