Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)

[Damien Mattei <damien.mattei@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On Sun, Jan 21, 2024 at 12:24 AM Dr. Arne Babenhauserheide <arne_bab@web.de>
wrote:

>
>
> >  Is your implementation of {} compatible with SRFI-105? (curly infix)
> >
> > yes it is based on SRFI-105
>
> That’s very cool!
>
> While I’m doubtful about your other changes in scheme+, this is an
> improvement that I’d 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/PrecedenceofOperators.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

[-- Attachment #2: Type: text/html, Size: 3978 bytes --]