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

Full Automatic 2 way Generation #1

Closed
sirinath opened this issue Dec 2, 2013 · 5 comments
Closed

Full Automatic 2 way Generation #1

sirinath opened this issue Dec 2, 2013 · 5 comments
Labels

Comments

@sirinath
Copy link

sirinath commented Dec 2, 2013

Is it possible to aim for full automated generation by v1. Assume all Java objects can be null unless they have appropriate annotations. Also additional information about assumption or conversion strategy can be given to the converter as a DSL.

Also abimily to wrap around Frege to create idiomatic Java API.

Perhaps you can use a large code base of common JVM libs to see where translations fail as slowly fix them.

@mmhelloworld
Copy link
Member

Is it possible to aim for full automated generation by v1

I guess not because there are few things that cannot be automated. I already tried but failed mostly in places where Java generics is involved.

For example, how would you type this in Frege?
static <T extends Comparable<? super T>> void java.util.Collections.sort(List<T> list)

or this?

static <T extends Object & Comparable<? super T>> T java.util.Collections.min(
                                                      Collection<? extends T> coll)

Assume all Java objects can be null unless they have appropriate annotations.

This can quickly get to be not really useful because you would end up polluting the code with so many Maybes in Frege. You also do not want to annotate each method for non-null.

Also additional information about assumption or conversion strategy can be given to the converter as a DSL.

This would be useful but not in scope for now. Currently the objective is to support as many Java APIs rather than evolving this project because with important Java APIs (like JDBC API), other Frege libraries can evolve.

Also abimily to wrap around Frege to create idiomatic Java API.

This is also another useful thing to have around but not in scope of this project. There is already an issue for this here Frege/frege#20 which might later be integrated within compiler itself.

@sirinath
Copy link
Author

sirinath commented Dec 6, 2013

I am not an expert in suggesting how but perhaps Frege can be extended to support this type of constructs.

@Ingo60
Copy link
Member

Ingo60 commented Dec 6, 2013

We must see to it that we don't demand too much from the frege type system. For example I think that Java genetics are out because that would mean we basically had to support much of the Java type system. Yet we already have Scala for this.

@sirinath
Copy link
Author

sirinath commented Dec 6, 2013

The type system is very important. We should have our own. Not Java's but is it is more powerful Java Generics and Type Annotations would end up being a subset of these features.

@mmhelloworld
Copy link
Member

As Ingo said, we shouldn't make any changes in Frege type system just to be friendly with Java and I also don't think we could provide complete auto generation of Frege code from Java classes. So I am closing this issue.

@sirinath If you have any suggestions or want to discuss about any approaches, please let us know through the discussion forum here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants