From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Damien Mattei Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed) Date: Mon, 22 Jan 2024 00:21:47 +0100 Message-ID: References: <87h6w2fkz8.fsf@web.de> <87v8jrdmk5.fsf@web.de> <87jzzr7cba.fsf@web.de> <87v8hc8i8v.fsf@web.de> <87legrs23a.fsf@gnu.org> <209e68fd-b010-8213-6c9b-a0d1b8f0f72c@telenet.be> <87o7jf2slw.fsf@web.de> <875y5h8j04.fsf@web.de> <87il9ctzhl.fsf@gnu.org> <875y5cdyvt.fsf@web.de> <87sf7omuag.fsf@web.de> <877co1jgww.fsf@web.de> <875y3egjtd.fsf@web.de> <87sf5v67k5.fsf@web.de> <87mstf9e67.fsf@web.de> <340c71c5-9e25-d622-8b24-9c18ea373a77@mutix.org> <877ck5t370.fsf@elephly.net> <22ec8c54-fca0-b797-9c03-f2cc461dea6a@mutix.org> <87le8j4vly.fsf@web.de> <878r4j4mht.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e32ce0060f7cfa19" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org To: "Dr. Arne Babenhauserheide" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Jan 22 00:22:41 2024 Return-path: Envelope-to: guile-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 1rRh9F-0006qx-3J for guile-devel@m.gmane-mx.org; Mon, 22 Jan 2024 00:22:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRh8h-0004o2-Gl; Sun, 21 Jan 2024 18:22:07 -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 1rRh8f-0004nr-Jc for guile-devel@gnu.org; Sun, 21 Jan 2024 18:22:05 -0500 Original-Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rRh8d-0006h9-Dv for guile-devel@gnu.org; Sun, 21 Jan 2024 18:22:05 -0500 Original-Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-55790581457so3306073a12.3 for ; Sun, 21 Jan 2024 15:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705879320; x=1706484120; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UsXccw5xj45Tro9ZXBRJoriwhYKn5Zeqju+OeFJGBwM=; b=UELkkqAapf+ZbXwiq0qGC2yRvLc3UeQ75gpNbZBrzJvFoxvxmFpdDLmKJNpKRYATip YS3D5w/xbVEiA95FDt1QIWJ+jXMW7CL/+cjJDzBmFggZQL4WgQDJAfp5inHnzxCnp3Dh xIe0IUEjK9YlrDltBZIEVMLR7sh7EyP2Mmhl1bBsx6YIFSeVA2D7EtLfD5jP7E+wvXJQ IEkPUKp6SxxVA6lnPUKy1sJ9tvBgUFacJJrxQ9psclWA5A+1wa5wYaJtl+ypi1ArSvSG sGLJvLF/czWMMZfxRShaq9xMlo6B4JHGbrQu3CmfEi7C7CvJX05IHps/esBEMM5InxSt TFwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705879320; x=1706484120; h=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=UsXccw5xj45Tro9ZXBRJoriwhYKn5Zeqju+OeFJGBwM=; b=baFKkT2vZbFROuZdAKaXJ2RiCl8PTnjkOWPmhKowlOjglkcmAV+ctsDd55YjdYVIFf OxCdKfj+ruk7UNAgdBjSke9ht+W38RHl9H/ZcIBJlkYyIJXv4k9DRpWkK7h/8LC4ZoeC clqUokTp7Hjrnnavgoo8ZNZlOltOcq2bt8U7MCUBAriIJwL4ekI7wn9gRgpsDa6prRSB KsbbvZTHBZuij33/IgE2Qmt2dYCAGsIQUEx+FJC/h4V+CQkpKeeItO2QAZs70FmUZSwo BJORhHaVzP3LmTi3cX3uf21usvDSht0Tn2c3eopmfLqz4ZLziagoZgiQ3SGj65qK2opI 6A0A== X-Gm-Message-State: AOJu0Yx/VoOe809uxzawYr9kUFrMSzu+p4ZYZh1pJVVY9+nvE/mvoLCp hwOHacfFdC17ofPWFo5LC0iPovr5BZvEFvzeU3/5qdoIF/Rz3KVCLLimNpkMufKyFL+HwJEF+mJ 0URcMfcQyaf/n1uFj+4IHeq5wIufMCIQXNCU= X-Google-Smtp-Source: AGHT+IFnNn7NI/gl+tMhbHKWXK5Yzk88pu+2fgBXnLNW70SDuj3qnOrIqRuggzkLpsv9j8ykj8+PIADHY2GUcE9htjE= X-Received: by 2002:a05:6402:373:b0:55a:63b0:57f5 with SMTP id s19-20020a056402037300b0055a63b057f5mr1640378edw.32.1705879319816; Sun, 21 Jan 2024 15:21:59 -0800 (PST) In-Reply-To: <878r4j4mht.fsf@web.de> Received-SPF: pass client-ip=2a00:1450:4864:20::530; envelope-from=damien.mattei@gmail.com; helo=mail-ed1-x530.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, HTML_MESSAGE=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: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22278 Archived-At: --000000000000e32ce0060f7cfa19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 21, 2024 at 12:24=E2=80=AFAM Dr. Arne Babenhauserheide wrote: > > > > Is your implementation of {} compatible with SRFI-105? (curly infix) > > > > yes it is based on SRFI-105 > > That=E2=80=99s very cool! > > While I=E2=80=99m doubtful about your other changes in scheme+, this is a= n > improvement that I=E2=80=99d love to see merged into Guile. > it is available for many scheme, as a module, if there is a packet manager,for racket it is quite simple to install,anyway it is 100% scheme, so for guile it should be installed like another module, i do not know if it could be integrated in guile. > > > the operator precedence are predefined in a list ordered by priority in > the source code: > > > > (define infix-operators-lst > > How does it treat procedures which are not in that list? > first , operator precedence is based on this list: https://runestone.academy/ns/books/published/fopp/Conditionals/Precedenceof= Operators.html but i do not know what answer, which procedure are you thinking about? the list of operator is quite exhaustive already. If new operator was to add it is as simple as update the list. Note that changing operator precedence is the first time i hear about it, as far as i know, not possible in C++,Java, searching for Python , it find that: https://stackoverflow.com/questions/11811051/change-operator-precedence-in-= python but the true answer seems NO: https://www.tutorialspoint.com/Can-we-change-operator-precedence-in-Python I had two methods for operator precedence, it was done at run-time so if you change rules it is immediately apply for the next computation. Now i added optimization at compilation , by parsing the source file before and all infix operator precedence is done before compilation, so it will no more possible to change the precedence rules. Note that in conjunction with operator overload too this is more useful but this could be complex to manage and implement. Not sure it is a good idea. Best regards, Damien --000000000000e32ce0060f7cfa19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 21, 2024 at 12:24=E2=80=AFAM Dr. Arne B= abenhauserheide <arne_bab@web.de&= gt; wrote:

<= br> >=C2=A0 Is your implementation of {} compatible with SRFI-105? (curly in= fix)
>
> yes it is based on SRFI-105

That=E2=80=99s very cool!

While I=E2=80=99m doubtful about your other changes in scheme+, this is an<= br> improvement that I=E2=80=99d love to see merged into Guile.

it i= s available for many scheme, as a module, if there is a packet manager,for = racket it is quite simple to install,anyway it is 100% scheme, so for guile= it should be installed like another module, i do not know if it could be i= ntegrated in guile.

> the operator precedence are predefined in a list ordered by priority i= n the source code:
>
> (define infix-operators-lst

How does it treat procedures which are not in that list?
first , operator = precedence is based on this list:
but i do not know what answer, which procedure are you thinking= about?
th= e list of operator is quite exhaustive already.
If new operator was to add it is as simple= as update the list.
Note that changing operator precedence is the first time i hear about= it, as far as i know, not possible in C++,Java,
searching for Python , it find that:
= https://stackoverflow.com/questions/11811051/change-operator-precedence-in-= python
but = the true answer seems NO:
https://www.tutorialspoint.com/Can-we-change-operato= r-precedence-in-Python

I had two methods for operator precedence, it was done at run-time so if = you change rules it is immediately apply for the next computation.
Now i added optimizatio= n at compilation , by parsing the source file before and all infix operator= precedence is done before compilation, so it will no more possible to chan= ge the precedence rules.
Note that in conjunction with operator overload too this is more = useful but this could be complex to manage and implement.
Not sure it is a good idea.

Best regards,
Damien
--000000000000e32ce0060f7cfa19--