Tuple unpacking #1080
Closed
thpani
started this conversation in
Development and documentation
Tuple unpacking
#1080
Replies: 1 comment 2 replies
-
I discussed synchronously with @konnov, and we agreed that we should have explicit syntax for tuple unpacking, similar to what @shonfeder suggested above. In the simple case where a lambda takes a tuple, this would look like tuples(S, T).filter( ((s,t)) => p(s,t) ) In the example above, the "uncurrying" would be made explicit: pure def c(tup, f) = Set(tup).map( ((x, y)) => f(x, y) )
pure def func(p, g) = p
pure val test = c((1, 2), func) @bugarela @shonfeder WDYT? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We introduced tuple unpacking in #362.
This was in support of naming tuple fields, and to avoid repeating tuple accessors like
t._1
.There's some issues with the current design. Consider the following snippet:
This spec type-checks, but REPL gives
undefined value
fortest
.There's also the question of how to statically type these definitions; e.g., above, the
Set
constructor is variadic.Even if we omit
Set
, it is unclear how to type, for example, the followingWe should revisit how we do tuple unpacking, and whether we need better syntax for it.
Also, this solution should factor in feasibilty of transpiling to Apalache.
I will think it through once more, but atm I don’t see a way to make this work for built-ins in the Apalache transpiliation. IMO we need a first-class unpacking construct in Quint, or at least unpacking reflected in the Quint IR, or a first-class unpacker in Apalache.
Initial comments (captured from Slack):
@bugarela:
(a, b) => ...
and([a, b]) => ...
([]
being the constructor for tuples@shonfeder:
(((a,b)) => foo)(1,2)
@thpani:
t._1
a lot, you probably want a recordtuples
\X
is prevalant in TLA+, I have a feeling we're usingtuples
a lot less in more recent specsBeta Was this translation helpful? Give feedback.
All reactions