Full tuple unpacking

[ptal]

The following example gives the type ((String, PExpr), PExpr), we would like instead (String, PExpr, PExpr).

let_expr = let_kw let_binding in_kw expression
let_binding = identifier bind_op expression

[pczarn]

I think it's better to leave this unchanged. I'd prefer to use an explicit tuple unpacking operator, if anything at all.

[ptal]

Really? I believe that your AST will seldom use a type of the form (A, (B,C)) but either (A, B, C) or a custom type. The use case was as follow:

factor = let_expr > let_in_expr
let_expr = let_kw let_binding in_kw expression
let_binding = identifier bind_op expression

fn let_in_expr(let_binding: (String, PExpr), expr: PExpr) -> PExpr {
  Box::new(LetIn(let_binding.0, let_binding.1, expr))
}

In this example, I feel it is more clear and convenient to unpack so the function becomes:

fn let_in_expr(identifier: String, expr: PExpr, body: PExpr) -> PExpr {
  Box::new(LetIn(identifier, expr, body))
}

Can you provide a use case for which tuple unpacking is not convenient?

[pczarn]

Ah, thanks for clarification. I'm thinking about situations where the tuple is directly included in a sequence or in the parse result, rather than consumed by a function. Then, the current behavior follows WYSIWG WYSIWYG in the simplest way. I'm writing a parser generator that takes a slightly different approach to typed parsing expressions.

[pczarn]

Keep in mind that the following works: (even though it's less readable, admittely)

fn let_in_expr((identifier, expr): (String, PExpr), body: PExpr) -> PExpr {
  Box::new(LetIn(identifier, expr, body))
}

[ptal]

Thanks for your feedback. Actually, I didn't know pattern matching directly work on function's parameters. I'm curious about your approach to write a parser generator, do you want to discuss more about it?

[pczarn]

I can explain my approach to making a parser generator. However, I would rather write an exhaustive blog post about it. (I don't have a blog yet.) The most interesting stuff is still at a concept stage, anyway.

I think there are two important areas to creating a parser generator: a) the set and character of fundamental features it provides, and b) the ways users are allowed to describe grammars.