nevalang / neva

🌊 Dataflow programming language with static types and implicit parallelism. Compiles to native code and Go
https://nevalang.org
MIT License
91 stars 7 forks source link

Infix notation for builtin operators #721

Open emil14 opened 8 hours ago

emil14 commented 8 hours ago

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

flow AddP(a float) (res float) {
    (:a + 3.14) -> :res
}

=>

flow AddP(a float) (res float) {
    Add<float>
    ---
    :a -> add:acc
    3.14 -> add:el
    add -> :res
}

Steps to implement

  1. Consider what operators must be supported this way. Look at conventional languages for inspiration.
  2. Change deferred connections syntax to free () (e.g. use ||), or remove deferred connections at all (see #717)
  3. Add parser rule for infix notation inside () in network block. Both left and right sides must be valid network senders.
  4. () expression is itself sender and thus must always have right-side ... ->
  5. Make sure type-safety is supported (should work kinda same way as with explicit operator component usage)

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

emil14 commented 7 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)