Open emil14 opened 8 hours ago
Should all binary operators implement reducer interface?
Boolean operators like ==
are not reducers but it would be nice to support them too
Maybe universal rule can be applied that left-side operand is first inport (in source code) and right is second?
This however has some problems - in sourcecode
package ports are (unordered) maps and also it breaks the rule that order doesn't matter
Maybe acc
and el
naming could be changed to first
and second
and this is how Reduce gonna work? (it damages reduce semantics though)
Problem
See #719 for general description of problem with existing syntax. This issue describes specific case of usage of builtin operators that usually have infix form in both mathematical notation and control-flow languages.
The fact that control-flow languages supported infix form might not be strictly bound to the fact of "control-flow'ish" nature of math notation (lambda-calculus-like reduction). It all could be just function/procedure calls. But take Haskell for example - it supports infix notation for operators
Infix notation is so well known and easy to use that Haskell adopted it for operators, while having prefix notation for regular functions calls (just like Lisp).
Proposal
=>
Steps to implement
()
(e.g. use||
), or remove deferred connections at all (see #717)()
in network block. Both left and right sides must be valid network senders.()
expression is itself sender and thus must always have right-side... ->
Potential Problems
Probably fan-in/out connections. At the moment it's possible to send message to N places, one of which is an operator