Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Implement Java Interfaces with Frege Records #363

Open
wants to merge 23 commits into
base: master
Choose a base branch
from

Conversation

matil019
Copy link
Member

@matil019 matil019 commented May 19, 2018

This PR is not meant to be merged (yet)!

The ongoing effort to implement the feature #360.

The changes are in frege/compiler/gen/java/MethodCall.fr.

Cases to consider:

  • generate generics parameters from type variables
    • when the native data type has type variables
    • when the method itself has type variables
  • non-pure native data type
  • Maybe to null marshalling
  • Either to throw marshalling

@matil019 matil019 requested a review from Ingo60 May 19, 2018 01:47
--- Wraps an expression into Thunk.lazy, without generics arguments:
--- > Thunk.lazy(expr)
asLazy :: JExpr -> JExpr
asLazy expr =
Copy link
Member Author

Choose a reason for hiding this comment

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

This is slightly different from frege.compiler.gen.java.Common.lazyJX. This function doesn't take a JType. A java compiler can infer the generics of Thunk.lazy from its argument, so there isn't a need to emit one, or is it?

Copy link
Member

Choose a reason for hiding this comment

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

That's probably so, however, I adopted the policy to not rely on Java type inference if at all possible, as the frege compiler should know the desired types anyway.
Or, to put it differently, if we don't know the types, then we might need to re-consider our code generation model.

Therefore, I prefer having everything explicit in general.

That being said, it is possible that we can avoid some clutter here and there in code generation primitives like "lazyJX". But then we should adopt this in general, not just for some code.

let nativsi = evalStG g $ symInfo nativsym
fldsym <- TreeMap.lookup fldnm irsym.env
pure $ wrapIRMethod g (head args) (tauJT g $ head taus) fldsym fldnm nativsi nativnm
in JNewClass jrty (tail args) x
Copy link
Member Author

Choose a reason for hiding this comment

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

head args here is the IR itself, so it's omitted. args is ensured to be nonempty in the sanity function.

So that it is possible to run programs even if some of them failed to
compile
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.

2 participants