The Nice user's manual

If a package contains a method whose name is main and the method has a void return type and takes a single String[] as its argument, this method receives special treatment, in that when the program is run, execution will begin with this main method. The runtime system will pass the command line arguments used to invoke the program as the argument to main.

Note that since the main unit of code in Nice is the package, and not the class, the main method should be implemented outside of any class declaration.

The main component of a class is the list of its fields. A field is a variable that is attached to each instance of the class. It has a type, a name, and optionally a default initial value. The syntax for field declaration is:

	  type field-name[ = initial-value];
	

If no default value is given, then every call to the constructor must specify the value for this field. If it is given, a call to the constructor call still override it with a different value, in which case the default value is not computed (this fact is only important if it has side effects).

Classes in Nice have a default (or "automatic") constructor which is generated automatically by the compiler. This constructor allows all the fields of the class to be specified explicitly, though if the field has a default value in the class definition, it can be omitted from the constructor call and the default value will be used. In many cases this default constructor is all that is needed, and it saves the programmer from having to write tedious code that simply accepts values and assigns them to fields.

class Car
{
  String brand;
  String model;
  int numberOfWheels = 4;
  int numberOfDrivingWheels = 2;
}

void test()
{
  Car renault5 = new Car(brand: "Renault", model: "Cinq");
  Car jeep = new Car(brand: "Jeep", model: "Some jeep", numberOfDrivingWheels: 4);
}

It is required to include the names of the fields in the call to the constructor. This is important for two reasons. First, it is easy to understand what the arguments represent, without looking at the class definition. Second, it does not require some arbitrary ordering of the fields ^[1]. Because the names of the fields are used, they can be given in any order.

When more control over construction is desired, it is possible to write new constructors that can be used in place of the automatic constructor. These are written much like any other method, but they use a slightly different declaration syntax:

	  new class-name(param-typeparam-name[ = initial-value], ...) 
	  { 
	    method-body;
	    this(argument, ...);
	  }
	

This syntax requires that the last statement in any custom constructor calls some other constructor for the same type. In most cases, the automatic constructor will be called.

/** 
 * Class which encapsulates a strategy for 
 * way of translating a character.
 */
class Translator
{
  //The function that actually performs the translation
  char->char transFunction;

  //convenience method 
  char translate(char input) 
    {
      return (this.transFunction)(input);
    }
}

/**
 * Constructor which takes a map of characters, and
 * returns a Translator which looks up the input 
 * character in the map, or just returns the input
 * character if it's not in the map.
 */
new Translator(Map<char,char> characters) 
{
  this(transFunction: char c => characters.get(c) || c);
}




//A translator which provides rot13 ciphering.
//Uses automatic constructor.
var Translator rot13 = new Translator(transFunction: 
				      char c => char(int(c) + 13));

//A translator which just changes 's' or 'S' to '$'.
//Uses custom constructor.
var Translator sToDollar = new Translator(characters: listToMap([
						      ('s', '$'), 
						      ('S', '$')
						      ]));
	

It is also possible to define initializers for your classes. An initializer is simply a block of code that executes after construction is finished. To define an initializer, simply include code directly in the class definition, inside a block:

	  class class-name
	  { 
	    {
	      initializer
	    }
	    fields-and-methods
	  }
	

Here is an example. Notice that since the initializer runs after any constructors, the hidden counter field will always be set to zero, even if the caller had tried to set it to some other value when the object was created.

class Counter
{

    { 
      this._internal_counter = 0;
    }

  int _internal_counter = 0;
}

	

A powerful feature of Nice is the ability to define parametric classes. Parametric classes are like templates in C++, or similar constructs in various functional languages. Programming with parametric classes is sometimes called generic programming.

A parametric (or parameterized) class is simply a class which has a parameter. In this case the parameter is a type rather than a value. You can consider a parametric class as a family of related classes, all of which have the same behavior and structure except for the part that is parameterized. A common case where this is useful is in data structures.

class Stack
{
  List contents = new LinkedList();
  void push(Object o) 
  {
    contents.add(o);
  }
  
