match pattern for txexpr*
?
#11
Closed
opened 6 years ago by AlexKnauth
·
4 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Should there be a match pattern for
txexpr*
?If so, should the match-expander look like this, or?
The weird things are:
If an optional-pattern isn't supplied, should it be filled in with
_
, or the pattern for the default argument? Concretely, ifattrs
isn't supplied should it be_
or'()
? For now I'm leaning towards_
, because that's common for match-pattern forms like?
,regexp
, andstruct*
.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 ...)
.The
txexpr*
is barely necessary to begin with, so I don’t think atxexpr*
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 bytxexpr*
, so it’s fair that atxexpr*
match pattern would not match'(p "foo")
.(txexpr* 'p '())
is allowed though, so what do you mean by that?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.I’m sure you’re right. Let’s leave it out since it’s unlikely to add much but confusion.