dark
dark copied to clipboard
darklang
Creating a Block from a List of Tuples should offer the # of items in the Tuple
When I'm working with a List of Tuples, and I List::map from that list, I want the Block to match the # of elements in the tuple.
For example:
let headers = Dict::toList request.headers |> List::map \item1, item2 -> (String::toLower fst, snd)
Currently, when I create the block with \, the editor offers \val, but I'd rather it offer something more sophisticated. At least, \item1, item2, .... Perhaps in tuples of size 2, we offer fst and snd as niceties. Users are likely to update them to something else such as key and value, though.
Users will be able to 'get around this' want for a while, with:
List::findFirst headers \header ->
let (key, value) = header
What'd be even nicer would be a way to quickly toggle between val and item1, item2 in the block.
This holds true for tuples, but also other types. e.g. I'd love to toggle between val and a deconstructed record.
(this comment likely to be extracted into a separate issue if useful)
Idea: allow users to autocomplete here - both 'val' and the tuple deconstruction should be available completions.
I'm thinking that this may end up as a 'lambda pattern,' in addition to the existing 'match pattern' and the 'let pattern' discussed here. Potentially, 'let patterns' could apply in a lambda, but conflating the concepts may not be worthwhile.
Haven't thought this through - just wanted to get the idea out.
Off the top of my head, lambda arguments are probably a list of "let patterns"
Off the top of my head, lambda arguments are probably a list of "let patterns"
Let's say we eventually support this in a let expr:
let [head, ...tail] = list as discussed here
Would you want to have this be legal as well?
List::map
[[1,2,3],[4,5,6],[7,8,9]]
\[head, ..._tail] -> head
(naturally this is ugly and \val -> List.head val would be better in this case)
I'm not sure - I could see that supported, or I could see us requiring such a deconstruction to be done inside of the block's expr.
It doesn't look that bad but having "potentially-incomplete" patterns in a let pattern seems somehow more permissible to me than having potentially-incomplete patterns in a "lambda pattern." Maybe I only think that because our debug-ability/analysis of lambdas is a bit rough right now, though.
Off the top of my head, lambda arguments are probably a list of "let patterns"
Let's say we eventually support this in a let expr:
let [head, ...tail] = listas discussed here
I don't think we should support this, as what happens for an empty list? Runtime error? I don't think we want runtime errors in the language anywhere they can be avoided.
Would you want to have this be legal as well?
List::map [[1,2,3],[4,5,6],[7,8,9]] \[head, ..._tail] -> head(naturally this is ugly and
\val -> List.head valwould be better in this case)I'm not sure - I could see that supported, or I could see us requiring such a deconstruction to be done inside of the block's expr.
It doesn't look that bad but having "potentially-incomplete" patterns in a
letpattern seems somehow more permissible to me than having potentially-incomplete patterns in a "lambda pattern." Maybe I only think that because our debug-ability/analysis of lambdas is a bit rough right now, though.
I agree we don't want them for lambda but I believe we also don't want them for lets. Lets and lambdas are both bindings, and seem to me to be equivalent.
Let's say we eventually support this in a let expr:
let [head, ...tail] = listas discussed hereI don't think we should support this, as what happens for an empty list? Runtime error? I don't think we want runtime errors in the language anywhere they can be avoided.
I'm not sure I agree - see https://docs.google.com/document/d/10mr811ONuUSm6Q1egfv9dGtpN7QdHwhM96uyW8w0140/edit?disco=AAAAofTAbWo
Do you think the tuple deconstruction RFC needs to be updated to prevent expressions such as let (a, b) = 1? If so, I'd appreciate some guidance - I can't imagine preventing such an expression in a non-awkward way in the editor. This let [head, ...tail] = [1] seems to me like a roughly equivalent type error.
The tuple deconstruction is a static error: it's always right or always wrong, since tuples are a known size statically.
List deconstruction might be right or wrong depending on the length of the list, so it's a runtime error.
This is a little confusing as we currently find static errors at runtime, but we plan to separate them.
That makes sense. Also, I was conflating the thing actually proposed there (a match pattern for list deconstruction) and a new thing (a let pattern for list deconstruction). Thanks!