TWiki > Doc > NiceQuestions	TWiki webs: Dev | Doc | Main | TWiki | Sandbox
	Doc . { Changes | Index | Search | Go }

• Nice doesn't allow for constructors (sometimes this is handy as the use of your class can't always decide how certain properties should be set (even worse, a user of your class may not know all the private attributes...)
• The removal of NullPointerException? to some it may be a hassle but it can be quite informative at times..
• The way of defining objects with the question mark ?String vs String

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:

• Multimethods (thought the syntax is awkward w.r.t. Java)
• Optional parameters and parameter naming (well having a bit of a Ruby background :P)

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

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>)
Possibilities:
T test.Node.value
nice.lang.int[?] 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;

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 it implicit in the JVM (Java standard library?) handling of threads that shared state is the default? I'd prefer shared state to be (highly) optional with some syntax for marking classes (fields?) as shared. Then the compiler could do nullness checks on fields where it's known no other thread can alter the contents. -- RohanHart - 02 Nov 2004

I don't think that the JVM is much different from other implementations in this regard. Though the JVM is free to make a copy of a member variable when accessing it, the JVM may also choose to access the variable directly as well. "non-shared" annotations would be a real pain in the ass (much more so than C++'s const).

However, the idea of guaranteeing "repeatable read" semantics for global data is interesting. I don't think it'll be too hard to implement, since the Nice compiler is probably already performing the required data-flow analysis. One problem is that repeatable read semantics can't be carried across virtual method invocations, so I wonder how useful it'll be in practice...

-- KannanGoundan - 23 Nov 2004

It appears that wrapping any non-shared field into a java.lang.InheritableThreadLocal (and to a reference's fields and so on recursively... the term "invasive" comes to mind) would (mostly) do the trick. Uh oh, it may also require shared references to provide deep-clone or immutable semantics and given those there's no need for InheritableThreadLocal?. -- RohanHart

To make it more palatable this could be applied by the compiler to any non-shared fields visable at the point a thread is spawned. This still wouldn't work with plain Java code nor dynamically loaded classes.

"non-shared" annotations wouldn't be a pain because that would be the default according to this worldview (though it may confuse Java programmers) and the "shared" annotation would occur exactly zero times in my (currently on-hold, closed source) 5000-lines-of-source project. Since there's also no thread creation I'd see no InheritableThreadLocal? explosion and it would same a good few handfuls of local variables.

Hmmm... maybe this can wait for Nice-3.0

-- RohanHart - 01 Dec 2004

Since using thread local storage isn't exactly the same as using a local variable, I think it might be helpful to work out precisely what "non-shared" means. I think there are some tricky issues involved in virtual method invocation because thead-safety isn't the only issue. There's also the problem of re-entrant code (when multiple methods of the same object are on the stack at the same time). The following code fragment demonstrates the problem of the compiler's lack of visibility into the Prepare() method (because is can be overridden).

class X {

   Target? target;
   Object? argument;

   void Run() {
      if (this.target != NULL) {
         Prepare();
         this.target.Go(argument);
      }
   }

   void Prepare() {
      if (this.argument == null) {
         this.argument = "Test";
      }
   }

}

How does the compiler know that target isn't null when the Go() method is invoked? Because the compiler is clever enough to check Prepare 's contract for invarients (which Nice doesn't seem to provide) or ensures on the value of target ? This is a good point I hadn't considered: part of the reason for fields is to share state between methods so it would be wrong to make the default non-shared here!

All these compounding requirements for a clever compiler because the Java object model doesn't work this way... when the programmer can do this job much better and with knowledge of the particular nuances required by their code... it's a non-feature. -- RohanHart

Of course, it might turn out that people just don't (or shouldn't) write code like that and we don't have to worry about handling such cases.

Also, isn't thread local storage slow (too slow to be the default, at least)? Apparently there's not much overhead in the 1.4+ JVMs -- RohanHart

-- KannanGoundan - 06 Dec 2004

In summary:

• the JVM and Java object model have shared state
• the manner of that sharing, between threads and between methods (or the same method recursively) respectively, is different
• given that context: the programmer is best placed to enforce the semantics their program requires

-- RohanHart - 16 Dec 2004

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);
}

You can do that with the fill function:

Thing[] things = new Thing[10].fill(int i => 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?

It might be possible to keep track of all arrays elements locally but it's probably not worth the complexity.

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.

Performance is not a reason to do null checks at compile time. The problem with null pointers exceptions is that they are often triggered at a different places than where they are caused. Making an exception for arrays reduces the confidence in the compiler detecting missing null checks greatly.

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

No, mutable data structures especially arrays are difficult for all type systems. The best you can do with new arrays is initialize them right away. -- ArjanB - 12 Oct 2004