  //... omitted methods

  public static void main(String[] args)
  {
    Stack st = new Stack();
    st.push("Test");
    Integer num = (Integer)st.pop(); // Runtime error
  }
}

There is a big type safety problem here. We pushed a String on to the stack, and then tried to pop it off into an Integer, resulting in an exception at runtime. Parametric classes can solve this problem.

class Stack<T>
{
  List<T> contents = new LinkedList();
  void push(T t) 
  {
    contents.add(t);
  }
  
  //... omitted methods

}

void main(String[] args)
{
  Stack<String> st = new Stack();
  st.push("Test");
  Integer num = st.pop(); // Compile time error!
}

In the Nice version, we have parameterized Stack by a type T. Essentially, Stack<T> is a recipe for the compiler that tells it how to create a Stack that works for any given type. So now the compiler knows that we only mean for Strings to go into our stack, and it reports an error when we write code that expects an Integer to come out of our Stack<String>.

Nice has single inheritance, like Java or C#, which means that each class can have at most one superclass which it extends. Sometimes, it would be nice to have a class that "extends" two (or more) different classes, taking some of its behavior and data from each. In Nice, as in Java, this can be accomplished via interfaces.

Interfaces are declared just like classes, except that they may not contain data fields, only methods. Unlike in Java, they may also contain default implementations of the methods, making interfaces more convenient and useful than Java interfaces.

To say even this much is still to think of interfaces in Java terms, however. In Nice, an interface doesn't really "contain" anything at all, it's just a marker. Just as java.io.Serializable is just a tag to tell Java that it's okay to use serialization on instances of a class, all Nice interfaces are really tags.

This is because Nice has multi-methods, which are defined by themselves and not contained in a class or interface. It is always possible to define new methods for an interface, just as it is always possible to define new methods for a class. Another consequence of the fact Nice is based on multi-methods is that interface definitions can "contain" not only method signatures, but also default implementations.

Nice does accept a style of interface definition similar to Java's, as in the following example:

interface Component
{

  String getID();

  (int,int) getPosition();

  (int,int) getDimensions();

  int getArea() 
  {
    (int width, int height) = this.getDimensions();
    return width * height;
  }

}
        

However, it's equally possible to define the same interface in this style:

interface Component {}

String getID(Component comp);

(int,int) getPosition(Component comp);

(int,int) getDimensions(Component comp);

int getArea(Component comp) 
{
  (int width, int height) = comp.getDimensions();
  return width * height;
}
        

and in fact, it's fine to mix the two styles, declaring some of the methods inside the interface block, and some outside. One good practice might be to declare those methods which have no default implementation inside the interface block, and those with default implementations outside of it. That way someone reading the code will have a clear idea of which methods must be implemented when implementing an interface. Of course, the compiler will ensure that all necessary methods are implemented, so this is only a suggestion.

Enumerations or simply (enums) are a group of related constants. Many languages support defining simple constants, and of course Nice does also. Many programs are written to use certain numeric constants with special meanings. For instance, one might write a method for a vending machine:

	let int NICKEL = 5;
	let int DIME = 10;
	let int QUARTER = 25;

	class VendingMachine
	{
	  int change = 0;
	}
	
        void addCoin(VendingMachine machine, int cents)
	{
	  machine.change += cents;
	}
      

but this method isn't very safe! It will accept any amount of change, including nonsensical amounts like 3, or 234320. One way to address this problem would be to do runtime checks to ensure that the value is acceptable, and throw an exception if it is not. However, there is an easier solution in Nice: the enum.

	  enum class-name[(parameter-type parameter-name, ...)]
	  { 
	    option,...
	  }
	

Enums can be simple symbols like

      enum Color { Red, Orange, Yellow, Blue, Indigo, Violet }
      

or they can contain integer (or other) values:

        enum VendingCoin(int value) 
	{
	  nickel(5), dime(10), quarter(25);
	}
	
	class VendingMachine
	{
	  int change = 0;
	}
	
        void addCoin(VendingMachine machine, VendingCoin cents)
	{
	  machine.change += cents.value;
	}
      

