• Importing Nice packages.

• Importing Nice packages.

Important

Thanks.

-- BrynKeller - 01 Oct 2003

Discussion

• How do you interoperate with Java code that relies on features Nice doesn't have (inner classes) [Developer Guide not Manual] -- IsaacGouy - 08 Feb 2004

• How do you interoperate with Java code that relies on features Nice doesn't have (inner classes) [Developer Guide not Manual] -- IsaacGouy - 08 Feb 2004 (Answer for inner classes: nothing special, you can specify the name as ToplevelClass.InnerClass)

• The requirement of using fully qualified name for the class at abstract interface implementations.

• Main method should be outside a class

• Enums

• Class initializers
• Custom constructors

• Block call syntax

• Nullness inference on fields (need to make a local var and use that instead)

• Main method should be outside a class
• Enums
• Class initializers
• Custom constructors
• Block call syntax
• Nullness inference on fields (need to make a local var and use that instead)

• overview short paragraph giving the big information - methods not contained in classes or interfaces; classes holders of state not methods; packages encapsulate state, type, methods -- IsaacGouy - 12 Feb 2004

• References to Methods (maybe this is the same as function type syntax?) Explain how we get a reference to a package/local method and an object method let String->String f = toLowerCase; IsaacGouy

• References to Methods (maybe this is the same as function type syntax?) Explain how we get a reference to a package/local method and an object method let String->String f = toLowerCase; [Developer Guide not Manual] IsaacGouy

• Java differences no switch statement - how do you do that in Nice (value dispatch, nested if)
• How do you interoperate with Java code that relies on features Nice doesn't have (inner classes) -- IsaacGouy - 08 Feb 2004

• Java differences no switch statement - how do you do that in Nice (value dispatch, nested if) [Developer Guide not Manual]
• How do you interoperate with Java code that relies on features Nice doesn't have (inner classes) [Developer Guide not Manual] -- IsaacGouy - 08 Feb 2004
• Manual doesn't say that abstract interfaces are not inherited

• Interfaces seem to be like Traits rather than Java interfaces - I haven't seen this mentioned anywhere? IsaacGouy - 24 Jan 2004

Hmmm maybe there's something to be said for being explicit, my guess would have been

   let greeting  =   "\nHello, world.\n"
                 + "You may be thinking, \"Why was I called here today?\"\n"
                 + "Well, there was a good reason. Honest.\n";

*Java differences no switch statement - how do you do that in Nice (value dispatch, nested if)

• How do you interoperate with Java code that relies on features Nice doesn't have (inner classes) -- IsaacGouy - 08 Feb 2004

• Multi-line string contstants

• Multi-line string constants

String Examples

The documentation mentions multi-line strings but it would be clearer to show how they would map to traditional syntax. For example, it is not clear how whitespace at the beginnning/end of an internal line works in a multi-line string.

    let greeting  = """
            Hello, world.
       You may be thinking, \"Why was I called here today?\"
       Well, there was a good reason. Honest.
      """;   

   let greeting  =   "Hello, world. "
                 + "You may be thinking, \"Why was I called here today?\" "
                 + "Well, there was a good reason. Honest.";

   let greeting  =   "Hello, world.\n"
                 + "You may be thinking, \"Why was I called here today?\"\n"
                 + "Well, there was a good reason. Honest.";

• Expression local variables

• Treat ints as bit arrays
• || operator with nulls

• Treat ints as bit arrays (this is defined in nice.lang, not sure it belongs in the manual)
• || operator with nulls (idem, defined in nice.lang )

• Range expressions

• Interfaces seem to be like Traits rather than Java interfaces - I haven't seen this mentioned anywhere? IsaacGouy - 24 Jan 2004

• Value dispatch - instances, null, chars

• Range expressions - metioned in for loop section, should have a section in expressions chap.

• Interfaces seem to be like Traits rather than Java interfaces - I haven't seen this mentioned anywhere? IsaacGouy - 24 Jan 2004
• Value dispatch - instances, null, chars

• Super calls
• Nullness inference on fields (need to make a local var and use that instead)

• Suggestions go here - Isaac?

• KnownIssues

|| is a method defined in nice.lang, so I don't think it should be documented in the UserManual?. As soon as we have a working nicedoc, we'll publish the documentation for the standard libraries on the website.

The general question is to document when autoboxing happens. On the one hand, one can often see that as an implementation detail, but either when you use reference equality or for performance reasons, it is sometimes important to know. So yes, that should be better documented. I'm not sure if it should go in the UserManual?, or if we should have a different document for lower-level aspects like this (this does not really belong to the definition of Nice itself, it just happens to work like this when you compile to the JVM).

The rule is that when a primitive value is used when a generic type (T) or an Object is expected, the value is boxed. Unboxing happens as need when a boxed value is used where a primitive type is expected.

-- DanielBonniot - 30 Jan 2004

The OptionOr? can make sense for numeric types too, example:

Map<String, int> map = new HashMap();
map["abc"] = 5;
int n1 = map["xyz"] || -1;
int n2 = map["abc"] || -1;
println(n1); //prints -1
println(n2); //prints 5

It's not possible to give OptionOr? a type so that it requires the first parameter to be an option type because of the typechecking rules for function application. But OptionOr? is an inlined operator so it would be possible to generate a warning when using it with a non option type first argument.

-- ArjanB - 29 Jan 2004

• Autoboxing

It was mentioned in the ConstructorSyntax discussion I believe. I tried it out because it wasn't documented and I wanted to figure out the semantics. I think it is important to document the semantics explicitly. But I think that I may be wrong about autoboxing anyway; it is also not documented and I haven't been able to figure out the autoboxing semantics yet. Anyway, I think that operator || is simply mistyped and should not apply to int/byte/long/float/double since it doesn't make any sense for numeric types. Maybe the typing should be:

    <Any T, T U> !T `||`(#?T e1, !U e2) = inline nice.lang.inline.OptionOr();
    <Any T, T U> ?T `||`(#?T e1, ?U e2) = inline nice.lang.inline.OptionOr();

What made you trying out all kinds of variations with the || operator?

Why do you use Integer as type instead of int?

I don't think users need to know about how autoboxing happens. -- ArjanB - 29 Jan 2004

The documentation for || with nulls should explain the interaction between || and autoboxing. In particular, 1 || 2 seems to be the same as new Integer(1) || new Integer(2). (The compiler should also be able to detected the dead code in this situation: new Integer(1) can never be null, so new Integer(2) is never executed.)

The documentation for || with nulls should explain the interaction between || and autoboxing. In particular, 1 || 2 seems to be the same as new Integer(1) || new Integer(2). (The compiler should also be able to detected the dead code in this situation: new Integer(1) can never be null, so new Integer(2) is never executed.) Also, the documentation should explain the way that || coexists with the nullness checking for fields as demonstrated at the end of this example:

Integer doublePipe(?Integer i) = i || new Integer(1); int doublePipe(int i) = i || 1;

class A { ?Integer n; }

System.out.println(doublePipe(0)); System.out.println(doublePipe(null));

println(0 || 1); println(2 || 1);

println(null || new Integer(1)); println(new Integer(2) || new Integer(1));

let a1 = new A(n: null), a2 = new A(n: new Integer(2));

println(a1.n || new Integer(1)); println(a2.n || new Integer(1));

Integer n1 = a2.n || new Integer(1); println(n1);

// NOT equivalent to // n2 = a2.n || new Integer(1); // error: // The value if(`!=`(a2.n(), null)) // a2.n() // else // new Integer(1) // cannot be assigned to n2 because it might be null. // // Integer n2 = a2.n != null ? a2.n : new Integer(1); // println(n2);

// equivalent to // n3 = a2.n || new Integer(1); ?Integer temp = a2.n; Integer n3 = temp != null ? temp : new Integer(1);

println(n3);

2 1 2

2 2 2

The documentation for || with nulls should explain the interaction between || and autoboxing. In particular, 1 || 2 seems to be the same as new Integer(1) || new Integer(2). (The compiler should also be able to detected the dead code in this situation: new Integer(1) can never be null, so new Integer(2) is never executed.)

    Integer doublePipe(?Integer i) = i || new Integer(1);
    int doublePipe(int i) = i || 1;
    void main(String [] args) {
       System.out.println(doublePipe(0));
           System.out.println(doublePipe(null));
    }

    0
    1

• Interfaces seem to be like Traits rather than Java interfaces - I haven't seen this mentioned anywhere? IsaacGouy

• Interfaces seem to be like Traits rather than Java interfaces - I haven't seen this mentioned anywhere? IsaacGouy - 24 Jan 2004

Something else to consider, note what we cannot do (yet) as well as what we can do.

-- IsaacGouy - 29 Dec 2003

Added a new section for this above. Any ideas what should go in it?

-- BrynKeller - 13 Jan 2004

I keep learning about the restrictions and then forgeting :-( Or raising the possibility of removing the restrictions ;-)

-- IsaacGouy - 14 Jan 2004

• References to Methods (maybe this is the same as function type syntax?) Explain how we get a reference to a package/local method and an object method - let String->String f = toLowerCase; IsaacGouy

• References to Methods (maybe this is the same as function type syntax?) Explain how we get a reference to a package/local method and an object method let String->String f = toLowerCase; IsaacGouy

• Interfaces seem to be like Traits rather than Java interfaces - I haven't seen this mentioned anywhere? IsaacGouy

• Extending, implementing classes and difference between implements and finally implements

• References to Methods (maybe this is the same as function type syntax?) Explain how we get a reference to a package/local method and an object method - let String->String f = toLowerCase; IsaacGouy

• Package Methods (which used to be toplevel methods) the section on 'Local Methods' refers to them but I can't find anything else in the manual that explains them. IsaacGouy

I keep learning about the restrictions and then forgeting :-( Or raising the possibility of removing the restrictions ;-)

-- IsaacGouy - 14 Jan 2004

Things that we can't do yet:

• Suggestions go here - Isaac?

Added a new section for this above. Any ideas what should go in it?

-- BrynKeller - 13 Jan 2004

Something else to consider, note what we cannot do (yet) as well as what we can do.

-- IsaacGouy - 29 Dec 2003

• Block call syntax
• Explanations of manual formatting conventions (for syntax examples and so on)

• Arrays: type syntax, and literals: [e1,...,eN]

• Multi-line string contstants
• String concatenation by juxtaposition

• Array type syntax (with option types)
• Function type syntax (with option types)

• (Toplevel) functions do not exist anymore, their syntax is now equivalent to a method declaration together with its default implementation.

Things that have now been done:

• Method override syntax changes
• (Toplevel) functions do not exist anymore, their syntax is now equivalent to a method declaration together with its default implementation.
• Multi-line string contstants
• String concatenation by juxtaposition
• Array literals: [e1,...,eN]

• Class initializers
• Custom constructors

• The type of Object

• String concatenation by juxtaposition

• !T vs. T clarification, as discussed on the Nice-Info list. Include definition of 'subtype' in Nice.

• Retypings - it needs more explaination and more kinds of retypings exist(constructors, fields, static methods)

• Array literals: [e1,...,eN]

• Arrays: type syntax, and literals: [e1,...,eN]

• Main method should be outside a class.
• OperatorOverloading?

• Main method should be outside a class
• OperatorOverloading? (including get and set )
• Range expressions
• Enums
• Treat ints as bit arrays
• || operator with nulls
• Type inference (variables, for loops, null-tests, instanceof narrowing)
• Multi-line string contstants

• Value dispatch - instances, null, chars
• Classes - initializers, overridable finals

Important

Thanks.

-- BrynKeller - 01 Oct 2003

-- DanielBonniot - 20 Jul 2003

Aspects that should be updated:

• (Toplevel) functions do not exist anymore, their syntax is now equivalent to a method declaration together with its default implementation.

• OperatorOverloading?

• Main method should be outside a class.

• Additional type in patterns to resolve ambiguities: ident@type(additionaltype)

%META:TOPICINFO{author="DanielBonniot" date="1058730724" format="1.0" version="1.1"}% %META:TOPICPARENT{name="WebHome"}% These are aspects of the language that are not covered by the User Manual, but that should be.

• Array literals: [e1,...,eN]

-- DanielBonniot - 20 Jul 2003