This adds purs dce. It reads corefn dumped to output and generates javascript modules in dce-output directory. (There is also a switch to just generate corefn representation).

To generate javascript modules I use moduleToJs but it required to add annotations to the json representation of CoreFn (source spans and meta).

I run into problem when using Language.PureScript.CodeGen.JS.moduleToJs. The CoreFn representation does not distinguish between non recursive bind and the recursive one (NonRec vs Rec). And it seems that moduleToJs shuffles the recursive ones to put them in the right order, am I right?. This does not work for modules parsed from CoreFn dump, since all binders are read as non recursive. Would it be fine to distinguish NonRec and Rec in the json representation?

The issue is that declarations are encoded using an object, and aeson using using hash maps and they do not guarantee order. Changing the json encoding of module declarations to a list binds, where each one is a list of three tuples (identifier, annotation, expression) (this way NonRec and Rec binds can be encoded using the same structure), solved the problem.

With webpack I could reduce the bundle down to 440kB and with a naive removing of exports from foreign modules additional 20kB - so I guess it makes sense to do that in a safer way.

Thanks for taking the time to work on this!

This is obviously a very big change, and could eventually replace psc-bundle, which is pretty stable and well-tested at this point. I'd like to suggest this:

• merge the corefn json parser into the compiler
• make a separate repo to test this approach, and give it some real time to iron out any bugs.

Once it's thoroughly tested on lots of code (maybe after 1.0 even), we could deprecate purs bundle, with a plan to remove it in a future breaking release, and a plan to add this tool in a non-breaking release (could be 0.12.x or 1.x for example).

What do you think?

Also, now would be the time to break the corefn format, if we're going to do it, since we can do it in 0.12.0.

I agree, that indeed needs some time to mature and grow its test suite and be tested on real projects.

I will prepare PR for the json representation.
Is its format documented somewhere?

I'll be glad to test it out, if any help is needed in that department 😃

@paf31 maybe when you will announcing the next version of purescript you could include a line about new experimental (external) tool for tree shaking?

Here it is zephyr.

maybe when you will announcing the next version of purescript you could include a line about new experimental (external) tool for tree shaking?

Yes, I think we should definitely do that. Thanks!

Also, now would be the time to break the corefn format, if we're going to do it, since we can do it in 0.12.0.

Can we do this? Corefn is kind of a pain to work with, enough so that I've given up on writing a JSONSchema for it. It being a pain to work with is a sentiment shared by others that aren't known/active in the PS community.

Yes. If you have experience working with it, it would be good to get suggestions for a better format.

Here are some things we found hard, in no particular order:

Very few things are named.

It can be kind of hard to know which parts are which when you're deep in the nesting. It required me to explain what each piece of the JSON was in order for others to understand what they were looking at.
For instance, case expressions look very convoluted unless you understand all the possibilities that PS source has for case expressions:

[
    "Case",
    [
        [
            "Var",
            "v"
        ]
    ],
    [
        [
            [
                [
                    "LiteralBinder",
                    [
                        "IntLiteral",
                        1
                    ]
                ]
            ],
            [
                "Literal",
                [
                    "IntLiteral",
                    1
                ]
            ]
        ],
        [
            [
                "NullBinder"
            ],
            [
                "Literal",
                [
                    "IntLiteral",
                    0
                ]
            ]
        ]
    ]
]

The S-expression encoding feels harder to work with than an object encoding would.

This ties in with the naming concern. I see the appeal for the S-expression encoding, but I think it would be better if we just had a way to dump an actual S-expression and left the JSON dump as an object.

[
    "Abs",
    "dict",
    [
        "Accessor",
        "foo",
        [
            "Var",
            "dict"
        ]
    ]
]

vs

{
    "type": "Abs",
    "argument": "dict",
    "body": {
        "type": "Accessor",
        "key": "foo",
        "object": {
            "type": "Var",
            "name": "dict"
        }
    }
}

I have no strong feelings on what the names should be, but they should exist.

The value of each decls has to be parsed before you know how to generate them.

In JS this is not much of a problem, because a function can be used for both a lambda abstraction and an object constructor. But in languages that don't conflate the two ideas, it requires more work.

"decls": [
    {
        "Foo": []
    },
    {
        "Bar": []
    }
]

You can't know what Foo or Bar are supposed to be until you parse their arrays. One could be a type class, the other a value constructor, maybe other things.

Qualified names are serialized as a string interspersed with . between module names.

This is another thing that is fine in JS because you can dot your way wherever you need to go. But, it's harder in other languages that don't use . for everything. If module resolution is done with :: you have to then parse the string into its module pieces and value pieces (or whatever you're trying to do).

I agree with @joneshf, having more verbose output would make it much easier to work with the json files.

@paf31 if you agree with @joneshf proposal I can add the changes to #3049.

@joneshf Thank you for the detailed notes! I can't disagree with anything you've said. The S-expression syntax was something of an experiment to begin with, and maybe it hasn't worked out. I would be fine with breaking the format to use the suggested type fields for 0.12.0.

@rightfold Any thoughts?

I agree. Especially problems with ambiguous names

I think we should also change recordToJson to always encode records as lists of pairs, rather than try to encode it as object. This will simplify parsers, but also avoid bugs in them due to unexpected format that is present only if encoding of a label fails.