[sc34wg3] Supporting variants in TMCL
Lars Marius Garshol
larsga at garshol.priv.no
Mon Nov 2 06:08:53 EST 2009
* Steve Pepper
> [designing variant constraints is difficult]
> I hope you excuse me if I say that I don't find this argument
> particularly compelling. Surely if a language cannot meet a
> legitimate requirement, then there is a problem with the language,
> not with the requirement?
We don't disagree on this. What I was saying was more along the lines
(1) There is no proposal on the table.
(2) I'm not sure how to put one together.
(3) Implicitly: those wanting this feature had better come up with a
proposal if they want to see this happen.
(4) Implicitly: if those wanting this feature don't want it bad
enough to do (3), then, well...
> Unfortunately I don't understand the inner workings of TMCL well
> enough to be able to propose a solution. But are you sure you are
> not trying to create something more general than is really needed?
That could well be. Hence (2) and (3) above.
> Would it help if I were to formulate a constraint in English that I
> believe would do the job:
> NAMES of type "foo" belonging to
> TOPICS of type "bar" can or must have (one or more)
> VARIANTS in the scope "baz"
> In other words, we need to be able to constrain every variant
> statement on the basis, not of its type, but of what type of name it
> is a variant of (and what type of topic that name belongs to).
Is "baz" here a topic type, the way it is in nearly all other
constraints (except scope-required-constraint), or is it an instance
(as in scope-required-constraint)? In other words, is the requirement
that the variant contain the topic "baz" in its scope, or that it
contain an instance of "baz"?
More information about the sc34wg3