From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.bugs Subject: bug#47368: 28.0.50; map-elt returns nil without "deprecated" TESTFN Date: Fri, 26 Mar 2021 08:38:24 +0100 Message-ID: References: <87sg4kyw1q.fsf@tcd.ie> <87lfacvtwt.fsf@web.de> <87blb6h8f2.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a5b12905be6b9e6e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3703"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Stefan Monnier , 47368@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 26 08:39:09 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lPh3l-0000t3-IF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Mar 2021 08:39:09 +0100 Original-Received: from localhost ([::1]:60840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPh3k-00074y-Kn for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Mar 2021 03:39:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51994) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPh3d-00072v-V2 for bug-gnu-emacs@gnu.org; Fri, 26 Mar 2021 03:39:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56946) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lPh3d-00058F-O5 for bug-gnu-emacs@gnu.org; Fri, 26 Mar 2021 03:39:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lPh3d-0001QD-Lm for bug-gnu-emacs@gnu.org; Fri, 26 Mar 2021 03:39:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Mar 2021 07:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47368 X-GNU-PR-Package: emacs Original-Received: via spool by 47368-submit@debbugs.gnu.org id=B47368.16167443235440 (code B ref 47368); Fri, 26 Mar 2021 07:39:01 +0000 Original-Received: (at 47368) by debbugs.gnu.org; 26 Mar 2021 07:38:43 +0000 Original-Received: from localhost ([127.0.0.1]:40259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPh3K-0001Pg-OA for submit@debbugs.gnu.org; Fri, 26 Mar 2021 03:38:43 -0400 Original-Received: from mail-vs1-f49.google.com ([209.85.217.49]:42577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPh3J-0001PT-RK for 47368@debbugs.gnu.org; Fri, 26 Mar 2021 03:38:42 -0400 Original-Received: by mail-vs1-f49.google.com with SMTP id b5so2240481vsl.9 for <47368@debbugs.gnu.org>; Fri, 26 Mar 2021 00:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W/GSYOtZ32UuETsUaHDNh7p3PJZmV1k+b2mI4L0SES4=; b=UD+FlKnelnAHwxSvf/N9Y2dKOw4q3IJc0Vx4pdweOTHUSjx143atzhQ/3TvFMd3toK RePwGWhyA3gn35WFek2uXkBdIRHzzqpsy2HJYz3P/zBA9ulz2TXlyxI+kS/dT0X9NYiz GL1HDOdIBVSCkHyxqxJitpuh0qf+IdZoH4AmuVF4Gj/JBCqdA1AVBs8sT1JVNthwrcoD r+lU2KRIzRcmYtjSP1Wwt9sh4szyczMrxQSAfxmLbv0PLLfyMtdHghTmt/vZhZBnWLlz AP0mk6cw57TXMv2s5chz6WJ3s9XTdrTjB/d0w7LqHHdFfOsIME1CG3jmFo8Q1NfvJgdW TafA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W/GSYOtZ32UuETsUaHDNh7p3PJZmV1k+b2mI4L0SES4=; b=UL2apiTHqBcSzF2Vs0ffB1jQGj+OvVnBQl71Qb7Dc8udjDYfUPRo1VfIzkx6NikLDh vtsOAkeKSFl6LtmZyYzF2IVDJUnOx58ZQyCKT62QVIT4GrfJR7DS4R/dJ3XkP+lk505A gJYlZXZ9w+BM0lmCDwV4zucVSHW5MHFei7ipkOkEvs51PrGZ+OQaQ/Pa9edb0fT4QEe7 TDHiCYNxurK4MzBpKYBwxCC3aeB4Ls/qUfXCkaPKDXJwXlDIWCIwaPXfvUolU0f7is4D JGx+q8njfms31ws/GZAFQWUA4iMxvHAb1s9XlI/yPYxcypZ+VPb97ChLOMXsZrS9rRwa 4xJA== X-Gm-Message-State: AOAM5324d/5ieAKVIVE5hhG4Z7eEqCqiI2uMWpK0K3kMB/V8+kdOn9Qu vigmRQ51ORs0HS8SBie1vkHjIjPctYBvWR+PUEY= X-Google-Smtp-Source: ABdhPJwagcIQNYtd/a605vzyMts0AU8iN3RuGhMMndAg6ZfWk8myPrGPcxktafP064CbGzyZ69peQBCPfvlHSLwokqg= X-Received: by 2002:a67:c209:: with SMTP id i9mr436403vsj.8.1616744315988; Fri, 26 Mar 2021 00:38:35 -0700 (PDT) In-Reply-To: <87blb6h8f2.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203035 Archived-At: --000000000000a5b12905be6b9e6e Content-Type: text/plain; charset="UTF-8" You probably already noticed it, but I only notice just now that the TESTFN option also has been removed from the calling convention with `(advertised-calling-convention (map key &optional default) "27.1")`. (Just to add to my previous answer) On Fri, 26 Mar 2021 at 04:59, Michael Heerdegen wrote: > Hi Stefan, > > we are discussing here the limitation for `map-elt' calls with alists > caused by deprecating the TESTFN argument (done by you a while ago). > > What's a good way to solve this? Obviously the map abstraction doesn't > fit so super well for alists because unlike the other map type alists > don't know "their" test function. But disallowing alists that don't > test with `eq' seems an unnecessary restriction. Can we say that the > argument is allowed only for alists? > > Regards, > > Michael. > > > I wrote: > > > > > The docstring of the map-elt function from the map.el package > (version > > > > 3.0) mentions that TESTFN is deprecated because "its default depends > on > > > > the MAP argument". However when I try e.g. > > > > > > > > (map-elt '(("A1" . 3)) "A1") > > > > > > > > it returns nil. > > > > > > This is expected, as alist keys are tested with eq by default. > > > > > > That's what the docstring is trying to warn about: alists default to > > > testing with eq, but can also use eql, equal, or anything else. > > > > Is it that obvious? We have `assoc' and `assq' built-in - to me it's > > not obvious that "alist keys are tested with eq by default". It's the > > default for `alist-get', ok, which is used by the implementation, but > > not everybody will know that. I would add a sentence about that. > > --000000000000a5b12905be6b9e6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You probably already noticed it, but I only notice ju= st now that the TESTFN option also has been removed from the calling conven= tion with
`(advertised-calling-convention (map key &optional= default) "27.1")`. (Just to add to my previous answer)
=

