arrays can mix multiple data types

[BurntSushi]

I believe

No, you can't mix data types, that's stupid.

is at odds with

[ [ 1, 2 ], ["a", "b", "c"] ]

Namely, the above is an array with two elements: the first element is an array of integers and the second element is an array of strings. This is a mixing of data types.

Practically, this makes it awkward for languages whose native lists are homogeneous to read TOML correctly.

TOML allows mixing of data types at the level of the hash table. I propose that TOML not allow the mixing of data types at the array level.

[thehydroimpulse]

@BurntSushi The main array holds two arrays (same type). The inner arrays hold integers and strings respectively (same type). An array of integers has a type of array which is the same for strings.

[C0mkid]

This has already been dealt with in #29 and has been added to the spec.

[BurntSushi]

@thehydroimpulse Yes. That is clear.

@C0mkid Indeed. But I'm proposing a change to the specification. Namely, that arrays be homogeneous with respect to the type of value they contain. This means that the type of an array isn't just array but array of *type*. My reasons for this change:

1. Conceptually simpler.
2. Practically easier to work with in languages whose native list types are homogeneous.

[amadawn]

@BurntSushi I disagree. Personally I would even prefer to allow mixed arrays.

[ibotty]

it will be impossible to map untyped arrays as in the spec right now to haskell's native lists.

[ 1, 2 ] :: [Integer]
[ "a", "b", "c" ] :: [String]

so native nested lists have the type

[ [ 1, 2 ], [ 3, 4 ] ] :: [[Integer]]

and it is impossible to have the following list

[ [ 1, 2 ], [ "a", "b", "c" ] ] 

[mojombo]

Part of me wants to say that it's insane not to consider array as a type that would satisfy homogeneity, but another part of me feels your pain and wants TOML to work without hassle in as many languages as possible. I too am a fan of homogenous arrays, but damn kids these days! Will ponder.

@tnm any thoughts?

[tnm]

I guess the question is half-philosophical, half-practical. But, yes, a number of static, strongly-typed languages are going to have a hell of a time dealing, as noted above. So that's one purely practical strike against the 'mixed' form.

The more I think of it, the more I'm inclined to agree that having completely homogenous is fine. I don't see many situations where (well-designed) config files would actually want to mix sub-element types in arrays. You'll want something like:

port_groups = [ [ 8080, 8000 ], [4000, 4002] ]

or

user_groups = [ [ "admins", "owners" ], ["members" ] ]

These sorts of nested arrays in configs are (almost) always of the same type, through and through.

So I don't see very much practical benefit in the mixing, and probably not enough to justify the added complexity on implementations.

[ibotty]

or you go the other way around and support mixed arrays as well:

uid_users = [ [ 0, "root" ], [ 1, "bin" ] ]

is very useful as well...

[tnm]

@ibotty — That's a great example. So an array where all sub-arrays are of the same 'tuple'-esque type (even if different from the enclosing array) might be reasonable, while an array of completely mixed type sub-arrays does not seems reasonable.

[ibotty]

hmm. i thought, that's an example pro just be lax in everything. but of course, you are right. (i like my models well typed :D)

i'm not sure what you mean about signature. is that something akin to types (as in my first comment)? because if so, my uid_users example cannot be typed. if signature is like a signature of a record (struct), we open a whole can of worms (record syntax).

another thing you might want to express is the following.

search_terms = [ ["rick", "roll"], ["wat"] ]

where the first array has the signature (as in the second meaning) string + string and the second only string. so search_terms would have to be interpreted as array of string arrays instead.

imho it's only reasonable to simply have no typing constraints on array members or easy to satisfy constraints (as in one of the two meanings here).

[BurntSushi]

@ibotty The example you've chosen is an association list, which can very easily be represented at the level of a hash (with some trade offs):

[uids]
0 = "root"
1 = "bin"

Allowing tuples would be great, but I propose we not pretend that they are arrays. i.e.,

uid_users = [(0, "root"), (1, "bin")]

Note that [ ["rick", "roll"], ["wat"] ] is well typed. The type of a list is not defined by the number of elements it contains.

[ibotty]

i know that this example can be made into an association list. but without any shorthand syntax for those there will be instances where this will be cumbersome. i like your tuples idea. i have not checked whether it's already in the bugtracker. if not, it would be great if you can propose them.

of course [ ["rick", "roll"], ["wat"] ] is well-typed. i meant to say that this 'signature' idea from this bug does not work for that case. that was my whole point.

going forward, i guess we just need a decision.

[BurntSushi]

of course [ ["rick", "roll"], ["wat"] ] is well-typed. i meant to say that this 'signature' idea from this bug does not work for that case. that was my whole point.

Ah, I'm not sure what a signature is. But I think I see now, You're saying that if we intermix arrays with tuples, then [["a", "b"], ["wat"]] would be disallowed. Right? Makes sense.

[ibotty]

yes. that's right. (sorry, english is not my primary language. not secondary either :D)