Target the greatest language in existence?

[Michiel Crefcoeur]

Alright, that was clickbait and I know this will sound like a wacky plan but hear me out!

What if Haxe could compile to.... Haxe?

This would serve three purposes:

1. It would serve as the ideal reference target for new target implementers as it should always support every single language feature
2. It would serve as a tool to debug macro's as the output would be Haxe code with all macro's translated into the final code
3. It would serve as a tool by which to identify optimization opportunities for both the incoming Haxe code as well as the compiler as the output would show the effects of inlining and other optimizations done at the AST level (if that's where these optimizations take place)

It might also come in handy for unit-testing the compiler.

I might be completely wrong as I have practically zero technical compiler knowledge so please correct me if I am.

Curious to hear what you guys have to say about my little brainfart.

[Dan Ogles]

I love this idea. :)

[Ashiq A.]

I had a related thought many times: why isn't the Haxe compiler written in Haxe itself? Granted, some parts will not be in Haxe, but other languages often write a "core" language and use that language for their own standard library.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Cauê Waneck]

I've actually wanted to do this some time ago. It was part of a plan to automatically convert Java code into Haxe, and consisted of two parts: one that would convert the syntax (without typing) from Java to Haxe, and another part that would use macros to type the expressions and fix some expressions based on typing. In order to not need to execute that typing macro every time the expression is called, I was thinking about making a Haxe->Haxe target.

It shouldn't be too hard in the end to do that; In fact, I think `-D dump=pretty` almost does that right now

[Cristian Baluta]

I didn't understood the purpose but now that swift is open source maybe some smart guys can think of something useful

Băluță Cristian
http://ralcr.com
http://imagin.ro

[Michiel Crefcoeur]

I wouldn't have even been surprised if you'd have said you had the code lying around somewhere already :-)

Would you say the use cases I've stated are valid and, given your experience in implementing compile targets, could you name more?

You say that you don't expect it to be too hard. Would you say there's enough use for it to justify the effort?

Apart from the fact that it would be super-duper-cool in a nerdy kind of way.

[Johann]

On Monday, June 8, 2015 at 11:26:46 PM UTC+2, Michiel Crefcoeur wrote:

I wouldn't have even been surprised if you'd have said you had the code lying around somewhere already :-)

Would you say the use cases I've stated are valid and, given your experience in implementing compile targets, could you name more?

You say that you don't expect it to be too hard. Would you say there's enough use for it to justify the effort?

Apart from the fact that it would be super-duper-cool in a nerdy kind of way.

There are many very good use-cases for a Haxe->Haxe target along with a feature to easily emit complete Haxe source-files from macros. Most of the required functionality is implemented already in the compiler. However, some of the information of the original sources would be lost - parts of the comments and individual formatting, basically. That's not a show-stopper, however, and the benefits outweigh the issues by far. 

regards, Johann

[Michiel Crefcoeur]

That's a great use case indeed! :-)

For example, you could write a macro that generates Haxe source code based off of a database schema and meta-data or even generate Haxe source code based off of data in a database.

If this would then be compiled to Haxe code, you could use those generated sources in your project (or distribute as a library) and generate the sources again only when needed.

There's probably some projects out there already that would benefit from this.

Regards,

Michiel

[Marcelo de Moraes Serpa]

This sounds interesting, but I think we're confusing two things here:

1) A Haxe target for Haxe

2) Bootstrapping Haxe in Haxe

For 2, see: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29, and http://stackoverflow.com/questions/13537/bootstrapping-a-language. We have talked about #2 many times before, also.

I think the OP is talking only about #1, which sounds interesting, but I'm still having a hard time figuring out more use cases other than the one you mention. I think that would be mainly useful to expand and output the macro AST to the full Haxe source code?

Cheers!

-- Marcelo

[Michiel Crefcoeur]

Yes, Indeed: for now I'm only interested in #1: Compiling Haxe code to Haxe code in the form of a Haxe compiler target which might sound nonsensical at first but has some really practical uses once you think about it.

BTW: The compiler might still need to know which language to target virtually, that could probably be established by using a conditional compilation flag specifying the virtual target:

haxe -haxe <directory> -D js

Which would then compile to haxe code but apply conditional compilation as if you would have called:

haxe -js <file>

The more I think about it, the more I'm wondering why Haxe doesn't already compile to Haxe! :-)

Maybe it already does and I don't know about it???

Regards,

Michiel

[Michiel Crefcoeur]

Just to be clear:
I'm talking about compiling Haxe code into Haxe code, (src/Foo.hx -> out/Foo.hx) not writing a Haxe compiler in Haxe which has been discussed several times before.

[Cristian Baluta]

Why not just copy paste it? :P

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

[Michiel Crefcoeur]

You're not fooling me, troll! :P

[Marcelo de Moraes Serpa]

