From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Attaching context info to an error Date: Wed, 27 Dec 2023 19:27:10 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22396"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 27 20:28:25 2023 Return-path: Envelope-to: ged-emacs-devel@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 1rIZZo-0005d4-RH for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Dec 2023 20:28:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rIZYu-00077k-3L; Wed, 27 Dec 2023 14:27:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rIZYs-00077M-9E for emacs-devel@gnu.org; Wed, 27 Dec 2023 14:27:26 -0500 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rIZYq-0005nP-3w for emacs-devel@gnu.org; Wed, 27 Dec 2023 14:27:26 -0500 Original-Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2cca502e642so48041121fa.0 for ; Wed, 27 Dec 2023 11:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703705242; x=1704310042; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ptHDWTzXiY9ZoGksYvcVhBVrQ6zmBrwyhHjay+6hVKE=; b=dN6WY6f3ebNO48nT9+0kTgndksRwrgJGIYFFajFXIxTdw0VGA8WtV8YY+sjVSu/sRn jUvghvVIgj4/oboMf4cgSLfBQcT0yJKWmnZXrSaghErh8IWDBFCiXBiqRnyvOv4VZdVf Kwj28Sb7vbdsOgJwyZBNElKz180aNYKw+90I0AwUf4S7lecN0N2pz/wbkUTKjDLayEpv +eJMcsmMoqvu9KxEKcjuSP0Juh7OFzJvYWfZGRhx8eIzo28PXIeXFLqdQhPQoqQxFDcU SIJR7Saq0pR8hL3YzxBucXS2EL/fVx/ZkqnbJl1L6Qd4FFQ18dl7EoPK1VO0zyd9TmaZ ZWVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703705242; x=1704310042; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ptHDWTzXiY9ZoGksYvcVhBVrQ6zmBrwyhHjay+6hVKE=; b=j1OQWqQxCVJ9OPBl26TxVCWbylpblkp4LThXHkIQmZ5j5WNt1Q4e22BR6kw1vylwPA Mpl2RTG/I2S+seXKx1nGJHRz2TN49ZxkNsttPVH7JmBDYgZQfiJSjCGp4qEf2vHAcO7U Ca9tvbmm1TQpxxQF1/3ACbqjTyfRFYAeNG8gJ+rXQX6fYZijwiYcgW1Kb61AG1XeQ2AT QOJVid2nhOfa4xUFUiWSYTTCCr1MP/dqETUJqrVYadeqGBmzyCYjMAel6u5d/GP9NnGH e8vT+mh5HpK9yAMMrhNzuKnfPdEJ6vEyVo6+1pjgiDwgtkJPYWvtEfd8TgNpHdfbTDFq Snog== X-Gm-Message-State: AOJu0YwXmkm/XLigDumk8LNIVtOfDQcDFQQC0/skwX407ED56ZnttUq2 jgPrgybiJ51w92Wdn3rIXiWHYZOLKXDBDLo9+cGWi2gur6c= X-Google-Smtp-Source: AGHT+IEuzZLxhZyTSkragMlT1gyKWkT97Dkybidhc51hhGRu/120fr8ivw3WcZzU2m2L9mv6imViMXeYTvTv22N1zBQ= X-Received: by 2002:a2e:888d:0:b0:2cc:ddf3:30ae with SMTP id k13-20020a2e888d000000b002ccddf330aemr320289lji.25.1703705241805; Wed, 27 Dec 2023 11:27:21 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::232; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x232.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314261 Archived-At: On Wed, Dec 27, 2023 at 7:08=E2=80=AFPM Stefan Monnier wrote: > > Just look at anyCL program that uses conditions, there are > > very many of them. One of them is Snooze [1] which uses them > > to represent HTTP error codes. > > But these use error objects throughout. > My question was about "at least supporting EIEIO in this handler-bind". > > > First, we'd have to be able to `signal` such objects. And then, > > CLOS is good :-) you get access to lots of existing useful protocols. > > initialize-instance, print-object, etc for free. > > [ Not clear what `initialize-instance` would be used for. It is passed the keyword arguments that are passed to CL:ERROR or CL:SIGNAL [1,2]. Though, I've noted before how our initialize-instance protocol is inferior: It takes slots as its second argument, whereas is should take initargs instead. This makes changing the representation without changing the interface hard, but that can be worked around with the slot-missing protocol. > I also don't > think `print-object` would be super useful, It's useful when printing the human-readable error message isn't appropriate say, because it takes multiple lines. > More importantly, that doesn't tell me what new things we could do, > most importantly how to attach context info :-) You can modify a condition object like you can any other object. > > From a CL perspective, and even other languages, using our > > "error symbol with some 'error property" representation of > > errors is almost self-evidently inferior to just making it > > a first class object. > > You don't need to convince me of that, indeed. But that's not what we > have right now, and it's not trivial to retro-fit it cleanly in the > current system. Luckily, AFAICT it's orthogonal to `handler-bind`. AFAICT CL:HANDLER-BIND is aware of inheritance [3], i.e. the things you put in "type" of each handler binding in CL:HANDLER-BIND are interpreted as designators of subclasses of CL:CONDITION and dispatch similarly to generics. That shouldn't be too hard to fit if we say `cl-condition` is the base class and `cl-error` and `cl-warning` are its children, etc. Jo=C3=A3o [1]: https://cl-community-spec.github.io/pages/signal.html [2]: https://cl-community-spec.github.io/pages/error.html [3]: https://cl-community-spec.github.io/pages/handler_002dbind.html