GNU bug report logs - #45610
27.1; Symbol’s function definition is void: seq-concatenate

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45610 in the body.
You can then email your comments to 45610 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Symbol’s function definition is void:
 seq-concatenate
Date: Sat, 02 Jan 2021 20:29:37 +0800

I have the following macro that is working until 27.1.

(defmacro cl-concatenatef (type place &rest sequences)
  `(cl-callf2 cl-concatenate ,type ,place ,@sequences))

cl-concatenate is inlinable (since forever) as declared in cl-macs:

 (cl-proclaim '(inline cl-acons cl-map cl-concatenate cl-notany
                cl-notevery cl-revappend cl-nreconc gethash))

In 27.1 after expansion only (apply #'seq-concatenate type sequences)
remains bypassing the cl-concatenate autoload which is supposed to load
the dependency seq.el.

Message #8 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1;
 Symbol’s function definition is void:
 seq-concatenate
Date: Sat, 02 Jan 2021 14:47:08 +0200

> From: Leo Liu <sdl.web <at> gmail.com>
> Date: Sat, 02 Jan 2021 20:29:37 +0800
> 
> I have the following macro that is working until 27.1.
> 
> (defmacro cl-concatenatef (type place &rest sequences)
>   `(cl-callf2 cl-concatenate ,type ,place ,@sequences))
> 
> cl-concatenate is inlinable (since forever) as declared in cl-macs:
> 
>  (cl-proclaim '(inline cl-acons cl-map cl-concatenate cl-notany
>                 cl-notevery cl-revappend cl-nreconc gethash))
> 
> In 27.1 after expansion only (apply #'seq-concatenate type sequences)
> remains bypassing the cl-concatenate autoload which is supposed to load
> the dependency seq.el.

What did that expand to in Emacs 26?

Message #11 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Sat, 02 Jan 2021 22:22:35 +0800

On 2021-01-02 14:47 +0200, Eli Zaretskii wrote:
> What did that expand to in Emacs 26?

The body of cl-concatenate before Emacs 27:

(pcase type
   (`vector (apply #'vconcat sequences))
   (`string (apply #'concat sequences))
   (`list (apply #'append (append sequences '(nil))))
   (_ (error "Not a sequence type name: %S" type)))

Message #14 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Sat, 02 Jan 2021 16:25:51 +0200

> From:  Leo Liu <sdl.web <at> gmail.com>
> Cc: 45610 <at> debbugs.gnu.org
> Date: Sat, 02 Jan 2021 22:22:35 +0800
> 
> On 2021-01-02 14:47 +0200, Eli Zaretskii wrote:
> > What did that expand to in Emacs 26?
> 
> The body of cl-concatenate before Emacs 27:
> 
> (pcase type
>    (`vector (apply #'vconcat sequences))
>    (`string (apply #'concat sequences))
>    (`list (apply #'append (append sequences '(nil))))
>    (_ (error "Not a sequence type name: %S" type)))

Thanks.  Then does the patch below fix the problem in Emacs 27.1?

diff --git a/lisp/emacs-lisp/cl-extra.el b/lisp/emacs-lisp/cl-extra.el
index 9c9da4a..a6e6619 100644
--- a/lisp/emacs-lisp/cl-extra.el
+++ b/lisp/emacs-lisp/cl-extra.el
@@ -556,6 +556,7 @@ cl-subseq
 (defun cl-concatenate (type &rest sequences)
   "Concatenate, into a sequence of type TYPE, the argument SEQUENCEs.
 \n(fn TYPE SEQUENCE...)"
+  (require 'seq)
   (apply #'seq-concatenate type sequences))
 
 ;;; List functions.

Message #17 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Sun, 03 Jan 2021 00:07:47 +0800

On 2021-01-02 16:25 +0200, Eli Zaretskii wrote:
> Thanks.  Then does the patch below fix the problem in Emacs 27.1?

Yes it does.

> diff --git a/lisp/emacs-lisp/cl-extra.el b/lisp/emacs-lisp/cl-extra.el
> index 9c9da4a..a6e6619 100644
> --- a/lisp/emacs-lisp/cl-extra.el
> +++ b/lisp/emacs-lisp/cl-extra.el
> @@ -556,6 +556,7 @@ cl-subseq
>  (defun cl-concatenate (type &rest sequences)
>    "Concatenate, into a sequence of type TYPE, the argument SEQUENCEs.
>  \n(fn TYPE SEQUENCE...)"
> +  (require 'seq)
>    (apply #'seq-concatenate type sequences))
>  
>  ;;; List functions.

But it seems the function will become slower when called regularly
because of the (require 'seq).

Is it better to remove cl-concatenate from the cl-proclaim list in
cl-macs.el?

Message #20 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Sat, 02 Jan 2021 18:30:49 +0200

> From:  Leo Liu <sdl.web <at> gmail.com>
> Cc: 45610 <at> debbugs.gnu.org
> Date: Sun, 03 Jan 2021 00:07:47 +0800
> 
> On 2021-01-02 16:25 +0200, Eli Zaretskii wrote:
> > Thanks.  Then does the patch below fix the problem in Emacs 27.1?
> 
> Yes it does.

Then I'd like to push this fix to the release branch, but...

> >  (defun cl-concatenate (type &rest sequences)
> >    "Concatenate, into a sequence of type TYPE, the argument SEQUENCEs.
> >  \n(fn TYPE SEQUENCE...)"
> > +  (require 'seq)
> >    (apply #'seq-concatenate type sequences))
> >  
> >  ;;; List functions.
> 
> But it seems the function will become slower when called regularly
> because of the (require 'seq).

...slightly, yes.

> Is it better to remove cl-concatenate from the cl-proclaim list in
> cl-macs.el?

Wouldn't that make it even slower?  And cause incompatibilities with
already byte-compiled files that saw the original cl-macs.el?

But I'm not an expert on these issues, so I'l defer to Stefan and Lars
here.

Message #23 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45610 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#45610: 27.1; Symbol’s function
 definition is void: seq-concatenate
Date: Sat, 02 Jan 2021 17:35:08 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> But I'm not an expert on these issues, so I'l defer to Stefan and Lars
> here.

Hey, what did I do?  :-)

I think the easiest fix here is to put an autoload cookie on
seq-concatenate.  But there may be something off on the macro expansion
that should be fixed instead, perhaps?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #26 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Sun, 03 Jan 2021 00:45:38 +0800

On 2021-01-02 18:30 +0200, Eli Zaretskii wrote:
> Wouldn't that make it even slower? 

Indeed. But my suggestion to remove it was based on the fact that
cl-concatenate depends on another package at runtime, unlike other items
on that list.

> And cause incompatibilities with already byte-compiled files that saw
> the original cl-macs.el?
>
> But I'm not an expert on these issues, so I'l defer to Stefan and Lars
> here.

I am curious too.

Message #29 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45610 <at> debbugs.gnu.org, sdl.web <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#45610: 27.1; Symbol’s function
 definition is void: seq-concatenate
Date: Sun, 03 Jan 2021 17:46:28 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Leo Liu <sdl.web <at> gmail.com>,  Stefan Monnier <monnier <at> iro.umontreal.ca>,
>   45610 <at> debbugs.gnu.org
> Date: Sat, 02 Jan 2021 17:35:08 +0100
> 
> I think the easiest fix here is to put an autoload cookie on
> seq-concatenate.

Leo, does this work for your use case?  In your opinion, is this
better than my suggestion?

Message #32 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45610 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Mon, 04 Jan 2021 00:19:39 +0800

On 2021-01-03 17:46 +0200, Eli Zaretskii wrote:
> Leo, does this work for your use case?  In your opinion, is this
> better than my suggestion?

Yes autoload works too.

I was hesitant to suggest it because the autoload (cookie) would live
too far away from cl-concatenate.

Message #35 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45610 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Mon, 04 Jan 2021 13:39:03 +0800

On 2021-01-03 17:46 +0200, Eli Zaretskii wrote:
> In your opinion, is this better than my suggestion?

I didn't comment much on this point last night.

Adding (require 'seq) to cl-concatenate is probably the least favourable
because it also defeats the purpose of the `inline' cl-proclaim.

Adding autoload cookie for seq-concatenate is simple though not the
cleanest, IOW, we have the workings of cl-concatenate in some situations
depend on the autoload cookie. But this is not uncommon practice.

Given the dilemma we are in I wonder if the considerations for `inline'
cl-concatenate in the first place are no longer applicable.

Message #38 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: larsi <at> gnus.org, 45610 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#45610: 27.1; Symbol’s function definition
 is void: seq-concatenate
Date: Mon, 04 Jan 2021 17:07:08 +0200

> From:  Leo Liu <sdl.web <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  45610 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Mon, 04 Jan 2021 13:39:03 +0800
> 
> On 2021-01-03 17:46 +0200, Eli Zaretskii wrote:
> > In your opinion, is this better than my suggestion?
> 
> I didn't comment much on this point last night.
> 
> Adding (require 'seq) to cl-concatenate is probably the least favourable
> because it also defeats the purpose of the `inline' cl-proclaim.
> 
> Adding autoload cookie for seq-concatenate is simple though not the
> cleanest, IOW, we have the workings of cl-concatenate in some situations
> depend on the autoload cookie. But this is not uncommon practice.
> 
> Given the dilemma we are in I wonder if the considerations for `inline'
> cl-concatenate in the first place are no longer applicable.

Thanks.

Stefan, any comments?  My personal tendency is to add the autoload
cookie, with a comment saying that cl-concatenate needs that.  At
least on the emacs-27 branch.  Any problems or issues with that?  What
do people think about removing cl-concatenate from the inline
declaration (on master)?

Message #41 received at 45610 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, Leo Liu <sdl.web <at> gmail.com>, 45610 <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function
 definition is void: seq-concatenate
Date: Mon, 04 Jan 2021 12:35:13 -0500

> Stefan, any comments?  My personal tendency is to add the autoload
> cookie, with a comment saying that cl-concatenate needs that.  At
> least on the emacs-27 branch.  Any problems or issues with that?

Sounds good to me.

> What do people think about removing cl-concatenate from the inline
> declaration (on master)?

Fine by me as well,


        Stefan

Message #46 received at 45610-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: larsi <at> gnus.org, sdl.web <at> gmail.com, 45610-done <at> debbugs.gnu.org
Subject: Re: bug#45610: 27.1; Symbol’s function
 definition is void: seq-concatenate
Date: Sat, 09 Jan 2021 14:13:47 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Leo Liu <sdl.web <at> gmail.com>,  larsi <at> gnus.org,  45610 <at> debbugs.gnu.org
> Date: Mon, 04 Jan 2021 12:35:13 -0500
> 
> > Stefan, any comments?  My personal tendency is to add the autoload
> > cookie, with a comment saying that cl-concatenate needs that.  At
> > least on the emacs-27 branch.  Any problems or issues with that?
> 
> Sounds good to me.
> 
> > What do people think about removing cl-concatenate from the inline
> > declaration (on master)?
> 
> Fine by me as well,

I've now done both, and I'm closing this bug.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.