Michiel, what other use cases are you referring to, for an Haxe target? It’d be nice to know. I can’t think of many, besides the ones we discusses here.

[Mark Knol]

I can imaging quite some cases where you want to target haxe, especially when you write macros, it would be nice to generate the output to real source file. Sometimes you need a macro once, instead of running this macro over and over again. Macros slows down compile time, (especially with file system related stuff) you just run it once to generate the haxe sources out of it and then its blazing fast again.

Some examples:
Generate haxe interfaces based on database objects (or xml/json definitions)
Generate static fields on class based on file system related stuff
Generate extern classes based on macros

The nice thing of "real" classes is that you can use "go to definition" in your editor.

[Johann]

On Wednesday, June 10, 2015 at 11:11:05 PM UTC+2, FullOfCaffeine wrote:

Michiel, what other use cases are you referring to, for an Haxe target? It’d be nice to know. I can’t think of many, besides the ones we discusses here.

The main use-cases are macro-driven transformations and IDE-support for computationally expensive whole-program / whole-package / whole-module transformations e.g. based on static analysis that's best done in the compiler directly. Both of these, just as macros themselves, have such a broad spectrum of possible individual use-cases that speaking of them as one or two would be a bit misleading. 

Parser generators are one example for for specialized library generators, with such a target it would be trivial to work around the currently missing @:build macro support in macros themselves, and would hence make it easy to use hxparse in macros. 

The general answer is that use-cases are limited by the users imagination only. Haxe already is a spectacularly powerful meta-programming toolkit and adding these multi-stage/full-roundtrip capabilities would make it even better.

regards, 

Johann

[Michiel Crefcoeur]

Thank you Johann, I couldn't have said it better myself! :-)

So... should we propose it as a feature?

regards,

Michiel

[Marcelo de Moraes Serpa]

Johann, nice, I can see how this could be useful now. Perhaps it would worth creating an issue and tag it as a feature-request (not sure if this is part of the current workflow in github, but @josefiene might confirm) in the Haxe compiler github repo so that it’s not lost in the mailing list?

— Marcelo.

[Simon Krajewski]

Am 11.06.2015 um 21:07 schrieb Marcelo de Moraes Serpa:

Johann, nice, I can see how this could be useful now. Perhaps it would worth creating an issue and tag it as a feature-request (not sure if this is part of the current workflow in github, but @josefiene might confirm) in the Haxe compiler github repo so that it’s not lost in the mailing list?

You could probably get 95% done by connecting the already existing type printer (from --gen-hx-classes) with the already existing expression printer (from -D dump=pretty).

After that you can spend a month figuring out how to translate pattern matching results back to something sane.

Simon

[Cauê Waneck]

I've been thinking about this, and there are some problems. For example, haxe.ds.Vector will already inline the target-specific code.

I don't think this will work out very well in the end

--

[Johann]

On Thursday, June 11, 2015 at 9:25:28 PM UTC+2, Cauê Waneck wrote:

I've been thinking about this, and there are some problems. For example, haxe.ds.Vector will already inline the target-specific code.

There are some options to deal with this, e.g. black-/white-listing types to prevent inlining and perhaps even following in some cases. Currently I'm doing the source-writing manually, and while it works, a general, agreed upon solution with a good macro API would be very helpful. It's not that rare that people ask about things that a source writer would be a good solution to.

[szczepan]

Reading through github haxetink repo I saw a method which name suggested it produces haxe source code. Can't find it now, though. Anyone knows which one it is and what really does?

I'm exploring an idea (no code yet :-)) of generating DB metamodel like with JPA (JEE programmer here...) with macros and caching to generated source files - seems to be a perfect use case.

[szczepan]

Found it! :)

line 145:

    https://github.com/back2dos/tinkerbell/blob/master/src/tink/macro/tools/TypeTools.hx

and then:

    https://github.com/back2dos/tinkerbell/blob/master/src/tink/macro/tools/Printer.hx

What does it actually do?

[Johann]

On Friday, June 12, 2015 at 12:32:10 PM UTC+2, szczepan wrote:

Found it! :)

line 145:

    https://github.com/back2dos/tinkerbell/blob/master/src/tink/macro/tools/TypeTools.hx

and then:

    https://github.com/back2dos/tinkerbell/blob/master/src/tink/macro/tools/Printer.hx

What does it actually do?

Printer is now in the std lib, called haxe.macro.Printer - http://api.haxe.org/haxe/macro/Printer.html 

you can use it like this:

using haxe.macro.Tools;

@:publicFields

class X {

    macro function print_expression_at_compiletime(e){

        trace(e.toString());

        return e;

    }

}

It turns an expression (as well as other things, like fields) into valid Haxe code. 

regards,

Johann

[szczepan]

Yep, that's why namespaces didn't make much sense. ;) Thanks!

This should suffice then to make 'cached macros' or am I missing something?