Dylan Language
Volume Number: 11
Issue Number: 8
Column Tag: Dynamic Languages
Apple Dylan 
Apple Dylan: What does the future hold?
By Steve Palmen, tshirt2b@halcyon.com
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
[As we put this issue to bed, the Dylan developer community is buzzing with rumors on
the future of Apple Dylan.
As you may remember, Apple intends to ship “Early Dylan” this fall. This
implementation is built on top of Macintosh Common Lisp and is capable of targeting
Power Macintosh, but not running native on Power Mac. To date, Apple Dylan has been
developed by the former ATG group in Cambridge, MA.
As of this writing, the report is that Apple may be closing it’s Cambridge office
(of about 20 people) focused on Dylan, and moving the efforts to Cupertino. It isn’t
clear if nor when this is going to happen - although it won’t likely happen until at
least October when Early Dylan is released. What also isn’t clear is who will be
working on Apple Dylan - new folks in Cupertino? the current folks in Cambridge? or
a combination?
Apple is working on the plans now for the future of Apple Dylan. Hopefully, by
the time you read this, we’ll have an idea. We’re being told that this is a good thing for
Apple Dylan - we hope they are right. As with all “sea changes” - time will tell. Stay
tuned Ed. - nst]
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.
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
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.
CEvent also defines a DoEvent() method that processes the event.
Dylan Class Definition
define class (
slot event-type :: ,
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 (
defines a variable named for the class whose parent class is
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 :: ,
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 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 ; .
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 :: = 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 :: = 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 ()
/*
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 :: = make (, event-type: $some-event);
defines a local variable named the-event of type
the
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 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;
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 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 specifically for window events, and
another for mouse events.
define class ()
slot window :: ,
init-value: $nil-window,
init-keyword: window:;
end class;
define class ()
slot local-coordinates, init-value: #f;
end class;
(Note that the 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 :: )
// basic event handling
end method;
define method do-event(event :: )
// window-specific event handling
end method;
define method do-event(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
do-event family are examined to see which method most closely resembles the objects
passed as arguments. In this example the do-event(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 :: ) specialized method may need to run the event
handling code contained in the base do-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
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 :: )
x * x;
end method;
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 :: )
=> x-squared :: ; // => result value
x * x;
end method;
The inclusion of => x-squared :: ; 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,
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 :: , width :: );
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 class shown above, 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 :: ;
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(,
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 :: ;
// 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 :: ;
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.
was exited. What you want to do is:
define method how-loud?(album) => level :: ;
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;
the result of the if statement:
define method how-loud?(album) => level :: ;
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
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
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
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.