Dynamics 0.2 (21^th of November 2002)

Changes

• A lot of bugs have been fixed. The basic implementation is now being debugged.
• Polymorphic dynamics are allowed. For example and more information, please refer to the reference manual and the Unify-folder within the examples folder.
• Support for type synonyms
• Object IO support
• Various small bug fixes and changes

Changes (Dynamics 0.1, 25^th of June 2002)

• A lot of bugs have been fixed. The basic implementation is now being debugged.
• More support for lazy dynamics by eliminating the three former restrictions in the section about ‘Dynamic Pattern matches’.
• Garbage collection on dynamics and their libraries.
• Dynamics now have (nearly) unique identifications which mean that they can move them as you wish.

Install

• Unpack the dynamic-package in the root of the already unpacked Clean base distribution.
• Move the dynamic link libraries DynamicLink.dll and ServerChannel.dll to your Windows-system directory.
• Enter the proper path names for the dynamic projects by changing the definition of the p-function in the where clause of the Start-rule. Do not forget that slashes need to be escaped by putting another slash in front.
• If you installed Dynamics 0.{0,1} and you want to use dumpDynamic on your dynamic, then delete HKEY_CLASSES_ROOT\prjfile\Shell\dynamic link-key.

Introduction

Dynamics are still under development. It is therefore important to note that dynamics are released for experiments only. Please re-read the last sentence.

At least the following restrictions apply:

• Unsupported release. It is mainly intended for small experiments and to satisfy the curiosity.
• Overloaded types, unique types, universally quantified types, existentially quantified types, abstract types cannot be packed and/or unpacked.
• For the time being, windows only. It has been tested on windows 95/98. It has also been run under windows 2000/XP.
• Binary compatibility is not guaranteed i.e. you may need to recompile every dynamic when a next release occurs. To be sure delete and recompile your old dynamics.
• Lazy dynamics i.e. a dynamic containing at least one reference into another different dynamic are not fully implemented.
• Probably a lot of small bugs.

However algebraic, record, function and array typed objects can be safely packed and/or unpacked.

The rest of this text is a practical guide on using dynamics and its supporting tools.

Short introduction to dynamics

A dynamic (of static type Dynamic) consists of:

• a value i.e. dynamic expression
• the static type of the value i.e. dynamic type.

Basic operations on dynamics:

• packing an object into a dynamic by using the dynamic-keyword.
• unpacking an object from a dynamic by using a dynamic pattern match.

In addition there are type dependent functions i.e. the context determines the type of the packed object.

Please see the ‘Examples’-folder for concrete syntax and examples.

Creating a dynamic project

In addition to the normal procedure to create a new Clean project:

• Use an environment containing a Clean 2.0 compiler.
• Mark it as the project as a dynamic project by marking ‘Enable Dynamics’ in the ‘Project Options’-menu of CleanIDE.

Creating a dynamic

A dynamic is created using the following syntax:

dynamic <an arbitrarily Clean object> :: <external type>

Eventually most typed Clean objects can be injected into a dynamic. Only for some objects e.g. World, File, … natural restrictions will apply.

The external type of a dynamic is the static type of the object injected into the dynamic. The internal type of a dynamic are the types of all objects which help to create an object of the external type.

An example (Clean fragment):

dynamic (length [‘a’,’b’,’c’]) :: Int

The current implementation need not perform the rather costly internal type check because it is done at compile-time and the use of code repositories preserves the validity of the compile-time check.

Building a dynamic project

After a dynamic project has been compiled and linked without errors, the static linker has created:

• a type and code repository. In contrast to an executable, a code repository contains symbolic definitions and references.
• a batch-file to start the project from the code repository.

Only the batch-file is visible for the user and it replaces the executable that would normally be generated by the linker.

The code and type repositories for the dynamic project have been stored in the ‘libraries’-subfolder of the dynamic linker folder which has been set in the Clean IDE.

Starting a dynamic project

There are two ways to start a dynamic project:

• using the normal ‘Run’-option of the Clean IDE which uses the batch-file to start the project.
• clicking on the generated batch-file.

The batch-file starts the dynamic linker by giving it the code repository for the dynamic application. The dynamic linker then starts the application at its normal entry point.

Writing a dynamic using writeDynamic

Each object in Clean conceptually is a graph rewriting system. The graph at run-time consists of:

• a data graph i.e. that part of the graph containing constructors which is actually built at run-time.
• descriptors which reference code for functions which implicitly rewrite the graph according to the reduction strategy.

In order to encode a dynamic e.g. write it to disk the above components of the run-time graph need to be encoded:

• the data graph is encoded using a top-down, left-to-right traversal.
• a descriptors is encoded as: its code repository name, its module name and the descriptor name itself.

In addition lazy dynamics are supported. The dynamic version of the standard apply-function (see also Examples-folder) creates references to other dynamics. These references can be viewed using the dumpDynamic-tool. At run-time only those pieces of the dynamic are constructed which are actually needed. This improves efficiency.

Reading a dynamic using readDynamic

An object packed into a dynamic on disk can be retrieved using the readDynamic-function. This function converts the disk representation of a dynamic to its run-time representation. The necessary functions are linked by a dynamic linker. As said the retrieval of dynamic happens in pieces to increase efficiency.

Dynamic pattern matches

A dynamic pattern is transformed into the following actions that are performed in the order of enumeration:

• Unification of the dynamic pattern and type component in a dynamic. The unification of a variable with another variable or a type constructor name will always succeed. In case of two type constructor names, their names must be the same. The dynamic library implements the unification.
• A type definition check for equally named type constructors. The dynamic linker implements the definition check and processes its results even further.

Two type constructors are considered equal if their implementations are syntactically exactly the same modulo alpha-conversion. In case of an algebraic data-type the constructor order is insignificant.

The multiple occurrence of a type pattern variable on the left hand side of a function definition can be views as a means to do unification between different dynamics.

Garbage collection for dynamics and libraries

The garbage collector collects dynamics and libraries starting from some root mentioned on the first line of the ‘rootDir.txt’-file in your Dynamics 0.1-folder. Only a single root can be handled at the moment. You need to adapt the path for your machine. The garbage collector itself is in the utilities folder.

Practical tips

Some practical tips are given below:

• There is a bug in the up-to-date cycle in the CleanIDE. Try a force recompile by shift+control+U on your dynamic projects.
• Don’t mix different releases because they are binary incompatible.

Further references

From the paper-page (http://www.cs.kun.nl/st/Onderzoek/Publicaties/publicaties.html):

Papers about dynamics:

• ftp://ftp.cs.kun.nl/pub/Clean/papers/2002/verm2002-LazyDynamicIO2.pdf

This paper describes the Input/Output of dynamics. This is called dynamic I/O. It illustrates the most interesting problems and their solutions to realize dynamic I/O.

• ftp://ftp.cs.kun.nl/pub/Clean/papers/1999/pilm99-DynTypesIFL98.ps.gz

This paper describes type dependent functions. A type dependent function can be use to enforce the static type context of the function upon a dynamic.

• ftp://ftp.cs.kun.nl/pub/Clean/papers/1997/pilm97-FstClassIOIFL.96.ps.gz

This paper introduces the notion of a dynamic and its two basic operations for the lazy functional programming language Clean.

Papers about the applications of dynamics:

• ftp://ftp.cs.kun.nl/pub/Clean/papers/2002/achp2002-GenericDynamics2.pdf

This paper describes the combination of dynamics and generics. The combination allows writing pretty printers and parser for dynamic in an easy way.

• ftp://ftp.cs.kun.nl/pub/Clean/papers/2002/vWeA2002StronglyTypedOS.pdf

This paper describes a first step towards an operating system written using Clean. It intensively uses dynamics.