ISSUE: Aref Notation

REVISION HISTORY: Rob MacLachlan, 2 February 94

STATUS: open

CATEGORY: Addition

PROBLEM DESCRIPTION:

Currently the only way to access a multidimensional array is to use the AREF
function in function call notation:
    aref(a, i, j, k) := aref(a, i, k, j) * aref(a, i, j, kk)

This is rather verbose and unnatural to programmers accustomed to
imperative languages.  Normally all array access is denoted by subscripting the
variable with indices in brackets:
    a[i, k, j]
    a(i,j,k)

However, in Dylan, [ is already used for the generic ELEMENT collection
accessor, and ( is used for function invocation.

PROPOSAL:

Denote aref(a, i, j, k) by a[[i, j, k]].  The meaning of ( and [ are unchanged.

RATIONALE:

This proposal allows a convenient and reasonably natural notation for
multi-dimensional array access.  This is done without altering any existing
syntax or semantics in undesirable ways.  Doubled square brackets are
recognized typographical array access notation, and [[ ... ]] is used by
Mathematica.

EXAMPLES:

Before:
    aref(a, i, j, k) := aref(a, i, k, j) * aref(a, i, j, kk)

After:
    a[[i, j, k]] := a[[i, k, j]] * a[[i, j, kk]]


COST TO IMPLEMENTORS: One more construct to parse.

COST TO USERS: One more construct to learn.

PERFORMANCE IMPACT: none.

BENEFITS: 
    Improves clarity of expressions involving multidimensional array access.
    Provides a more familiar notation than function call.

AESTHETICS: Kinda cute.

FUTURE FEATURES:

DISCUSSION:

The Gwydion group spent a lot of time trying to "fix" the square bracket
notation.  Before we came up with this idea, there were three main
possibilities with no clear winner:
 -- [ is always ELEMENT, AREF must be called as a function; the status quo.  
    Convenient for code that doesn't use multi-dimensional arrays.
 -- [ is always AREF, ELEMENT must be called as a function.
    Convenient for code that uses only arrays and vectors.
 -- [ is somehow overloaded to do "the right thing" for both arrays and other
    collections. 

Most discussion centered around [ overloading, with two major variations:
  Semantic:
    [ is always some new function INDEX which does AREF if the argument is an
    array and ELEMENT otherwise.
  Syntactic:
    [ is either AREF or ELEMENT depending on the syntax inside the [].  The
    leading variant was "ELEMENT if one argument, AREF otherwise."

All overloading proposals suffered from varying degrees of unexpected behavior,
loss of power and distasteful violation of existing syntactic and/or interface
conventions.  Semantic schemes suffer from the fundamental problem that AREF
and ELEMENT do distinct useful things on multidimensional arrays.  Syntactic
schemes suffer from apparently capricious semantics of [ and from varying
degrees of ugliness.

Most people agreed that either always-AREF or always-ELEMENT would be better or
nearly as good is the best overloading proposal, but there was no agreement on
*which* of always-AREF and always-ELEMENT was nearly as good.