For example, a bridge C2.foo to I.foo is not needed in the code below:

interface I {
    shared default void foo() {}
}

class C1() satisfies I {}
class C2() extends C1() {}

But be careful to generate a bridge when the superclass's bridge is insufficient. Below, a bridge from C2.foo to I2.foo is required:

interface I {
    shared default void foo() {}
}

interface I2 satisfies I {
    shared actual default void foo() {}
}

class C1() satisfies I {}
class C2() extends C1() satisfies I2 {}

See eclipse-archived/ceylon#4127 (comment)

For example, using dart.html:

    value elements = querySelectorAll("#something");
    for (Element el in CeylonIterable(elements)) {
        print(el.\iATTRIBUTE_NODE);
    }

the compiler throws:

Compilation failed: AssertionError: Assertion failed: Member identifiers must be DartSimpleIdentifiers.; violated

but print(Node.\iATTRIBUTE_NODE) works.

native headers may provide default implementations. For example:

native class C() {
    shared String defaultMember0 => "";
    native shared String defaultMember1 => "";
    native shared String defaultMember2 => ""; 
    native shared String nonDefaultMember;
}

native("dart") class C() {
    native("dart") shared String defaultMember2 => "";
    native("dart") shared String nonDefaultMember => "";
}

and toplevels

native String s => "";

For toplevel functions and values with default implementations, backend specific implementations are optional.

For toplevel classes, objects, and interfaces with default implementations for all members, it's unclear if backend specific implementations should be required.

Default members for Inner class and interface headers appear to be valid.

Expressions like { 1, *rest }, rest's evaluation should be lazy.

When I do

ceylon new simple --module-name=com.foo.bar fooBar

and then take a look at the run.ceylon, it contains comments like these:

// on the command line compile with "ceylon compile com.foo.bar" or "ant compile"
// and execute with "ceylon compile com.foo.bar/1.0.0" or "ant run"

I think they should have been like this:

// on the command line compile with "ceylon compile-dart"
// and execute with "ceylon run-dart com.foo.bar"

I have not had the chance to try ant.

Both of these currently fail with an assertion error expecting f.model to be a Value in generateDefaultValueAssignments(), since the AST node type is DefaultedValueParameter | DefaultedParameterReference.

            shared void run(f = print) {
                void f(String s);
            }

            class Run(f = print) {
                void f(String s);
            }

compile-dart should colorize output just as compile-js and compile now do.

Optimize expressions like bool then x else y to compile to conditional expressions instead of treating the then and else separately and performing a null test on bool then x.

