Complete PFA DSL Library

[Paxanator]

Address #7

[Paxanator]

These tests were added by hand before i did the code gen thing

[Paxanator]

the dsl._ namespace has parse.{int,float..} functions that conflict with JsonMethods

[Paxanator]

I ran into a bunch of conflicts where either:

• FunctionRef was the param type, but FunctionDef was supplied
• Another type was supplied that was not FunctionRef

Overall, I would like to understand whether the DSL should be completely loosely types, or as strongly types as possible, and that's future work we should include

[Paxanator]

The build is failing because of some maven key thing, any insight into how to fix it?

[Paxanator]

I ran into a bunch of conflicts where either:

• FunctionRef was the param type, but FunctionDef was supplied
• Another type was supplied that was not FunctionRef

Overall, I would like to understand whether the DSL should be completely loosely types, or as strongly types as possible, and that's future work we should include

Additionally there are PFAExpressions that were peppered through that provide implicit casting of strings to StringLiterals, so some tests are failing. Waiting to hear on the above to resolve it

[Paxanator]

@MLnick any insight into the above questions?

[MLnick]

Hi there - I am out of office currently but will take a look early next week and revert. Thanks for your efforts!

…

On Wed, 2 Jan 2019 at 22:05, Paxanator ***@***.***> wrote: @MLnick <https://github.com/MLnick> any insight into the above questions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_SB2g72LA-YhJ2WFEzQl18MBIM7-L7ks5u_RD8gaJpZM4YsTIL> .

[MLnick]

@Paxanator overall the approach looks good and I like the code gen for functions. It would be interesting to also see whether we could code gen the test cases based on the PFA conformance tests JSON (but that may be more involved).

Overall ideally I think the DSL would be as strongly-typed as possible, to try to avoid runtime errors at conversion time (i.e. generating invalid PFA, that can only be caught running integration / conformance tests or trying to execute the PFA). As you mention it's not very close to that goal as yet but would be good to work towards it. This is why many of the functions (in most cases the ones we added later on in development) try to take PFAExpression as args - the implicit casts from common simple types then make it easier to use Scala strings, numbers etc in the DSL in raw form.

Of course, this does introduce more "magic" and there's an argument that being more explicit and requiring users to use StringLiteral, DoubleLiteral, makes it more clear what is going on under the hood.