Joey

Also another issue is Generic types of a Union needing a default type somehow even though it could potentially be any of the types of the Union.

> That the Haxe compiler's generation of instantiated code from generic functions does not know how to add two values together using the instantiated type is a severe limitation. Yes...

Okay here is the layout of the problem so far. Generic types need to support the following: * type extensions, example: adding methods to a named underlying GoInt type *...

> Of course, the best result would be if the project could use Haxe generics. * Go Generic function = Macro function * Go Generic type = Haxe Generic type...

So much macro writing..... This is the current issue: ``Field index for _add not found on prototype github_com.go2hx.go4hx.rnd.L_static_extension`` It involves referencing a static extension macro but it doesn't exist at...

Actions speak louder then words, very pleased with a first draft now committed @elliott5 I wrote up what's still missing in the commit and I hope it's clear enough to...

@elliott5 Yes you are correct. Basically macro functions must be called straight away so in order to have the Haxe compiler not complain. There is a Haxe compiler issue holding...

@elliott5 yes even better I could check for name conflicts and then simply make those functions non modular and instead in a class, shouldn't change anything functionality wise, only slightly...

github action beta for pages will make compiling all of the sources together much easier and more automated. The readme will be able to be compiled into html, as well...

Working now, go install needs to be bootstrapped in order to be able to run ``go test math`` at least for linux/amd64.