libatscc: packaging

[Artyom Shalkhakov]

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).

[Sami Zeinelabdin]

Hi Artyom,

I would be very interested :)
A packaged and uniform interface would be a great help!

[Richard]

Sounds like a good idea to me!

[M88]

Somewhat related:  maybe it would be good to have some character-sequence that represents a module accessor in the host language?

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. 

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.

On Monday, April 1, 2019 at 6:46:44 AM UTC-4, Artyom Shalkhakov wrote:

[artyom.s...@gmail.com]

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.

[M88]

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.

[gmhwxi]

This is a great idea!

I would suggest that we follow the library

support for Temptory to build this libatscc, making extensive

use of templates (instead of higher order functions).

On Monday, April 1, 2019 at 6:46:44 AM UTC-4, Artyom Shalkhakov wrote: