match pattern for txexpr*? #11

Closed
opened 5 years ago by AlexKnauth · 4 comments
AlexKnauth commented 5 years ago (Migrated from github.com)

Should there be a match pattern for txexpr*?

If so, should the match-expander look like this, or?

(txexpr* tag)                = (txexpr tag _ '())
(txexpr* tag attrs)          = (txexpr tag attrs '())
(txexpr* tag attrs elem ...) = (txexpr tag attrs (list elem ...))

The weird things are:

  1. How should it deal with "optional pattern" arguments?
  2. How should it deal with "sequence of pattern" arguments?

If an optional-pattern isn't supplied, should it be filled in with _, or the pattern for the default argument? Concretely, if attrs isn't supplied should it be _ or '()? For now I'm leaning towards _, because that's common for match-pattern forms like ?, regexp, and struct*.

If a sequence-pattern is empty (which looks the same as not being supplied), should it be filled in with _, or with the empty sequence? I think it should be the empty sequence, because otherwise it would be hard or unintuitive to express that it must be empty.

However, if someone thinks about optional and sequence arguments as similar, this might seem inconsistent. An unsupplied optional argument looks the same as an empty sequence argument. So, they might think it's weird that if they don't supply any attributes pattern anything goes, but if they don't supply any elements patterns it must be empty.

I'm also unsure with the optional-ness of the attributes pattern because I'm somewhat afraid that someone might try to match with (txexpr* tag elem ...) when they should use (txexpr* tag _ elem ...).

Should there be a match pattern for `txexpr*`? If so, should the match-expander look like this, or? ``` (txexpr* tag) = (txexpr tag _ '()) (txexpr* tag attrs) = (txexpr tag attrs '()) (txexpr* tag attrs elem ...) = (txexpr tag attrs (list elem ...)) ``` The weird things are: 1. How should it deal with "optional pattern" arguments? 2. How should it deal with "sequence of pattern" arguments? If an optional-pattern isn't supplied, should it be filled in with `_`, or the pattern for the default argument? Concretely, if `attrs` isn't supplied should it be `_` or `'()`? For now I'm leaning towards `_`, because that's common for match-pattern forms like `?`, `regexp`, and `struct*`. If a sequence-pattern is empty (which looks the same as not being supplied), should it be filled in with `_`, or with the empty sequence? I think it should be the empty sequence, because otherwise it would be hard or unintuitive to express that it must be empty. However, if someone thinks about optional and sequence arguments as similar, this might seem inconsistent. An unsupplied optional argument looks the same as an empty sequence argument. So, they might think it's weird that if they don't supply any attributes pattern anything goes, but if they don't supply any elements patterns it must be empty. I'm also unsure with the optional-ness of the attributes pattern because I'm somewhat afraid that someone might try to match with `(txexpr* tag elem ...)` when they should use `(txexpr* tag _ elem ...)`.
mbutterick commented 5 years ago (Migrated from github.com)

The txexpr* is barely necessary to begin with, so I don’t think a txexpr* match pattern is necessary (especially if it creates avoidable confusion)

IIUC the rule of thumb is that a match expander, in destructuring, should mirror the behavior of the constructor. (txexpr* 'p "foo") is not allowed by txexpr*, so it’s fair that a txexpr* match pattern would not match '(p "foo").

The `txexpr*` is barely necessary to begin with, so I don’t think a `txexpr*` match pattern is necessary (especially if it creates avoidable confusion) IIUC the rule of thumb is that a match expander, in destructuring, should mirror the behavior of the constructor. `(txexpr* 'p "foo")` is not allowed by `txexpr*`, so it’s fair that a `txexpr*` match pattern would not match `'(p "foo")`.
AlexKnauth commented 5 years ago (Migrated from github.com)

(txexpr* 'p '()) is allowed though, so what do you mean by that?

`(txexpr* 'p '())` is allowed though, so what do you mean by that?
AlexKnauth commented 5 years ago (Migrated from github.com)

Oh, I see. Someone using txexpr* as a normal value would get an error if they tried to use (txexpr* tag elem ...), so it's less likely that they would try the same thing as a pattern?

The problem is that with txexpr* as a normal value used wrongly, they get an error, but with the match-pattern used wrongly, it could silently bind the "wrong" thing, and not error.

Oh, I see. Someone using `txexpr*` as a normal value would get an error if they tried to use `(txexpr* tag elem ...)`, so it's less likely that they would try the same thing as a pattern? The problem is that with `txexpr*` as a normal value used wrongly, they get an error, but with the match-pattern used wrongly, it could silently bind the "wrong" thing, and not error.
mbutterick commented 5 years ago (Migrated from github.com)

I’m sure you’re right. Let’s leave it out since it’s unlikely to add much but confusion.

I’m sure you’re right. Let’s leave it out since it’s unlikely to add much but confusion.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mbutterick/txexpr#11
Loading…
There is no content yet.