bug#29857: 27.0.50; error: "Loading `nil': old-style backquotes detected!"

[Michael Heerdegen]

Philipp Stephani <p.stephani2@gmail.com> writes:

> It's somewhat subtle, but if you skip ` there is an oldstyle backquote here. 
> There's a
> comment in lread.c:
>            Because it's more difficult to peek 2 chars ahead, a new-style
>    ,@ can still not be used outside of a `, unless it's in the middle
>    of a list.
> That is, in the construct (,@argument the ,@ is oldstyle unless the ` has 
> been read
> before.

Hmm, ok.
 
>  Also, the error message saying loading `nil'
>  failed is confusing, it took me a while to find out where I tried to
>  load `nil' (nowhere).
>
> It would be reasonable and easy to remove the "Loading `nil'" part in
> the case where no file is being loaded.

Yes, I think that would be good.
  
>  Finally, let me say that `read' raising such errors about old-style
>  backquotes, may it be justified or not, breaks "el-search" which relies
>  heavily on `read' at diverse buffer positions to succeed.
>
> That's a bummer. It means that el-search currently relies on an
> underspecified legacy feature. Could el-search be changed to always
> include reading the initial ` in such cases?

Not really.  It would mean that the "construct" after any backquote
can't be matched or replaced.

E.g. if you have a function `foo' accepting three arguments, and you
decide to change the definition of `foo' so that the meaning of the
second and third arguments are interchanged, you want to replace all
calls in your code with the rule

  `(foo ,a ,b ,c) -> `(foo ,a ,c ,b)

to adopt to the new signature.

(Note that the backquote here is part of `pcase' pattern semantics and
there is no relation with this issue).

But in this occurrence:

#+begin_src emacs-lisp
(defmacro bar (form)
  `(foo 1 1 ,@form))
#+end_src

this replacement rule would fail because the according form would be
unmatchable (and the backquoted thing doesn't match).  One could work
around this...there are always workarounds.  To need to do that would be
very bad.

> Otherwise I'd accept introducing a variable to control whether
> oldstyle backquotes should raise an error or get interpreted as
> newstyle.

That would be optimal for my case.

> El-search would need to adapt, though, because the newstyle
> interpretation is different.

In which way would el-search need to adapt?  It doesn't interpret code.
It is a tool for matching and transforming lists, which, in most cases,
happen to be code.  The user would need to know how `read' interprets
what's matched, of course.


Thanks,

Michael.