Differences between Object Icon and Icon.

Introduction

Although Object Icon is quite compatible with Icon source code, there are several differences. These notes should be helpful in converting Icon code to Object Icon.

Differences

New reserved words: class, const, optional, native, abstract, final, import, package, private, protected, public, readable, succeed.
A few new builtin functions, most notably : is(), classof(), keyof(), ucs(), uchar(), text(). In total though, Object Icon has far fewer builtin functions, since much functionality now exists in classes. See BuiltinFunctions.
Some new keywords, amongst them &why is a string, giving the reason for a failure (rather like C’s errno variable). &yes and &no are values for an on/off flag to take. &yes is the single value of a type “yes”, and &no is a synonym for &null. Again, several of Icon’s keywords have their equivalent in classes. See Keywords.
I/O has been completely rewritten in Object Icon; there are no builtin I/O functions nor is there a builtin file type. Rather, I/O is implemented using a new set of classes in the io package. There are procedures in this package which emulate some of Icon’s I/O functions (open, read, write, etc).
Graphics facilities are re-cast in object-oriented form and are found in the graphics package. Most notably, the class Window represents an window, rather than Icon’s builtin file type, and most of the Icon graphics functions have corresponding methods in that class. The various Icon graphics keywords don’t exist in Object Icon.
The maths functions are static methods in the class util.Math, rather than builtins. Object Icon doesn’t have Icon’s keyword constants &pi, &e and &phi, but equivalents can be found in util.Math.
The set() function creates a set and adds each parameter provided to the function to the new set. In Icon the set() function takes a list and adds its members to the new set.
Icon’s runtime error conversion control using the &error keyword is absent from Object Icon. Rather, runtime errors can be handled with co-expressions, using the &handler keyword.
For a record, type() returns the record type name in Icon, whereas in Object Icon it returns “record”; the static method Constructor.get_name() can instead be used to get the record constructor’s name for a given record instance.
The invocation of PDCO procedures passes the co-expressions as individual parameters, rather than collected as a list in one parameter. So the syntax
```
proc{expr1, expr2, ...}
```
is equivalent to
```
proc(create expr1, create expr2, ...)
```
rather than Icon’s
```
proc([create expr1, create expr2, ...])
```
Co-expressions have slightly different semantics. Further, in Icon, co-expressions are quite expensive to create and use, whereas in Object Icon they are very cheap. See Coexpressions for full details.
In Icon, an undeclared identifier produces a compiler warning; in Object Icon it is an error.
In Icon, global variables representing functions, procedures and records can be assigned to at runtime. In Object Icon, they are constants and cannot be changed.
The builtin functions insert and delete may be used to modify lists; Icon does not support such usage.
The builtin functions put and push only allow a single value to be added to a list; Icon allows multiple values. There are library functions, ipl.lists.put_n and ipl.lists.push_n which behave more like Icon.
The builtin function trim behaves differently; by default it trims characters from both ends of the input string, whereas Icon just trims from the end. To replicate Icon, pass -1 as a third argument.
A different ucode format - you can’t link Icon and Object Icon ucode files.
Different executable names. Icon has icont and iconx; Object Icon has oit and oix.
Different path variables. Whereas Icon has IPATH and LPATH, Object Icon has OI_PATH and OI_INCL. Furthermore, these path variables use the platform’s path syntax rather than Icon’s space-separated syntax.
Icon program library. Most of the IPL is available in Object Icon, but uses Object Icon’s package system to avoid filename and symbol clashes. Generally, this just means changing a link declaration like
```
link options
```
to an import declaration
```
import ipl.options
```
The preprocessor uses $if rather than $ifdef for conditionals, and allows a more general syntax.
Cset literals in Object Icon can include character ranges specified with a hyphen. Thus
```
'a-zA-Z'
```
has the same value as &letters in Object Icon. To include a hyphen in a cset, it must be escaped with a backslash.

Contents