Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Stefan Monnier]

Tassilo Horn [2022-08-26 16:06:39] wrote:
>     Improve function calls to retrieve key=vals in style hooks
>     
>     * latex.el (TeX-read-key-val): Improve call of functions as
>     argument of `TeX-arg-key-val' inside style hooks.
[...]
>                 (fboundp (car key-val-alist)))
> -          (let ((head (car key-val-alist))
> -                (tail (cdr key-val-alist)))
> -            (apply head tail)))
> +          (if (> (length key-val-alist) 1)
> +              (eval key-val-alist t)
> +            (funcall (car key-val-alist))))
>           (t

FWIW, replacing `apply` with `eval` is not an "Improve"ment in my
book :-) It means now that `key-val-alist` contains code represented as
data (i.e. code to which flymake, the compiler, the eager macroexpander,
etc... don't have access) whereas it previously only contains values
(which can't contain code that needs macroexpansion, for example).


        Stefan

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan & Arash,

> Tassilo Horn [2022-08-26 16:06:39] wrote:
>>     Improve function calls to retrieve key=vals in style hooks
>>     
>>     * latex.el (TeX-read-key-val): Improve call of functions as
>>     argument of `TeX-arg-key-val' inside style hooks.
> [...]
>>                 (fboundp (car key-val-alist)))
>> -          (let ((head (car key-val-alist))
>> -                (tail (cdr key-val-alist)))
>> -            (apply head tail)))
>> +          (if (> (length key-val-alist) 1)
>> +              (eval key-val-alist t)
>> +            (funcall (car key-val-alist))))
>>           (t
>
> FWIW, replacing `apply` with `eval` is not an "Improve"ment in my book
> :-) It means now that `key-val-alist` contains code represented as
> data (i.e. code to which flymake, the compiler, the eager
> macroexpander, etc... don't have access) whereas it previously only
> contains values (which can't contain code that needs macroexpansion,
> for example).

That's true.  I've searched the auctex lists and found out that Arash
made this change because he wanted to make it possible for styles to do
stuff like

  (TeX-add-style-hook
   "foo"
   (lambda ()
     (TeX-add-symbols
      '("bar" (TeX-arg-key-val (append alist1 alist2))))))

where (append alist1 alist2) is what's being evaled.  Arash, wouldn't

  (TeX-add-style-hook
   "foo"
   (lambda ()
     (TeX-add-symbols
      `("bar" (TeX-arg-key-val ,(append alist1 alist2))))))

be just as good?  I guess no because IIRC the context was that alist1
and alist2 might be populated dynamically (by parsing the document) so
we need to take the values at the time the \bar macro is inserted.  So
probably

  (TeX-add-style-hook
   "foo"
   (lambda ()
     (TeX-add-symbols
      `("bar" (TeX-arg-key-val ,(lambda () (append alist1 alist2)))))))

would be the right thing which works without eval, right?  It's a bit
longer but I wouldn't mind.  Wrapping code in a lambda to be evaluated
later is a common concept.

Bye,
Tassilo

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Stefan Monnier]

> be just as good?  I guess no because IIRC the context was that alist1
> and alist2 might be populated dynamically (by parsing the document) so
> we need to take the values at the time the \bar macro is inserted.  So
> probably
>
>   (TeX-add-style-hook
>    "foo"
>    (lambda ()
>      (TeX-add-symbols
>       `("bar" (TeX-arg-key-val ,(lambda () (append alist1 alist2)))))))
>
> would be the right thing which works without eval, right?  It's a bit
> longer but I wouldn't mind.  Wrapping code in a lambda to be evaluated
> later is a common concept.

FWIW, I don't understand exactly how the above code is "linked" to the
definition of `TeX-arg-key-val` (which in my code takes two arguments
rather than one).
I tried to trace through the code, but it's a bit less obvious than
needed for my little head.


        Stefan

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I guess no because IIRC the context was that alist1 and alist2 might
>> be populated dynamically (by parsing the document) so we need to take
>> the values at the time the \bar macro is inserted.  So probably
>>
>>   (TeX-add-style-hook
>>    "foo"
>>    (lambda ()
>>      (TeX-add-symbols
>>       `("bar" (TeX-arg-key-val ,(lambda () (append alist1 alist2)))))))
>>
>> would be the right thing which works without eval, right?  It's a bit
>> longer but I wouldn't mind.  Wrapping code in a lambda to be
>> evaluated later is a common concept.
>
> FWIW, I don't understand exactly how the above code is "linked" to the
> definition of `TeX-arg-key-val` (which in my code takes two arguments
> rather than one).

Yes, all TeX-arg-* functions have OPTIONAL as first arg but that's
implicit.  If you use it them parentheses, it's mandatory (optional is
nil) whereas when you use it with brackets it's optional.  Brackets
because that's how optional arguments are written in TeX.  So you could
also have

  `("bar" [TeX-arg-key-val ,(lambda () (append alist1 alist2))])

if it was \bar[key1=val1, key2=val2] instead of \bar{key1=val1,
key2=val2}.

> I tried to trace through the code, but it's a bit less obvious than
> needed for my little head.

Hehe, I agree... with the non-obviousness, of course, not the size of
your head. :-)

Bye,
Tassilo

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Emanuel Berg]

Stefan Monnier wrote:

> replacing `apply` with `eval` is not an "Improve"ment in my
> book :-)

What does it say about replacing `apply' with `funcall' then?

Does it say you should do it since `funcall' is not only
shorter but also more efficient?

But not always or not always possible to do, right?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> That's true.  I've searched the auctex lists and found out that Arash
> made this change because he wanted to make it possible for styles to do
> stuff like
>
>   (TeX-add-style-hook
>    "foo"
>    (lambda ()
>      (TeX-add-symbols
>       '("bar" (TeX-arg-key-val (append alist1 alist2))))))
>
> where (append alist1 alist2) is what's being evaled.  Arash, wouldn't
>
>   (TeX-add-style-hook
>    "foo"
>    (lambda ()
>      (TeX-add-symbols
>       `("bar" (TeX-arg-key-val ,(append alist1 alist2))))))
>
> be just as good?  I guess no because IIRC the context was that alist1
> and alist2 might be populated dynamically (by parsing the document) so
> we need to take the values at the time the \bar macro is inserted.

