Comprehensive Haxe syntax demo file?

[arotter (Alexander Rotter)]

I’m currently trying my hands on a Haxe plugin for Prettier (mostly as a personal development project and in a somewhat slow and arduous journey since I’m not really a JS developer ), and was wondering if there’s some kind of demo/test file - or a small-ish group of such files - that contain (more or less) comprehensive examples of the Haxe syntax and features.

Right now I’m testing my current progress against a random file from my team’s game, but there’s a lot of things currently not included in that (macros, arrow functions, nested arrays or anonymous objects, typedefs, complex metadata, abstracts, enums, …).

I’ve already checked the test sources of Haxe and HaxeFormatter on GitHub, but those are literally hundreds of files, which makes perfect sense for a test setup but is not really suitable for my current progress.

There are several language features (e.g. the more intricate pattern matching stuff) that I haven’t used a lot yet, and which I’m pretty sure would miss when building such a file myself, so I’d be really thankful for any pointers here.

[rathewolf (rahil627)]

1. Learn haxe in Y Minutes
2. Language Features - Haxe - The Cross-platform Toolkit
3. Haxe Beginner articles overview - Beginner - Haxe programming language cookbook

i don’t know of an examples tutorial folder, but maybe there’s some stuff out there in the github universe?

…ohhhhh i understand what you mean now… you need like all the possible ways that each feature can be written… hmmm, yeah, the docs is all can think of. sorry

wait a minute, HaxeFormatter?.. is that different form checkstyle?..

is there something that Prettier can do that HaxeFormatter can’t, or is this purely for practice/education?

…well, maybe you’ve got yourself another project! LOL. It’d be neat to have, as a learn by example kind of way, but comprehensive. Learn x in y minutes: the complete edition!

update: i’ve just found features that might not even be in the docs! …and some of them are amazing

GitHub - HaxeFoundation/haxe-evolution: Repository for maintaining proposal for changes to the Haxe programming language

[arotter (Alexander Rotter)]

@rathewolf

wait a minute, HaxeFormatter?.. is that different form checkstyle?..

No, I did mean the HaxeCheckstyle/haxe-formatter.

@rathewolf

is there something that Prettier can do that HaxeFormatter can’t, or is this purely for practice/education?

It’s mostly for personal development, but I hope that I can push this to the point where I can put it out on GitHub.

I started this project because I really like the way Go handles formatting - the language comes with gofmt, a default formatter, and people just use that one.

We’ve had a lot of discussions about how to format code in our team, with lots of bike shedding about (and modified formatting rules for) arrays, anonymous structures, method chains, and so on. That was a lot of time effectively wasted on inconsequential minutiae.

I think a formatter with fewer options that runs on an already widely used platform that follows a similar principle (that’s why Prettier calls itself “opinionated” ^^) could be a nice addition.

And it’s also a really good excuse to mess around with JS and some aspects of Haxe I don’t come in contact with normally (since I’m using @Simn’s hxparse and have to dive into Haxe’s AST).

[ablum (Alexander Blum)]

@arotter

I started this project because I really like the way Go handles formatting - the language comes with gofmt, a default formatter, and people just use that one.

haxe-formatter is integrated with language server, so it’s basically the default formatter that comes with Haxe tooling. it’s disabled by default, because not everyone likes auto-formatting.

@arotter

We’ve had a lot of discussions about how to format code in our team, with lots of bike shedding about (and modified formatting rules for) arrays, anonymous structures, method chains, and so on. That was a lot of time effectively wasted on inconsequential minutiae.

welcome to programming in a team!
you will have the same discussion again next time you start with a new team - unless there’s already some company policy in place, in which case someone else has had that meeting…

@arotter

I think a formatter with fewer options that runs on an already widely used platform that follows a similar principle (that’s why Prettier calls itself “opinionated” ^^) could be a nice addition.

And it’s also a really good excuse to mess around with JS and some aspects of Haxe I don’t come in contact with normally (since I’m using @Simn’s hxparse and have to dive into Haxe’s AST).

I don’t know anything about prettier or it’s architecture (and I don’t care enough to look through its Javascript sources) so my naive approach would be to simply wrap formatter in a plugin. but that might not be as easy as it sounds since prettier seems to expect operations to be split into a parser and a printer part.

building your own parser capable of producing a useful AST for any given Haxe code is quite a task. I’m looking forward to see what you come up with.

[arotter (Alexander Rotter)]

@ablum

haxe-formatter is integrated with language server, so it’s basically the default formatter that comes with Haxe tooling. it’s disabled by default, because not everyone likes auto-formatting.

Ah, good to know. I tried getting into that code, but I admit that I was hitting a pretty big wall and bounced off very early on.

@ablum

welcome to programming in a team!
you will have the same discussion again next time you start with a new team - unless there’s already some company policy in place, in which case someone else has had that meeting…

