Nice TWiki > Doc > NiceQuestions (r1.15) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Doc . { Changes | Index | Search | Go }
This section is for questions that people have about Nice, and may serve as the beginnings of an FAQ, if desired. Please don't post bugs here but submit them to the bugtracker. If you have a complex question or have a larger piece of code containing the problem, consider making a topic of your question.
I've had a brief look at Nice (specifically the manual listing the features.) While it seems to have many similar features as Pizza it threw me off on a few things.

It is planned to add something to handle complex object construction. We are still thinking what the best feature is, between Java-style constructors (which have their issues), factory methods-likes, etc... For the moment, you can define a construction function + an initialization method calling super.

I'm not sure what your point is about NullPointerException?. It can be informative in Java, to start searching for the bug that caused it. In Nice, the compiler will make sure that there is no bug in the first place. This can be done because it differenciate between types that include the null value (like ?String), and those that don't (like String). --DanielBonniot

Some things I did like about Nice over Pizza were:

As for Tuples, I'm not quite sure what my feelings towards them are... -- Vincenz

You don't need to use them if you don't like them. But they can be very useful in some cases.

Is there support or plans for LexicalClosures?? How about TypeInference??

Lexical closure (which we call anonymous functions) are already present. You can read about them in the UserManual.

There might be more type inference (in particular for anonymous functions) in the future. It is not worked on at the moment.

Seems Nice has nearly everything that is needed for FunctionalProgramming?, but I didn't find anything mentioned about its support for proper TailRecursion?. Any plans?

-- TWikiGuest - 04 Jul 2003

TailRecursion? isn't implemented yet, but it's planned. Because of the amount of changes to compiler needed for TailRecursion?, it will probably implemented after 1.0 .

-- ArjanB

Any support for multiline strings planned? It's a very annoying lack in java. -- MartinDeMello - 29 Sep 2003

It is implemented as of Nice 0.9.5. See the UserManual for examples. -- BrynKeller - 02 Feb 2004

First off, syntatical support for option types is excellent. It's the coolest language feature I've seen in a long time. Until I read about Nice, I didn't realize that how silly it was to allow any reference to be null.

The problem is that Nice doesn't seem to allow multiple levels of this. Here's my example program. It's kind of long, but I hope it shows what I'm getting at:

class Lookup<T> {
  ?T lookup(int i, T item)
    if (i % 2 == 0) {
      return item;
    } else {
      return null;

void main(String[] args)
  String always = "Always";

  Lookup<String> lookupAlways = new Lookup();
  lookupAlways.lookup(1, always);
  lookupAlways.lookup(2, always);

  ?String maybe = null;
  if (args.length % 2 == 0) {
    maybe = "Yes";

  Lookup<?String> lookupMaybe = new Lookup();
  ??String maybeResult;
  maybeResult = lookupMaybe.lookup(1, maybe);
  maybeResult = lookupMaybe.lookup(2, maybe);

I get two compilation errors. One near the top at return item. It says that it's expecting type ?T and it found type T. I can use cast(item) to get rid of that, but shouldn't this be automatic (since it's kind of like weakening the type constraints)?

The compiler didn't handle ? on typeparameters well in all cases but this problem has been fixed in version 0.9.8. Please update.

The second compilation error I get is near the bottom at ??String maybeResult. It was a parse error and not a type-checking error, so I wasn't too surprised by this. I'm assuming that multiple-level option types aren't allowed (will they be allowed later?). When I changed it to a single question mark, the compiler flagged an error (which, I believe, is the correct thing to do). However, the error was strange:

Found   : ?java.lang.String
Expected: ?java.lang.String

This strange error message is caused by the same problem as above.

So, are you guys tring to coalesce multiple levels of options into a single one? This seems like a viable option, but you do lose the power to include null as a "real" value (which would allow the insertion of null values into a hashtable).

On the other hand, it would be nice if we could get the same semantics as the Maybe type in Haskell (or the option type in ML). Multi-level option typing will not just end at the type checker, so (I think) "higher order option types" will require a wrapper class (to keep track of how many levels of Haskell-style Just things there are before we hit a Nothing). I think the extra object overhead would be worth it though, since you only take the hit when you use 2+ levels of option types.

-- KannanGoundan - 14 Aug 2004

I agree that multi-level option types can be usefull but that would require wrapper classes to represent options. One of Nice's design goals is easy interaction with Java code. Java doesn't have the concept of multi-level option types so adding that to Nice will either require conversion functions around every call to Java methods or all Java libraries would need a Nice variant. -- ArjanB - 15 Aug 2004

Hi, I'm a beginner at Nice. I had trouble with the first programming example that I tried:

class Ref<T> {
  public ?T content = null;

interface Comparable {}

class Node<Comparable T> {
  public Ref<Node<T>> left = new Ref();
  public Ref<Node<T>> right = new Ref();
  public T            value;

<Comparable T> Node<T> create_node(T value) {
  return new Node(value: value);

<Comparable T> int local_compare(T x, T y);

<Comparable T> void insert(T x, Ref<Node<T>> node) {
  if ( node.content != null ) {
    T v = node.content.value;

This produces the error:

No possible call for value.
Arguments: (?test.Node<T>)
T test.Node.value[?] value(java.math.MutableBigInteger ...

I don't understand what is wrong here. The objective of the program is to define a tree which can store any type for which "compare: 'a -> 'a -> int" has been defined. I'm a refugee from Ocaml where there are no hooks into the compare function and am looking to Nice and it's multimethods to help.

-- RichardCole - 31st Aug 2004

The problem here is that Nice doesn't take nullness tests on fields in account yet. So you need to use either

T v = notNull(node.content).value;
let content = node.content;
if (content != null)
  T v = content.value;
Btw most people on the #nice channel live in european timezone. ArjanB - 31 Aug 2004

To add to what Arjan said, Nice can't "take nullness tests on fields in account" because it would cause problems with with multithreaded code--the two accesses to the variable create a race condition. -- BrianSmith

Is there a "proper" way to handle option types and arrays? The most straightforward option is to initialize the entire array with pointers to some default object. Another option is to require an array to be initialized explicitly upon creation:

Thing[] things = new Thing[](&myFunc);
Thing myFunc(index i) {
   return new Thing(i);

Is there a way to make arrays keep track of the number of cells that have been assigned? For example:

let array = new String[10]; // type is String[0/100]
array[0] = "abcd";          // type morphs to String[1/100]
print(array[0]); // <-- OK
print(array[1]); // <-- type error

Or are arrays just plain enemies of a strong type system? Are there other data types that have better static typing properties but can still be compiled down to array-style assembly code?

You don't really lose complete type safety with arrays because Java does all the null checks anyway. There probably isn't even an implementation overhead because the paging hardware will detect null pointer exceptions transparently. But I'm still curious to know if there is a clean way to handle arrays with Nice's full type system.

-- KannanGoundan - 11 Oct 2004

Topic NiceQuestions . { Edit | Attach | Ref-By | Printable | Diffs | r1.25 | > | r1.24 | > | r1.23 | More }
Revision r1.15 - 11 Oct 2004 - 21:17 GMT - KannanGoundan
Parents: WebHome
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.