Actually, I changed all AUCTeX styles to have a function which returns a
keyval-alist for the ones which are populated dynamically.  Maintaining
a single variable for this kind of stuff was a mess.

So take fancyvrb.el for example which has a variable
`LaTeX-fancyvrb-key-val-options'[1] (which can declared by defconst now)
and a function `LaTeX-fancyvrb-key-val-options'[2] which returns the
current keyvals.

So my last requirement was to be able to do something like this:

(TeX-add-style-hook
 "foo"
 (lambda ()
   (TeX-add-symbols
    '("bar" (TeX-arg-key-val
             (append (func1-returning-keyval-alist)
                     (func2-returning-keyval-alist)))))))

And this didn't work with the (apply head tail) version.  Any other
suggestion how to implement this in `TeX-arg-key-val' is highly welcome.
I was reluctant to use eval in the first place since I knew that Stefan
will complain :-) but I didn't see any other possibility.

Best, Arash

Footnotes:
[1]  http://git.savannah.gnu.org/cgit/auctex.git/tree/style/fancyvrb.el#n74

[2]  http://git.savannah.gnu.org/cgit/auctex.git/tree/style/fancyvrb.el#n127

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

> So take fancyvrb.el for example which has a variable
> `LaTeX-fancyvrb-key-val-options'[1] (which can declared by defconst now)
> and a function `LaTeX-fancyvrb-key-val-options'[2] which returns the
> current keyvals.
>
> So my last requirement was to be able to do something like this:
>
> (TeX-add-style-hook
>  "foo"
>  (lambda ()
>    (TeX-add-symbols
>     '("bar" (TeX-arg-key-val
>              (append (func1-returning-keyval-alist)
>                      (func2-returning-keyval-alist)))))))
>
> And this didn't work with the (apply head tail) version.  Any other
> suggestion how to implement this in `TeX-arg-key-val' is highly
> welcome.

