From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Replace trivial pcase occurrences in the Emacs sources Date: Wed, 31 Oct 2018 12:23:23 -0400 Message-ID: <3806f024-c562-150a-99b7-53c9d36824ba@gmail.com> References: <86mur137n8.fsf@gmail.com> <20181029130132.GB4195@ACM> <20181029134722.GC4195@ACM> <83r2g8klf9.fsf@gnu.org> <9bfd9d19-3b6b-57cd-50a0-24660707768b@gmail.com> <20181030181434.GB5705@ACM> <87231bd6-d4a3-e117-06b9-774ec482d62f@gmail.com> <867ehzx9j8.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1541002992 14272 195.159.176.226 (31 Oct 2018 16:23:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Oct 2018 16:23:12 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 31 17:23:08 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHtGq-0003X3-Pb for ged-emacs-devel@m.gmane.org; Wed, 31 Oct 2018 17:23:04 +0100 Original-Received: from localhost ([::1]:60580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHtIx-00063k-7K for ged-emacs-devel@m.gmane.org; Wed, 31 Oct 2018 12:25:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHtHV-00061O-5U for emacs-devel@gnu.org; Wed, 31 Oct 2018 12:23:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHtHR-00069z-W9 for emacs-devel@gnu.org; Wed, 31 Oct 2018 12:23:45 -0400 Original-Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:35040) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHtHR-00061h-OS for emacs-devel@gnu.org; Wed, 31 Oct 2018 12:23:41 -0400 Original-Received: by mail-qt1-x835.google.com with SMTP id a10-v6so17758536qtp.2 for ; Wed, 31 Oct 2018 09:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XolSNI3LxrkrWOi1RXFsBHvrwkvC6sXYIgjIcmLpKIY=; b=CN/ZqAx+Sn682xz93Ecf8uNq6Dt+2w8PSJUF/Cw0a5ROTaZLR12KIzht40uRMx9b4u QngP4lG5vMsFuEVHnO5fycQvky+95WLb7PYy466AsQyFV+PoAdGn/TCA3w653laRAuo+ DO93pMkJ7QpoSJAIVX/xtxRrRB0MVBrisMH4RgjMKXiSsw3sjKZg9scbm+fmQuSraApJ WADD0dOe3rLiIKQpIRNHh5HZ3fxdDQFmzucn4Otqa+9fEGyL9MDX7+102EoPdRIyivGL MHIQM7v03z7jLF+wGEgqn6PIqG5pvKEIvS9MNFwjp4A8KBqKS8Mfh/v73BCZa1HAvEQM DzHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XolSNI3LxrkrWOi1RXFsBHvrwkvC6sXYIgjIcmLpKIY=; b=j/c0YiWu5ED+AYyR1gKvTFHNAcaYSfOtTQKW0E3+Wrp5/OCRqUX6Yt1prg3diNhGQv SNRa8uAYDEpYKx6r6HQfhI46GPMJNj+qCyvNtE/R9Nt9CcS1ZsXOk2uYxVHP/oPLuud7 rSkWLdAgNiHxpc/regF9bvn4a/BCe8LdT382tdiYDDf9kHXGIfK8dPEES28JGtvruzgJ 1h+EUDpq0aXMy0cUxI+l6KDB+ja/gV0iglH6axoCSXFzdr+dhXZuEZumoavMbFfugkSO oFCdjGeGKCIlOiBCrDyrBRJW8jhA8xbSS7Ks/+BJznQTRQuUC+6Df/C/jr8CisURzvjV bCeg== X-Gm-Message-State: AGRZ1gJV1UEH09EcDeCKztcEpQYAGHK+9pHhuRQAqIx3S/XLEpkkY+pO hs/SRf2+yFP7Cv+u3r1fJ0UbOmjS X-Google-Smtp-Source: AJdET5fVSTBJEsJFmHF7eQx28H5bBTimhfv6bNsZszRmmETVMF5kVwp/+PamNAJSjlSI8/ZkcDe3AA== X-Received: by 2002:a0c:f0c2:: with SMTP id d2mr3277875qvl.123.1541003005015; Wed, 31 Oct 2018 09:23:25 -0700 (PDT) Original-Received: from [18.26.2.123] (26-2-123.dynamic.csail.mit.edu. [18.26.2.123]) by smtp.gmail.com with ESMTPSA id b11-v6sm20240491qta.88.2018.10.31.09.23.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 09:23:24 -0700 (PDT) In-Reply-To: <867ehzx9j8.fsf@gmail.com> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::835 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230884 Archived-At: On 30/10/2018 20.08, Andy Moreton wrote: > On Tue 30 Oct 2018, Clément Pit-Claudel wrote: > >> On 30/10/2018 14.14, Alan Mackenzie wrote: >>> Hello, Clément. >> >> Hey Alan :) >> >>> On Tue, Oct 30, 2018 at 11:05:55 -0400, Clément Pit-Claudel wrote: >>>> On 30/10/2018 10.16, Andy Moreton wrote: >>>>> How are users meant to write reliable code using such constructs ? >>> >>>> Ensure that the pattern actually matches :) >>> >>> You mean, unless you can be 100% sure that the pattern will match, you >>> mustn't use pcase-... constructs. That sounds equivalent to saying you >>> shouldn't use these constructs at all. >> >> That's an odd conclusion. > > It is a perfectly reasonable conclusion. Why? A large number of ELisp functions don't say what they do if their argument isn't of the expected type, or doesn't have the expected structure. If you're not 100% sure that the argument has the right type, you shouldn't use them (instead, you should do an appropriate check first). This is not equivalent to saying that they shouldn't be used at all. I don't understand what's so special about pcase-*. Functions like lookup-key or define-key don't tell you what happens if you pass something else that a keymap; does that mean you should never use them? Same for a function like `c-common-init' in cc-mode (the doc doesn't tell you what happens if you pass a symbol that isn't a mode; AFAICT, if you do, you get an error but the current buffer is left in a broken state. This is a pattern across most ELisp functions, really: if you pass them the wrong thing, some do sanity checks and exit cleanly, some exit silently, some raise a seemingly unrelated error, etc. Most of them don't document that behavior (some, like car and cdr, do). If pcase-dolist, pcase-let, or pcase-lambda happen across a value that doesn't match the pattern, they'll typically raise an error; that behavior isn't guaranteed, so you're not supposed to rely on it. The docs point it out. We can debate whether they should be amended to have more predictable behavior in the face of match failures, but it's sounds like a real stretch to conclude that they shouldn't be used at all use them at all. Clément.