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: Thu, 28 Dec 2023 23:53:01 +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="11405"; 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 Fri Dec 29 00:54:19 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 1rJ0Ch-0002iz-5k for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Dec 2023 00:54:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJ0Bk-0002lO-Iz; Thu, 28 Dec 2023 18:53:20 -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 1rJ0Bi-0002l8-BE for emacs-devel@gnu.org; Thu, 28 Dec 2023 18:53:18 -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 1rJ0Bg-0005lK-HP for emacs-devel@gnu.org; Thu, 28 Dec 2023 18:53:18 -0500 Original-Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2cce70ad1a3so10320361fa.1 for ; Thu, 28 Dec 2023 15:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703807594; x=1704412394; 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=Kv7zilmF5z8VL7p32LCMdR+NzwepRtnC1l68aTCU7q0=; b=PrutatNOIqQRL5s7r7v8g+l8mkpkcRlmclO7H5rptuIpgcvB3ykZfD5rUv8Yhj85IA 4wTQ2jc2ejh+2nN82UWDBm5mjNm18ArRfno45iqdQBXIjIHVm5+fjgK8ZKEp7GBPBCey EWZTlp/Wsr29ErGU5ASRzSBTdJRcq93ASs7EEKOyqoq9MAzBTA5lxlC37RlmKbZZsa7G vbyhLXTGbd/8N4foGCIzKmG3Ie7ZIj8+kROJaj7Ix0AMZpjo+grQMd6lu6R0g3zdoIl2 iI1tjsqvnGzVFk8vF+/akcD5NIwth+pF7fFNzWv9htj9WbHelmZOs9GugBC3RICi0lpW fhWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703807594; x=1704412394; 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=Kv7zilmF5z8VL7p32LCMdR+NzwepRtnC1l68aTCU7q0=; b=QasrDLTPOgEbQALWXHHhMS7P3N60XAImMWOGHfj5ZhdBAcA6Hz20wZiMWR29YI/nIz F4tSgvqBwt3VZftkJk+sadUMyZX2zwutW4FaFPTjvxOQueAm8kElkv18XFPR8oHCVzVm JjGhxGwUorxcqfM8lOfJQnD0SwaD67238rBp/JqFtBnXa7S9k2b/ynybNchkQlja1X/z 2hspeaLoxXUHdEmnpBr1JfTpCao9LBOX9qrYKR5gpNwBUSq+n79FjdKs7FMn7HPpCHDb qxIDuWkNUpCoewvkOONGPuYQ1f3jSZlpbkWxKzpWprcUuYu9nYvzwrAnGTDsZ3CDplCl QP5Q== X-Gm-Message-State: AOJu0Yy16NIrLIW1o5SGtcxR0LLrtO2iGY/nnZqsvoY0WfzJKpsuH9UM u0Xglhws7brO+f8zk9fbnPzSaC5xYMlcwSYnOILunF2G X-Google-Smtp-Source: AGHT+IFDqeTdh+61W3OJpxK0/viQ1j3E9VsYfT8bqMYiE3aAnIvwkpZh/U7aB7HWyaoGkwGLiYAfxq5pPCAq671UjrQ= X-Received: by 2002:a2e:870e:0:b0:2cc:53a9:b6f with SMTP id m14-20020a2e870e000000b002cc53a90b6fmr5418199lji.21.1703807593859; Thu, 28 Dec 2023 15:53:13 -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:314294 Archived-At: On Thu, Dec 28, 2023 at 7:22=E2=80=AFPM Stefan Monnier wrote: > > > Just see eglot.el and jsonrpc.el for examples. It's a constructor > > in the C++ style. Meaning the client of the library, when making > > an object, won't get just a bunch of data. They will either > > get a fully functioning object _or_ an error. You can't do that > > in plain Elisp without "-init" custom constructors, just as > > you can't do that in C without foo =3D (Foo*)malloc() + init_foo(foo). > > Not sure where using a "smart constructor" function (what you call > "-init" custom constructor) is less work than defining > a `initialize-instance` method. That's right! It isn't, it's more work, and more dangerous because you will forget when to call it. > > Furthermore, just like in typical OO, derivation of such classes > > are guaranteed to have the base class parts valid and constructed > > in their `intialize :after` this is the bread and butter of CLOS, > > and it's awkward and error-prone to program without it. > > Ah... I think I'm beginning to see why I don't see the benefit: in my > world, objects are basically immutable, so an object that's partly > initialized (as in your "have the base class parts valid") is just > already very weird :-) It's not weird. If D derived from B then the object that is passed to the derived mode's contructor is already a fully functioning B. This is exactly as in C++ where at least that part is bullet proof. Not so in C and plain Elisp where allocation is one thing and initialization another thing. > > Right, it's because I _know_ that you wrote these things that I find > > it odd you do now see how useful they are. > > There's a difference between knowing how to build a car and being > a good driver, yes. > > I can write a Prolog interpreter but my Prolog programming skills suck. > Similarly, I'm more comfortable using Haskell-style type classes (or > the closely related C++ templates) than "classic OOP" with subtyping. Many modern C++ template tricks are done using inheritance, std::tuple comes to mind. "Classic OOP" is about runtime polymophism/virtual dispatch and yes it's seen better days in the systems programming world, because the indirection usually trashes caches and double dispatch is silly hard. But for sporadic exceptions/conditions with objects generic functions that to multiple dispatch beautifully? I'd be hard pressed to see better than what CL has. > >> Redefinition of a class is definitely not currently supported (with no > >> plan to support it in the foreseeable future). > > In this case, it was a new version of jsonrpc.el that has to > > be backward compatible to clients programming against the older > > version. > > Then your bug report would be a feature request, I guess. It's a bug inasmuch as EIEIO purports to be a port of CLOS, where it's easy to do. I don't need any class redefinition support. The recipes I gave earlier would be easy to replicate even if both CL didn't support such trivial things. > E.g. include a small patch to `jsonrpc.el` showing the code > you would *like* to use. I'd just like to remove the horrible slot-missing hack, it's clearly marked in jsonrpc.el, just search for "Yuck!". > > CLOS class redefinition is big business indeed, but just removing > > a slot here in the same image worked nicely here for demonstration > > purposes: it still errored as reassuringly as it would have if in > > another Emacs session. > > Yes, I'm aware of this. > But ELisp is a fairly limited "programming system" (as opposed to > programming language", see doi:10.1145/2384592.2384611). > > I'm a PL guy and one from the functional programming side (i.e. averse > to mutation) to boot, so redefining the classes of existing objects > makes my head hurt. Mine too, in fact in many years of CL I've not seen a single case of useful CHANGE-CLASS. But Emacs and Lisp machines are designed as object landscapes mutating all the way. Anyway, this is all besides the point: that protocol has nothing to do with the current limitations of EIEIO's initialize-instance, and even those limitations are quite small in comparison to the benefits. I see you've snipped all the rest of the "where to keep the context" discussion. Does that mean that my answer of "stack _is_ the context, unwind only when absolutely done with it" is satisfactory? Did you understand how a standard named restart for reporting byte compiler errors could be invoked from "up above"? What object exactly goes into the handler bind handlers? Is it the funny cons? Can we at least get some generic functions to hide that representation so that we can change it later on? Jo=C3=A3o