From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Sv: Is this a bug in while-let or do I missunderstand it? Date: Sun, 10 Nov 2024 18:18:14 +0000 Message-ID: References: <86ldxrliau.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_DU2PR02MB10109D7B9849395DD5BDEC488965F2DU2PR02MB10109eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27300"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "ams@gnu.org" , "yuri.v.khan@gmail.com" , "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 10 19:45:30 2024 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 1tACwD-0006yI-RN for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Nov 2024 19:45:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tACva-00038o-CV; Sun, 10 Nov 2024 13:44:51 -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 1tACW1-00006m-MT for emacs-devel@gnu.org; Sun, 10 Nov 2024 13:18:25 -0500 Original-Received: from mail-vi1eur05olkn2107.outbound.protection.outlook.com ([40.92.90.107] helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tACVz-0005GB-0r; Sun, 10 Nov 2024 13:18:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=J6JD/ZYf+/RIIXmkHGdjd1u0ud6E4MKcfMEjsKQ4nTmeKWNF1eVlU/v1LDhm8xPWxudw6ZlyBIq2Vo9b/CULFunb3f6scegaBOpU6mo4QR6lqyK6hmxyrMAavtFSPlxYeB2Up0VwA6W/EM6sYSDrGFbhuGpd/Z9k8tirbkmDTQA8mMk/bJrp72del/lYM0GKYyigLxIuLPsTBaKGOGWAqtx7+wunwPBpN2piRG560AneLlX0QHRuKFA+y4x5QmH7x3PaGk5ZdXO4mnydVAZIR5d8cdMPyL1ys2FYPj79u9/xmZANhdlR2D/U+VDmgQN24psY0WaZ1dl490Ds4eUAxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DmEoaNDsd0qlacAAQiBdpuDs91+04/Z6QSUvG39hlQ0=; b=u8muuaqOek8ePz3+OnOawNRRlQ4updoB0qCjXwBVwnv8e/zZiBDEeWF7gmNmCILLKBocgKp6u4AG2zOrj9Q8ZY/+L9aFecc9BZB0wtyIt/iuEKYhlBK9j0SjUp7P/y7qi5EFW3iOKtgQCOT8xOWENviEClNkzxOqok9HC9mVsXg5t3wfdxLPOxjP0JMj2dj9lDADTKNclNjyea/j3wfQwQj3yE7RtkJZh3UR+ObQyqOWMatCSrF9Kp65t6efkUiB1FtvH0lSYMklZrLVj0LQsjeSxVcM5idW2HsrGY/6a7rqu1n9aZ+MiUbvp7ofM3dolcUJ15G6GgzWRUoj9LaHiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DmEoaNDsd0qlacAAQiBdpuDs91+04/Z6QSUvG39hlQ0=; b=GQ5Cx74F0r69qJGt7tyqH2XkqtWvmekex3d8b1Qvm4PNj8Gcjvj7bhCywp4qbvgp1v4Hjsql41PUTypTGhaqyxPnEST/kJEAKBwHw7U2BpdEy6eDtqbvxt+3hROxPhDqUJTqqZadggwG0d4kVLrmz/wwtM3pd4IHJksaS/8YdIZo92T/aPektNIp5UVHJQZQvqgfNahGM5xxM2ZbnbMZFWtYRJJ7x3/f2rCxHWMCt0Ye407BElR0yfKVWMrzYSpjqV3NQjr/GXo/2A/kjy/pMT6p6oG1sR/EoUXk6rv/aji+uKKSZxv2u/6ayTExk7mGQ2X2gPGS8eNaFdTtDw9KvA== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by DB8PR02MB5833.eurprd02.prod.outlook.com (2603:10a6:10:fa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8137.26; Sun, 10 Nov 2024 18:18:15 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487%4]) with mapi id 15.20.8137.027; Sun, 10 Nov 2024 18:18:14 +0000 Thread-Topic: Is this a bug in while-let or do I missunderstand it? Thread-Index: AQHbMfbIoZNom93mHkmQsSTvSCnRb7Kur/AAgAA0XUGAAAq2gIAAAU7JgAAF/YCAAAA4e4AABg0AgAApz0+AAEHNJ4AApbaGgADFQ+o= In-Reply-To: <86ldxrliau.fsf@gnu.org> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU2PR02MB10109:EE_|DB8PR02MB5833:EE_ x-ms-office365-filtering-correlation-id: 381a0ede-257c-42fd-2582-08dd01b40b0c x-microsoft-antispam: BCL:0; ARA:14566002|461199028|8062599003|8060799006|15030799003|19110799003|7092599003|15080799006|440099028|3412199025|102099032; x-microsoft-antispam-message-info: =?iso-8859-1?Q?QSpdJDn9iLxgH01wX30Dz1OZECJO9x675eg67uKneyMb4I6Ik4fs6F46Nz?= =?iso-8859-1?Q?nvYIGyRN6zWwxJwUjAlYsmyVoqnAmx55S3Yy5o+LpiVP+PbI4G1AA3DGO2?= =?iso-8859-1?Q?ijvlXQwFZGmMA5GjF1LsF5A7YriqyllIJOo1zO6v4Bx+RuPoa93nZZcFGh?= =?iso-8859-1?Q?e75DEdAxE1+H/GltvUyfr1wj9Y/6N2bFTt19R2IHDazWuUNPWbZ8bM1qYO?= =?iso-8859-1?Q?2hNRvAzaJ7oG4fVXPCWvtc9pBiGPdY5tiDmqbzpolT0uyiNKz6OWCtET0Z?= =?iso-8859-1?Q?jJaq+TyezBz2SIYUBFMSNg4F9/gTU1TS1LkoPLvAwv5al6qzNL30DjLTwN?= =?iso-8859-1?Q?/jqyDwcOUIatLogatrZtkuymtMw+XZjuL8kj8C2JVjzk3gV1ZWgDLDIMg9?= =?iso-8859-1?Q?D9GNtoE7gMEBQJUkcT78FgqDj4eHxQ8UzDQ1PKfhA6WxWiRiIZc2oMO1Ra?= =?iso-8859-1?Q?NcyfPoM3Q3IS2x7RE2v9aMJAxI9qQUhP5ledxZwZIztDgmG1JBRSV0sFA9?= =?iso-8859-1?Q?HHAiWqqaVw9kl5cJ3ghbvqBUzXj0206PyzDTP9Iy1Dvjvrcjbmx6LMLH1m?= =?iso-8859-1?Q?m5u5Z5Ury4pAmyEkqa8bb3KprNmU9Q/YmKXFLqOaLhscLOaQ3P25RfCb37?= =?iso-8859-1?Q?WGr x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?RgzvR96ww9NTYtIFPfz+XN/YXcMgOt1goSKrj32yvuEFUd9GPP3p+A1iZS?= =?iso-8859-1?Q?Rpl1HvN21WF4RqzPIfv5koTVoo/dVe9v/UCuo+wtpMPG79KBTYEmOi2vh2?= =?iso-8859-1?Q?5n0Ddv6hP5/pwr2Heh48iezBD/dYKOSXTjxVHZsWWJqzHA1EAalu6uILfD?= =?iso-8859-1?Q?nHu3NAeQ180jtY1wi1Ax6DKiGdVn6Bkbofl5FE6Bdr4bf0ApEgJoqWlc9H?= =?iso-8859-1?Q?BqRXVW7W4aNp7wTdjHvlC0Yi+pObuzPVrZGeWiSF97GMEwdZvukUU6TZEA?= =?iso-8859-1?Q?EUQZzhpcDPnRqkcrrx780hP8Nu3yZufnHSutnjRF7NmJBXWPJ8YLmlHBwg?= =?iso-8859-1?Q?XeIoya1yD2RpobwCI79ArIUemCrYomLRasRlSExFrjSFSvR7At1dEUalxe?= =?iso-8859-1?Q?aYAgi8gGsqTrSn1avkHvLjrm2Bbl9JqzrhTyWfHaUwQZV3haLkAnKXILP8?= =?iso-8859-1?Q?RlukwdVIrMOF06fXA+TmLdmmDo+zC3hwmpKONLjYl0VuJDsmr7H2e9wtxb?= =?iso-8859-1?Q?TVVRNAyesBbGP0jWyKDmxKHKFutijUqZ3nBjJaLhtdQrZ8/YLJom09TPSJ?= =?iso-8859-1?Q?psUGfn006nMpELTWEzJU+laTEVjFGP2vNxO9cDPC5XNd2X9bOBolzsufOw?= =?iso-8859-1?Q? X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 381a0ede-257c-42fd-2582-08dd01b40b0c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2024 18:18:14.7077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5833 Received-SPF: pass client-ip=40.92.90.107; envelope-from=arthur.miller@live.com; helo=EUR05-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.743, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 10 Nov 2024 13:44:47 -0500 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:325382 Archived-At: --_000_DU2PR02MB10109D7B9849395DD5BDEC488965F2DU2PR02MB10109eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> From: arthur miller >> CC: "emacs-devel@gnu.org" >> Date: Sat, 9 Nov 2024 20:29:29 +0000 >> >> In other words, there might be variables live outisde of >> the loop-scope we wish to access in the loop, and that is >> what Yuri's example shows. However, i,j are not re-initiated >> on each iteration, but remembers their value. The effecto of >> while-let in current implementation is that i,j are re-initiated >> in each iteration, not re-evaluated, if that makes it clear. >> >> I am not sure how to illustrate in a better way. The net effect is >> that lexical variables declared in while-let loop are "read-only". >> >> They are not, but since they are re-iniated, it is pointless to >> write to them. > >You can write to them indirectly, if the evaluation is properly >written. If the evaluation is just assigning a fixed value to a >variable, then yes, writing to that variable in the body is pointless; >but then so is the use of while-let, IMO. That depends how you define the while-let semantics of course. >Even in your for-loop example from C, the CONDITION part of the loop >is re-evaluated on each iteration, and if you assign some fixed value >to the loop control variables there, your loop might become an >infloop, regardless of what you do in the body with those variables. Infloops are not in question here, since they are results of a programmers misstake. The job of for-loop in C or while-let in Emacs is not to ensure always terminating loop. >That's basically what the example of while-let you show at the >beginning of this discussion did. As I understand it now, Emacs while-loop is a unique kind of loop, at least I have never seen a construction with such semantic before. The semantic of while-let in Emacs is that of for-loop or while-loop in C++, but where initialization of loop variables happens on each iteration for (int i=3D0; i Skickat: den 10 november 2024 07:22 Till: arthur miller Kopia: ams@gnu.org ; yuri.v.khan@gmail.com ; emacs-devel@gnu.org =C4mne: Re: Is this a bug in while-let or do I missunderstand it? > From: arthur miller > CC: "emacs-devel@gnu.org" > Date: Sat, 9 Nov 2024 20:29:29 +0000 > > In other words, there might be variables live outisde of > the loop-scope we wish to access in the loop, and that is > what Yuri's example shows. However, i,j are not re-initiated > on each iteration, but remembers their value. The effecto of > while-let in current implementation is that i,j are re-initiated > in each iteration, not re-evaluated, if that makes it clear. > > I am not sure how to illustrate in a better way. The net effect is > that lexical variables declared in while-let loop are "read-only". > > They are not, but since they are re-iniated, it is pointless to > write to them. You can write to them indirectly, if the evaluation is properly written. If the evaluation is just assigning a fixed value to a variable, then yes, writing to that variable in the body is pointless; but then so is the use of while-let, IMO. Even in your for-loop example from C, the CONDITION part of the loop is re-evaluated on each iteration, and if you assign some fixed value to the loop control variables there, your loop might become an infloop, regardless of what you do in the body with those variables. That's basically what the example of while-let you show at the beginning of this discussion did. > Of course, all loop predicates should be evaled on each iteration, > but not re-iniated on each iteration. If that makes sense. Sorry, > I am not very good at writing. If while-let doesn't seem to do the job in some code of yours, then don't use it there. Use something else. AFAIU, while-let was introduced for those cases where its use makes sense and does the job cleaner and clearer than the alternatives. It could be abused, of course, but that's not necessarily its fault, is it? Anyway, to get this long discussion back on track: is there a need to clarify something in the documentation of while-let? if so, what? --_000_DU2PR02MB10109D7B9849395DD5BDEC488965F2DU2PR02MB10109eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>> From: arthur miller <arthur.miller@live.com>
>> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Sat, 9 Nov 2024 20:29:29 +0000
>>
>> In other words, there might be variables live outisde of
>> the loop-scope we wish to access in the loop, and that is
>> what Yuri's example shows. However, i,j are not re-initiated
>> on each iteration, but remembers their value. The effecto of
>> while-let in current implementation is that i,j are re-initiated
>> in each iteration, not re-evaluated, if that makes it clear.
>>
>> I am not sure how to illustrate in a better way. The net effect is=
>> that lexical variables declared in while-let loop are "read-o= nly".
>>
>> They are not, but since they are re-iniated, it is pointless to
>> write to them.
>
>You can write to them indirectly, if the evaluation is properly
>written.  If the evaluation is just assigning a fixed value to a
>variable, then yes, writing to that variable in the body is pointless;<= /div>
>but then so is the use of while-let, IMO.

That depends how you define the while-let semantics of course.

>Even in your for-loop example from C, the CONDITION part of the loop
>is re-evaluated on each iteration, and if you assign some fixed value
>to the loop control variables there, your loop might become an
>infloop, regardless of what you do in the body with those variables.

Infloops are not in question here, since they are results of a programmers<= /div>
misstake. The job of for-loop in C or while-let in Emacs is not to ensure
always terminating loop.

>That's basically what the example of while-let you show at the
>beginning of this discussion did.

As I understand it now, Emacs while-loop is a unique kind of loop, at least=
I have never seen a construction with such semantic before. The semantic
of while-let in Emacs is that of for-loop or while-loop in C++, but where
initialization of loop variables happens on each iteration

    for (int i=3D0; i<some_bound(); i++) {
        we can read i here, but
        we can't write to it
    }

Since re-initialization is happening on each iteration, as you say we have<= /div>
to go via a third variable (or a function), and the variable must not be sh= adowed
by the local binding established by while-let spec. That does make while-le= t
pointless to use for not so unusual idiom in other languages:

(let ((run t))
  (while run
     ...
     (when (some-condition)
       (setf run nil))))

I personally would expect to be able to write:

(while-let ((run t))
  ...
  (when (some-condition)
  (setf run nil)))

Since while-let was supposed to simplify that case, but that wont work :).<= /div>