Make sure local imports (eclipse-archived/ceylon#6646) support importing members of top-level objects.

Given:

printAll { for (i in 0..10) i^2 };

I get:

0Unhandled exception:
type 'dart$Default' is not a subtype of type 'String' in type cast.
#0      Object._as (dart:core-patch/object_patch.dart:70)
#1      $package$printAll.<anonymous closure> (package:ceylon/language/language.dart:9655:46)
#2      Iterable.$each (package:ceylon/language/language.dart:4652:22)
#3      functionIterable$$anonymous$0_.each (package:ceylon/language/language.dart:1142:44)
#4      $package$printAll (package:ceylon/language/language.dart:9651:12)
#5      printAll (package:ceylon/language/language.dart:9662:90)
#6      $package$run.<anonymous closure> (file:///var/folders/3l/_1gb8m1n51j9_tc07h0lflr40000gn/T/ceylon-run-dart5767981372227819311/hello/hello.dart:53:16)
#7      $package$run (file:///var/folders/3l/_1gb8m1n51j9_tc07h0lflr40000gn/T/ceylon-run-dart5767981372227819311/hello/hello.dart:54:7)
#8      run (file:///var/folders/3l/_1gb8m1n51j9_tc07h0lflr40000gn/T/ceylon-run-dart5767981372227819311/hello/hello.dart:57:15)
#9      main (file:///var/folders/3l/_1gb8m1n51j9_tc07h0lflr40000gn/T/ceylon-run-dart5767981372227819311/hello/hello.dart:61:5)
#10     _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:261)
#11     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:150)

It works with plain print().

In Ceylon, it's valid for two modules to import each other as long as they are compiled together.

This is necessary for Dart interop, since cyclic dependencies exist in the Dart SDK. See https://api.dartlang.org/1.14.2/dart-core/List/shuffle.html

The JS issue for this is eclipse-archived/ceylon#6003

This results in a compile time assertion error:

class X() {
    variable value count = 1;
    shared actual String string;
    this.string => (count++).string; // error
}

although it does work without this..

Support this:

abstract class A() {
    shared formal String(String) v;
}
class B() extends A() {
    v(String s) => s;
}

Support 1.3.2 feature eclipse-archived/ceylon#3544

This works:

HttpClientResponse response = await (client.getUrl(url)
    .\ithen((hcr) => uncurry(HttpClientRequest.close)(hcr)));

but not:

HttpClientResponse response = await (client.getUrl(url)
    .\ithen(uncurry(HttpClientRequest.close)));

Unhandled exception:
Closure call with mismatched arguments: function 'call'

NoSuchMethodError: method not found: 'call'
Receiver: Instance of 'dart$FlatFunction'
Arguments: [Instance of '_HttpClientRequest']
#0      Object._noSuchMethod (dart:core-patch/object_patch.dart:42)
#1      Object.noSuchMethod (dart:core-patch/object_patch.dart:45)
#2      dart$FlatFunction.noSuchMethod (package:ceylon/language/language.dart:15068:25)
#3      _RootZone.runUnary (dart:async/zone.dart:1204)
#4      _FutureListener.handleValue (dart:async/future_impl.dart:131)
#5      _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:637)
#6      _Future._propagateToListeners (dart:async/future_impl.dart:667)
#7      _Future._completeWithValue (dart:async/future_impl.dart:477)
#8      _Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:528)
#9      _microtaskLoop (dart:async/schedule_microtask.dart:41)
#10     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50)
#11     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#12     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:149)

• Non-formal interface members are implemented as Dart static methods that take this as the first argument.
• Within a Ceylon interface, super.string refers to Object.string unless string is overridden by a satisfied interface.
• Dart's Object.toString() is inaccessible in this case, since super can't be used in a static method.

This affects only super.string, since all other non-formal members that may be qualified with super within an interface will be defined by another interface, and therefore, will be implemented as Dart static methods that can be called directly.

The only fix is likely to be to intercept calls to super.string and redirect them to a static method that returns the same value as Dart's Object.toString(). That is, never really call Object.toString().

In Dart, all classes can be used as interfaces. The Ceylon translation would be:

class MyClass satisfies SomeOtherClass { ... }

which of course is not legal in Ceylon.

There seems to be no option but to have each Dart class map to two separate types: a Ceylon interface and a Ceylon class that satisfies that interface.

Either the class or interface will need a synthetic name.

Scenario 1: Use class DartClass and interface I_DartClass

• The model loader would map parameters and returns of type DartClass to I_DartClass
• Use of DartClass for parameter types in Ceylon code would be discouraged; I_DartClass should be used instead, for maximum flexibility.
• The identifier DartClass would be use for instantiations and extensions in Ceylon code (e.g. DartClass() and ... extends DartClass().
• I_DartClass would be erased to DartClass by the backend compiler.

Scenario 2: Use class C_DartClass and interface DartClass

• Parameters and returns would be of the type DartClass.
• Use of C_DartClass for anything other than instantiations and extensions would be discouraged.
• C_DartClass would be erased to DartClass by the backend compiler.

Perhaps Scenario 2 is the most natural, since the synthetic name would be used less frequently, and when needed (for instantiation & extension), its use would be forced by the typechecker.

A further concern is that classes DartClass_A and DartClass_B that do not share a subtyping relationship are not guaranteed to be disjoint, which breaks Ceylon's type system. Adopting scenario 2 (which helps reduce unintentional use of the identifier that maps to the class) should help to avoid this unsoundness.

module test.com.vasileff.ceylon.random.api "0.0.6-SNAPSHOT" {
    //import ceylon.collection "1.2.1";
    import ceylon.test "1.2.1";
    shared import com.vasileff.ceylon.random.api "0.0.6-SNAPSHOT";
}

Without the ceylon.collection import, the json loader fails to load the test module:

Caused by: com.redhat.ceylon.compiler.js.CompilerErrorException: Package not found: ceylon.collection
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.getTypeFromJson(JsonPackage.java:889)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.loadAttribute(JsonPackage.java:562)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.addAttributesAndMethods(JsonPackage.java:310)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.loadClass(JsonPackage.java:283)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.loadDeclarations(JsonPackage.java:129)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.getTypeFromJson(JsonPackage.java:892)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.parseTypeList(JsonPackage.java:332)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.loadClass(JsonPackage.java:276)
    at com.vasileff.ceylon.dart.compiler.loader.JsonPackage.loadDeclarations(JsonPackage.java:129)
    at com.vasileff.ceylon.dart.compiler.loader.JsonModule.loadDeclarations(JsonModule.java:73)
    ... 34 more

Seems like this sort of thing was working before.

Temp and synthetic variable name generation is a bit ad-hoc and should be centralized. Maybe something like String generateName(NameTypeEnum purpose, Declaration? forDeclaration).

"Note: Created module ..." should be printed after warnings.

ClassAliases, like ceylon.json::JsonObject don't have ClassAlias.extendedType or ClassAlias.constructor set correctly. After deserialization, the first is Object, and the second is null.

The raw JSON model info is:

"JsonObject":{
    "$alias":1,
    "an":{"doc":["Alternative name for [[Object]] which avoids collision with\nceylon.language::Object."]},
    "mt":"c","nm":"JsonObject","pa":1,
    "ps":[{"$t":{"md":"$","nm":"Iterable","pk":"$","ta":{"Iterable.Absent":{"md":"$","nm":"Null","pk":"$"},"Iterable.Element":{"md":"$","nm":"Entry","pk":"$","ta":{"Entry.Item":{"nm":"Value","pk":"."},"Entry.Key":{"md":"$","nm":"String","pk":"$"}}}}},"mt":"prm","nm":"values"}],
    "super":{"nm":"Object","pk":"."}}

and a test program generating an error is:

JsonObject o = JsonObject { "key"->"value" };

Assertion failed
        violated is ClassModel | ConstructorModel resolved
            =   constructor.constructor
ceylon.language.AssertionError "Assertion failed
        violated is ClassModel | ConstructorModel resolved
            =   constructor.constructor"
        at com.vasileff.ceylon.dart.compiler.core.resolveClassAliases_.resolveClassAliases(functions.ceylon:519)
        at com.vasileff.ceylon.dart.compiler.core.computeCaptures_$1captureVisitor_.captureForClass$priv$(computeCaptures.ceylon:205)
        at com.vasileff.ceylon.dart.compiler.core.computeCaptures_$1captureVisitor_.visitBaseExpression(computeCaptures.ceylon:181)

Copy this nice optimization from the Java compiler.

This:

noop("``nothing``");

currently fails to compile as an attempt is made to find a member named "string" in the type Nothing. Instead, we should treat the instance as Anything, and use Object.string if not null, or "<null>" if Null.

Surely this used to work?

class X(fun) {
    shared String fun(String s);
}

this does work:

class X(shared String fun(String s)) {}

The first compiles to:

class X implements $ceylon$language.dart$$Basic {
  X([$ceylon$language.Callable fun]) {
    this._fun$c = fun;
  }
}

and the second:

class X implements $ceylon$language.dart$$Basic {
  X([$ceylon$language.Callable fun]) {
    this._fun$c = fun;
  }
  $ceylon$language.Callable _fun$c;
  $dart$core.String fun([$dart$core.String s]) {
    return $ceylon$language.$dartString(_fun$c.f($ceylon$language.$ceylonString(s)));
  }
}

So generation of _fun$c and fun is not being triggered in the split declaration case.

While not specified AFAICT, expressions like:

obj.attribute++

and

obj.attribute += 1

should evaluate obj only once. This especially matters if obj has side effects.

Edit: and for postfix increment and decrement operators, attribute should only be evaluated once.

Support assignments like array[index] = val;. See eclipse-archived/ceylon#4148

For example, with:

shared class StaticTest {
    static late String s;
    s = "s";
    shared new () {}
}

s is not marked static in the generated code, resulting in

NoSuchMethodError: method not found: '_s='

Ceylon AST cannot handle the output of the typechecker for:

[""->""].map((k->v) => v else "<null>");

The workaround is to add parens in the source code.

Waiting on eclipse-archived/ceylon#6427 for a fix.

The most reasonable (edit: or not... see below) output for the code below is what the JVM produces, where the assignment to a late value is non-polymorphic unless the value has a late or variable refinement.

I'm guessing the JVM behavior is a natural result of setX() refinements existing for j and k, but not i.

class A() {
    shared default late Integer i;
    shared default late Integer j;
    shared default late Integer k;

    shared void initialize(Integer x) {
        i = x;
        j = x;
        k = x;
    }
}

class B() extends A() {
    shared actual Integer i = 1;
    shared actual variable Integer j = 1;
    shared actual late Integer k;
}

shared void runit() {
    value b = B();
    b.initialize(2);
    printAll { b.i, b.j, b.k };
    // {1, 2, 2}      on JVM
    // {1, 1, Crash!} on JS
    // {2, 2, 2}      on Dart
}

OTOH, @gavinking, should each of these be allowed?

For the implementation, we could do one of the following:

1. use a late indicator value (analogous to dartDefault) for uninitialized values, or
2. do what the Java backend does: use null as the indicator value for non-optionals, and a separate Boolean for optionals.

For the first, we'd have to use Object as the type for the underlying value and add casts in exposed getters and setters, but that should be fine.

• Mark named parameters as such when generating model info for interop modules
• Generate named arguments as necessary for Dart function invocations

Dart "private" members of classes are polymorphic, at least within the same package. Ceylon non-shared members are not; a private member may shadow, but not override a super class member of the same name.

So we need some way to distinguish Super.x from Sub.x. The easiest (only?) approach may be to use globally (or at least module-wide) unique names for private members. This isn't a problem for interfaces since static invocation is always used for non-shared interface members.

The code below currently prints "B B" rather than "A B":

shared void run() {
    class A() {
        String id => "A";
        shared String idA => id;
    }
    class B() extends A() {
        String id => "B";
        shared String idB => id;
    }
    print(B().idA); // should print "A"
    print(B().idB); // should print "B"
}

the problem can also occur with outer in a recursive member class:

shared void run() {
    class C() {
        String id => "C";
        shared class D() extends C() {
            String id => nothing;
            shared String outerId => outer.id;
        }
    }
    print(C().D().D().outerId); // should print "C", not crash on `nothing`
}

or on invocation of a static reference:

shared void run() {
    class E() {
        String id => "E";
        shared class F() extends E() {
            String id => nothing;
            shared String eId => E.id(this);
        }
    }
    print(E().F().eId); // should print "E", not crash on `nothing`
}

I had no idea they were a thing.

Forward declared values can be specified as functions:

String(String) v1;
v1(String s) => s;

Make this work.

Ceylon allows new value definitions in assert to shadow declarations made in outer scopes, even if the declaration has already been used in the same block containing the assert. Java allows similar, but Dart doesn't.

This fails at runtime:

class B() {
    shared variable Integer x = 10;
}
class C() extends B() {
    shared void f() {
        print(x); // 10
        assert(is Integer x = 20 of Anything);
        print(x); // 20
    }
}

#12 is similar.

This did work recently...

Support static class (and interface, why not) members including:

• classes
• class aliases
• interfaces
• interface aliases
• functions
• values
• objects
• aliases

See eclipse-archived/ceylon#6515 (comment)

Future.then (docs) is defined as:

Future/*<S>*/ then/*<S>*/(/*=S*/ onValue(T value), { Function onError });

which results in the return type Future<Nothing> in Ceylon. Instead, we should consider hard-coding the model to have something like:

Future<S> then<S>(S|Future<S> onValue(T value), ...);

although, it may need to be more complicated, like:

Future<S|E|Throwable> then<S,E=Nothing>(S|Future<S> onValue(T value), E onError(Nothing) = nothing)

which starts to defeat the purpose. Especially since non-Throwables can be thrown in Dart. So, would we actually wind up with a return type of Future<Anything>?

Edit: not sure why I had Throwable in the union. Need to test this. It might be:

Future<S|E> then<S,E=Nothing>(S|Future<S> onValue(T value), E onError(Nothing) = nothing)

shared void run() {
    C().foo();
}

class C() {
    shared variable String? attribute = "";
    shared void foo() {
        switch (attribute = attribute)
        case (is Null)   { }
        case (is String) { }
    }
}

fails with:

error: line 17 pos 31: initializer of 'attribute' may not refer to itself
            $dart$core.String attribute = attribute;
                              ^

We'll probably have to force a this. qualifier.

From @quintesse:

I added a --include-dependencies option to both the JVM and the JS compilers so I think you should probably add that to the Dart compiler too. This commit shows the changes I made to the JS compiler, it isn't much: eclipse-archived/ceylon@b70258a
It's just that the runCompiler() method in the RepoUsingTool now expects this option to exist

Dart dynamic is currently mapped to:

• Nothing for return types
• Anything for parameter types
• Nothing for type arguments (since generics in Dart are always covariant)

The idea was to be permissive, and somewhat match Java's pre-generics type safety.

But, this is probably too permissive. So let's try making dynamic always map to Anything, and see if the asserts are manageable.

See also 234ef05

In #8, each Dart type turns into a Ceylon interface and a static member class named Class. For generic Dart types, both the Ceylon interface and static class currently have type parameters. But, since in Ceylon, qualifying type type parameters are in scope for static members, the Class's type parameters are redundant and should be removed.

For most non-empty iterable-to-sequence operations where the iterable is not actually empty, there is a class cast exception. But this one trips up the Dart backend:

    object lyingIterable satisfies {Integer+} {
        iterator() => emptyIterator;
    }
    Integer x = [1, *lyingIterable][1];
    print(x); // <null>

It may be best to explicitly check all spread arguments involving non-empty Iterables.

for should even iterate {finished} at least once, or throw. See eclipse-archived/ceylon#5866

See eclipse-archived/ceylon@9ecc2eb...6a9366e for an example of what to do.

I have tried different versions of "ceylon new -name=foo", but I always get this:

ceylon new: Argument 'name' to command 'new' should appear at least 1 time(s)

I'm looking forward to playing more with Ceylon and Dart. ;-)

Per §4.2.2, this should work:

import ceylon.language {
    true {
        string
    }
}

shared void run() {
    print(string);
}

print(string) currently compiles to:

$ceylon$language.print($ceylon$language.String.instance(toString()));

but should be:

$ceylon$language.print($ceylon$language.String.instance($ceylon$language.$true.toString()));

Currently makePrivate() prepends _$ to avoid conflicts with Ceylon identifiers that already begin with _. Instead, we should:

1. Not use makePrivate() on class initializer parameters, and
2. Prefix Ceylon parameters that begin with _ with $, since Dart parameters should begin with _.

Test case:

shared class AvoidNonUniqueNames(String myString, shared String _myString) {}

Classes and interfaces with the same ancestry and name need to be disambiguated:

shared void run() {
    if (1==1) {
        interface I {}
        class C() satisfies I {}
    }
    else {
        interface I {} // compiles to same name as previous interface I
        class C() satisfies I {} // compiles to same name as previous class C
    }
}