Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infix notation for builtin operators #721

Closed
emil14 opened this issue Oct 4, 2024 · 2 comments
Closed

Infix notation for builtin operators #721

emil14 opened this issue Oct 4, 2024 · 2 comments

Comments

@emil14
Copy link
Collaborator

emil14 commented Oct 4, 2024

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 Constants as triggers (reduce deferred connection usage) #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
Copy link
Collaborator Author

emil14 commented Oct 4, 2024

Binary Operators as Reducers (Compatibility Problem)

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)

@emil14
Copy link
Collaborator Author

emil14 commented Oct 31, 2024

#740

@emil14 emil14 closed this as completed Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant