ceylon / ceylon-compiler Goto Github PK

Between the source map and some smartness, we should be able to determine that when we want to compile a module with a special --incremental flag we:

• only need to compile source files which are newer than their target classes
• and their transitive dependencies
• and automatically detect the list of those files

That could be seen as the job of the build tool, but I don't think anyone can do this sort of detection better than the compiler itself.

It's sort of needed in case there are stuff to document at the toplevel but as it is it's not helpful and worse, the link to the overview from there is broken.

Class Tree should be removed from interface's page.

• We need to replace any call to Object.hash and Object.string attributes into method calls Object.hashCode() and Object.toString().
• We need to replace any Object.hash and Object.string overriding into methods Object.hashCode() and Object.toString().
• We need to replace any Ceylon method definition named hashCode and toString into $hashCode and $toString.
• We need to replace any call to *.hashCode(...) and *.toString(...) into *.$hashCode(...) and *.$toString(...).

Only direct satisfied interfaces are listed, all hierarchy should be showed in the list.

The name could be changed to "All Known Satisfied interfaces".

This should already be handled in the model loader, but perhaps not in the compiler generation. Add support for method type parameters.

This means generating

int i = 5 + 2;

instead of for example:

int i = Integer.instance(5).plus(2).intValue();

will depend on #46.

Because Eclipse insists on copying .ceylon files to the build folder, we need to make sure the compiler doesn't barf on that, because currently it does and that's not cool and the message is less than clear

Note: good candidate for new contributors

Make sure that every M1 operator is tested and implemented.

Non-binary-compatible named-param invocation is already done in M1.

Simple approach

// ceylon method decl
void xy(X x, Y y) {}

// java method decl
void xy(X x, Y y) {}
abstract class xy {
    abstract X getX();
    abstract Y getY();
    final void call() { xy(getX(), getY()); }
}

// ceylon call site
foo.xy{ x = X("foo"), y = Y("bar")};

// java call site
foo.new xy() {
    final X x = new X("foo");
    final Y y = new Y("bar");
    final X getX() { return x; }
    final Y getY() { return y; }
 }.call();

Invokedynamic approach

We should make named-invocation calls invokedynamic calls, which would be resolved by the method resolver at runtime into the proper calling order and get the benefit that any subsequent call would be optimised and run without the proxying.

Not sure yet if that solution also works with default values, but perhaps it does if we can bypass visibility checks at runtime in the proxy and replacing missing values with the default expressions applied to the target callee object.

Note: this requires:

• invokedynamic to really be implemented in the compiler
• to mark such named-invocation calls somehow so that they can be turned into the proper invokedynamic call by the bytecode generator
• to implement the runtime proxy
• a Java 7 VM

Other solutions

We should look at other languages that have this feature on the JVM, how they implement it. We might be missing much simpler solutions.

Something is broken in the compiler

Because this is most likely what we will want

See how javac can produce ceylon archives instead of .class files. This would solve our case-sensitivity issues on Windows and OSX.

Non shared members should not be listed by default. An option like "-private" (under discussion) should allow this.

We need to make sure all the types are there, that signatures and everything is the same.

For both classes and interfaces

It's wrong because it evaluates the expression twice.

Note: good for new contributors.

It should support no parameters and -help parameters rather than the ugly exceptions it now throws.

On interface methods show if it's a concrete method or not.

Some are necessary and others are just historical which we should clear up because in most cases they are now harmful.

• Implement ceylon.language.Usable and ceylon.language.Exception in the runtime
• Figure out how to deal with Ceylon exceptions (Ask Gavin). They have to be of type ceylon.language.Exception, we will need to do erasure to java.lang.RuntimeException.
• Also figure out how to catch exceptions thrown from Java code. Since Ceylon doesn't have checked exceptions there is currently no support to know that you must catch exceptions when invoking a Java method that throws.

They end up in the constructor rather than in the body.

Show somewhere the module defined. Possibly in the overview by listing expanded packages by module, and by having a "Module" top menu for each package/type that would go to a "Module overview" page that would be like the current overview but only list that module's packages.
Also display some info about the module like its name, version and dependencies.

we should be filling it in for all model declarations concerned

I think we're missing all of 6.12.8. Correspondence and sequence operators

this way we can load the module-info info just from the class's annotations

Turns out we need to remove the parsing function from the TypeChecker constructor (Stef)

Support varargs parameters in methods and initialiser. Same sort of implementation as in Java, by making an array out of them on call-site.

Similar to @TypeParameters but for type arguments

Note: good candidate for new contributors

