JSON interface between `lingo` and `lfc`

[tanneberger]

{
    "src": "/home/revol-xut/workspace/lf-test/src/main.lf",
    "out": "/home/revol-xut/workspace/lf-test/src-gen",
    "properties": {
        "fast": true,
        "federated": true
    }
}

lfc --json '{...}'
lfc --json-file ./src-gen-ops.json

[tanneberger]

Do we also want to define which properties exist or do we want to leave this arbitrary? @lhstrh @cmnrd

[lhstrh]

Define where? lfc has to interpret whatever is thrown at it, and if there is stuff it doesn't understand it can either ignore it and issue a warning or error... Are you perhaps referring to documentation of the supported properties?

[tanneberger]

@lhstrh The question is should lingo validate the properties if they exist and if they have the correct datatype or should I just forward all properties to lfc?

[lhstrh]

I see. I think that for now we should keep things simple and do validation in lfc since a lot of validation is done there already, anyway. WDYT?

[tanneberger]

I am fully on your site there having the validation logic in two places is too much maintenance work and not a good style (a single point of truth is preferable).

The reason why I asked was that there are maybe properties that are required for lfc to run. I am here for example thinking about things like a target (in case we want to move it out of the lf-file). Lingo should complain about if those properties are not specified or default them to some value.

I took a list at our docs: https://www.lf-lang.org/docs/handbook/target-declaration?target=c

But currently, we don't have any necessary properties so no real need to specify and include some in our specifications.

[patilatharva]

I have a followup question regarding the json format - how would we expect the src field to look if we have multiple input paths? If it's array, should we also put single-file values in array for consistency?

[tanneberger]

@patilatharva what do you mean with multiple input paths ? In this suggestion src would point to the file that contains the main reactor and for building multiple programs at once I would invoke lfc multiple times with different values for src.

[patilatharva]

Yes, I meant for building multiple programs, but that makes sense. The lfc CLI supports multiple input paths at once so I was wondering whether we'd want that feature here too.

[tanneberger]

No I would say this lfc feature is useless for our use-case.

[lhstrh]

More specifically, I think the json flag should be mutually exclusive with any other parameters, no? This would sure make things simpler.