HaxeFoundation / haxe

Haxe - The Cross-Platform Toolkit
https://haxe.org
6.17k stars 655 forks source link

Issue 1117 - request : easy loading of ndll into macro context - haxe #1117

Closed issuesbot closed 10 years ago

issuesbot commented 11 years ago

[Google Issue #1117 : https://code.google.com/p/haxe/issues/detail?id=1117] by ploplopl...@gmail.com, at 01/08/2012, 16:58:40 loading ndll into macro context without recompilation of interp.ml. Enable a lot of great compile time stuff. (database creation, easy debug for writing llvm target...)

quote from https://groups.google.com/d/topic/haxelang/z90n4PDmIko/discussion

dlots Jul 17 I am wondering if its possible to load a ndll into the macro vm. At this time I am getting: s:/_flash/shared_haxe/nPostgres/src/haxe/sys/db/Postgresql.hx:120: characters 26-71 : You cannot use the library 'npostgres' inside a macro

Nicolas Cannasse Jul 17 It should be possible with the Haxe/Neko bridge, which already uses regexp.ndll and std.ndll for the xml parser and process API, but currently it's explicitely tied, it would require a bit of work in interp.ml to allow any ndll loading.

issuesbot commented 11 years ago

[comment from ncanna...@gmail.com, published at 03/09/2012, 10:17:37]

issuesbot commented 11 years ago

[comment from si...@haxe.org, published at 04/02/2013, 15:27:50]

issuesbot commented 11 years ago

[comment from si...@haxe.org, published at 24/02/2013, 17:12:14]

issuesbot commented 11 years ago

[comment from si...@haxe.org, published at 27/05/2013, 15:30:24] Do we (still) want this?

issuesbot commented 11 years ago

[comment from julopez....@gmail.com, published at 27/05/2013, 17:03:29] yes please ! I think macro is so far the core domain of haxe. top feature only provided by haxe. Somes others languages (scala, c#, f#...) have compiler plugins but nothing compared to haxe macro. Plugin requires compiler directives... are not integrated in the core syntax and can modify it sometimes. I think we should extends a lot features and facilities for macros and simplify integration of dependencies.

Java use a lot annotation for AOP (persistence, validation...) but everything is checked/defered at deployement of the application (runtime bootstrap) (database creation (java persistence, hibernate...), dependency injection coherence (CDI...)...). With haxe we can do this kind of things at compiletime, this is very very cool for runtime performances and feedback when coding. For this haxe can be better than java, C# scala...

Enabling loading dependencies without having to compile the compiler and knowing ML is a very good way to promote haxe (with some tutorial). I think we need this kind of things to show people that haxe have features that no other languages have. Actually, multi target, externs, modules, merge of structural subtyping with nominal typing (not trully), inference... are features proposed by every moderns languages (like ceylon or kotlin). Only our model of metaprogramming macro is our killer feature.

issuesbot commented 11 years ago

[comment from ncanna...@gmail.com, published at 27/05/2013, 19:48:16] Not sure if we want to keep the Neko bridge. We will remove its usage by wrapping sys.io.Process and PCRE in Ocaml for 3.2 (@ Simon please open an issue for it if there's not yet). I will look at it and decide at this time.

issuesbot commented 11 years ago

[comment from julopez....@gmail.com, published at 27/05/2013, 22:25:18] Are you saying you want to drop the virtual machine (and related rich api) in macro ?

Or we will keep such rich api but running by ML interpreter ?

ncannasse commented 10 years ago

Neko bridge is planned for removal, droping the feature request