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

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

生物反应器 展示架 审计 税务 不锈钢 打印机 钢结构 计算机 加盟 建筑材料 旅行社 企业管理 人力资源 网页设计 市场营销 室内设计 手机 饲料 涂料 卫星电视 物流 远程教育 展览 包装机械 包装设计 玻璃钢 瓷砖 地板 电池 电动工具 电话 电缆 电器 电线电缆 电源 雕塑 耳机 二手电脑 二手房 发电机 防盗门 纺织 机票 复印机 钢铁 工程机械 广告设计 继电器 家电 建筑设计 交换机 洁具 开关 乐器 木地板 皮革 啤酒 润滑油 摄像机 摄像头 数码摄像机 塑料机械 体育用品 网络电话 望远镜 文具 五金工具 显示器 相机 香水 蓄电池 仪表 中央空调 珠宝 平面设计 传感器 摩托车 玻璃 电机 工艺品 化工 化妆品 机械 空调 时装 食品 塑料 陶瓷 玩具 五金 印刷 轴承 钢材 汽车配件 橡胶 变压器 订房 订票 水处理 显示屏 礼品 旅游 汽车 服装 电影 数码相机 稳压器 招聘 触摸屏 机柜 酒店预定 模具 在线电影 笔记本 虚拟主机 管理咨询 域名注册 成人电影 肾病 免费电影 肿瘤 显微镜 婚介 股票 交换机 糖尿病 企业邮箱 乙肝 对讲机 化妆品 股骨头坏死 电子商务 网站推广 美女 UPS 液晶 尿毒症 条码打印机 电脑 家具 投影幕 服饰 网站空间 轮胎 网上购物 化学试剂 媒体 手套 二手笔记本 发动机 免费下载电影 水泥 塑料制品 机床 免费音乐下载 随身听 防水材料 纺织机械 耐火材料 肺结核 肺炎 风机 家居装饰 脱发 钢板 汽车美容 网络电话 监理 减速机 钢板网 钢管 网络设备 洗衣机 显卡 刀具 电视机 锅炉 二手车 滑板 眼镜 办公用品 防盗门 仪器 保温材料 继电器 变频器 办公家具 货运 高尔夫 叉车 插件 超声 泳装 箱包 小提琴 冲压 除湿机 油漆 小尾寒羊 元器件 磁性材料 刺绣 运动鞋 型材 打火机 打折机票 灯泡 电子产品 电子技术 垫仓板 吊钩 吊网 合成纤维吊装带 烘干机 胶带 结核 咖啡 空压机 冷却塔 热水器 日用品 乳品机械 石材 食品机械 收音机 手表 化工原料 多电脑切换器 茶叶 医疗设备 微型打印机 饮水机 污水处理 印刷机 冰箱 财务软件 彩钢板 音响 仓储 木制品 遥控器 摄影器材 数码产品 床上用品 面料 拉链 机箱 包装材料 涂装 水表 管理培训 门窗 破碎机 自动门 自吸泵 硬盘 绿色食品 燃气设备 容器 软管 木业 膜结构 石墨 条形码 帐篷 女装 食用菌 指纹 真空泵 喷雾干燥 喷雾干燥机 聚丙烯 聚乙烯 制药机械 汽车空调 水泵 水产 器材 汽车音响 胸罩 休闲服饰 丝网 虚拟仪器 照相机 挖掘机 袜子 白酒 半导体 单片机 钢琴 玻璃制品 装潢设计 投影机维修 混凝土 气动元件 饮料机械 聚醚 液压元件 铝合金 除尘器 珠宝首饰 焊锡 模板 消防 标准件 线切割 示波器 公司注册 防静电地板 金属 橱柜 塑料模具 树脂 雕刻 厨具 分析仪器 无线网 蝶阀 空调配件 红木 超声波清洗机 焊接设备 保护膜 电子白板 液压机械 制氧机 厨房设备 电镀 集成电路 产品设计 汽车零部件 针织 冶金 数字监控 数控机床 清洁设备 空气净化 起重机 发电机组 视频电话 视频监控 电视会议 防腐 壁球 胶粘带 售饭机 热交换器 柴油发电机组 会展 热敏电阻 电容 灯光 地毯 制冷设备 铜管 自行车 无纺布 丝绸 防雷 雕刻机 可视电话 人力资源管理 电动机 文胸 柴油机 造纸 有机玻璃 染料 连接器 空气压缩机 管件 电脑维修 电话机 摩托车配件 葡萄酒 五金机械 低压电器 包装设备 过滤器 橡塑 液压机 温湿度 管道 催化剂 电子秤 电加热器 开关柜 建材机械 保险柜 电路板 乳胶漆 工程塑料 特许经营 楼宇自控 喷码机 液位计 聚丙烯酰胺 电磁铁 超市设备 薄膜开关 指纹考勤 渔具 跑步机 防腐设备 锁具 弹簧 纸箱 煤炭 保龄球 家用电器 植绒 钻头 冲压件 建筑机械 实木地板 捏合机 整流器 酒店用品 升降台 转换器 软件下载 喷砂机 制罐 工业炉 生产线 瓷器 搅拌机 印刷机械 综合布线 避雷器 减震器 色织 燃烧器 机电设备 防雷器 地坪 纸品 冷弯型钢 木工机械 物流设备 铁塔 非开挖 热电偶 保险箱 吸塑机 喷漆 过滤材料 电刷 冷水机 采暖 机械加工 照相器材 电镀原料 毛毡 交通设施 消毒机 压滤机 刻字机 接口转换器 电视电话会议 贴纸相机 橡胶机械 喷泉设备 丝印 精细化工 塑胶玩具 五金模具 电子设备 企业形象设计 指纹识别 搬运车 牛仔布 电动车配件 会议系统 终端服务器 录音笔 球磨机 园林设计 路由器 手套箱 实验室设备 童装 手机美容 户外用品 证卡 机床附件 彩电 酒店管理 电话录音 油墨 布线 蜡烛 印刷包装 表面活性剂 节能灯 调味品 齿轮 高压泵 红外热像仪 塑料托盘 吊带 工业锅炉 反光材料 印刷设备 足球推介 热处理 压铸 商标注册 喷灌 逆变器 输送带 锻造 车库门 体育器材 太阳能热水器 绝缘材料 焊管 鼓风机 试验 插座 艺术品 矿山机械 图像监控 无缝钢管 激光切割 标签打印机 燃气表 手机配件 卫星定位 印染 玻璃机械 铝型材 注塑 液压升降机 打标机 工具柜 焚烧炉 电力设备 干燥剂 计量泵 程控交换机

wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh http://www.a688.net

生物反应器 展示架 审计 税务 不锈钢 打印机 钢结构 计算机 加盟 建筑材料 旅行社 企业管理 人力资源 网页设计 市场营销 室内设计 手机 饲料 涂料 卫星电视 物流 远程教育 展览 包装机械 包装设计 玻璃钢 瓷砖 地板 电池 电动工具 电话 电缆 电器 电线电缆 电源 雕塑 耳机 二手电脑 二手房 发电机 防盗门 纺织 机票 复印机 钢铁 工程机械 广告设计 继电器 家电 建筑设计 交换机 洁具 开关 乐器 木地板 皮革 啤酒 润滑油 摄像机 摄像头 数码摄像机 塑料机械 体育用品 网络电话 望远镜 文具 五金工具 显示器 相机 香水 蓄电池 仪表 中央空调 珠宝 平面设计 传感器 摩托车 玻璃 电机 工艺品 化工 化妆品 机械 空调 时装 食品 塑料 陶瓷 玩具 五金 印刷 轴承 钢材 汽车配件 橡胶 变压器 订房 订票 水处理 显示屏 礼品 旅游 汽车 服装 电影 数码相机 稳压器 招聘 触摸屏 机柜 酒店预定 模具 在线电影 笔记本 虚拟主机 管理咨询 域名注册 成人电影 肾病 免费电影 肿瘤 显微镜 婚介 股票 交换机 糖尿病 企业邮箱 乙肝 对讲机 化妆品 股骨头坏死 电子商务 网站推广 美女 UPS 液晶 尿毒症 条码打印机 电脑 家具 投影幕 服饰 网站空间 轮胎 网上购物 化学试剂 媒体 手套 二手笔记本 发动机 免费下载电影 水泥 塑料制品 机床 免费音乐下载 随身听 防水材料 纺织机械 耐火材料 肺结核 肺炎 风机 家居装饰 脱发 钢板 汽车美容 网络电话 监理 减速机 钢板网 钢管 网络设备 洗衣机 显卡 刀具 电视机 锅炉 二手车 滑板 眼镜 办公用品 防盗门 仪器 保温材料 继电器 变频器 办公家具 货运 高尔夫 叉车 插件 超声 泳装 箱包 小提琴 冲压 除湿机 油漆 小尾寒羊 元器件 磁性材料 刺绣 运动鞋 型材 打火机 打折机票 灯泡 电子产品 电子技术 垫仓板 吊钩 吊网 合成纤维吊装带 烘干机 胶带 结核 咖啡 空压机 冷却塔 热水器 日用品 乳品机械 石材 食品机械 收音机 手表 化工原料 多电脑切换器 茶叶 医疗设备 微型打印机 饮水机 污水处理 印刷机 冰箱 财务软件 彩钢板 音响 仓储 木制品 遥控器 摄影器材 数码产品 床上用品 面料 拉链 机箱 包装材料 涂装 水表 管理培训 门窗 破碎机 自动门 自吸泵 硬盘 绿色食品 燃气设备 容器 软管 木业 膜结构 石墨 条形码 帐篷 女装 食用菌 指纹 真空泵 喷雾干燥 喷雾干燥机 聚丙烯 聚乙烯 制药机械 汽车空调 水泵 水产 器材 汽车音响 胸罩 休闲服饰 丝网 虚拟仪器 照相机 挖掘机 袜子 白酒 半导体 单片机 钢琴 玻璃制品 装潢设计 投影机维修 混凝土 气动元件 饮料机械 聚醚 液压元件 铝合金 除尘器 珠宝首饰 焊锡 模板 消防 标准件 线切割 示波器 公司注册 防静电地板 金属 橱柜 塑料模具 树脂 雕刻 厨具 分析仪器 无线网 蝶阀 空调配件 红木 超声波清洗机 焊接设备 保护膜 电子白板 液压机械 制氧机 厨房设备 电镀 集成电路 产品设计 汽车零部件 针织 冶金 数字监控 数控机床 清洁设备 空气净化 起重机 发电机组 视频电话 视频监控 电视会议 防腐 壁球 胶粘带 售饭机 热交换器 柴油发电机组 会展 热敏电阻 电容 灯光 地毯 制冷设备 铜管 自行车 无纺布 丝绸 防雷 雕刻机 可视电话 人力资源管理 电动机 文胸 柴油机 造纸 有机玻璃 染料 连接器 空气压缩机 管件 电脑维修 电话机 摩托车配件 葡萄酒 五金机械 低压电器 包装设备 过滤器 橡塑 液压机 温湿度 管道 催化剂 电子秤 电加热器 开关柜 建材机械 保险柜 电路板 乳胶漆 工程塑料 特许经营 楼宇自控 喷码机 液位计 聚丙烯酰胺 电磁铁 超市设备 薄膜开关 指纹考勤 渔具 跑步机 防腐设备 锁具 弹簧 纸箱 煤炭 保龄球 家用电器 植绒 钻头 冲压件 建筑机械 实木地板 捏合机 整流器 酒店用品 升降台 转换器 软件下载 喷砂机 制罐 工业炉 生产线 瓷器 搅拌机 印刷机械 综合布线 避雷器 减震器 色织 燃烧器 机电设备 防雷器 地坪 纸品 冷弯型钢 木工机械 物流设备 铁塔 非开挖 热电偶 保险箱 吸塑机 喷漆 过滤材料 电刷 冷水机 采暖 机械加工 照相器材 电镀原料 毛毡 交通设施 消毒机 压滤机 刻字机 接口转换器 电视电话会议 贴纸相机 橡胶机械 喷泉设备 丝印 精细化工 塑胶玩具 五金模具 电子设备 企业形象设计 指纹识别 搬运车 牛仔布 电动车配件 会议系统 终端服务器 录音笔 球磨机 园林设计 路由器 手套箱 实验室设备 童装 手机美容 户外用品 证卡 机床附件 彩电 酒店管理 电话录音 油墨 布线 蜡烛 印刷包装 表面活性剂 节能灯 调味品 齿轮 高压泵 红外热像仪 塑料托盘 吊带 工业锅炉 反光材料 印刷设备 足球推介 热处理 压铸 商标注册 喷灌 逆变器 输送带 锻造 车库门 体育器材 太阳能热水器 绝缘材料 焊管 鼓风机 试验 插座 艺术品 矿山机械 图像监控 无缝钢管 激光切割 标签打印机 燃气表 手机配件 卫星定位 印染 玻璃机械 铝型材 注塑 液压升降机 打标机 工具柜 焚烧炉 电力设备 干燥剂 计量泵 程控交换机

wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh wire mesh http://www.a688.net

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

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. 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.

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.

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. 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

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

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

You can do that with the fill function:

Thing[] things = new Thing[10].fill(int i => new Thing(i));

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.

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.

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

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

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

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;

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 compiler didn't handle ? on typeparameters well in all cases but this problem has been fixed in version 0.9.8. Please update.

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

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

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 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

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

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 theri issues), factory methods-likes, etc... For the moment, you can define a construction function + an initialization method calling super.

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.

Yes, it's only not implemented yet. -- ArjanB

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

Yes, it's only not implemented yet. -- ArjanB

Any support for multiline strings planned? It's a very annoying lack in java.

-- MartinDeMello - 29 Sep 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

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

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

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

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 theri 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

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 cna 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.

• 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

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)

%META:TOPICINFO{author="guest" date="1043947521" format="1.0" version="1.1"}% %META:TOPICPARENT{name="WebHome"}% 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.