Sujet : Re: infix via code walker hook.
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.lispDate : 05. Apr 2025, 02:09:55
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250404174836.670@kylheku.com>
References : 1 2 3 4 5 6
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-04, Stefan Monnier <
monnier@iro.umontreal.ca> wrote:
Ah, but how about higher precedence operators?
>
Same: the "usual" convention in those languages (and in most λ-calculus
papers) is that function application takes the shape "e1 e2" and binds
tighter than "anything else".
>
Would you want
>
sin a * b * c
>
to be
>
sin (a) * b *c
>
Yup.
But then that is inconsistent with a very common treatment of
sin, which is that product terms comprise one argument.
For instance, oh sin 2 * pi * f * t .
It seems that a useful behavior to have would be for the
range of the unary operator to stop when we encounter
another such unary operator; i.e.
>
sin a + b + c + sin d + e + f
^ ^
>
Well, now you're falling into the world of heuristics to try and handle
the inconsistent mix of rules used by various authors.
You're obviously free to go there, but don't count me in.
It may seem like a heuristic, but it's actually one clear rule. (It may
be novel; I should ping the CS StackExchange or something.)
It's not some very specific, dark corner case but a general rule
prominently situated at the heart of the algortihm.
Whenever processing any infix operator O, we determine whether it is
followed by a nonempty, contiguous sequence of prefix operators P1, P2,
... In other words, does the right operand of O begin with prefixes.
If so, we calculate the minimum precedence among the Pi,
and decrement that minium by one level (or perhaps a fraction of a
level, just to make it smaller). If the precedence of O is not at least
as low as that value, we demote O's precedence to that value,
for the purposes of the usual operator processing logic that follows.
As far as I can see, with that, I am done. I don't see any situations
that yield results that grate on my eyes/nerves. I'm ready to move on
from exploratory coding to cranking out test cases, and writing
documentation.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca