Log of Changes for ATS/Anairiats

In this page, we list some important changes made to ATS/Anairiats. In particular, we report changes made to the grammar of ATS.

Changes

Date: 2007-09-13

The sorts for boxed types and viewtypes are introduced. We now use type and viewtype as the sorts for boxed types and viewtypes, respectively. For unboxed types and viewtypes, the sorts are t@ype and viewt@ype, respectively.

Here are two type definitions for boxed and unboxed pairs of integers:

stadef int2_box: type = '(int, int) // boxed tuple
stadef int2_flt: t@ype = @(int, int) // flat tuple

Date: 2007-11-25

For a function declaration, the default function kind is now function (FUNCLOfun) instead of closure (FUNCLOclo). For example, The following function declaration assigns foo the type T1 -<fun1> T2:

fun foo (x: T1): T2 = ...

We use fun1 to indicate that foo is function potentially of (full) effects.

In order to assign a closure type to foo, the function kind annoation needs to be supplied as follows:

fun foo (x: T1):<clo1> T2 = ...

We use clo1 to indicate that foo is closure potentially of (full) effects.

Date: 2007-12-09

For each constructor associated with a dataviewtype, we can use refvar patterns to gain access to both the locations of the arguments of the constructor and the views associated with these locations.

In the following example, we first declare a dataviewtype for linked lists:

datatype list_vt (a:viewt@ype+, int) =
  | {n:nat} list_vt_cons (a, n+1) of (a, list (a, n)) | list_vt_nil (a, 0)

We then implement a list traversal function foreach_list_vt:

fun{a:t@ype} foreach_list_vt {n:nat} ..
  (f: (!a) -<f> void, xs: !list_vt (a, n)): int n =
  case+ xs0 of
  | cons (!x, !xs) => (f (!x); foreach_list_vt (!xs); fold@ xs0)
  | nil () => ()

The patterns !x and !xs are refvar patterns. If a list matches the pattern cons (!x, !xs), then the pointers pointing to the head and tail of the list are stored in x and xs, respectively, and the views associated with these pointers are automatically absorbed into the proofstore.

Date: 2008-03-30

Closures are classified into linear closures (cloptr) and persistent closures (cloref). This is a great change, resulting in global impacts on ATS statically as well as dynamically. With linear closures, it becomes possible to support high-order functional programming in a situation where the memory footprint of a program must be kept minimal.

Date: 2010-05-12

ATS/Proto, the first implementation of ATS, supported object-oriented programming (OOP). So, it was naturally assumed that OOP should be supported in the following implementations of ATS, and there was a lot of work done to prepare for incorporating OOP into ATS/Anairiats. However, after a long struggle (for several years), I have decided to abandon the plan to directly support OOP in ATS as this would simply make ATS overly complicated. However, indirect support for OOP in ATS is fairly easy to achieve. For instance, the API for GTK in ATS is done in the OOP-style. The plan to have an OOP-style module system in ATS is now on hold.

Date: 2010-08-13

Linear strings (strptr) are now supported in ATS. Most string-generating functions return linear strings. If needed, a linear string can be readily casted into a persistent one by calling string_of_strptr.