Name this package

[davidagold]

A number of people have suggested this package ought to be renamed. @dmbates gives a good summary of the justification here. That was always the plan. I suppose it ought to happen sooner rather than later. So! Suggestions are more than welcome in this thread.

[ararslan]

The name alludes to Hadley's notion of dplyr as a "grammar of data manipulation", rather than a specific design spec.

DataGrammar.jl? ¯_(ツ)_/¯

[nalimilan]

Not a big fan of DataGrammar, which sounds a bit obscure for newcomers. DataManagement? DataQueries? DataTools? DataFlows? Plus the same series replacing Data with Tables.

We could also imagine merging the package into DataStreams when it's ready.

[davidagold]

I prefer Select.jl over all of these.

Why should this go into DataStreams?

Edit: Queries.jl would be nice, too. Or Inquire.jl.
Double edit: Just realized "inquire" rhymes with "dplyr", which makes me like it even more =p

[dmbates]

select already has a meaning in base Julia

help?> select
search: select select! selectperm selectperm! set_bigfloat_precision

  select(v, k, [by=<transform>,] [lt=<comparison>,] [rev=false])

  Variant of select! which copies v before partially sorting it, thereby returning the same thing as select! but
  leaving v unmodified.

julia> methods(select)
# 1 method for generic function "select":
select(v::AbstractArray{T,1}, k::Union{Int64,OrdinalRange{T,S}}) at sort.jl:69

[ararslan]

I think @milktrader had some ideas. Now's your time to shine!

[davidagold]

@dmbates Can you pun a Base method with a package name? I never really thought that an issue. In any case, your logic applies even more so to the actual command @select we export from this package, but I don't intend on renaming that. (Though similar packages in other languages call such a manipulation project, which I don't mind.)

[milktrader]

Okay, since this is on topic. I've got a clever name in mind and maybe it can generate some other ideas if nothing else.

Mercury.jl

Mercury is used to pull gold from rocks.

[milktrader]

There is precedence for naming packages after elements from the periodic table:

Gallium.jl

Can't remember where Mercury and Gold fit in the periodic table?

[nalimilan]

I'd prefer a more explicit name (Gallium itself might be a temporary name until the debugger is finished). Select.jl has the drawback that it's only the name of one operation, and there's much more in the package.

Why should this go into DataStreams?

@davidagold Because they both provide backend-agnostic support for working with data. But that was just a suggestion.

[davidagold]

@nalimilan Though select is representative of querying on the whole -- in SQL, the other commands represented in this package are clauses of a SELECT statement. Of course, this is all modulo two-table commands, e.g. join, which I do intend to support. (But maybe they go in Join.jl =p)

I think the functionality provided here is sufficiently different from that in DataStreams that they warrent different packages. The strategy DataStreams takes towards backend agnostic-ness is also quite different.

@milktrader I think Mercury may be too easily confused as relating to the Mercurial SCM. =/

[johnmyleswhite]

RelationalAlgebra.jl is probably the name that most closely represents the goals of the package as I understand them.

[davidagold]

@johnmyleswhite though that's also kind of obscure to folks of different backgrounds. I guess that doesn't matter so much if the package is included in DataFrames or whatever tabular data package folks will be using.

[johnmyleswhite]

If your goal is to ensure no one expects too much from your work, giving it an obscure name seems like a good strategy.

[garborg]

Relational algebra seems right for the core common API, so it's great to hear that's in the works.

I don't know of a term for 'relational algebra as applicable to tables' (tables not being 'relations'), but people mostly talk about it in relation to tables, so the name evokes tables just fine.

[bramtayl]

PanQuery? Or AbstractQuery?