Hello,

Today I just rewrote the PTMD_STD operator precedence table, so it now has 21 nesting precedence levels rather than 7. The main change since release 0.137.0 is that the middle 2 precedence rules dealing with infix operators were split into 14 and reordered. The new list should now resemble the precedences of a typical programming language (the Perl 6 table was a strong influence; see http://perlcabal.org/syn/S03.html#Operator_precedence for that).

The new list is below the ===== line in this message.

I request your feedback on how the current table can be further improved.

A few points:

1. This table generally just applies in functional code, meaning in Muldis D functions, updaters, and recipes. Every term or operator listed herein, except for the very loosest one, "Assignment", results in a value and has no side-effects; this includes the if-else and given-when. The very loosest one is where variable assignments happen, and all variables are parameters or globals.

2. The ??!!, if-else, etc are looser than all the other ops because they conceptually short-circuit, only trying to evaluate results when said are needed, while all the other normal ops conceptually don't short-circuit, though all operators are still lazy as the implementation chooses. The purpose of the short-circuit distinguishment in a functional/lazy context is so that you can be manually polymorphic, say using an operator that only works on Foo type inputs if your input is a Foo value, and otherwise using a different operator.

3. Particularly relevant for a database language, please look in particular at the operators which are closed around relations, most of which I grouped with "Multiplicative", "Additive", and "Filtering Infix". Please suggest how these might be better organized.

4. I want people who have studied logic to look at the 10 dyadic logical operators I have and indicate what all of their conventional relative precedences are, which hopefully is also something that works for computer science in general for the ones commonly used there. From looking at Wikipedia, I saw 5 precedence levels mentioned: [not, and, or, implies, material equivalence], but that doesn't tell me how to place the other 6 operators I have; meanwhile I grouped "xor" with "or" as is programming convention, and everything else with "implies".

5. Any other correctness or cleanup feedback is appreciated, including better names for the levels if any.

Thank you in advance.

-- Darren Duncan

==============

=head1 NESTING PRECEDENCE RULES

This documentation section outlines Muldis D's PTMD_STD dialect's nesting
precedence rules, meaning how it accepts Muldis D code lacking explicit
expression delimiters and implicitly delimits the expressions therein, in a
fully deterministic manner.

Muldis D has 21 precedence levels when the C<catalog_abstraction_level>
pragma is C<rtn_inv_alt_syn>; if it is C<plain_rtn_inv> instead, then 16 of
the levels can be eliminated, so then PTMD_STD has just 5; if it is
C<code_as_data> instead, then 4 more can be eliminated, leaving just 1.

Here we list the levels from "tightest" to "loosest", along with a few
examples of each level:

    Level            | Assoc | Examples
    -----------------+-------+---------------------------------------------
    Terms            | N/A   | Inf True Order:Same Down 42 3.14 -5/7 3*2^8
                     |       | F;'27E04' 'eek' foo "x" <Int> #`comment!`#
                     |       | {43,9,5} [1,2,3] {'Carrots'=>42} {11..20}
                     |       | $:{...} %:{...} @:{...} nlx.lib.MyType
                     |       | (1+2) myfunc(...)
    Accessor Postfix | N/A   | nlx.data.quux .age foo().bar
                     |       | p.{...} r{...} x.[...] y[...]
    Ordinal Postfix  | N/A   | ++ -- i!
    Generic Prefix   | N/A   | || # #+ % @
    Currying Infix   | left  | assuming
    Exponentiation   | right | ^ exp ** log e** log-e
    Multiplicative   | left  | * / div mod intersect join times divideby
                     |       | compose intersect+
    Rounding 2-Infix | left  | round
    Filtering Infix  | left  | where !where matching !matching
    Additive         | left  | + - |-| ~ ~# union exclude minus
                     |       | union+ union++ minus+
    Ordering Infix   | left  | <=>
    Selecting Infix  | left  | as asserting min max [<=>] //
    Comparison       | left  | isa !isa = != < > <= >= like !like
                     |       | inside !inside holds !holds in !in has !has
                     |       | {<=} {!<=} {>=} {!>=} {<} {!<} {>} {!>}
                     |       | {<=}+ {!<=}+ {>=}+ {!>=}+ {<}+ {!<}+ {>}+ {!>}+
    Logical Negation | N/A   | not ! ¬
    Conjunction      | left  | and ∧
    Disjunction      | left  | or ∨ xor ⊻ ↮
    Implies          | left  | imp → nimp ↛ if ← nif ↚ nand ⊼ ↑ nor ⊽ ↓
    Equivalence      | left  | xnor ↔
    Conditional      | right | ??!! if-else-expr given-when-def-expr
    Naming           | right | ::=
    Assignment       | non   | := :=++ :=-- :=foo

Any imperative code that embeds a value expression has looser precedence
than all value expressions.

Using two C<!> symbols below generically to represent any pair of operators
that have the same precedence, the associativities specified above
for binary, ternary, or N-ary operators are interpreted as follows:

    Assoc | Meaning of $a ! $b ! $c
    ------+------------------------
    left  | ($a ! $b) ! $c
    right | $a ! ($b ! $c)
    non   | ILLEGAL

_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users

Reply via email to