add tuple parsing for types and expressions #246
Conversation
✅ Deploy Preview for dada-lang ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
As I said, I was hoping to not have 1-tuples be a thing, but I can't really remember where I landed on that. Otherwise this looks good to me. Probably a good idea to land it as is and maybe we refine the 1-tuple case later.
I do have to warn you, I welcome the contribution, but I also wasn't expecting it, I'm still actively hacking on the type checker bits, so I wouldn't want major changes there so as not to get too many conflicts.
But I could probably close a bunch of issues and open up new ones, I have various ideas I want to pursue.
components/dada-parser/src/expr.rs
Outdated
| AstExpr::eat_comma_with_trailing_info, | ||
| )? { | ||
| let kind = if elts.len() == 1 && matches!(trailing, crate::Trailing::No) { | ||
| AstExprKind::Parenthesis(elts.pop().unwrap()) |
There was a problem hiding this comment.
I would if possible like to eliminate the difference between 1-tuples and types. I forget why I thought this could work but that was my plan, which is why I didn't distinguish Parenthesis from tuple types.
There was a problem hiding this comment.
Now, in type position (i32) and in expression position (42), it's interpreted as a one-element tuple.
There was a problem hiding this comment.
Or did you mean that the type should be like tuple[..]?
gvozdvmozgu
force-pushed
the
tuple-parsing
branch
from
6d9fc4d to
26fb81d
Compare
gvozdvmozgu
force-pushed
the
tuple-parsing
branch
from
26fb81d to
986fc10
Compare
No description provided.