So what's wrong with this one?

(TeX-add-style-hook
 "foo"
 (lambda ()
   (TeX-add-symbols
    `("bar" (TeX-arg-key-val
             ,(lambda ()
               (append (func1-returning-keyval-alist)
                       (func2-returning-keyval-alist))))))))

That's again caught by the functionp case and can simply be funcalled.
I'd rather prefer to keep the DSL simple, e.g., TeX-arg-key-val
arguments can either be a literal alist, a function of no args
delivering an alist, or a symbol denoting an alist variable (checked in
that order).  That is, I wouldn't even distinguish functions from
variables syntactically but prefer functions in general, e.g.,

  (TeX-arg-key-val (LaTeX-enumitem-key-val-options))

would become

  (TeX-arg-key-val LaTeX-enumitem-key-val-options)

where LaTeX-enumitem-key-val-options is funcalled and takes precedence
of the variable of the same name.

Sorry, I know we had a discussion back then where I haven't been
explicit enough or haven't had an informed opinion yet. :-(

Bye,
Tassilo

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FWIW, replacing `apply` with `eval` is not an "Improve"ment in my
  > book :-) It means now that `key-val-alist` contains code represented as
  > data (i.e. code to which flymake, the compiler, the eager macroexpander,
  > etc... don't have access) whereas it previously only contains values
  > (which can't contain code that needs macroexpansion, for example).

+1.

It is cleaner for a hook-like variable to contain a function with
arguments to pass to it, than to contain an expression.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> So what's wrong with this one?
>
> (TeX-add-style-hook
>  "foo"
>  (lambda ()
>    (TeX-add-symbols
>     `("bar" (TeX-arg-key-val
>              ,(lambda ()
>                (append (func1-returning-keyval-alist)
>                        (func2-returning-keyval-alist))))))))

If this is the best/only option, well, I'm buying it :)

> That's again caught by the functionp case and can simply be funcalled.

How would you then re-write `TeX-read-key-val'?  It currently looks like
this:

(defun TeX-read-key-val (optional key-val-alist &optional prompt)
  "Prompt for keys and values in KEY-VAL-ALIST and return them.
If OPTIONAL is non-nil, indicate in the prompt that we are
reading an optional argument.  KEY-VAL-ALIST is an alist.  The
car of each element should be a string representing a key and the
optional cdr should be a list with strings to be used as values
for the key.  KEY-VAL-ALIST can be a symbol or a function call
returning an alist.  Use PROMPT as the prompt string."
  (multi-prompt-key-value
   (TeX-argument-prompt optional prompt "Options (k=v)")
   (cond ((and (symbolp key-val-alist)
               (boundp key-val-alist))
          (symbol-value key-val-alist))
         ((and (listp key-val-alist)
               (symbolp (car key-val-alist))
               (fboundp (car key-val-alist)))
          (if (> (length key-val-alist) 1)
              (eval key-val-alist t)
            (funcall (car key-val-alist))))
         (t
          key-val-alist))))

And while we're at, what do we do with `TeX-arg-eval'?

> I'd rather prefer to keep the DSL simple, e.g., TeX-arg-key-val
> arguments can either be a literal alist, a function of no args
> delivering an alist, or a symbol denoting an alist variable (checked in
> that order).  That is, I wouldn't even distinguish functions from
> variables syntactically but prefer functions in general, e.g.,
>
>   (TeX-arg-key-val (LaTeX-enumitem-key-val-options))
>
> would become
>
>   (TeX-arg-key-val LaTeX-enumitem-key-val-options)
>
> where LaTeX-enumitem-key-val-options is funcalled and takes precedence
> of the variable of the same name.

Hmm, Sorry, but I don't like this.  Why taking away the clarity of what
is currently used, the variable or the function?  I think having the
function call in () increases the legibility.

