Hi Artyom, It's in a rather primitive state and not thoroughly tested, but feel free to have a look: https://github.com/mephistopheles-8/ATS-Postiats/commit/61404adc68ffb5e1b5925cbd735bfe5ac8b5cdb9
All it really does is dump stored functions into an object. There are more entities that should probably be exported (eg, variables). The format of the object depends on the specified module. It turns out I never got around to doing UMD, but I did IIFE, CommonJS and ES6. On Tuesday, May 7, 2019 at 3:40:41 AM UTC-4, [email protected] wrote: > > On Tuesday, May 7, 2019 at 5:58:44 AM UTC+3, M88 wrote: >> >> >> Somewhat related: maybe it would be good to have some character-sequence >> that represents a module accessor in the host language? >> >> > Yes, it makes sense to support some form of qualified identifiers in the > source language. As it stands now, the ATS compiler will escape all "." and > other symbols, so they would have to be unmangled. > > >> For example, something like "mac#Math**sqrt" could be translated to >> "Math.sqrt" by atscc2[x], depending on what the module system uses for >> namespaces. >> >> From an implementation standpoint, the accessor notatiion might be a >> rather* bad* idea ( we'd be converting functions named >> "Math_052__052_sqrt" to "Math.sqrt" ). Still, maybe there >> are ways to make it better. >> >> Beyond making FFI easier, we'd also be able to package the prelude as a >> module in the host language, which may have benefits (integration, >> bundling, tree-shaking, etc) over >> methods like concatenation. >> >> > Yes, this is precisely what I was aiming at, and note that the existing > translators do this (except for atscc2js, which I planned to enhance with > some support for ES modules). Not only do we want to package the prelude, > but also the code that we get via the source-to-source compilers. > > >> Just a thought.... >> >> A while ago, I had attempted to add [es6, commonjs, IIFE, UMD] module >> support to atscc2js. Though it worked with a single file, I decided it had >> little benefit over inline code blocks if there is no [easy] way to access >> functions from the generated modules. >> >> > Could you post this work somewhere? I'd like to have a look. > > >> >> On Monday, April 1, 2019 at 6:46:44 AM UTC-4, Artyom Shalkhakov wrote: >>> >>> Hi all, >>> >>> I've started work on improving atscc2js yesterday and found that we have >>> three similar projects: >>> >>> 1. https://github.com/steinwaywhw/ATS-Python3 >>> 2. https://github.com/bakpakin/ats-lua >>> 3. https://github.com/sazl/ats-go >>> 4. and the in-progress atscc2js >>> >>> Every target programming language comes with its own "prelude" (e.g. >>> libatscc2js for JS), but such preludes essentially implement the interfaces >>> defined in libatscc. >>> >>> Now I'm thinking that we need to package up the interface and keep it as >>> uniform as possible across the different targets, so that programmers may >>> hopefully share more code between platforms with little issues (or no issue >>> at all). >>> >>> With the above in mind, I propose to: >>> >>> 1. package up libatscc somehow, e.g. put it on NPM (I'm working on >>> this, it will require only minimal changes to the existing code) >>> 2. come up with some process to maintain this 'specification' (maybe >>> create a github organization and put this library into a repository; let >>> people use issues and PRs to propose changes) >>> >>> Is anybody interested? If not I'll just go with the first point, and the >>> specification will live on in the ATS-Postiats repository (for now). >>> >> -- You received this message because you are subscribed to the Google Groups "ats-lang-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/ats-lang-users. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/abc2e98e-67f4-4f1a-915c-0bd57f842247%40googlegroups.com.
