Unit, Parenthesis, Tuples (both at the value and type level)

[miniBill]

Agree with @lue-bird here: it would feel weird to unify them.

Most of the time I'll want to deal with those three differently. I guess one can pattern match on the list length but still. I don't vibe with this.

I'd actually mildly prefer Tuple2 and Tuple3 to be separated. I can understand that a good chunk of the time they're just going to be handled the same, but I'd love to be able to exclude the case of TupleExpression [a,b,c,d,e,f,g]

[lue-bird]

(also at the pattern level)

I can understand that a good chunk of the time they're just going to be handled the same

This is precisely not my experience, with my elm-review eyes. The two almost always need to be handled separately, explicitly.

[jfmengels]

I'm in agreement with reverting back to multiple variants for this. I just updated the old v8 branch but don't remember being involved in this decision. I also agree

I think Tuple2 and Tuple3 make sense as well in order to be sure we don't have Tuple [] for instance.
So we'd end up with

type Expression
  = Tuple2 (Node Expression) (Node Expression)
  |  Tuple3 (Node Expression) (Node Expression)
  -- ...

With the discussion in #205, we could even go

type Expression
  = Tuple2 Range (Node Expression) (Node Expression)
  |  Tuple3 { firstComma : Range, secondComma : Range } (Node Expression) (Node Expression)
  -- ...

(maybe with a type alias for Tuple3)

a good chunk of the time they're just going to be handled the same

For generic operations like tree traversals, yes. For the rest, I'm not too sure that this is true.

[lishaduck]

I just read "Rewriting elm-syntax and future plans" and took a look at the v8 proposals. As someone who doesn't really use elm-syntax, I'm just wondering aloud here. Is there a reason why the following api doesn't work?

type Expression
  = Tuple TupleSize (Node Expression) (Node Expression)
  -- ...

type TupleSize
  = Unit
  | Twople
  | Triple

Naming of Twople could obviously be improved.
It provides typesafety, casing independently, and casing together.

Also, I do think of a unit as a no-element tuple, but parenthesis are different.

[lue-bird]

• imagine you cased on Triple, how do you get the Node Expression for the third part?
• imagine you cased on Unit, what dummy expressions should be put as the two arguments? (IMO there shouldn't really be "dummy expressions" in elm-syntax)

I imagine what you had in mind was something like

= Tuple (Maybe ( Node Expression, Node Expression, Maybe (Node Expression) )

but the ergonomics of that aren't better than regular variants for each case and it's more confusion as well.

Thanks for the idea! I hope I understood what you were trying to suggest?

[lishaduck]

• imagine you cased on Triple, how do you get the Node Expression for the third part?
• imagine you cased on Unit, what dummy expressions should be put as the two arguments? (IMO there shouldn't really be "dummy expressions" in elm-syntax)

Oh, yeah 🤦‍♂️

I guess I meant more of the following, but it doesn't really case well:

type Expression
  = Tuple TupleType
  -- ...

type TupleType
  = Unit
  | Twople (Node Expression) (Node Expression)
  | Triple (Node Expression) (Node Expression) (Node Expression)

It's more explicit about what it is than the nested maybes, but you can't partially case in Elm (right? no Type (Value wildcard) ->?)¹, which makes this annoying.

Footnotes

1. Phrased that funnily. What I mean is that you couldn't get the stuff out without another case, right? I was thinking you could but now I'm doubting myself. ↩

[lue-bird]

you can nest any patterns inside patterns if that's what you're asking. It's a really nice feature of elm.

And yeah, with these types, the suggestion is more reasonable. Still think it's more confusing than making them variants on the "main Expression type" but that's personal opinion at this point.

[lishaduck]

you can nest any patterns inside patterns if that's what you're asking. It's a really nice feature of elm.

Yeah, I think so.

And yeah, with these types, the suggestion is more reasonable. Still think it's more confusing than making them variants on the "main Expression type" but that's personal opinion at this point.

Yeah, that's fair. I personally feel that, if it's just another word but not otherwise more verbose, it strikes a good balance between being able to handle them together or separately; but as I said, I don't directly use elm-syntax. You're who it matters to.