0

Is it possible to implement the ceylon typechecker in such a way, that a class, that satisfies an interface directly (types in members signatures are the same as in the interface being satisfied), can omit types in its own members signatures?

This would help to reduce visual clutter at implementation site by moving all meta information (types, annotations) to the interface. And it helps to focus on implementation details.

This would be close to a signature file in ocaml.

And it could help to say more, more clearly.

Edited after the answer was given by Lukas Werkmeister:

What I'd like to have is a shortcut syntax that works not only for attributes but also for methods.

Look at "name(x)" in class Person:

interface Named {
    shared formal String name(String n);
}
class Person(shared String  firstName, shared String lastName) satisfies Named {

    name(x) => firstName + x +" " + lastName;

}

Named named = Person("Lucas", "Werkmeister");
print(named.name);

3 Answers3

2

This isn't allowed because it would be a bit too syntactically ambiguous. That is, it's impossible for the parser to distinguish name(x, y, z) from an invocation expression, until it finally hits the =>. This would result in some pretty undesirable behavior, for example, in the IDE when you start typing in a shortcut refinement, the parser would treat it as an invocation expression, and display errors on x, y, and on z.

In general we're very careful to make sure that we don't have any syntactic constructs that require too much lookahead to make sense of.

Gavin King
  • 3,182
  • 1
  • 13
  • 11
  • The decision criterion shouldn't be what the parser is doing. Its important to respect the needs of user of the language. –  Mar 07 '16 at 09:56
  • 3
    I think that's a very naive way to design the syntax of a language. If tools (i.e. the compiler, the IDE) can't easily disambiguate a syntactic construct, then the user experience is going to be terrible: confusing error messages, broken autocompletion, etc, etc. "Respecting the needs of the user" includes paying attention to what is the user experience when they have written something that's a little incorrect, or a little incomplete. – Gavin King Mar 08 '16 at 12:46
0

Yes, with the shortcut refinement syntax: you can simply write thing => ...; instead of shared actual Type thing => ...;. For exampled

interface Named {
    shared formal String name;
}
class Person(firstName, lastName) satisfies Named {
    shared String firstName;
    shared String lastName;

    name => firstName + " " + lastName;
    // shortcut for
    // shared actual String name => …;
}

Named named = Person("Lucas", "Werkmeister");
print(named.name);

Try online

Lucas Werkmeister
  • 2,584
  • 1
  • 17
  • 31
0

Shortcut refinement does work with methods too, you just need to specify the parameter types:

interface Named {
    shared formal String name(String n);
}

class Person(shared String  firstName, shared String lastName) satisfies Named {
    name(String x) => firstName + x +" " + lastName;
}
gdejohn
  • 7,451
  • 1
  • 33
  • 49
  • Well, yes. But parameter types aren't really necessary for type inference. In scala: abstract class A { var a : Int }; class B extends A { var a = 2}; In contrast Ceylon's type inference is somewhat weak. –  Feb 25 '16 at 20:10
  • I'd expected this to work in ceylon: String( String ) name = (x) => " x: " + x; In scala it's correct to say: val a : Int => Int = (s)=> 3; –  Feb 25 '16 at 20:11
  • That discussion is probably better suited to [GitHub](https://github.com/ceylon/ceylon-spec/issues/new). – gdejohn Feb 25 '16 at 23:12