So obviously I did missunderstood how while-let works, but I would say the<= /div>
semantics are bit arcane. I haven't seen any other language with read-only<= /div>
semantic for loop variables.

Somebody said in another mail that bindings are conditions. I think it is a=
good illustration of while-let bindings, but it perhaps does not catch the<= /div>
fact that they are not used as ordinary lexical bindings strongly enough, s= o,
perhaps a mention about not being settable from the loop is in order?

That would also be my answer for the question in another mail about what
to add to docs. Also perhaps mention t= hat the way out of that loop is to either 
go via an implicit variable, or to use try/catch or cl-block/cl-return-from= to 
break out of the loop.

As a remark:

Perhaps while-let is a wrong name for this construct to start with. It beha= ves
more like for-loops, but with a twist. Typically in C/C++ and derivatives, = we
can't introduce a variable in while condition: while (int i =3D some_var ) = is not
legal. 

Since those bindings are not settable in loop body; they really are conditi= ons,
perhaps while* is a better name for this construct, since it introduces
multiple conditions. But it is not good either, since this construct is rea= lly
somewhere in-between a while and for loop from other languages.





Fr=E5n: Eli Zaretskii <e= liz@gnu.org>
Skickat: den 10 november 2024 07:22
Till: arthur miller <arthur.miller@live.com>
Kopia: ams@gnu.org <ams@gnu.org>; yuri.v.khan@gmail.com <yu= ri.v.khan@gmail.com>; emacs-devel@gnu.org <emacs-devel@gnu.org> =C4mne: Re: Is this a bug in while-let or do I missunderstand it?
 
