Apple Dylan

Apple Dylan: What does the future hold?

By Steve Palmen, tshirt2b@halcyon.com

[As we put this issue to bed, the Dylan developer community is buzzing with rumors on the future of Apple Dylan.

To paraphrase Lennon & McCartney, “I saw a film today (oh boy), the C++ Army had just won the language war.” Then again maybe not. Over the last few months I’ve had the opportunity to explore an early alpha implementation of Apple Dylan. This article examines some of the basic aspects of the Dylan language and presents a brief overview of the Apple Dylan development environment.

A Brief History of Dylan

In the late 80’s, Apple’s Advanced Technology Group (ATG) saddled themselves with the task of creating a new language, one that would combine the best qualities of dynamic languages like Smalltalk™ and Lisp, with those of static languages like C++. Recognizing that a language definition alone wasn’t sufficient to meet the challenges of developing the next ever-more complex generation of software, ATG further committed the Dylan team (now a part of the Developer Products Group) to developing an attendant development environment that would enable the rapid prototyping and construction of real-world applications.

The result of Apple’s largess? A object-oriented dynamic language where everything is an object - forget about whether a method argument is passed by value, reference or pointer, it’s not an issue. Automatic memory management which renders memory leaks and dangling pointers as bugs of the past. A language wherein the degree of type checking is controlled by you, the programmer. Robust exception handling capabilities which enable you to intelligently respond to failures.

In addition to these language features, Apple Dylan includes an integrated development environment that supports incremental compilation and linking which enables you to suspend a running program, alter its source, recompile and link just the affected source, and then resume program execution. Apple has also extended the language standard to include cross language support which enables you to use existing C-compatible libraries in your Dylan application.

Apple Dylan also includes an application framework tailored for building (surprise!) Macintosh applications. Apple Dylan creates stand-alone applications that don’t require the Dylan environment.

Perhaps best of all, Dylan is not Macintosh-specific, it is intended to be a multi-platform language. In addition to Apple’s efforts, Carnegie Mellon University is implementing a UNIX™ version of Dylan and Harlequin Ltd. is implementing a Windows version. There are also freeware implementations available now, including Marlais, an interpreter that has been ported to Macintosh, Windows, and UNIX, and Mindy, a byte-code compiler available for the Mac (PPC and 68K) and UNIX.

Language Overview

Some time ago, I spent a weekend playing with Macintosh Common Lisp. Its peculiar notational style, e.g., using (+ 2 3) to add two numbers, left my head reeling. When I first heard of Dylan, its Lisp roots conjured up images of this same “backwards” notation. Not to worry - Dylan uses algebraic notation that C and Pascal programmers will find familiar in many ways. Here’s a quick look to give you a feel for its syntactic personality.

Identifiers for variable names, function names, etc., are case-insensitive and composed of alpha, numeric and a wide range of special characters. Some of the allowable special characters are the &, |, <, >, /, *, +, and - symbols. In fact, by convention, Dylan class names are held inside a <> pair, witness its <integer> class. Since some of these symbols can denote arithmetic operations they must be surrounded by whitespace - 2+3 is a valid identifier; 2 + 3 is 5.

As you would expect, Dylan defines an assortment of conditional and iteration clauses, some with pleasant additional or new features.

For instance, a for loop can contain more than one termination condition statement, and allows you to define the bounds check using to, above or below. Here is a contrived example:

C For Loop   Dylan For loop
for (i = 0; for (i from 0 below $max,
 i < kMax - 1;   while is-it-ok?(i))
 ++i)     finally do-post-loop-stuff()
 err = IsItOK(i);end for;

if (err == false)
 DoPostLoopStuff();

The use of below sets up i to count from 0 to some constant value, $max - 1. By default the loop’s step value is 1, but you can specify it by appending by n, where n is the increment value, to the for statement. The while clause evaluates the result of the is-it-ok? method, and lets the loop continue if it is. is-it-ok?() (which isn’t defined here) returns an true / false indicator as its result. If the loop completes without an error, the wrapup routine, do-post-loop-stuff(), is called.

There is a lot of Dylan-ese in this example. Note how constants, by convention, begin with the $ character. The for block must be explicitly terminated with an end statement. This goes for the other conditional statements as well: if/else, unless, case, and select.

Another convention is that predicate functions, those that return a true / false value as is-it-ok? does, end in a question mark. Dylan, unlike C, defines a true Boolean class. A single object, #f, is considered false. All other values are considered true. The value #t is provided by the language for clarity.

Finally, notice how multi-word identifiers are, by convention, separated by hyphens, rather than the Inside Macintosh convention of capitalizing each word in the identifier.

Namespaces

As you’ve seen, it’s easy to “read” Dylan. Its syntax is really not that different from C++ or Object Pascal. One characteristic it does differ in is how namespaces are established and controlled.

In C++, a class definition establishes a namespace encompassing both data members and methods. Access to class data and functions depends on their public, private and protected nature as established by the class designer.

In Dylan, a module acts as a namespace. A module “holds” class and method definitions you choose to group together. Since Dylan is completely object-oriented, classes, methods, and data are all stored in variables. You control access to a module variable by choosing whether to “export” it. Only variables you specifically export are visible outside of that module. If you don’t export a variable, it is visible only within that module. This is analogous to C++’s public and private access control mechanisms.

Class Definition

Another difference between Dylan and C++ is in the role classes play. A C++ class defines member functions which give the class its behavior, and data members which provides context. In a Dylan class only data is defined.

C++ Class Definition
class CEvent : public CObject
{
private:
 short  eventType;
 short  eventPriority;
public:
 CEvent(short type, short priority = kEventPriorityNormal) 
 : eventType(type), eventPriority(priority) {};
 OSErr DoEvent();
};

This mythical CEvent class defines two data members: eventType, whose value is the type of event, and eventPriority, which indicates the priority of the event. Its constructor requires two arguments with which it initializes the two data members. The eventPriority argument is optional, defaulting to a “normal” priority value. CEvent also defines a DoEvent() method that processes the event.

Dylan Class Definition
define class <event> (<object>)
 slot event-type :: <integer>, 
 required-init-keyword: event-type:;

 slot event-priority,
 init-keyword: event-priority:, 
 init-value: $event-priority-normal;
end class;

Here’s a line-by-line breakdown of the Dylan class definition:

 define class <event> (<object>)

defines a variable named <event> for the class whose parent class is <object>, the common ancestor of all Dylan classes. (As you would expect, Dylan supports multiple inheritance. Additional superclasses would be included, comma-separated, inside the parenthesis.)

 slot event-type :: <integer>, 
 required-init-keyword: event-type:;

defines a slot (akin to a C++ class data member) named event-type whose data type is limited to integer values. When an <event> object is instantiated, you are required to supply an initial value for this slot using the event-type: keyword.

 slot event-priority, 
 init-keyword: event-priority:, 
 init-value: $event-priority-normal;

defines a untyped slot named event-priority whose keyword initializer is optional. If you don’t provide it, the slot will default to the value of the $event-priority-normal constant.

As is typical of Dylan block end statements, end class; could have been written just end;, or end class <event>;.

Note that some of the idioms so often implemented for a C++ class - a constructor to initialize the object’s state, a copy constructor to properly clone the object, and an operator= overload to handle a new value assignment - are not needed. As shown above, keywords define the slot initialization that takes place when the object is instantiated. Dylan has built-in functions for copying and assigning objects. Destructors aren’t required either as automatic memory collection deletes objects that are no longer being referenced.

Data Type Declaration

But what’s with this unspecified data type for the event-priority slot? In Dylan, type declarations are optional. From a C++ perspective this lackadaisical approach to data typing seems fraught with peril. After all, isn’t the strict typing requirements of C++ one of its strengths?

If you write let a-number = 1; (let simply creates a local variable, see Creating and Initializing Variables below) you can trust the compiler to do the right thing. However there’s nothing preventing you from later setting a-number to a non-integer value, whether you mean to or not. Dylan allows you to provide data type information when type safety is truly important. In the example above, all it takes to specifically type a-number as referencing only integer values is to write the statement as let a-number :: <integer> = 1;

Dylan-ites cite this characteristic of the language as an aid in rapid prototyping. This reduction in the cognitive load, however slight, has other virtues. It is pleasant to not have worry about whether a loop counter variable should be a long or a short - what does it matter? If you leave a-number untyped, the compiler will take care of promoting it to a larger data type should you ever exceed its capacity. And as illustrated, providing the information necessary to strictly type a variable is easily done. However, be careful that this new found freedom doesn’t go to your head. Here’s an example:

define variable any-thing = 1;
    // any-thing is untyped, initially references an integer value

define variable a-number :: <integer> = 1;
     // a-number is restricted to integer values
/*
note: define variable  creates a module variable which is globally visible within the module. See Creating 
and Initializing Variables below.
*/

define method foo ()
/*
note: define method foo() defines a function named foo which takes no arguments. See Generic Functions 
and Specialized Methods below.
*/

 any-thing := "a string";
    // OK, any-thing used to reference an integer, now it  references a string

 a-number := -1000;
    // OK, still references an integer value

 a-number := ‘n’;
    // compiler will complain about type violation since ‘n’ is a character constant,                               
    // not an  integer
end method foo;

define method bar()
 a-number := any-thing;
    // compiler will let this pass
end method bar;

Since any-thing is untyped, it can contain well anything. By the time you call the bar() method, any-thing may have been altered to reference an integer value, so the compiler dares not complain. Note that the error in the example above is not ignored, it will be caught at run-time. Fortunately, Dylan’s exception handling capabilities enable you to gracefully recover from such an error.

Instantiating an Object

As mentioned above, Dylan doesn’t expect you to provide an explicit constructor method to initialize an object. You create an object instance via the make method.

let the-event :: <event> = make (<event>, event-type: $some-event);

defines a local variable named the-event of type <event>, and creates an instance of the <event> class, initializing its event-type slot with the value of the $some-event constant. Since we didn’t provide the event-priority keyword, the event-priority slot is initialized to its defined default value. The reference to the created instance is assigned to the the-event variable.

There are a number of other slot options you can utilize in your class definitions. For instance, instead of an explicit default value, you could instead specify an init-function: that is called during object creation to supply the initial value for the slot.

You can also specify how storage for a slot is allocated. By default, each object instance gets it own storage for a slot. You can define that a single storage location be used for a slot by a class instance and all its descendants (analogous to a C++ static data member). Dylan also supports the notion of virtual allocation for a slot. Storage is not automatically allocated for virtual slots, it is up to you to provide getter and setter methods that retrieve and store the value of the slot.

Slot Accessors

Programmatically, you always access a slot’s value via a function call. By default, the getter function name is the same as the slot’s name, and the setter function is the getter’s name appended with “-setter”. Continuing with our <event> class example above, to retrieve the slot’s value you would call:

 event-type(the-event);

and to set the event type you would call:

 event-type-setter($some-event, the-event);

Dylan kindly provides some syntactic sugar in this regard. It also allows the more conventional ‘object.slot’ syntax. The following forms are equivalent:

Getters

 event-type(the-event)
 the-event.event-type

Setters

 event-type-setter($some-event, the-event);
 the-event.event-type := $some-event;
 event-type(the-event) := $some-event;

The use of the assignment operator := in the alternate setter is discussed in Creating and Initializing Variables below.

In addition to the slot options mentioned in the discussion above on class declarations, you can also specify the names for the slot’s getter and setter accessor functions. You may also protect a slot’s value from modification (i.e. make it read-only.)

Generic Functions and Specialized Methods

OK - we’ve defined an <event> class, we know how to instantiate one, and by default Dylan provided getter and setter functions for its slots. Big deal! - we didn’t define any class member functions. So how in the world do we use the bloody thing?

In Dylan, the term generic function refers a family of methods that share the same name and basic arguments. A specialized method is a member of a generic function family whose arguments are specialized to act upon a particular object or object type. When you call a generic function, Dylan looks at all the arguments you provide to determine the most specific method to call.

To explore how this form of polymorphic method dispatch works, we need to first refine our design. Let’s add a subclass of <event> specifically for window events, and another for mouse events.

define class <window-event> (<event>)
 slot window :: <window>, 
 init-value: $nil-window, 
 init-keyword: window:;
end class;

define class <mouse-event> (<event>)
 slot local-coordinates, init-value: #f;
end class;

(Note that the <window> class is for illustrative purposes only, it is obviously not intrinsic to the language. However, the Apple Dylan application framework does contain a window class and many other Macintosh-related classes.)

Now let’s provide specialized methods to handle these events:

define method do-event (event :: <event>)
    // basic event handling
end method;

define method do-event(event :: <window-event>)
    // window-specific event handling
end method;

define method do-event(event :: <mouse-event>)
    // mouse-specific event handling
end method;

When your event detection code calls the do-event generic function, the specific method that gets run depends on the event subclass of the object passed as the parameter. For instance, in response to a mouse event, you would instantiate a <mouse-event> object and pass it as the argument to do-event. All members of the do-event family are examined to see which method most closely resembles the objects passed as arguments. In this example the do-event(event :: <mouse-event>) specialized method is invoked. In many cases the compiler will be able to make this analysis and generate code that directly calls the most specific method thus incurring no runtime penalty.

Methods pass control to the next most specialized method by calling next-method(), which is similar to calling Inherited in Object Pascal, or invoking the direct superclass method via CSuperclass:Method() in C++. For example, the do-event(event :: <mouse-event>) specialized method may need to run the event handling code contained in the base do-event (event :: <event>) method before its code is run.

In contrast, C++’s polymorphic method dispatch depends on common ancestry. Every class that needs to handle an event must (in our example) descend from CEvent, and with each new event that is added, the class hierarchy must be altered. In Dylan, you just define the new class and add a method specialized on the new event type. Dylan’s approach reduces class coupling and minimizes the impact on existing code when new functionality is introduced. If nothing else, it “feels” more natural. Instead of thinking “event-class, handle the mouse event”, it’s just, “handle the mouse event.” I know this difference seems trivial, but to me it is the critical difference between C++ and Dylan.

Finally, note that methods, like classes, are first-class objects. That means they can be assigned to a variable and passed around like any other variable. Yah, weird Local Methods below gives an example of how powerfully weird this feature can be.

Method Parameter Lists

In addition to required parameters, a method’s parameter list can be defined to accept an unlimited number of arguments.

define method plot-points(#rest points-to-plot); 

defines a method named plot-points that accepts a variable number of arguments. Parsing the point arguments inside the method is easily done via:

 for (a-point in points-to-plot) // plot each point provided
   draw-point(a-point);
  end for;
end method plot-points;

To call this method, you merely pass all the points you want:

plot-points(point-a, point-b, point-c);

Method parameter lists can also define optional keyworded parameters. For instance,

define method make-window (dimensions, #key title = "Untitled", 
     has-zoom-box?)

defines a method that has one required argument, dimensions, and two optional keyword arguments. If the title keyword is not specified, its value is “Untitled”. If has-zoom-box? is not specified its value is false (#f). You can specify keywords in any order, as shown below:

make-window(window-size, has-zoom-box?: #t, title: "New Window");

Return Values

OK, here’s a quiz. What does this method return?

define method square-of(x :: <integer>)
  x * x;
end method;

Not real obvious, is it? In Dylan there is no explicit return statement - the result of a function is whatever value is generated by the last expression in the method, in this case x * x. If you were just browsing through the method definitions in a module, it wouldn’t be immediately apparent that this method returned anything at all. Luckily, Dylan allows you the option of declaring the result type of a method :

define method square-of (x :: <integer>) 
 => x-squared :: <integer>; // => result value
  x * x;
end method;

The inclusion of => x-squared :: <integer>; reveals that the method returns an integer value. Note that just => x-squared; is legal as well. Unfortunately this is pretty much useless, other than as an indication that the method returns a result of some undetermined data type. Note as well that the name of the result value, x-squared in this example, never comes into scope. So it can be any valid identifier: the-result, x*x, square-of, <integer>, or omitted altogether. I’ve made a habit of always explicitly defining a method’s result values, and giving them meaningful names. Just because Dylan will let us be lazy is no reason to do so.

One feature of Dylan I have grown fond of is the ability of an expression to return multiple values using the values function. For example, let’s pretend we have a C++ method that accepts a Rect, and returns its height and width. In C++ you would declare:

void RectSize(Rect& rect, short& height, short& width)
{
 height = a-rect.bottom - a-rect.top;
 width = a-rect.right - a-rect.left;
}

and call it by:

RectSize(rect, h, w);

In Dylan you could instead:

define method rect-size(a-rect) 
 => (height :: <integer>, width :: <integer>);
  values(a-rect.bottom - a-rect.top, 
 a-rect.right - a-rect.left);
end method;

let (h, w) = rect-size(a-rect);

Note that like the <point> class shown above, <rect> is not an intrinsic Dylan class, but it is a part of the Apple Dylan application framework.

Local Methods

Quite frankly, there’s very little I miss about my Object Pascal programming days, except local procedures and the availability of class meta-data. For those of you untainted by Pascal, local procedures are small, special purpose procedures that can be embeded inside another procedure. They’re neat, clean and don’t clutter up your interface. Dylan’s got ‘em too. The special form local is used to bind a variable (and hence methods) within the current scope. Here’s an example:

define method plot-random-point() => ()  // returns nothing
 local
 method compute-random(max-value)
 => random-value :: <integer>;
 let r = remainder(Random(), max-value);
    // remainder is a built-in Dylan function
    // Random() is the Mac Toolbox trap
 if (r < 0) 
 - r    // => compute-random returns (- r)
 else 
 r // => compute-random returns r
 end if;
 end method compute-random;

 let (h, w) = screen-dimensions();  
    // screen-dimensions returns screen height and width

 draw-point(make(<point>, 
 h: compute-random(h),
 v: compute-random(w) ));

end method plot-random-point;

A local method’s scope is that of its enclosing method, it has access to the parameter list, and any other methods created within the local block. However, you can use a local method outside of this scope. For instance, if you were doing some sort of analysis where the function to be performed depends entirely on the object under scrutiny, you could define a method that looks at the object and returns the proper function:

define method analyze-me(patient) => analyst :: <method>;  
    // <method> is a built-in class

 local method freudian () ... end;
 local method jungian () ... end;

 if (blames-mother(patient))
    freudian // returns the freudian method, does not execute it
 else
    jungian // returns the jungian method, does not execute it
 end if;
end analyze-me;

let axe-dude = analyze-me(alan-bates);
    // this creates and returns a function

axe-dude();  
    // this invokes the local method in its original scope (patient = alan-bates)

Creating and Initializing Variables

Like Bob’s Country Bunker where they have two kinds of music: country AND western, Dylan supports two kinds of variables: module and lexical.

Module variables can be referenced from anywhere inside the module, i.e. they are “global.” A module variable is created using:

define variable *current-temperature* = 55;  
 // the high today in Seattle 

You can, as noted above, associated a data type with the variable name, and by convention, variables whose value will change begin and end with asterisks.

Module constants (read-only variables) are defined in similar style:

define constant $the-meaning-of-Life = 42;

Variable names for constants, by convention, begin with a $ character.

A lexical, or local, variable is created using:

let counter = 0;

let binds a new name to an existing object. This is unlike assignment, which alters the contents of an existing storage location.

Like C, a local variable’s scope is limited to the smallest enclosing block in which it occurs. For instance, outside of this if block:

define method how-loud?(album) => level :: <integer>;  
 if (album = "Smell the Glove")
 let volume = 11
 else
 let volume = 10
 end if;
 volume;  // => how-loud? result
end method;

volume doesn’t exist and so the compiler won’t be able to make sense of the last line. volume was created by a let statement inside the if block, and fell out of scope when it was exited. What you want to do is:

define method how-loud?(album) => level :: <integer>;  
 let volume =
 if (album = "Smell the Glove")
 11// => result of 'if' assigned to volume
 else
 10// => alternate result
 end if;
 volume; // => method result
end method;

But a true Dylan-Weenie would drop the references to volume altogether and return the result of the if statement:

define method how-loud?(album) => level :: <integer>;  
 if (album = "Smell the Glove")
 11  // => result
 else
 10  // => result
 end if;
end method;

Assigning Values to Variables

I’d like to tidy up a few loose ends regarding assignment and equality which illustrate some important Dylan precepts. The special form := was introduced earlier. Unlike C, which uses the = to assign a value, Dylan uses := to assign a different value to an extant variable.

define variable counter = 10;
define variable delta = 20;
counter := counter + delta;  // counter now set to 30

:= can also be used as an alternate form for setter functions. Recalling our Slot Accessors discussion above,

 event-type-setter($some-event, the-event);

can also be written:

 the-event.event-type := $some-event;

It’s important to note that assigning the contents of one variable to another does not copy the object being referred to.

 let the-joker.enemy = batman;  
 let the-penguin.enemy = the-joker.enemy;

the-penguin.enemy slot doesn’t reference a copy of the batman object, it references the very same object as does the-joker.enemy slot. If you alter batman, mutating it into his alter ego, then both the-joker and the-penguin “see” the change.

Equality Testing

The = function is used as an equivalence test, and == is used to test for uniqueness. To explore the difference, let me present <vector>, one of Dylan’s many built-in collection classes. Vectors are simply one-dimensional arrays.

let vector-A = vector(1, 2, 3);
    // creates a vector of 3 elements: 1, 2 and 3

let vector-B = vector(1, 2, 3);
    // creates another vector which does not share storage with the first

(vector-A = vector-B);
    // => true.  the two vectors are equivalent - their contents “appear” the same

(vector-A == vector-B);
    // => false!  the two vectors are separate objects, and so are unique

let vector-C = vector-A;
    // now the first vector is known by two names:
    //   vector-A and vector-C

(vector-A = vector-C);
    // => true.  the two vectors are equivalent

(vector-A == vector-C);
    // => true!  vector-A and vector-C reference the same object

Built-in Collection Classes

The last characteristic of the language I’d like to introduce you to is its collection classes. As in Smalltalk and Lisp, collection classes are an natural part of the Dylan language, not a feature of some external class library built with Dylan. This topic is so broad that it would require a separate article to do it justice. But I would like to touch on it briefly.

Dylan’s collection classes include those optimized for dealing with arrays, byte string, unicode strings, single and doubly-linked lists, and hash tables.

All of these classes support a consistent suite of functions that enable you manipulate and interrogate their contents. Included among these are functions that determine whether then collection is empty, the number of elements in the collection if it is not empty, and can perform complex “search for this set of elements and do this to them” operations. You’ve already seen an example of this above in the parameter list discussion. The plot-points method used the for construct to step through each point in the list provided by the caller. Note the simplicity of this for (each-element in the-list) do this construct - there’s no i = 0 counter setup, or i < range checks.

Apple Dylan Development Environment

Since Apple’s integrated development environment (IDE) is, as of this writing, in an early alpha stage, specific details would be premature. But here’s a teaser of what you can expect.

Source code is held in a project database, not individual files. You view, edit and compile your project using intelligent “browser” windows. A great feature of these browser windows, or binders as Apple calls them, is that they support multiple views of a project’s content. Completely configurable, you can split a binder window into multiple panes and set each pane to display a different aspect of your project and its source code. These panes can be “linked” together so that a change in selection in one pane automatically updates the display in another, or you can drag an item from one pane to another to see the different aspect of the item. Dylan comes with several handy binder configurations, and you can create your own and save them for recall later.

Figure 1 below shows one possible configuration. This binder window is displaying the Online-Insultant sample project, included with the current alpha release. The upper left hand pane displays the project-level contents: modules, resource and text files. Clicking on an item in the upper left panel causes the contents of the selected item to be displayed in the lower-left pane. As we see in Figure 1, the project’s Online-Insultant module has been selected. The source folders contained within it - Engine, Picture, Sound, and Application - are displayed in the lower left pane. This browser has been configured to display in the right pane the source records contained in a selected source folder. Selecting the Engine source folder causes all of its source records to be displayed in the right pane. The Finder-like turn down arrows operate as you expect, expanding and collapsing the view of the selected item. Opening a source record in the right pane enables you to edit its contents. Menu commands are used to add and delete items in a pane.

Figure 1. “Project” Browser

The modules displayed in the upper left pane directly correspond to the modules that define your project’s namespace as discussed above. The source records displayed in the right pane each contain one top level expression, such as a method, variable or a constant definition. However, the source folders displayed in the lower left pane have no corresponding language construct, they are merely an abstraction employed within a binder to enable you to logically organize your source records.

Figure 2 shows a binder window configured to display a class hierarchy graph in the upper pane, the selected class’ slots in the lower left, and its direct (i.e. non-inherited) methods in the lower right.

Figure 2. “Class Info” Browser

Typically you would invoke this binder window by selecting the class name you want more information on (e.g., by double-clicking on <sequence> in the text of a source record displayed in a project browser), and then selecting the “Class Info” browser from the IDE’s menu of available browsers.

The application under development runs in a memory partition separate from the browser. After compilation, it is downloaded into the “application nub” where it executes. You can disconnect from your application, and reconnect to it at a later time, even across a network.

The third component of the IDE is a “Listener” window. It looks like a MPW Worksheet window, but is much more. You can type Dylan functions directly into the Listener window, and execute them to see how they will react. The code you enter is downloaded to the application nub where it is executed. This has turned out to be quite useful, I often experiment with code using the Listener and once I get it working, only then do I add it to the actual project. You can also use the Listener to communicate with your running application. For instance, you can invoke methods within your application and have their result returned directly to the Listener, another handy feature for debugging. You can even call Macintosh OS Toolbox Traps from the Listener.

The Apple Dylan application framework will feel immediately familiar to those acquainted with MacApp. It employs similar logical constructs like views, behaviors, commands and adorners, however it is definitely not a port of MacApp to Dylan.

Apple Dylan’s cross-language support is a significant feature. This extension to the language, which Apple hopes will be adopted by other Dylan implementations, allows you access to the Macintosh Toolbox or C / C-compatible libraries, including C++, Pascal, assembler, and FORTRAN. C header files can be imported directly, enabling you to access the functions and data structures definitions as if they were Dylan objects. Apple Shared Library Manager and Code Fragment Manager shared libraries, inline traps, code resources, and PowerPC transition vectors are also supported. Calls between Dylan and C-compatible libraries can be made in either direction. You can also gain access to low-level machine pointers.

Summary

Dylan’s many qualities make it attractive. Its clean syntax offers little resistance to the novice, less so, I think, than C presents. A good C++ or Object Pascal programmer will have little difficulty grasping its basic constructs, though exploiting its more dynamic elements will take time and study. To me, its strongest qualities are its flavor of polymorphic method dispatch and automatic memory management. Prior to working with Dylan, I didn’t notice how much time I spent in design worrying about issues of class coupling and memory management. It’s remarkable how often I now find myself faced with a design conundrum in C++ that simply wouldn’t be an issue in Dylan. Neither do I miss worrying about bogus pointers or memory leaks one bit. Incremental compilation, coupled with the ability to suspend a running program, make a change to the source, recompile, and step back in where you left off, makes the debugging cycle much less tedious.

Take a look at Dylan - you might be surprised.

Suggested Reading

If you’re like me, steeped in static languages, but unacquainted with dynamic languages, do yourself a favor and skim a book on Lisp before diving into Dylan. Trust me, it will help flatten the learning curve. Here are a couple I found useful:

Freidman, Daniel P. and Felleisen, Matthias. “The Little LISPer”, The MIT Press, ISBN 0-262-56038.

Koschmann, Timothy. “The Common Lisp Companion”, John Wiley & Sons, ISBN 0-471-50308-8.

For Dylan-specific information, download a copy of the language reference manual from the Apple Dylan ftp site. You can also take a look at these articles:

Matejic, Larisa. “Writing an Application in Dylan”, MacTech Magazine, September 1994.

Strassmann, Steve. “A First Look at Dylan: Classes, Functions and Modules”, develop, March 1995.

Credits

I gratefully acknowledge the assistance of those who reviewed this article: Rick Fleischman, Dylan Product Manager, Apple Computer, Inc., and especially Steve Strassmann, Intellectrician, Apple Computer Inc., (aka The Dylan Answer Guy) who serves with great patience as mentor to us early explorers of Apple Dylan.

Where To Get More Information

Sources for Dylan software, language reference manual and other documentation include:

• Internet:

http://www.cambridge.apple.com
Apple Dylan World Wide Web server

ftp.cambridge.apple.com:/pub/dylan
Apple Dylan ftp site

comp.lang.dylan
Newsgroup discussion. If you’d like to join the newsgroup discussion, send your request to:
info-dylan-request@cambridge.apple.com.

• AppleLink: Developer Support: Developer Services:
Development Platforms: Dylan Related

• eWorld: go to “dev service”; where you’ll find ToolChest:
Development Platforms: Dylan Related

• CompuServe: Apple support forum (GO APPLE)
Programmers / Developers Library #15

Want to get in on the ground floor? Apple invites beta testers. Send a message, including your name, address, FAX and voice telephone numbers, and a brief statement of what you’d like to do with Apple Dylan, to AppleLink: DYLAN, or to dylan@applelink.apple.com.