feat(std): rename operators/reducers ports nameing from acc/el to lef…

.vscode/launch.json

@@ -8,7 +8,7 @@
       "mode": "auto",
       "program": "${workspaceFolder}/cmd/neva",
       "cwd": "${workspaceFolder}/examples",
-      "args": ["run", "add_numbers"]
+      "args": ["run", "--trace", "99_bottles"]
     },
     {
       "name": "DEBUG CODEGEN",

README.md

@@ -74,14 +74,16 @@ Hello, World!
 If you open `my_awesome_project/src/main.neva` with your favorite IDE you'll see this
 
 ```neva
+import { fmt }
+
 def Main(start) (stop) {
-	Println
+	fmt.Println
 	---
 	:start -> { 'Hello, World!' -> println -> :stop }
 }
 ```
 
-The `Main` component has `start` inport and `stop` outport, with a `println` node (instance of stdlib's `Println`). The network after `---` shows: on `start` message, `"Hello, World!"` is sent to `println`, then program terminates via `stop` signal.
+The `import { fmt }` statement imports the standard library's `fmt` package which provides common formatting and printing functionality. The `Main` component has `start` inport and `stop` outport, with a `println` node (instance of stdlib's `fmt.Println`). The network after `---` shows: on `start` message, `"Hello, World!"` is sent to `println`, then program terminates via `stop` signal.
 
 ### What's Next?
 

docs/components.md

@@ -21,7 +21,7 @@ Overloaded native components use a modified extern directive: `#extern(t1 f1, t2
 
 ```neva
 #extern(int int_add, float float_add, string string_add)
-pub def Add<T int | float | string>(acc T, el T) (res T)
+pub def Add<T int | float | string>(left T, right T) (res T)
 ```
 
 Usage:

docs/constants.md

@@ -29,8 +29,8 @@ const one int = 1
 def Inc(data int) (res int) {
     Add
     ---
-    $one -> add:acc
-    :data -> add:el
+    $one -> add:left
+    :data -> add:right
     add -> :res
 }
 ```
@@ -43,8 +43,8 @@ You can omit explicit constants; the compiler will create and refer to them impl
 def Inc(data int) (res int) {
     Add
     ---
-    1 -> add:acc
-    :data -> add:el
+    1 -> add:left
+    :data -> add:right
     add -> :res
 }
 ```

docs/directives.md

@@ -17,7 +17,7 @@ Native components can be overloaded using `#extern(t1 f1, t2 f2, ...)`. These co
 
 ```neva
 #extern(int int_add, float float_add, string string_add)
-pub def Add<T int | float | string>(acc T, el T) (res T)
+pub def Add<T int | float | string>(left T, right T) (res T)
 ```
 
 ## `#bind`

docs/interfaces.md

@@ -26,34 +26,34 @@ Interfaces in Nevalang are used for:
 `any` is too generic; specific types are often needed. Let's define an interface for an integer adder:
 
 ```neva
-interface IAdd(acc int, el int) (res int)
+interface IAdd(left int, right int) (res int)
 ```
 
 What if we want to add not just integers but also support `float` and `string`? You could use `union` for that
 
 ```neva
 type addable int | float | string
-interface IAdd(acc addable, el addable) (res addable)
+interface IAdd(left addable, right addable) (res addable)
 ```
 
-This solution is problematic because it allows mixing types, e.g., `int` for `:acc` and `float` for `:el`. The `:res` message will have a union type `int | float | string`, making the code complex. To maintain type-safety, use type-parameters in the interface definition:
+This solution is problematic because it allows mixing types, e.g., `int` for `:left` and `float` for `:right`. The `:res` message will have a union type `int | float | string`, making the code complex. To maintain type-safety, use type-parameters in the interface definition:
 
 ```neva
-interface IAdd<T>(acc T, el T) (res T)
+interface IAdd<T>(left T, right T) (res T)
 ```
 
-This ensures `:acc` and `:el` receive compatible types, and `:res` matches their type. However, our current definition allows any type, including `IAdd<bool, bool>`, which we don't want. To fix this, we can explicitly constrain `T` using our union:
+This ensures `:left` and `:right` receive compatible types, and `:res` matches their type. However, our current definition allows any type, including `IAdd<bool, bool>`, which we don't want. To fix this, we can explicitly constrain `T` using our union:
 
 ```neva
-interface IAdd<T int | float | string>(acc T, el T) (res T)
+interface IAdd<T int | float | string>(left T, right T) (res T)
 ```
 
 Now only `IAdd<int, int>`, `IAdd<float, float>` or `IAdd<string, string>` (and their compatible variants) are possible. `IAdd:res` will always be `int`, `float`, or `string`.
 
 Type-expressions in interface definitions follow type-system rules, so you can pass `T` to other type-expressions. Example:
 
 ```
-interface IAppend<T>(lst list<T>, el T) (list<T>)
+interface IAppend<T>(lst list<T>, right T) (list<T>)
 ```
 
 These expressions can be complex and nested, but we'll keep this section brief.
@@ -63,7 +63,7 @@ These expressions can be complex and nested, but we'll keep this section brief.
 Let's return to the original `IAdd` without type-parameters for simplicity
 
 ```neva
-interface IAdd(acc int, el int) (res int)
+interface IAdd(left int, right int) (res int)
 ```
 
 It's suitable for combining 2 sources, but what if we need to combine any number of sources? Chaining multiple `IAdd` instances is tedious and sometimes impossible. Let's look at the array-inports solution:

docs/networks.md

@@ -121,11 +121,13 @@ Each connection always has a sender and receiver side. There are 3 types of each
 
 ### Sender Side
 
-There are 3 sender-side forms:
+There are 5 sender-side forms:
 
 1. Port address
 2. Constant reference
 3. Message literal
+4. Binary expression
+5. Ternary expression
 
 #### Port Address Sender
 
@@ -152,21 +154,21 @@ It acts as an infinite loop, repeatedly sending the same message at the receiver
 
 One way to work with them is to have a node with multiple inports, where at least one is connected to a port, not a constant. This limits the constants' speed to that of the port. Here's a simple example:
 
-We'll create a component that increments a number using an addition component with 2 inports: `:acc` and `:el`. We'll use a constant `$one` for `:acc`, while `:el` receives dynamic values:
+We'll create a component that increments a number using an addition component with 2 inports: `:left` and `:right`. We'll use a constant `$one` for `:left`, while `:right` receives dynamic values:
 
 ```neva
 const one int = 1
 
 def Inc(data int) (res int) {
     Add
     ---
-    $one -> add:acc
-    :data -> add:el
+    $one -> add:left
+    :data -> add:right
     add -> :res
 }
 ```
 
-In this example, `add:acc` and `add:el` are synchronized. When `:data -> add:el` has a message, `add:acc` can receive. If the parent of `Inc` sends `1, 2, 3`, `add` will receive `acc=1 el=1; acc=1 el=2; acc=1 el=3` and produce `2, 3, 4` respectively.
+In this example, `add:left` and `add:right` are synchronized. When `:data -> add:right` has a message, `add:left` can receive. If the parent of `Inc` sends `1, 2, 3`, `add` will receive `left=1 right=1; left=1 right=2; left=1 right=3` and produce `2, 3, 4` respectively.
 
 Another way to synchronize constants with real data is to use deferred connections. We'll explore this in the receiver-side forms section.
 
@@ -205,8 +207,8 @@ Sometimes it's convenient to refer to message values directly in the network wit
 def Inc(data int) (res int) {
     Add
     ---
-    1 -> add:acc
-    :data -> add:el
+    1 -> add:left
+    :data -> add:right
     add -> :res
 }
 ```
@@ -218,6 +220,68 @@ Only primitive data-types (`bool`, `int`, `float`, `string` and `enum`) can be u
 - float: `42.0 -> ...`
 - enum: `Day::Friday ->`
 
+#### Binary Expression
+
+#### Binary Expression
+
+Binary expression is an easy way to perform arithmetic, comparison, logic or bitwise operation with two operands. Syntax of binary expression is infix notation with binary operator in the middle and operands on left and right. Binary expression is always wrapped in `()` braces (so there's no precedence in Nevalang).
+
+Examples:
+
+```neva
+// arithmetic
+(5 + 3) -> println // addition: outputs 8
+(5 - 3) -> println // subtraction: outputs 2
+(5 * 3) -> println // multiplication: outputs 15
+(6 / 2) -> println // division: outputs 3
+(7 % 3) -> println // modulo: outputs 1
+(2 ** 3) -> println // power: outputs 8
+
+// comparison
+(5 == 5) -> println // equal: outputs true
+(5 != 3) -> println // not equal: outputs true
+(5 > 3) -> println // greater than: outputs true
+(5 < 8) -> println // less than: outputs true
+(5 >= 5) -> println // greater or equal: outputs true
+(5 <= 8) -> println // less or equal: outputs true
+
+// logic
+(true && true) -> println // AND: outputs true
+(true || false) -> println // OR: outputs true
+
+// bitwise
+(5 & 3) -> println // AND: outputs 1
+(5 | 3) -> println // OR: outputs 7
+(5 ^ 3) -> println // XOR: outputs 6
+```
+
+> Bitwise left and right shifts (`<<` and `>>`) are not yet implemented.
+
+Operands of a binary-expression are senders themselves. In example above they are message literals but they could be any senders:
+
+```neva
+(5 + node:port)
+($some_const && false)
+(someNode == 'some string')
+```
+
+Binary expressions could be infinetely nested. Example: `((a + b) * (c - d)) -> receiver`.
+
+Both operands (their resolved versions) must be of the same type. Type of a valid binary expression is the same as types of its operands. Type-compatibility between binary expression sender and its receiver-side is resolved the same way as with any other sender and receiver sides.
+
+#### Tenrary Expression
+
+Similar to binary, but there are 3 operands instead of 2 and first operand is always of `bool` type. Just like binary, ternary expression sender is always wrapped into `()` braces, supports any senders as operands and could be infintely nested (and mixed with binary expressions). Examples:
+
+```neva
+(a ? : b : c) // simple
+(a + (b ? c : d)) // as operand in binary expression
+(cond ? (a + b) : (c * d)) // with binary expressions as brances
+((a == b) ? c : d) // with binary expression as condition
+```
+
+Compiler with ensure that condition operand resolves to `bool` type and that both branch-operands are compatible with the receiver-side.
+
 ### Receivers Side
 
 There are 3 types of receiver side:

docs/program_structure.md

@@ -43,7 +43,7 @@ neva: 0.26.0
 deps:
   github.com/nevalang/x:
     path: github.com/nevalang/x
-    version: 0.0.13
+    version: 0.0.14
 ```
 
 The `deps` field is a map where each dependency has an alias. When adding dependencies via CLI (e.g., `neva get github.com/nevalang/x`), the package manager automatically inserts a key-value pair. Third-party dependencies must have a valid git-clone path and a fixed semver version. The package manager uses git to download the repo and looks for the corresponding git-tag. The alias typically defaults to the module's path, but custom aliases allow multiple versions of the same module:
@@ -55,7 +55,7 @@ neva: 0.26.0
 deps:
   github.com/nevalang/x@0-0-12:
     path: github.com/nevalang/x
-    version: 0.0.13
+    version: 0.0.14
   github.com/nevalang/x@0-0-11:
     path: github.com/nevalang/x
     version: 0.0.11
@@ -71,7 +71,7 @@ Module references uniquely identify modules in a build, used by the compiler to
 
 ```yaml
 path: github.com/nevalang/x
-version: 0.0.13
+version: 0.0.14
 ```
 
 ### Entry Module
@@ -287,12 +287,8 @@ pub const p int = 3.14
 // foo/bar/bar.neva
 import { @/foo }
 
-pub def AddP(el float) (res float) {
-  Add<float>
-  ---
-  $foo.p -> add:acc
-  :el -> add:el
-  add -> :res
+pub def AddP(data float) (res float) {
+  (:data + $foo.p) -> :res
 }
 
 // main/main.neva
@@ -304,7 +300,7 @@ import {
 def Main(start) (stop) {
   bar.AddP, Println
   ---
-  :start -> { $foo.p -> addP:el -> println -> :stop }
+  :start -> { $foo.p -> addP:right -> println -> :stop }
 }
 ```
 
@@ -316,7 +312,7 @@ Third-party imports are imports of packages located in third-party modules - mod
 deps:
   github.com/nevalang/x:
     path: github.com/nevalang/x
-    version: 0.0.13
+    version: 0.0.14
 ```
 
 Then when you `import { github.com/nevalang/x }` compiler will know exactly path and version of the module you are referring to.

docs/qna.md

@@ -109,4 +109,8 @@ elseValue -> ternary:else
 ternary:res -> println
 ```
 
-And guess what? This is exactly how desugared `Ternary` component works! But these are 4 (!) connections! Compare it with `(condition ? thenValue : elseValue) -> println`.
+And guess what? This is exactly how desugared `Ternary` component works! But these are 4 (!) connections! Compare it with `(condition ? thenValue : elseValue) -> println`.
+
+## Why operators and reducers have `left` and `right` naming for ports?
+
+Operators should follow same pattern for simplicity of desugarer and usage by user and they also also should be able to be used as reducers by `Reduce`. It means we need to choose between `left/right` which is convinient for operators and `acc/el` for reduce. Binary expressions (infix form) are more common than reduce operations so desicion was made to sacrifice reduce clarity a little bit.

docs/style_guide.md

@@ -1,6 +1,6 @@
 # Style Guide
 
-This guide sets standards for Nevalang code organization, formatting, and naming conventions to ensure consistency and readability.
+This guide sets standards for Nevalang code to ensure consistency and readability.
 
 ## Formatting
 
@@ -10,7 +10,6 @@ Keep lines under 80 characters.
 
 - Comfortable for split-screen viewing
 - Accommodates larger font sizes without horizontal scrolling
-  - Better for visual accessibility
 - Leaves room for IDE features (code lens, git blame, inline-hints, etc.)
 - Enables reading full lines with eye movement alone
 
@@ -19,7 +18,6 @@ Keep lines under 80 characters.
 Use tabs over spaces.
 
 - Tabs allow users to customize indentation width according to their preferences
-  - More accessible for users with visual impairments who may need larger indentation
 - Tabs are more efficient in terms of file size
 
 ### Imports
@@ -33,17 +31,19 @@ Names should inherit context from parent scope. Good naming eliminates need for
 - **Packages/Files**: lower_snake_case up to 3 words
 - **Types**: CamelCase up to 3 words
 - **Interfaces**: CamelCase with `I` prefix up to 3 words
-- **Constants**: lowerCase up to 3 words
+- **Constants**: lower_snake_case up to 3 words
 - **Components**: CamelCase noun up to 3 words
 - **Nodes**: lowerCamelCase up to 3 words
 - **Ports**: lowercase, 1 word up to 5 letters
 
 ## Interfaces
 
-- Use type-parameters when need to preserve type information between input and output.
-- Limit to 3 inports and outports max.
+- Use outports to separate data flows, not for destructuring
+- Use `data` for input with payload, `sig` for input without payload (trigger), `res` for output with payload, `sig` for output without payload (success), and `err` for failures.
+- `err` outport must be `error` type. `sig` inport must be `any` type for flexibility. For outports, `sig` should be `struct{}` in concrete components and `any` in interfaces. Never use `any` for `res` outport.
+- Don't send input data downstream - parent already knows it
+- Use type-parameters when need to preserve type info between input and output
 
 ## Networks
 
-- Prefer simple topologies over complex networks.
-- Omit port names when possible
+- Omit port names when possible. It enables renaming of ports without updating the networks.