Of course, a realistic vending machine would have to keep track of the actual number of each coin rather than a total value!

Method declaration takes the following form:

[type-parameters] return-type method-name ([parameters]);

Note that in Nice, methods can be defined within the body of a class definition, or outside of it - both are identical for the compiler's purposes.

It is also possible to define a default implementation at the same time that the method signature is defined. This form looks like:

[type-parameters] return-type method-name ([parameters]) { code-body }

In comparison to their declarations, method implementations can be quite terse:

method-name ([arguments]) { body }

There is also a special form for methods which consist of a single expression:

method-name ([arguments]) = expression;

The [arguments] consist of names, and optionally types, of the form

name

or

class-name name

The class-name is used to specialize the method on that argument. An example should make the difference clear. Also note the use of both the block- and expression-style methods.

class Vehicle {}
class Motorcycle extends Vehicle {}
class Car extends Vehicle {}

//Declare method
int numberOfWheels(Vehicle vehicle);

//Default implementation
numberOfWheels(vehicle) 
{
    throw new Exception("Unknown number of wheels!");
}

//Specialize for Cars
numberOfWheels(Car car)
{ 
    return 4;
}

//Specialize for Motorcycles
numberOfWheels(Motorcycle mc) = 2;

        

It is also possible to specialize a method on the exact class of the argument. Then the method will apply to arguments which match the class exactly, and not to an argument which is a subclass of the class specified. The syntax for exact matching is:

#class-name name

Specializing on the exact class of an argument is useful in situations where an implementation is correct for a certain class, but you know that each subclass will require a different implementation.

There is also an example where exact matching is required to type-check a method with a precise polymorphic type.

When specializing a method with type parameters, it is not necessary or possible to restate the type parameters in the method implementation. However, if you need access to the type parameters as in the example below, use the syntax:

<type-parameters> method-name ([arguments]) { body }

//Method definition
<T> T lastItem(Collection<T> coll);


/* This version is incorrect because the type parameter T is not in scope:

lastItem(coll)
{
  Iterator<T> it = coll.iterator();
  //...
}
*/

// This one will work correctly:
<T> lastItem(coll)
{
  Iterator<T> = coll.iterator();
  //...
}

Note that it is not possible to dispatch a method call on an array type, nor to specialize a method on the subtype of a type parameter. This means that method implementations of the form:

foo(Collection<String> string){}

or

foo(String[] array){}

are not valid. You should use respectively the specializers Collection and Array instead.

In addition to choosing a method based on the classes of the arguments, it's even possible to override a method based on the actual values of the arguments. Currently this feature works with integers, booleans, strings, characters, enums, and class instances which are used as package level constants. It is also possible to override a method for the special case of null.

This feature makes it convenient to code things that might otherwise have required switch statements or nested if/else statements. Using value dispatch can be more flexible than switch or if/else statements, because you can always add new alternatives conveniently by just adding a new method implementation.

String digitToString(int digit, String language)
  requires 0 <= digit < 10;

digitToString(digit, language)
{
  throw new Exception("Couldn't convert "digit" to language "language);
}

digitToString(1, "english") = "one";
digitToString(2, "english") = "two";
digitToString(3, "english") = "three";

digitToString(1, "french") = "un";
digitToString(2, "french") = "deux";
digitToString(3, "french") = "trois";

String booleanToYesNo(boolean bool);

booleanToYesNo(true) = "yes";
booleanToYesNo(false) = "no";

enum Grade {
  A, B, C, D, F
}

Grade charToGrade(char input);

charToGrade('a') = A;
charToGrade('b') = B;
charToGrade('c') = C;
charToGrade('d') = D;
charToGrade('f') = F;
charToGrade(input) {
  throw new IllegalArgumentException("Not a grade letter: " + input);
}

char gradeToChar(Grade grade);
gradeToChar(A) = 'a';
gradeToChar(B) = 'b';
gradeToChar(C) = 'c';
gradeToChar(D) = 'd';
gradeToChar(F) = 'f';

class Person
{
}

let Person BOB = new Person();

void greet(Person p)
{
  println("Hello, anonymous person!");
}

greet(BOB)
{
  println("Hi Bob!");
}

<T> int containsHowMany(?List<T> list);

<T> containsHowMany(List list) = list.size();
containsHowMany(null) = 0;

When calling a method it is possible to specify the name of a parameter, followed by : before the value given to that parameter. Named parameters can be given in any order. This is useful when writing the call, because one does not need to remember the order of the arguments, but only their names. This makes the code much easier to understand what each parameter represents, provided that parameter names are chosen carefully.

void copy(File from, File to) { ... }
...
copy(from: f1, to: f2);
copy(to: f3, from: f4);

It is of course still possible to omit the names of the parameters, in which case the arguments must be given in the order of the declaration.

Many methods have some parameters that are used most of the time with the same value. In Nice, a parameter can be given a default value. That argument can then be omitted when calling the method, and the default value will be used.

void copy(File from, File to, int bufferSize = 1000) { ... }
...
copy(from: f1, to: f2); // with a buffer size of 1000
copy(from: f1, to: f2, bufferSize: 4000);

In the method definition, the optional parameters should be listed after the required parameters. This is needed to allow calls that do not name the arguments and want to use the default values for the optional parameters.

Note that the optional values of parameters can be based on other parameters, for example:

T[] slice(T[] array, int from = 0, int to = array.length - 1);

Method implementations must still bind all parameters, including the optional ones, and can dispatch on them.

The syntax for assertions is the same as in Java (since 1.4). Assertions are statements of the following form: assert <boolean expression> : <error message>. The <error message> is optional.

Preconditions are introduced with the requires keyword, and postconditions with the ensures keyword. If there are several conditions in either section, they must be separated by commas. For convenience, an optional trailing comma is accepted.

In a method returning a value, the special variable name result can be used to refer to the result value of the method in the postcondition. The old to refer to values before the execution of the method is not supported yet.

For example, we can define the contract of the add method of a Buffer interface. It is guaranteed that isEmpty returns true if, and only if, size returns 0. The add method can be called only when the buffer is not full. It is guaranteed to make the buffer non-empty, and to increase the size by one.

interface Buffer<Elem>
{
  int size();

  boolean isFull();
  boolean isEmpty() ensures result == (size() == 0);

  void add(Elem element)
    requires
         !isfull() : "buffer must not be not full"  // A comma here is optional
    ensures
         !isEmpty() : "buffer must not be empty",   // Note the comma
         size() == old(size()) + 1 : "count inc";
}

By default, assertions and contracts are not used at runtime. They are discarded by the just-in-time compiler, and should cause no slow-down. They can be turned on when starting the JVM.

Local variables may be defined with the var keyword. Here is the syntax:

var [type] variable-name [= initial-value] ;

For local variables (not package variables), the Nice also accepts the Java style of declaration:

type variable-name [= initial-value] ;

Constants are declared with "let":

let [type] variable-name [= initial-value] ;

If the variable or constant is of a simple type (i.e., not a parameterized type), then it is not necessary to specify the type yourself, the compiler can infer the correct type automatically.

Since Nice uses packages as its largest conceptual unit, variable and constant declarations may appear outside class definitions, and are useful in the same way that static variables in Java are. Package variables are introduced with var, and package constants with let. The type must be specified, since it is a useful documentation.

Nice supports the traditional for loop, with the same syntax as in Java. In addition, it provides a form that allows iterating over the items in a sequence like C#'s foreach. Here is the syntax:

for ( item-type variable-name : container ) { body }

Currently, this version of the for statement can be used to iterate over Collections, arrays, Ranges, Strings, and StringBuffers.

let String[] strings = ["one", "two", "three"];
for(String s : strings)
{
  println(s);
}

Since Nice also has syntax for generating ranges of numbers, another convenient way to use the for statement is as follows:

