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

Dict and List reading syntax #746

Open
emil14 opened this issue Nov 3, 2024 · 2 comments
Open

Dict and List reading syntax #746

emil14 opened this issue Nov 3, 2024 · 2 comments

Comments

@emil14
Copy link
Collaborator

emil14 commented Nov 3, 2024

Problem

At and Get components are used for accessing list element and dict value respectfully. Here's how it looks (example with dict):

Get?
---
v -> get:dict
k -> get:key
get -> println

This is cumbersome compared to other languages. Can we introduce syntax sugar for this?

Proposal - v[k|i] syntax

  1. Make Get/At send Maybe instead of having 2 outports
  2. Introduce index/key reading syntax that is desugared to using Get and At (based on data-type used)
v[k] -> unwrap
unwrap:some -> println
unwrap:none -> panic
@emil14
Copy link
Collaborator Author

emil14 commented Nov 9, 2024

Use match

In Rust match statement is used to handle Option and Result (it also have unwrap macro which causes panic). It's possible to imagine that with Maybe is used with match statement (will work same for lists):

match v[k] {
    some -> println
    none -> panic
}

Problems

  1. It's not clear how exactly match statement must work - is this special form or common use-case? How will it play with other "forms" (if any)?
  2. We have to use maybe for something that is not IO-specific, while it was stated before that for internal logic outports must be used (but maybe this is good case for maybe too?)
  3. If we end up not having Result but only Maybe it might be not clear for folks with Rust/Haskell/etc background why emptiness handling is different than error handling

Related to #747 #726 #751 #756

@emil14
Copy link
Collaborator Author

emil14 commented Nov 9, 2024

Standalone syntax form

v[k] {
    some ->
    match ->
}

I don't like this because numbers of reasons

  1. Both selecting and routing must be supported, which means it would be nice to be able to use it with match/switch statements
  2. maybe type, regardless of whether this union or base type, is more universal - e.g. we can pass it to other components

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