Those are getters/setters as local variables. They can appear in the constructor (if the variable is not captured) or in methods. Make sure we have tests and implement them if not already done.

Do 2.4.4. Single quoted literals

Note: good candidate for new contributors

• Bitwise operators (and assignment of)

Do like javadoc and show inherited members, otherwise most classes are empty

On an interface documentation, we want to show which interfaces or class satisfies the current interface.

Note: good candidate for new contributors

Add simplistic support without binary compatibility, by dropping default values and calling the method with the proper order of parameters as defined during compilation.

// Create this class in ceylon.language (probably needs entry in SymTab as well)
public abstract class NamedArgumentCall<R,X> {
    protected final X instance;
    public NamedArgumentCall(final X instance, Object... args) {
        this.instance = instance;
    }
    public abstract R call();
}

// Ceylon
Float z = calcFoo().bar{x = "hello"; y = 10;};

// Java
Float z = new NamedArgumentCall<Float, Foo>(calcFoo(), "hello", 10) {
    final Float call() {
        return instance.bar((String) args[0], (Integer) args[1]);
    }
}.call();

Erasure of the Ceylon basic types String, Integer, Natural, Float etc to their Java counter parts.
And boxing the java objects/values when accessing specific Ceylon functionality.

Will need #45 to be done first to be able to complete.

rather than a jar

It is called in the for condition and in the for body. This is probably breaking some implicit contract.

It doesn't deal with interfaces. We need to fix this and add some tests.

Note: The tests for this feature might be good for new contributors

Make sure that whatever name we use for Ceylon declaration works if it's also a Java keyword: variable name, class name, method name, parameter name, generic parameter name, everything. This might need some fixes in the model loader as well.

++/-- just don't work due to getters/setters.

We should not call (i = i.getSuccessor()).getPredecessor() but should save the old value, using a let expression.

++/-- and all +=, -=... math and logical operators are invalid and should not be evaluating the LHS twice. For instance foo().b += 2 should only call foo() once.

This little bit of code illustrates a several issues:

In test.ceylon:

class Single<Element>(Element e) {
    shared Element get() { return e; }
}

void test() {
    value s = Single(69);
    if (s.get()<100) {}
}

Java code generated for test.ceylon

@.com.redhat.ceylon.compiler.metadata.java.Ceylon
class Single<Element> {
     private final Element e;

    @.com.redhat.ceylon.compiler.metadata.java.TypeInfo("Element")
    public final Element get() {
        return e;
    }

    Single(@.com.redhat.ceylon.compiler.metadata.java.Name("e")
    @.com.redhat.ceylon.compiler.metadata.java.TypeInfo("Element")
    Element e) {
        this.e = e;
    }
}
@.com.redhat.ceylon.compiler.metadata.java.Ceylon
@.com.redhat.ceylon.compiler.metadata.java.Method
final class test {

    private test() {
    }

    static void test() {
        final .Single<ceylon.language.Natural> s = new <ceylon.language.Natural>.Single<ceylon.language.Natural>(.ceylon.language.Natural.instance(69L));
        if (s.get().compare(.ceylon.language.Natural.instance(100L)).smaller().booleanValue() == true) {
        }
    }
}

The problems are:

1. "new <ceylon.language.Natural>.Single<ceylon.language.Natural>" has two type argument lists.
2. "smaller()" returns unboxed "boolean"
3. "== true" is just garbage.

This requires adding some localisation entries somewhere and using those keys otherwise we can't use javac's Log system.

The Java implementation of String does not implement Summable

if there's none we're compiling try to load it from the classpath (already compiled)

Note: good candidate for new contributors

Make sure we support the "outer" keyword and map it properly in Java.

There are several ways we can do this. The easiest being that each interface "A" with concrete methods "ret foo(params)" produces a "$$AImpl" Java class with methods "static ret foo(A that, params)", and any implementing class of "A" will have the following placeholder generated:

ret foo(params){
  return $$AImpl.foo(this, params);
}

This should work if in the body of the interface method we replace any unqualified (or "this" qualified) call to interface method/attributes "foo" into "that.foo".

Note: we can't do "super" qualified calls in concrete interface methods so this method should just work.

Note: there are more optimal implementations possible with Java 7 invokedynamic but not sure we need to investigate those at this point since this would work.

Note: The tests for this feature might be good for new contributors

Add support and tests.

See spec "6.12.5. Equality and comparison operators"

• lhs in rhs

See spec "6.12.7. Operators for handling null values"

• lhs ? rhs
• lhs ?= rhs
• lhs ?.member

See spec "6.12.8. Correspondence and sequence operators"

This is in #72