> From: arthur miller <arthur.miller@live.co= m>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Sat, 9 Nov 2024 20:29:29 +0000
>
> In other words, there might be variables live outisde of
> the loop-scope we wish to access in the loop, and that is
> what Yuri's example shows. However, i,j are not re-initiated
> on each iteration, but remembers their value. The effecto of
> while-let in current implementation is that i,j are re-initiated
> in each iteration, not re-evaluated, if that makes it clear.
>
> I am not sure how to illustrate in a better way. The net effect is
> that lexical variables declared in while-let loop are "read-only&= quot;.
>
> They are not, but since they are re-iniated, it is pointless to
> write to them.

You can write to them indirectly, if the evaluation is properly
written.  If the evaluation is just assigning a fixed value to a
variable, then yes, writing to that variable in the body is pointless;
but then so is the use of while-let, IMO.

Even in your for-loop example from C, the CONDITION part of the loop
is re-evaluated on each iteration, and if you assign some fixed value
to the loop control variables there, your loop might become an
infloop, regardless of what you do in the body with those variables.
That's basically what the example of while-let you show at the
beginning of this discussion did.

> Of course, all loop predicates should be evaled on each iteration,
> but not re-iniated on each iteration. If that makes sense. Sorry,
> I am not very good at writing.

If while-let doesn't seem to do the job in some code of yours, then
don't use it there.  Use something else.  AFAIU, while-let was introduced for those cases where its use makes sense and does the job
cleaner and clearer than the alternatives.  It could be abused, of
course, but that's not necessarily its fault, is it?

Anyway, to get this long discussion back on track: is there a need to
clarify something in the documentation of while-let? if so, what?
--_000_DU2PR02MB10109D7B9849395DD5BDEC488965F2DU2PR02MB10109eu_--