The Java implementations of Map are Set are missing members.

There are some classes lying around in ceylon.language/runtime that don't occur in ceylon.language/languagesrc. Some of them appear to be needed, e.g. Annotation. Others appear to be garbage from long ago, e.g. Any.

Stef, would you please help me figure out which are needed and which are not? Thanks!

Is this intentional? I'd have thought that separators should not be included by default…

When I implemented span() everywhere, I had it returning empty spans when to<from. Actually, this is supposed to be a reverse-order span.

A second issue is whether segment() should accept an integer as its second argument, allowing backward segments.

The tour talks about these two creatures, but they never got added to the language module!

I wonder if we actually need something like a Platform type to hold this info, since it could vary b/w JVM and JS.

The relationship between Set and Slots doesn't seem to be working out.

The thing holding this up is the code to enforce the rules that apply to subtypes of an enumerated interface type.

Currently Numeric is a subtype of both Comparable and Number. But this isn't very nice for Complex numbers. So I propose introducting Scalar which mixes in Numeric, Comparable, and Number, and has Float, Integer, and Natural as subtypes. Then Integral would also be a subtype of Scalar. Any objections?

Decide what to do with naturals.

All the things declared object including instances of Boolean and Comparison are just attributes, they don't have their own type, which means they can't be used in a switch.

http://ceylon-lang.org/code/source/#ceylonlanguage_module links to "See the API documentation for more information." at

http://ceylon-lang.org/documentation/api/current/

That page gives me 403 Forbidden.

The page at http://ceylon-lang.org/documentation/api/current/ceylon/language works.

The by() method is missing from Range.

The entries() function is not done.

Now that ceylon/ceylon-compiler#238 is done, we need to add the appropriate annotations to the runtime classes.

We need tests for Range and Entry.

Add these useful functions to the language module.

Some of the attributes (e.g. name) in Module and Package descriptors are Quoted. If single quoted literals won't be supported till 1.1 how do we expect people to use the descriptors?

(It works in ceylon.language we just create a Quoted Java-side.)

The List class either has to implement FixedSized, or it must not be used as return value for span and segment methods; nonempty cannot be used on it.

Some tests are breaking right now:

  [ceylonc] ceylon.language/test/sequences.ceylon:45: compiler message file broken: key=compiler.err.ceylon arguments=expression must be a type with fixed size: List<String> is not a supertype of FixedSized, {1}, {2}, {3}, {4}, {5}, {6}, {7}
  [ceylonc]     assert(nonempty singleton.span(0, 1), "nonempty singleton span(0,1)");
  [ceylonc]            ^

  [ceylonc] ceylon.language/test/sequences.ceylon:143: compiler message file broken: key=compiler.err.ceylon arguments=expression must be a type with fixed size: List<String> is not a supertype of FixedSized, {1}, {2}, {3}, {4}, {5}, {6}, {7}
  [ceylonc]     assert(nonempty result.span(0,0), "nonempty sequence.span(0,0)");
  [ceylonc]            ^

I think List should implement FixedSized (unless it's mutable but it doesn't seem to be).

StringBuilder would be a lot more useful if methods returned this instead of void, since calls could be chained as in sb.append("A").appendCharacter('B').appendNewLine().appendAll("C", "D").appendSpace().append("E").

This could also apply to SequenceBuilder, although there's not much point in that as it only has two methods, to append a single Element and a sequence of Elements.

This:

throw Exception("Invalid Scheme");

Results in:

symbol  : variable Exception$impl
location: class ceylon.language.Exception
        throw Exception("Invalid Scheme");
              ^

I thought this used to be working.

Only the first line is meaningful for us, so the rest should be filtered out. Potentially we may have to filter out more compiler-generated artifacts but that's a good start.

        at fr.epardaud.net_test.testAll.testAll(decomposition.ceylon:54)
        at fr.epardaud.net_test.testAll.main(decomposition.ceylon)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at ceylon.modules.api.runtime.SecurityActions.invokeRunInternal(SecurityActions.java:85)
        at ceylon.modules.api.runtime.SecurityActions.invokeRun(SecurityActions.java:76)
        at ceylon.modules.api.runtime.AbstractRuntime.invokeRun(AbstractRuntime.java:66)
        at ceylon.modules.api.runtime.AbstractRuntime.execute(AbstractRuntime.java:106)
        at ceylon.modules.Main.execute(Main.java:74)
        at ceylon.modules.Main.main(Main.java:53)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.modules.Module.run(Module.java:248)
        at org.jboss.modules.Main.main(Main.java:313)

We are missing methods to parse a String and get a number out of it!

It looks like we can now merge the semantics of Equality into Object and remove the Equality interface, leaving == defined for any Object, which would greatly simplify a few things. See mailing list discussion titled "Object, IdentifiableObject and Equality". In particular, it lets us have well-defined equality for sequences.

Note that this requires first changing the compiler and typechecker!

It uses Java's StringTokenizer and I've never liked it much. For example, I believe that "a//b" tokenized by "/" should return three tokens: "a", "", "b". But it doesn't: it ignores empty tokens for some reason.

I just ran ant publish test and found that certain tests fail because the wrong String is returned (or expected):

  [ceylonc] ceylon.language/test/numbers.ceylon:52: incompatible types
  [ceylonc] found   : ceylon.language.String
  [ceylonc] required: java.lang.String
  [ceylonc]     assert((1.0).string in {"1", "1.0"}, "float string 1.0");
  [ceylonc]            ^
  [ceylonc] ceylon.language/test/operators.ceylon:17: incompatible types
  [ceylonc] found   : ceylon.language.String
  [ceylonc] required: java.lang.String
  [ceylonc]     assert(!nonempty empty[].uppercased, "spread 1");
  [ceylonc]                      ^
  [ceylonc] ceylon.language/test/operators.ceylon:18: incompatible types
  [ceylonc] found   : ceylon.language.String
  [ceylonc] required: java.lang.String
  [ceylonc]     assert(nonempty full[].uppercased, "spread 2");
  [ceylonc]                     ^
  [ceylonc] ceylon.language/test/operators.ceylon:19: incompatible types
  [ceylonc] found   : ceylon.language.String
  [ceylonc] required: java.lang.String
  [ceylonc]     value spread1 = full[].uppercased;
  [ceylonc]                     ^

We need a default implementation of Equality operations on the abstract collections.

Further to #30 we need to fix parseInteger() and parseFloat() so that only numbers conforming to the Ceylon literal syntax for integers and floats, optionally preceeded with a sign character (+/-) , are accepted. E.g. parseInteger("+1_000") and parseInteger("-1k") should be allowed.

Ordinal.successor and Ordinal.predecessor are documented to throw OverflowException. Since ++ and -- are defined in terms of Ordinal this leads to the unintuitive fact that x++ can throw but x := x + 1 never will. Is this what we want?

Secondly, the compiler optimizes ++ and -- on Integer to a Java ++/--, so that overflow won't be detected. Which makes things even more unintuitive.

Remove the Slots and FixedSlots interfaces and redefine the operators in terms of Set<Element>.

interface Qux {}

interface Foo<out T> {
    shared formal T foo();
}
interface Bar<out T> satisfies Foo<T> {
    shared formal actual T&Qux foo();
}

void test<X,Y>(Foo<X>&Bar<Y> x) {
    value foo = x.foo();
}

In this code, foo should have type X&Y&Qux, but it actually gets the type X&Y in the current implementation.

error encountered [formal member clone not implemented in class hierarchy] at 8:8-55:8 of entries.ceylon
error encountered [formal member lastIndex not implemented in class hierarchy] at 8:8-55:8 of entries.ceylon
error encountered [formal member rest not implemented in class hierarchy] at 8:8-55:8 of entries.ceylon

I tried but I have to admit I could not find the right method declaration (return type) for clone and rest.

This might be affected by issue #14

The xxxxOccurrence() methods return raw string indexes and the span() and segment() methods accept them. These all need to be adjusted to use count codepoints.

These functions should simply wrap their argument sequence. There's no need to allocate a whole new array.

The doc for Number.integer says explicitly that fractional parts are truncated. The Java implementation of this currently calls Math.round().

In section 4.5.6. of the spec:

1. The return type of the method in the second code example should be Callable<Comparison,Integer,Integer> (two Ls, not one)
2. The third code example is missing a + before lastName in the return statement.

All Java classes are subtypes of IdentifiableObject and Equality, but currently Util will only consider a class to be a subtype of these types if it has has explicit annotations specifying this. I suppose we need to take into account the absence of a @Ceylon annotation?

ceylon/ceylon-spec#119

We should move things like emptyIterator and all types required by the compiler into their own package rather than in ceylon.language.

Additionally we should probably remove the boxing methods of String, Integer, etc (value() and instance()) and put them into something like BoxUtils in that new impl package.

Note that this requires coordination with the compiler backend.

Should the relationship be:

1. A List is a Sequence, and a String has a List of Characters, or
2. A List has a Sequence, and a String is a List of Characters?

Note that String can't be a subtype of Sequence because we don't want to have to use Empty to represent the empty string.

UPDATE:

By way of explanation for the benefit of folks who are coming to this thread without sufficient context: sequences in Ceylon have that they are immutable as part of their contract. Sequence doesn't have add() and remove() methods. And the first operation of Sequence returns a non-null value. And so whether something is a Sequence or an Empty is statically determined.

One advantage of this, among others, is that it means that we can write a function like:

`T min<T>(Sequence<T> sequence) 
         given T satisfies Comparable<T> { ... }`

That has a non-null return type. This is better than what we can do if we want to accommodate the Empty case:

`T? min<T>(T[] sequence) 
        given T satisfies Comparable<T> { ... }`

One of the questions that this issue is implicitly touching on is:

Can you have a mutable List?

Clearly, if a List is a Sequence you would not be able to. (But we also have other motivations for thinking that interfaces like List, Map, and Set should have immutability as part of their contract.)

On the JVM we can promise 64 bit Integers, but on JS we can't, since JS only has Number, which is double precision floating point. So we can't actually promise anything more than 52 bits (the significand). How are we going to cope with this?

Float.positive is currently implemented as return value > 0. Similarly for .negative, this means that +0.0 and -0.0 are neither positive nor negative (just like NaN). We should document the expected behavior of zero.

The fact that foo.positive is not the same as ! foo.negative is likely to be a source of subtle bugs.

I think we should throw an exception for NaN.

Right now there's no way to determine if a Float value is infinity or NaN.

We need int.character and char.integer to do conversions between characters and code points.

The root package is very big. See if we can reorg it into several smaller packages.

Section 4.5.6 of the spec says:

A method which declares more than one parameter list returns instances of Callable.

Using the example given in the spec:

Comparison getOrder()(Integer x, Integer y) {
    return x<=>y;
}

If I try to call getOrder():

Callable<Comparison,Integer,Integer> c = getOrder();

I'm told "specified expression must be assignable to declared type: Comparison is not assignable to Callable<Comparison,Integer,Integer>".

Java's Double.equals() treats NaN (and -0.0) specially so that NaN can be used in HashMaps and HashSets. Similarly Double.compareTo() treats NaN as equal to itself. Are we comfortable with NaN not be retrievable from hash-based and ordered collections?

Would range() and measure() be better names than span() and segment() ?

Thoughts?

There are some assertions in the tests for Singleton.segment that indicate unintuitive behavior of Singleton.behavior, as well as contradictory ones:

assert(nonempty singleton.segment(0, 1), "nonempty singleton segment(0,1)");
assert(!nonempty singleton.segment(0, 0), "!nonempty singleton segment(0,0)");
assert(!nonempty singleton.segment(0, 1), "!nonempty singleton segment(0,1)");
assert(nonempty singleton.segment(0, -1), "nonempty singleton segment(0,-1)");

The first two are contradictory. I think the first one should is the correct one and the second one should be removed.
The third one should not be negated; I think singleton.segment(0,1) should be nonempty.
The fourth one, I think we had established that negative lengths for segment would return empty.

Ross points out that enumerated subtypes of a type must have the same variance as the supertype.

The split() method is unimplemented. I wonder if it should be toplevel? Also reversed is missing.