Which is why I really like the approach of gofmt and also Prettier.

You can’t bikeshed about formatting options if there are no formatting options. You just use the tool, get used to how the code looks, and then move on to the actually important issues.

@ablum

but that might not be as easy as it sounds since prettier seems to expect operations to be split into a parser and a printer part.

Yes, parsing and printing are separate things in Prettier’s architecture, and I’ll also be the first to admit that their documentation for plugin development is sort of terrible. The fact that they don’t have a complete example from start to finish for a simple fileformat (e.g. INI files or whatever) makes some things really difficult to figure out and connect.

But wrapping haxe-formatter would also not work on a conceptual level with Prettier, since their approach is to minimize the configurable options to avoid any possibility for bikeshedding from the start.

@ablum

building your own parser capable of producing a useful AST for any given Haxe code is quite a task

That was actually one of the easier parts, since I’m not writing my own parser but instead use hxparse transpiled to JS to create the AST. That worked completely out of the box without any issues, which was a really pleasant surprise.

The much more difficult part was actually understanding the AST’s structure and extracting the necessary data to rebuild the code from it, since I’ve never really worked with parsers/compilers in much detail before.

My first steps were loading the transpiled parser in a HTML page and feeding it code via the browser console to be able to properly browse the output because it’s over 9000 levels of nested objects and arrays otherwise.

I’ve already got all of the syntax and features used in my current dummy file to format properly (at least on a basic level), but now I need to look at the other things, which is why I was asking if there was already such a syntax demo file around.

@ablum

I’m looking forward to see what you come up with.

Oh, I’m curious as well, especially since I’m currently stuck with an issue regarding Prettier’s handling of comments, which will make this whole thing DOA if I can’t fix it.

[ablum (Alexander Blum)]

@arotter

But wrapping haxe-formatter would also not work on a conceptual level with Prettier, since their approach is to minimize the configurable options to avoid any possibility for bikeshedding from the start.

when you use formatter’s API you are in control of which configuration options you pass along / overwrite from its default config. so instead of reading hxformat.json files and passing them on to formatter, you take your settings from whatever configuration file prettier uses and translate them to corresponding formatter config values.

@arotter

That was actually one of the easier parts, since I’m not writing my own parser but instead use hxparse transpiled to JS to create the AST. That worked completely out of the box without any issues, which was a really pleasant surprise.

The much more difficult part was actually understanding the AST’s structure and extracting the necessary data to rebuild the code from it, since I’ve never really worked with parsers/compilers in much detail before.

hxparse is a generic lexer / parser library and as such does not know anything about Haxe syntax.
since you are talking about understanding Haxe’s AST, I assume you are using haxeparser lib which is an actual lexer / parser for Haxe code?

[arotter (Alexander Rotter)]

@ablum

when you use formatter’s API you are in control of which configuration options you pass along / overwrite from its default config. so instead of reading hxformat.json files and passing them on to formatter, you take your settings from whatever configuration file prettier uses and translate them to corresponding formatter config values.

According to the documentation you can override any provided config with a more local file:

Formatter uses hxformat.json files for configuration. It searches for a hxformat.json file closest to the file being formatted, starting with the file’s folder and moving upward all the way to your root folder. A configuration file in a subfolder will always overwrite any settings from a top or higher level folder.

So either it is not at all possible, or requires some kind of modification I couldn’t identify before bouncing.

@ablum

I assume you are using haxeparser lib which is an actual lexer / parser for Haxe code?

Yes, that one. No idea how the other one got stuck in my mind, sorry for the confusion.

[ablum (Alexander Blum)]

@arotter

According to the documentation you can override any provided config with a more local file:
…
So either it is not at all possible, or requires some kind of modification I couldn’t identify before bouncing.

when running formatter in CLI mode or with languageserver hxformat.json handling works as described. so far so true.
however when you are using formatter as a library you are in control of what configuration options apply. so you can load any hxformat.json from disc or create a configuration in memory and use it regardless of any exisisting config files.
hence the optional config parameter in Formatter.format API calls. CLI and languageserver use Formatter.loadConfig to locate and load a hxformat.json configuration file closest to the file being formatted but it’s entirely up to you to use it.

@arotter

Yes, that one. No idea how the other one got stuck in my mind, sorry for the confusion.

I thought so, but wanted to clarify.
haxeparser will produce an AST when using it’s HaxeParser class (and it’s fairly up to date with latest Haxe syntax). but you should be aware of a few road blocks that come with it:

1. no comments in AST
2. AST will contain only one path of conditional compilation so #if true callA(); #else callB(); #end will only give you AST for callA()
3. you will have to retain information about empty lines in source files used for visual separation of sections of code.

those are just the ones that immediately come to mind…