The Dylan name for the library that we are defining. There must be a corresponding define library somewhere in the source for this library.

A whitespace-separated list of source files that constitute this library. The .dylan extension can be omitted. Note that you can continue header statements on the next line by indenting the continuation line with whitespace.

Specifies that we are building a runnable application rather than a library. The executable is generated with the specified name.

This option specifies flags which must be passed to ld when linking against this library. This is primarily used when a foreign library is called via one of the undocumented callout mechanisms. For example, Dylan.lid specifies -lm so that it can use the math library. This dependency is automatically propagated to users of the library.

Unique class identifiers for classes defined in this library are assigned sequentially starting with the specified integer. This should always be specified, but you won't get a sensible error if it is missing. The base should be sufficiently far from the base for any other library so that class IDs won't overlap. You will get a compile-time error if overlap occurs. A good base for user code would be 30000.

The Unique ID is used for multimethod dispatch, and it is bound to go away in the near future.

When generating an executable, this LID option specifies which Dylan function is called as the main entry point. You can also have no main entry point, in which case the program exits after running all of the top level forms. This entry-point function is called with two arguments, argc (an integer) and argv (a raw pointer). Note that this is incompatible with Mindy, and rather brutal as well. You can get the mindy semantics of calling Extensions:Main by using the Extensions module in your main module and then specifying: Entry-Point: mymodule:%main in the LID file. The %Main function parses the arguments and then calls Main.

This header item is deprecated. Just use the side effect of top-level statements instead.

This prefix is used to make the C translation of names in this library unique w.r.t. any other libraries that might be used. This defaults to the library name, mangled according to the Dylan-to-C name mangling rules. You shouldn't need this.

The argument is a space-separated list of features or misfeatures. If the token begins with ~, then the rest of the token is interpreted as a feature to remove. Otherwise, the token is added as a feature.

Used to determine the precision of floating-point constants that are not suffixed with precision markers. Legal values are single (to default to <single-float>, double (to default to <double-float>, or extended (to default to <extended-float>). Without a float-precision: keyword, unsuffixed floating-point constants default to <double-float>.

A fourth alternative, auto, indicates that an unsuffixed floating-point constant should be a <double-float> if it has eight or more digits after the decimal point, or a <single-float> otherwise. This behavior corresponds to Functional Developer's default behavior, and is intended for code ported from Functional Developer.

Yes (the default) if define method should implicitly define the next-method variable within the body, or no if it should not. This keyword is available for compatibility with mindy (which does not implicitly define next-method, or for those who don't want to pay the cost of implicitly defined next methods in every method definition.

Yes if definitions in the library should be dynamic (modifyable at runtime, for example with add-method), or no if they should not. The default is no.