[sc34wg3] Supporting variants in TMCL

[Lars Marius Garshol]

* 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  
of:

(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"?

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/