//Print numbers from 1 to 10, inclusive
for(int i : 1..10)
{
  println(i);
}

Local methods are similar to regular methods (defined at the package or class level), except that they are defined inside another method, and therefore only usable in that scope. They can refer to local variables from their context. Like anonymous methods, local methods cannot be overridden.

Window createMyWindow()
{
  Window w = new Window();
  
  void addMyButton(String text)
  {
    w.addButton(new Button(text));
  }

  addMyButton("One");
  addMyButton("Two");
  addMyButton("Three");
}

A call is usually of the form f(e1, ..., en). f can be a method name, or more generally any expression which has a method type (for instance, a local parameter). e1, ..., en is the list of arguments to the method. Arguments can optionally be named.

In many object-oriented languages, methods are called with the syntax e1.f(e2, ..., en). This syntax is also accepted in Nice, and is completely equivalent to the previous one. In particular, e.f can be used to retrieve the value of the field f in the object e ^[2].

It is possible that a name refers to several unrelated methods. In that case, the types (and if applicable names) of the arguments are used to try to disambiguate which method must be called. If only one method is applicable, it is called. Moreover, if several methods are applicable, but one has a more restricted domain than all the others, it is chosen ^[3]. Otherwise, the compiler reports an ambiguity error.

	    method-name(argument, ...)
	    {
	      argument-body
	    }
          

	  //First define the method we're going to call:
	  //Like an 'if' statement
	  void when(boolean condition, void->void action)
	  {
	    if (condition)
	      action();
	  }	    

	  //Now exercise our method with block syntax:
	  void main(String[] args) 
	  {
	    when(1 > 0) 
	    {
	      println("Math is working correctly!");
	    }
	  }
	  

	    when(1 > 0, () => { 
	      println("Math is working correctly!");
	    });
	  

A tuple is a grouping of several values in a single expression. For instance, ("Hello", 2*3, x.toString()) is a tuple whose elements are the string "Hello", the number 6 and the string representation of x. The type of a tuple is a tuple type, whose elements are the types of the corresponding values. The type of our example tuple is (String, int, String).

A tuple can be of any length. In english, a tuple of two elements is called a couple. For an arbitrary number n, a tuple of n elements is called a n-tuple.

Tuple types are covariant, so a couple of ints can be used where a couple of longs is expected.

A funny feature is that swapping two variables can be done without a temporary variable, using tuples: (x, y) = (y, x). An important use of tuples is to allow a method to return several values. Example 7.2, “Method returning several values using a tuple” defines and uses the method minMax, which takes two integers, and returns the smallest first, the biggest second.

(int, int) minMax(int x, int y) = x < y ? (x, y) : (y, x);

void printTuple((int x, int y))
{
  println("(" + x + ", " + y + ")");
}

void main(String[] args)
{
  printTuple(minMax(14, 17));
  printTuple(minMax(42, 41));
}

An array can be created by simply enclosing the elements of the new array in brackets.

class-name[] variable-name = [ element1, element2, ...]

It is also possible to create an array which is filled with nulls, or some single value, or a value which is calculated on a cell-by-cell basis, by using the fill method in the standard library.

      //Fill every cell with the value 5000.
      int[] points = new int[10];
      fill(points, 5000);
      

     
      //build a little table of squares 
      int[] squares = fill(new int[10], int i => i * i);
      

Literal strings are surrounded with double quotes, for instance:

String s = "Hello";

The backslash character \ is used for escaping, as in Java.

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

        String name = "Nice";
        int factor = 10;
        println("My favorite language is " name ", which is " factor 
                   " times better than what they make me use at work.");
        
          

Since Nice allows methods to be passed as arguments, and returned as results, it is convenient to allow small anonymous methods to be defined at the same point in the program in which they are used, similar to the use of anonymous classes in Java. Anonymous methods cannot be overridden, and have exactly one implementation.

The syntax of anonymous methods is:

([parameters]) => { body }

As with named methods, there is also a single-expression format:

([parameters]) => expression

The parentheses around the parameters are optional if there is only one parameter.

The return type of an anonymous method is automatically determined by the compiler using a process called type inference, so it is not necessary or possible to specify it.

String concat(Collection<String> strings) 
{
    StringBuffer buff = new StringBuffer();
    strings.foreach(String s =>  {
        buff.append(s);
    });
    return buff.toString()
}

var String[] numberStrings = [1,2,3,4,5].map(int num => String.valueOf(num));

//Another way of defining "concat"
String concat2(Collection<String> strings)
{
  return strings.foldLeft((String accum, String s) => accum + s, "");
}

Nice supports a wide range of operators which will be familiar to most programmers. The table below lists the operators, ordered from highest precedence to lowest precedence.

The numeric primitive types are, from the largest to the smallest: double, float, long, int, short, byte. Conversion from a smaller to a larger type is automatic. Conversion from a larger to a smaller type must be done explicitly, since they can lose information about the magnitude of the value.

The explicit conversion is done by calling a special method, whose name is the target type. If e is a numeric expression, and type one of the numeric types, then type(e) will convert the value of the expression, so that it is represented as a value in type. This is equivalent to the (type) e syntax in Java.

In most cases, characters should be treated as abstract entities and not as the numbers that happen to encode them. Therefore, the char type is not a numeric type in Nice. Operations on characters can be performed using the methods of class java.lang.Character. Additionally, it is possible to convert a character c to its integer value with int(c), and to convert an integer to the character it encodes with char(i).

For instance, here is code to read characters from a Reader, whose read method returns an int (-1 meaning that the end of stream has been reached):

let reader = new BufferedReader(new InputStreamReader(System.in));

int v;
while ((v = reader.read()) != -1) {
  char c = char(v);
  ... // Do something with the character.
}

The Java libraries are automatically imported as necessary. Therefore it is straightforward to use existing Java code in Nice programs. In particular, it is possible to call Java methods, to instantiate Java classes, to create a Nice subclass of a Java class, overriding methods from the parent, ...

This section lists advanced features related to the use of Java code in Nice.

// Java code
public class MyJavaClass {
  public String getName() {
    return "foo";
  }
}	

String getName(MyJavaClass) = native String MyJavaClass.getName();

It is possible to use libraries developed in Nice in a Java program. Before anything, make sure that the classes generated by nicec can be found on your classpath when you compile the Java program with javac.

package my.nice.pkg;

class Person
{
  String name;

  // A method:
  String display() = "Person: " + name;
}

class Worker extends Person
{
  int salary;

  display() = "Worker: " + name + " salary: " + salary;

  boolean isRich() = salary > 500;
}

	

package main.java.pkg;

import my.nice.pkg.*;

public class Main
{
  public static void main(String[] args)
  {
    Person p = new Person("John");
    Worker w = new Worker("Julia", 1000);

    System.out.println(p.display());
    System.out.println(w.display());
    if (w.isRich())
      System.out.println("A well paid worker!");
  }
}
        

Nice (unlike Java) makes a distinction between a type that may be null, and one that may not be. So, if you want to allow null Strings, you write ?String for the type. If nulls should not be allowed, you just write String. It is not possible to pass a ?String where a String is expected, unless the compiler can prove it's not null. The easiest way to prove that the variable is not null is to use an if statement:

	void foo(String arg) {...}
	
	void bar(?String arg) {
		if (arg != null) {
			//Here Nice knows arg is not null, so it can 
			// be passed to a method which takes a String.
			foo(arg);
		} 
		foo(arg); //Here arg may or may not be null, 
			  //so Nice gives a compilation error.
	}

Therefore, you never have to check that all your arguments aren't null again, unless you actually want to allow nulls.

It's important to remember that nullness inference doesn't work on fields of objects, only on local variables. There's a good reason for this: the value of an instance variable may have changed (updated by another thread, perhaps) between the time the value was checked for nullness and the time it is actually used. To avoid this problem, simply take a local reference to the field first:

  class Person 
  {
    ?String name
  }

  //Takes a String, not a ?String
  void printName(String name)
  {
    println(name);
  } 

  void main(String[] args) 
  {
    Person p = loadPersonFromFile(args[0]);
    let name = p.name;
    if (name == null)
      throw new Exception("Unknown person!");
    else
      //safe to call printName, we know name is a String.
      printName(name);
  }

