Closed sirinath closed 10 years ago
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 Maybe
s 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.
I am not an expert in suggesting how but perhaps Frege can be extended to support this type of constructs.
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.
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.
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.
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.