= On Fri, 26 Mar 2021 at 04:59, Michael Heerdegen <michael_heerdegen@web.de> wrote:
Hi Stefan,

we are discussing here the limitation for `map-elt' calls with alists caused by deprecating the TESTFN argument (done by you a while ago).

What's a good way to solve this?=C2=A0 Obviously the map abstraction do= esn't
fit so super well for alists because unlike the other map type alists
don't know "their" test function.=C2=A0 But disallowing alist= s that don't
test with `eq' seems an unnecessary restriction.=C2=A0 Can we say that = the
argument is allowed only for alists?

Regards,

Michael.


I <michael= _heerdegen@web.de> wrote:

> > > The docstring of the map-elt function from the map.el packag= e (version
> > > 3.0) mentions that TESTFN is deprecated because "its de= fault depends on
> > > the MAP argument". However when I try e.g.
> > >
> > > (map-elt '(("A1" . 3)) "A1")
> > >
> > > it returns nil.
> >
> > This is expected, as alist keys are tested with eq by default. > >
> > That's what the docstring is trying to warn about: alists def= ault to
> > testing with eq, but can also use eql, equal, or anything else. >
> Is it that obvious?=C2=A0 We have `assoc' and `assq' built-in = - to me it's
> not obvious that "alist keys are tested with eq by default".= =C2=A0 It's the
> default for `alist-get', ok, which is used by the implementation, = but
> not everybody will know that.=C2=A0 I would add a sentence about that.=

--000000000000a5b12905be6b9e6e--