Sometimes, you know that a value cannot be null, although it has an option type. You can then use the notNull method to assert this fact. If an expression e has type ?type, then notNull(e) has type !type. Note that if type is not a type variable, !type is the same as type.

The notNull method uses assert to check that the argument is not null. This means that the check will only happen at runtime if assertion checks are enabled. Otherwise, execution will continue, but the JVM will probably fail soon afterwards with a NullPointerException if the value is null, and it is used as if it was not null.

There are (rare) situations where it is necessary to allow a null where one shouldn't normally go, for instance if you need to declare a variable before entering a loop, but don't have a value to initialize it with. You should first try to think about an alternative way of writing the code so that this is not needed. However, if there is none, a solution is to use cast(null). This expression will be accepted in any context. It is then your responsibility to make sure that this value is not used.

Note that notNull and cast(null) have completely different uses. notNull is used to tell the compiler that you know a certain value is not null, although the type system does not guarantee it. On the other hand, cast(null) is used to provide a non-null value which is never going to be used. You could not use notNull(null) for that purpose, because this would fail at runtime if assertion checks are enabled.

Additional information is available on the Wiki page about option types.

There is related type, which is prefixed with an exclamation point (!). This is used to specify a non-null type when it is not known if the original type allowed null or not. This is only needed for type parameters; for all other types, !type is equivalent to type.

For instance, in the following method:

<T> T myMethod(Collection<T>);

the type parameter T can be instantiated at any type, including option types like ?String. If it is necessary to exclude option types from the domain of T, the type can be specified this way:

<!T> !T myMethod(Collection<!T>);

Class casting is not used in Nice. Similar to Option types and nullness, if the compiler can prove that the type of an object is compatible with the target context, it will allow that object to be used. This can be done using the instanceof operator and an if statement:

	void foo(FileOutputStream arg) {...}
	
	void bar(OutputStream arg) {
		if (arg instanceof FileOutputStream) {
			//Here Nice knows arg is a FileOutputStream, so it can 
			// be passed to a method which takes a FileOutputStream.
			foo(arg);
		} 
		foo(arg); //Here arg may or may not be a FileOutputStream, 
			  //so Nice gives a compilation error.
	}

As with Option types, type inference doesn't work on fields of objects or on method calls, only on local variables. There's a good reason for this: the value of an instance variable may have changed (updated by another thread, perhaps) between the time the value was checked for its type and the time it is actually used. Similarly, method calls can return objects of different sub-types every time they are called. To avoid this problem, simply assign the value to a local variable first.

Classes and methods can be parameterized with type variables in Nice as is demonstrated in each of their respective chapters. In addition to the ability to introduce type variables, Nice provides the ability to constrain those types in certain ways. Option types are one such constraint.

Simple type parameters of the form

<type-variable [, type-variable ... ]>

are commonly encountered in Nice, but are a simplified form of a more general syntax. <T> is actually shorthand for <Any T>, which says that T may be any type at all. It is possible to constrain T so that it must be a subtype of some other type. This example shows that filter may be implemented for any type T, but C must be a subclass of Collection.

<Collection C, T> C<T> filter(C<T>, T->boolean);

It's also possible to enforce some relation among the type parameters, such that one must be a subtype of the other, as in this example from the standard library, which can be read as "Any T and U, so long as U is a subtype of T".

<T, U | U <: T> U[] fill(T[] array, int->U value)

Note the notation <T | T <: SomeType > means the same thing as <SomeType T>.

There is also a notation for the same class as the declaring class of a method: alike. For instance, the following class Foo declares a method copy, such that x.copy() has the same type as x, x being of any subclass of Foo.

class Foo
{
  String value;

  alike copy();
}

copy(#Foo f) = new Foo(value: f.value);

class Bar extends Foo
{
  int id;
}

copy(#Bar b) = new Bar(value: b.value, id: generateNewId());

Note that exact matching is required to implement the copy method.

Nice offers a powerful tool known as the abstract interface. Abstract interfaces are similar in some respects to regular Java- or Nice-style interfaces in that they define a set of methods that a type must implement to be considered a member of the interface.

Two things make an abstract interface different from a regular interface. First, a class can be made to implement an abstract interface after it's been defined, and even the source code is unnecessary. You can make the basic String class implement your new abstract interface, if you like. Second, an abstract interface is not actually a type, it's an annotation which can be applied to types. This means that when you declare an abstract interface, you're not creating a new type, you're saying "types which implement this abstract interface will all have these methods", but those types are not related in any other way. So it is not possible to make a List<MyAbstractInterface>, or to use an abstract interface as a type declaration like var MyAbstractInterface absInter = ... .

So what is an abstract interface for? Abstract interfaces can appear in type parameters, so one can write methods for them:

<MyAbstractInterface T> void doSomething(T thing);

and then apply these methods to any object whose class implements MyAbstractInterface. It's especially useful for situations where one wants to use a method on a group of unrelated types, as in the example below. We have a log() method which is parameterized for any class which implements the abstract interface LogEntry, and we make a number of classes implement LogEntry, so they can be passed to our log method.

//Abstract interface for things which can be logged.
abstract interface LogEntry
{
  String toLogString();
  int severity();
}

//Some constants for severity levels
let int DEBUG = 1;
let int INFO = 2;
let int ERROR = 3;

<LogEntry E> void log(E entry, int severity = -1) 
{
  if (severity < 0)
    severity = entry.severity();
  someLogWriter.println(timeStamp() + " " + severity + " " + entry.toLogString());
}

//Make strings pass straight through as DEBUG info.
class java.lang.String implements LogEntry;

toLogString(String s) = s;
severity(String s) = DEBUG;


//Make throwables print a stack trace, plus a message
class nice.lang.Throwable implements LogEntry;

toLogString(Throwable t) 
{
  let writer = new StringWriter();
  let printWriter = new PrintWriter(writer);
  printWriter.println("ERROR: " + t.getClass().getName() + ": " + t.getMessage());
  t.printStackTrace(printWriter);
  printWriter.close();
  return writer.toString();
}

severity(Throwable t) = ERROR;

//We like to log requests, too
class javax.servlet.http.HttpServletRequest implements LogEntry;

toLogString(HttpServletRequest r) = "Request from: " + r.getRemoteHost();
severity(HttpServletRequest r) = INFO;

There are some interesting things to notice about this code. First, we only had to write log() once, and we left it up to the LogEntry to do the formatting. This could be done with a regular interface as well, except that we also made String and Throwable implement our abstract interface, which we couldn't have done with a regular interface. So now we can write code like

            log(request);
            log("Beginning processing");
            try 
              {
                1/0;
              } 
            catch (Exception e)
              {
                log(e);
              }
          

and our abstract interface implementations will take care of making sure that we get the right formatting and severity levels. The most interesting thing about this code is that if we write log(5) then the compiler will catch the error, because byte doesn't implement LogEntry. If we had defined log with the signature <E> void log(E entry, int severity = -1), we could have achieved all the same effects, but we would have lost the type safety abstract interfaces gave us above - because <E> means any type is allowed, so we would have had to define some defaults:

            toLogString(e)
            {
              throw new Exception("No toLogString method defined!");
            }

            severity(e)
            {
              throw new Exception("No severity method defined!");
            }
          

Then we'd be no better off than in a dynamically typed language - we wouldn't find out that we'd tried to log an integer until we got an exception at runtime. With abstract interfaces, we were able to tell the compiler exactly which classes should be allowed as arguments to log, and so our program is safer as a result.

Daniel Bonniot, Nice's creator, invented abstract interfaces. You can read more about them in the Academic Research section of the Nice website.