I second the vote for a YAML library. It makes text and arrays work
together a lot better than JSON.
The way I've been tracking arrays in text for documentation purposes is
basically just a table at heart:
array[first-key][this-key] = whatever
array[first-key][that-key] = foobar
array[2nd-key][some-key] = data
array[2nd-key][another-one] = more data
array[3rd-key][sub-key][new-level] = fake data
array[3rd-key][sub-key][next-level] = probably also fake data
array[3rd-key][sub-key][here-we-go-again] = totally the real data
Usually I'll omit the redundant text, which helps me think of it as a tree
array[first-key][this-key] = whatever
[that-key] = foobar
array[2nd-key][some-key] = data
[another-one] = more data
array[3rd-key][sub-key][new-level] = fake data
[next-level] = probably also fake data
[here-we-go-again] = totally the real data
On Thu, Aug 11, 2016 at 6:14 PM, Richard Gaskin <ambassa...@fourthworld.com>
wrote:
> Quentin Long wrote:
>
> > I don't know if there's a command that will do the job. However,
> > there's a construction I use when I merge two list variables into one:
> >
> > put ItemList2 into item (1 + the number of items in ItemList1) of
> > ItemList1
> >
> > That construction may seem a little weird, but it does the job. So
> > *if* the same sort of logic applies to arrays, something like this
> > might do the job:
> >
> > function ConcatArray Array1, Array2
> > -- if this was a real function, it would confirm that Array1 and
> Array2 are both, you know, *arrays*
> > put the number of lines in the keys of Array1 into A1
> > put the keys of Array2 into key (A1 + 1) of Array1
> > return Array1
> > end ConcatArray
>
> The "*if*" there is critical, as strings (LC lists) do not work like
> arrays.
>
> I'm not sure of the specifics of LC's implementation, but this general
> discussion may be useful:
> https://en.wikipedia.org/wiki/Associative_array#Implementation
>
> In brief (and woefully oversimplified), we could conceive of an array as a
> collection of memory addresses, in which each address is derived from a
> hashing function applied to the key.
>
> This is why when we try to display an array in a field it shows empty -
> there is no single string for the array data, its contents instead spread
> across multiple locations linked together through pointers. Indeed, given
> that arrays can be nested, it's non-trivial to come up with a string
> representation to meaningfully represent them.*
>
> In contrast to the actual structure of an array, using the keys function
> does return a string, a return-delimited list of the key names. But the
> creation of that string is copying the keys from the actual array
> structure, and not the structure itself.
>
> So given an array which we could notate as:
>
> Array2/
> key "a" = value "SomeValue"
> key "b" = value "SomeOtherValue"
>
> ...the line above that reads:
>
> put the keys of Array2 into key (A1 + 1) of Array1
>
> ...would first get a string comprised of copies of the key names, like
> this:
>
> a
> b
>
> ...then add 1 to the number of lines there to get 3, and then use that as
> the string list of key names as the value of element Array1[3]
>
> That is, if the syntax "...into key <keyName> of <arrayName>" was
> something LC did - using LC we'd need to write that as:
>
> put the keys of Array2 into Array1[A1+1)
>
> But while that modified line would execute, it still won't do what we want
> here. It applies a return delimited string of key names as a value to a
> single element, and what we're looking for is a method of bulk copying the
> actual array elements.
>
>
> This post may seem tediously long and pedantic, but bear with me, as I
> think we're discovering an opportunity for an enhanced array tutorial.
>
> The conceptualization of the role of array keys here closely matches one
> we saw a couple weeks ago on this list, in which a very experienced
> developer was attempting to use the keys of an array as a sort of bulk
> copying method for the array elements.
>
> Whether we have a good means of doing that bulk copying already (union
> seems useful here) is less interesting to me than the conceptualization
> itself. There may be value exploring ways we might make the
> conceptualization of arrays more closely match their actual structure,
> hopefully making it easier for us to anticipate how the various syntax for
> arrays can and can't be used for a given task.
>
> Many years ago Dar Scott put together a wonderfully animated tutorial on
> LiveCode (then "Revolution") Message Mechanics, available here:
> http://pages.swcp.com/dsc/revstacks.html
>
> I wonder if we might have a similarly inventive soul among us who may be
> able to deliver something as nice for explaining array structure.
>
> As with Dar's stack, this may well be a case where illustrations, esp.
> animated ones, might help far more than any explanatory text alone.
>
> Arrays are among the more abstract things in LiveCode, a language
> otherwise characterized by an ease of learning afforded through more
> concrete structures (objects, chunks - things we can see). But arrays are
> so useful in so many contexts that it seems an excellent tutorial would be
> a welcome addition to our community learning resources.
>
>
> * The challenge of representing associate arrays in a textual form is
> infamous; doable, but cumbersome. JSON is the most popular way to do this,
> but being designed specifically for the JavaScript engine it's notoriously
> tedious to parse in anything other language. YAML offers a much more
> human-readable/writable alternative, though less commonly used.
>
> Now that JSON is included in LC 8 we do at last have a common means of
> translating LC's associative arrays to and from textual form. But for the
> sake of readability, it might be nice if there was a common YAML library
> available as well.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
