Skip to content

Option --dump-coreimp to output imperative-core to JSON#3097

Closed
metaleap wants to merge 11 commits intomasterfrom
unknown repository
Closed

Option --dump-coreimp to output imperative-core to JSON#3097
metaleap wants to merge 11 commits intomasterfrom
unknown repository

Conversation

@metaleap
Copy link
Copy Markdown

New purs compile option --dump-coreimp, exactly like the existing --dump-corefn, to dump the CoreImp AST to a coreimp.json output file.

Requested in #876 and also in #711 in the comments

(The results can be seen in the various coreimp.json files throughout this directory --- one example )

New modules:

  • src/Language/PureScript/CoreImp/ToJSON.hs --- modeled after the existing src/Language/PureScript/CoreFn/ToJSON.hs. (Has duplicated the trivial tiny helper functions identToJSON and moduleNameToJSON as I didn't want to impress changes on to what the existing original exports.)

Existing modules:

Merely duplications of the existing --dump-corefn option handling in:

  • app/Command/Compile.hs
  • src/Language/PureScript/Make.hs
  • src/Language/PureScript/Options.hs
    (Too small & trivial to generalize into helper funcs for now IMHO --- until a 3rd --dump-xyz request comes along in the future at least.)

This was referenced Sep 27, 2017
coreFnFile = outputDir </> filePath </> "corefn.json"
min3 js exts coreFn
coreImpFile = outputDir </> filePath </> "coreimp.json"
min3 js exts coreFn coreImp
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

min3 -> min4

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in last added commit

T.pack name .= map astToJSON asts
]

subASTsLeftRightToJSON :: String -> (Maybe SourceSpan) -> AST -> AST -> Value
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't need the parens around Maybe SourceSpan

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All 3 occurrences removed with last added commit


subASTSingleToJSON :: String -> (Maybe SourceSpan) -> AST -> Value
subASTSingleToJSON name maybeSrcSpan ast =
object [T.pack "sourceSpan" .= toJSON maybeSrcSpan,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this hit the same issue as the CoreFn change, where it stores the file path in every node?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well with --source-maps enabled. Is it an issue to begin with? We're emitting sizable to-be-machine-processed json files already.. I can certainly ditch the file path if you guys prefer, personally am hoping I won't need the sourcemappings for my ps2go transpiler anyway


moduleToJSON :: (Show a) => Version -> Module a -> [AST] -> Value
moduleToJSON v m a = object [ T.pack "body" .= map (astToJSON) a
, T.pack "corefn" .= CoreFnToJSON.moduleToJSON v m -- might be good to "keep a snapshot of the original FP logic of the module" depending on coreimp-processing use-case (others can ignore it)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how I feel about including the functional core here. What's the use case?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ultimately I want to push (later) for an argument "include-everything-you-know-incl-especially-type/ctor-infos" to CoreFn.ToJSON.moduleToJSON. I get that the existing --dump-corefn output is meant to be small and semi-readable for (typically) troubleshooting use-cases, but for the --dump-coreimp I see the use-cases as tools that need the most information possible about the original source. More in-depth type info (ADTs / records) in the current (JS-focused) CoreImp will be very hard to reconstruct from these "untyped" (other than stringlit/boollit/numlit/obj-lit) --- including a more detailed corefn (than the original/current --dump-corefn scenario envisions) right there in the coreimp dump will probably help. I guess for now that's too vague to let into the main repo so I'll take it out for now in the next commit, then keep tinkering locally until it all solidifies a bit more.

moduleToJSON :: (Show a) => Version -> Module a -> [AST] -> Value
moduleToJSON v m a = object [ T.pack "body" .= map (astToJSON) a
, T.pack "corefn" .= CoreFnToJSON.moduleToJSON v m -- might be good to "keep a snapshot of the original FP logic of the module" depending on coreimp-processing use-case (others can ignore it)
, T.pack "modraw" .= toJSON (show m) -- only way to capture type/ctors info without rewriting corefn, good enough for those needing it badly enough, others can ignore it
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does modraw mean? Also, let's not use show here.

In general, I'd like to keep this minimal. It's harder to remove features later.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'll do away with this shortly, accidentally pushed this last commit. Still a bit more in flux than I expected I'm afraid!

@metaleap
Copy link
Copy Markdown
Author

That last commit 5e9d1fc.. wasn't intended, what a mess, sorry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants