Spec draft tokens

[Yoric]

Hey, @syg, could you take a look at this?

[syg]

Sorry I seem so obstinate about this: I still don't understand the motivation very well. Why is it undesirable to have the implementation understand the, e.g. the moduleSpecifier inside an Import node is to be treated differently than a plain identifier use? The immediate surrounding node type should be readily available information, right? Building this information into the node type still seems redundant and is more about encoding semantics than syntax.

[Yoric]

For one thing, we have the problem that typedef string Foo; typedef string Bar; actually means that Foo and Bar are exactly the same thing. So, we cannot decide that Foo has some restrictions but Bar doesn't. So, I tend to believe that before being useful, this fixes an actual spec error.

Now, I find your example undesirable because it forces us to introduce hardcoded logics specifically to work around the fact that we use the same type for unrelated pieces of data. In any programming language, if I have different types of data, I'm going to newtype them, I just want to do the same here :)

[syg]

Now, I find your example undesirable because it forces us to introduce hardcoded logics specifically to work around the fact that we use the same type for unrelated pieces of data.

I agree that for string literals with different lexical grammars, this type differentiation is desirable. On the other hand I think differences beyond grammar differences don't need to be encoded as different types in the AST tree grammar. Do you agree with that?

For example, one can argue that an identifier use of a local binding is different than an identifier use of an outer binding, or that a function statement that contains a recursive use is different than a function statement that is non-recursive. I am explicitly not interested in encoding semantic differences of that kind.

[Yoric]

I can go with that.

[Yoric]

@syg So, what's your opinion on this specific patch?

[Yoric]

An alternative would be to wrap them in interfaces instead

interface Identifier {
  value: string;
}
interface IdentifierName {
  value: string;
}
interface Label {
  value: string;
}
interface IdentifierLikePropertyNameLiteral {
  value: string;
}
interface PropertynameLiteral {
  value: string;
}
interface ModuleSpecifierLiteral {
  value: string;
}
interface RegExpFlags {
  value: string;
}
interface StringLiteral {
  value: string;
}

with specifications for the correct values for each of these value fields.

Either choice will require some work on the implementation side.

[syg]

I prefer the interface wrapping for now.

[Yoric]

Ok, that works. I'll reformulate this as an interface.

Then I'll spend a few days trying to get the code to work with that :)