On Sun, Sep 25, 2016 at 10:14 PM David Mertz <mertz@gnosis.cx> wrote:

All of those might promote changes in tools. But the tools exist to aid working with a language, not the other way around.

I can't think of a way to know that this string is code and that string is an actual string. And figuring out means finding context dependency.

I would not want my editor to do that much highlighting distinction, but

assuming you do, all your comments defeat your own point. If an expression being within an annotation merits different evaluation semantics, it is a vastly smaller change to say a string being in an annotation merits different syntax highlighting.

It is a smaller change, but of a very different kind. I think annotations *theoretically* deserve different syntax (e.g. using the arrow notation) but keeping it an Expression keeps things simpler. Just like type(type) is not type, *theoretically*, but merging these objects is a very smart decision. So yes, I think it should have (and already has) different semantics; but its useful to have the same syntax (and related semantics). Simple keyword-highlighting "except inside quotes" should still be very useful. Elazar

On Sun, Sep 25, 2016 at 10:14 PM David Mertz <mertz@gnosis.cx> wrote:

All of those might promote changes in tools. But the tools exist to aid working with a language, not the other way around.

I can't think of a way to know that this string is code and that string is an actual string. And figuring out means finding context dependency.

I would not want my editor to do that much highlighting distinction, but

assuming you do, all your comments defeat your own point. If an expression being within an annotation merits different evaluation semantics, it is a vastly smaller change to say a string being in an annotation merits different syntax highlighting.

It is a smaller change, but of a very different kind. I think annotations *theoretically* deserve different syntax (e.g. using the arrow notation) but keeping it an Expression keeps things simpler. Just like type(type) is not type, *theoretically*, but merging these objects is a very smart decision. So yes, I think it should have (and already has) different semantics; but its useful to have the same syntax (and related semantics). Simple keyword-highlighting "except inside quotes" should still be very useful. Elazar