> Sorry, I know we had a discussion back then where I haven't been
> explicit enough or haven't had an informed opinion yet. :-(

No problem, you will have to adjust all AUCTeX styles for being late ;-)

Best, Arash

TeX-arg-key-val syntax and let go of eval (was: [elpa] externals/auctex cb0a1e6be1 72/77: Improve function calls to retrieve key=vals in style hooks)

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

>> So what's wrong with this one?
>>
>> (TeX-add-style-hook
>>  "foo"
>>  (lambda ()
>>    (TeX-add-symbols
>>     `("bar" (TeX-arg-key-val
>>              ,(lambda ()
>>                (append (func1-returning-keyval-alist)
>>                        (func2-returning-keyval-alist))))))))
>
> If this is the best/only option, well, I'm buying it :)

It's the typical lispy solution which doesn't require eval.

>> That's again caught by the functionp case and can simply be
>> funcalled.
>
> How would you then re-write `TeX-read-key-val'?

In my suggested version where (TeX-arg-key-val foo) would funcall foo if
it were a function (without having to wrap it in parentheses), it would
be:

--8<---------------cut here---------------start------------->8---
(defun TeX-read-key-val (optional key-val-alist &optional prompt)
  (multi-prompt-key-value
   (TeX-argument-prompt optional prompt "Options (k=v)")
   (cond ((and (functionp key-val-alist)
               (fboundp key-val-alist))
          (funcall key-val-alist))
         ((and (symbolp key-val-alist)
               (boundp key-val-alist))
          (symbol-value key-val-alist))
         ((and (listp key-val-alist)
               (listp (car key-val-alist)))
          key-val-alist)
         (t (error "Cannot interpret key-val-alist %S" key-val-alist)))))
--8<---------------cut here---------------end--------------->8---

> And while we're at, what do we do with `TeX-arg-eval'?

Nothing.  It's been there since 1994 so we cannot really do anything
except declaring it obsolete.  But since probably nobody byte-compiles
his styles and therefore might see the warning, we will never be able to
get rid of it.

>> I'd rather prefer to keep the DSL simple, e.g., TeX-arg-key-val
>> arguments can either be a literal alist, a function of no args
>> delivering an alist, or a symbol denoting an alist variable (checked in
>> that order).  That is, I wouldn't even distinguish functions from
>> variables syntactically but prefer functions in general, e.g.,
>>
>>   (TeX-arg-key-val (LaTeX-enumitem-key-val-options))
>>
>> would become
>>
>>   (TeX-arg-key-val LaTeX-enumitem-key-val-options)
>>
>> where LaTeX-enumitem-key-val-options is funcalled and takes
>> precedence of the variable of the same name.
>
> Hmm, Sorry, but I don't like this.  Why taking away the clarity of
> what is currently used, the variable or the function?  I think having
> the function call in () increases the legibility.

Because it makes TeX-read-key-val easy to implement (no need to
distinguish a "funcall list" from a literal alist) and the heuristics
"try function, else try variable, else try literal alist" is really not
hard.  Also because

   '(TeX-arg-key-val (LaTeX-enumitem-key-val-options))

looks like normal evaluation syntax but that symmetry immediately breaks
with

   `(TeX-arg-key-val ,(lambda () ...))

which would need to be

   `(TeX-arg-key-val (,(lambda () ...)))

to keep symmetry.  But then we're in lisp-1 land which also looks
wrong. :-)

>> Sorry, I know we had a discussion back then where I haven't been
>> explicit enough or haven't had an informed opinion yet. :-(
>
> No problem, you will have to adjust all AUCTeX styles for being late
> ;-)

Sure, I can do that but want to achieve a consensus first.  Given that I
haven't written a LaTeX doc in at least 6 years and consequently my
AUCTeX activities have much decreased, I'm not in a position to enforce
my personal preferences.

Bye,
Tassilo

PS: I've added auctex-devel to the Cc and set Reply-To accordingly.