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