Initial attempt at supporting collections of arbitrary types as keys

[rofinn]

• Keys can now be an AbstractString or Vector{T}.
• Needed to adjust the parameterization of the Trie type and some of its constructors.
• Added some tests for Vector{Symbol} and Vector{UInt8} keys.

[oxinabox]

How about the following, append_key
so keys can be any iterable.

julia> append_key(prefix::K, x) where K = K([collect(prefix); x])
append_key (generic function with 1 method)

julia> append_key("abc",'c')
"abcc"

julia> append_key([1,2,3],2)
4-element Array{Int64,1}:
 1
 2
 3
 2

[rofinn]

That would work, but it results in extra allocations in the string condition.

julia> using BenchmarkTools, Compat

julia> append_key1(prefix::AbstractString, x::Char) = string(prefix, x)
append_key1 (generic function with 2 methods)

julia> append_key2(prefix::K, x) where K = K([collect(prefix); x])
append_key2 (generic function with 1 method)

julia> prefix = "abc"; x = 'c'
'c': ASCII/Unicode U+0063 (category Ll: Letter, lowercase)

julia> @btime append_key1($prefix, $x)
  35.271 ns (1 allocation: 32 bytes)
"abcc"

julia> @btime append_key2($prefix, $x)
  10.688 μs (48 allocations: 1.80 KiB)
"abcc"

NOTE: Did a similar check for arrays and it's about the same between the two implementations.

Maybe it would make sense to special case strings for now and make that the fallback?

[oxinabox]

Seems reasonable

[oxinabox]

To be clear
for the usage I proposed in andrewcooke/ParserCombinator.jl#20
it needs to support arbitrary iterators as keys (not just tuples, strings and vectors).
At least for look-up (if not for set) purposes.

[rofinn]

Okay, I guess since julia doesn't enforce the iterator interface we could just not have a type requirement on the key. Do you have a minimal example of the type of iterators you're working with?

[oxinabox]

I don't have a minimal example, because it is explicitly iterator.
For an example maybe use zip

[rofinn]

Okay, I don't really know how to make this work for arbitrary iterators easily because the supported constructor syntax seems to vary significantly by iterator. With the existing architecture we require that we can constructor the iterator type w/ 1) an empty constructor and 2) that splats the existing iterable with a new element.