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
