Arrays in LC [was: Re: [TAO] value() to obtain pointer functionality]

[Earthednet-wp]

Richard,
I'm still pretty new to livecode, so my first exposure to LC arrays left me a bit skeptical. I am an experienced Director programmer and had gotten very fluent with lingo "property lists", which is the closest analogy to the LC array. In Lingo (Director's main language), there are statements like x=getaProp(stuff) and setAProp(stuff), and several others to access, set, sort, and manipulate this entity.  After using lc's arrays, I grew to appreciate their compact, much more intuitive, syntax. "Put myValue into myArray["whatever"]" is much easier to remember than "setAProp" and a heck of a lot more intuitive. I did like Director's dot notation, tho.

Regarding truly indexed arrays, they would be most useful, it seems to me, if there is a speed advantage for matrix operations, where a numerical indexed array might be faster to access than one based on string keys. Functionally, the behavior of indexed arrays, where deleting an entry would adjust references to higher numbered entries might be an advantage if one was trying to convert matrix manipulation libraries from other languages, to LC. Building these matrix functions into a LC app, using LC code, is not difficult and there are numerous sources for routines in various languages. To me, matrix operations seem pretty specialized, outside of lc's area of strength. These routines could also be implemented as xtras, for the special applications that need them and require highest speed. Building them into the engine doesn't seem a high priority.

I feel that there are many more high priority needs for LC than building matrix operations into the engine, which can be easily implemented as functions in LC talk.

My humble opinion.
Regards,
Bill

William Prothero
http://es.earthednet.org

> On Aug 20, 2014, at 7:24 AM, Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> Across many programming languages we see two primary types of arrays: indexed and associative.
> 
> Both are useful, each with their own strengths and weaknesses.  Neither is broken, and nether is a complete superset of the other.
> 
> All arrays offer a single variable as a collection of pointers to values, in which each value can be obtained much more efficiently than can be done with lists.
> 
> We could think of arrays as name-value pairs, in which the name is the key and the value can be nearly anything, including strings, binary data, or even another array.
> 
> When an array element's value is itself an array, the common notation for this is to use another set of brackets to address the sub-array's elements, e.g.:
> 
>  put MyArray[1][2]
> 
> You can also conveniently extract the subarray if you want to work on it outside of its containing array:
> 
> put MyArray[1] into tAnotherArray
> put tAnotherArray[2]
> 
> Indexed arrays use numeric values as their keys, while associative arrays use strings.
> 
> One feature indexed arrays offer is that their keys reflect a certain ordinal relationship which adjusts itself on the fly to accommodate deletions.  That is, if you have an array with three elements numbered 1,2, and 3, and you delete element 2, what was element 3 is now in the #2 slot.
> 
> But because associative arrays allow nearly any string to be the key, we can have keys comprised solely of numerals to achieve most useful results from indexed arrays, and a whole lot more.
> 
> Both associative and indexed arrays can include things like:
> 
>   get MyArray[1]
>   get MyArray[2]
>   get MyArray[3]
> 
> ...but only associative arrays can use strings like:
> 
>  get myArray["bob"]
>  get myArray["mary"]
>  get myArray["steve"]
> 
> While associative arrays are not truly a superset of indexed arrays, they support such a broader range of applicable use cases that they made a good choice for a first implementation of arrays in LiveCode (or back then, "MetaCard").
> 
> However, given an indexed array's unique ability to adjust its keys during delete operations, it could be useful to add something like indexedArray as a new data type.
> 
> The trick then becomes, "How do we declare when we want an indexed array?"
> 
> Currently we just put values into variable slots within brackets, and the engine sets up the hash and pointers and all the rest so we don't ever need to explicitly declare that we want an associative array.
> 
> So if we were to propose that LiveCode add indexed arrays, the first thing we'll want to do is come up with the syntax for specifying those when those are what we want, ideally allowing all other usage to continue using associative arrays as they have all these years.
> 
> Suggestions on what that syntax should look like?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode