Tagged templates

[elsassph]

ES6/2015 has tagged templates, and it could be handy, esp. with macros:

tag`some string ${with} variables`

which becomes:

tag(["some string ", " variables"], with)

The function can return anything, not just a string. It would make some fancy macros functions fancier.

See: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Template_literals#Tagged_template_literals

[back2dos]

Is this critically better than tag('some string $with varialbes') where tag is a macro?

[ncannasse]

I agree with @back2dos, it's a quite specific case of macros that can already be implemented within the current language without requiring any syntactic addition.

[back2dos]

I was actually asking a genuine question. While I'm drawn to the same conclusion as you are, I wouldn't want to just assume it's true without Philippe saying something more about it.

[elsassph]

Ah come on, we just want to avoid typing a couple of parenthesis, is that a lot to ask? :)

It's not something that can be done with a macro efficiently.

For instance if we want to do: @jsx '<thetemplate>' or jsx'<thetemplate>' we can't do it without a full AST inspection which is awfully wasteful because you can have them anywhere in the codebase.

As we can't have DSLs in Haxe, it would be the next best thing. 'cause parenthesis suck.

[nadako]

I remember we discussed metadata macro triggers at WWX, that would allow @jsx '<template>' syntax without global build macros. OTOH, one could already just make a static jsx macro-function and then static-import it (and/or put to the import.hx file) and use like jsx('<template>')

[back2dos]

That being said, we could extend import.hx to allow registering @:tag as a macro on file system based scopes, on either type, field or expression scopes. Shouldn't be too hard to devise a syntax for that either, if this is generally considered acceptable.

[elsassph]

Fair point, import.hx will make jsx('<template>') palatable, but that's why I'm hinting that being able to drop the parenthesis would be a little syntax bonus.

[sledorze]

I agree - contrary to a 'popular' belief - syntax matters

[ncannasse]

If you want Haxe to become somewhat innovative syntax-wise, you're looking at the wrong language :) the whole benefit of Haxe is that it's being quite conservative, making it easy to read and adopt when coming from other mainstream languages, which is maybe the reason some of you adopted it in the first place.

I can understand that after years of using Haxe you don't care anymore and would just like the syntax to be "shorter", but it's also my role to keep the original language goals. In general, I don't think that shorter is better - or at least not for syntax :) Look at Perl for a good example.

If we would like to go this way, this would require creating an entirely new language syntax based on a very different perspective, but then it would not be Haxe anymore.

[ncannasse]

Just another thing I would like to add: additional syntax has a cost which that it needs to be learnt and remembered. I'm fine with specific syntax for the mostly used language features because people will soon feel it's became natural to use (metadata for instance). But when introducing some more particular features, they should when possible reuse existing syntax so it can easy be read, understood and remembered even by people that haven't been exposed to it yet.

[back2dos]

So if reusing existing syntax is ok, what would stand in the way of allowing to assign meaning to an expression level metadata tag from within an import.hx (as opposed to making it global, which might result in name clashing)? The result, e.g. the ability to write @:jsx "<some jsx code>" is something that can be achieved with macros anyway. You can't stop people from doing this, but you can make it significantly less of a PITA to wait for the compiler to process this kind of code. At the core, I think that is what this issue is about.

[elsassph]

Exactly, inline @foo processing without brute force AST exploration is a legitimate use case.