# The IDL/Lisp Standard and ORBLink

The CORBA IDL/LISP proposed standard mapping allows the implementor flexibility in the implementation of various types and functions. The purpose of this document is to describe the choices we have made.

## Sequence handling

This ORB always unmarshals values corresponding to the IDL sequence type as vectors. However, a list may be used anywhere a sequence is expected.

## float and double types

`corba:float`, corresponding to the IDL `float` type, denotes the type `single-float`.

`corba:double`, corresponding to the IDL `double` type, denotes the type `double-float`.

## Operation mapping

ORBLink implements CORBA operations as generic functions. An operation named "foo" will be mapped to a method on a standard generic function named `OP:FOO`.

The signature of the generic function is `(T &REST ARGS)`.

User code may rely on the fact that `OP:FOO` is a funcallable object and may freely use auxiliary methods with such objects. However, Franz may change the low-level implementation of such functions in the future and user code should not rely on the metaclass or the signature of such generic functions.

## Unimplemented features

The following aspects of the CORBA Core are unimplemented:

1. DII/DSI
2. Wide strings, wide characters [no longer true as of Orblink 2.2.03]
3. Extended numeric types (long double, long long)
4. Fixed types
5. POA [no longer true]
6. Contexts

## Note on on enum types

According to the CORBA 2.2 specification, an enum type does not begin a new naming scope. This means that enum members themselves define a new type in the namespace of the IDL construct containing the enum type definition. The CORBA 2.3 specification may change this counter-intuitive rule. In any case, we follow the CORBA 2.2 specification so that users must make sure that enum members do not conflict with names in a containing scope.