This is probably a bad idea, as it depends heavily on the features of the generated code.
Pay attention to the following points:
- Regardless of the name of the compiled module, fay is created in the
main variable. - In node.js, the return value from
require is the modules.export module (which is originally the same object as export ), but it does not necessarily remain the same). - A variable can be used before its definition is declared with
var . The specified variable is the same. He doesn't care about anything to streamline the source code, and everything that happened at runtime. - Fay by default (i.e. without
--library ) can instantiate an object and execute main .
Remarkably, this means that in main we can change module.exports or exports to export the fay code. Of course, we should use ffi, but this is a fairly simple matter; the following, compiled without --library (which, yes, slightly contradicts intuition and really confirms the credibility of the hypothesis that this is an unpleasant hack, doesn't it) works to some extent:
import FFI main :: Fay () main = ffi "module.exports = main"
when require 'd from node, the returned object is a bit of an effect
{ 'Main$main': { forced: true, value: { value: [Circular] } }, _: [Function: Fay$$_], '$': [Function: Fay$$$], '$fayToJs': [Function: Fay$$fayToJs], '$jsToFay': [Function: Fay$$jsToFay] }
With a working knowledge of Fay's internal representations, it is possible (although perhaps too much effort) to write a javascript wrapper for all thunk-forcing, etc.
(We could do more - in fact, with a bit more ffi work, we could write all the bindings as ffi code. It would be mildly stupid.)
source share