Nice TWiki > Doc > NiceQuestions (r1.24) 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 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 ( != NULL) {

   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:

-- 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 化工泵 净化设备 稳压电源 初级会计师 留学签证 珠海生活 波峰焊 晶振 移动PC 视频点播 聊天室 消毒 越野车 电容器 电磁阀 类风湿 留学专家 首饰 晶体 内存 东莞生活 拓展训练 股票证券 留学中介 广告 电教 液晶屏 超声波 桌面 黑客帝国 挤出机 汽车租赁 消毒液 博天堂 投影仪 黄历 液晶显示器 温控器 动画 屏幕保护 白癜风 垫片 证券 电热膜 主机 户外 扑克 防火墙 肝硬化 注册税务师 广东生活 逆变电源 北京现代汽车 枫叶卡 资源库 风湿 脉管炎 汇款 电脑报价 西联 工作站 监控 广州生活 空间租用 信息化 螺丝 套管 外语 强直性脊柱炎 邮件系统 办公楼 胶粘剂 压力变送器 电线 铃声 皮具 星座 扣件 印花 工商注册 温度计 实验台 歌曲下载 文化 工业控制 雨伞 管理咨询公司 证卡打印机 液压件 注册 助剂 豆粕 胰岛素泵 电子元件 链条 流水线 防爆电机 水处理公司 水产品 紧固件 铸件 保健品 粉末涂料 文件柜 工装 隔离器 中药 手推车 光通信 喷涂设备 铸造 绿茶 宽带接入 计算机学校 工控 激光测距仪 清洗机 尖锐湿疣 网络布线 手电筒 读卡器 网络维护 数码管 栈板 蜂胶 打码机 思科 托盘 免费下载 野营用品 护肤 絮凝剂 色织布 护肤品 儿童玩具 人才招聘 旅游用品 减速电机 金属材料 不锈钢制品 癫痫 电视 电视剧 电工工具 电动摩托车 客车 抛光 黄页 磨床 洗地机 木门 圆珠笔 铜门 调节阀 搜索引擎 环境实验设备 塑料管材 呼吸机 节能 电解电容 网页 医疗 司法考试 结婚 防腐涂料 玻璃仪器 书店 光盘制作 医药 音乐网站 臭氧 网球 铁柜 医院管理 洗衣 致富信息 冠心病 保姆 报关 法语 散热片 毛巾 形象设计

Topic NiceQuestions . { Edit | Attach | Ref-By | Printable | Diffs | r1.25 | > | r1.24 | > | r1.23 | More }
Revision r1.24 - 27 Jan 2005 - 06:22 GMT - LiYan
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.