''Discussion on "type" overloading issues. Remember, this query language has only 3 "native" parameter types: tables, expressions, and scalars. And, one of the goals as described in TqlDesignGoals is to allow both dedicated DB servers and small-footprint imperative API's to use the same or similar syntax. Type overloading of parameters rubs against this idea.''

Re: TqlExampleOne

  srt = orderBy(Employees, cols("dept, salary"), "order")
  top = group(srt, "dept", cols("dept, max(order) order"))
  top2 = calc(top, cols("(dept) dept2, order"))
  result = join(srt, top2, "dept=dept2 and b.order - a.order <= 5")
It might be easier to understand this query if there were a shortcut for cols(" ")
that did not take as much cognitive space. -- AnonymousDonor

It is (purposely) very similar to the column phrase in SQL SELECT clauses. The only immediate difference is the parenthesis around the first part if an alias is given. Once you recognize this pattern, SQL users should have no trouble making the leap. Example:

  SQL: SELECT a + b as zarg, m as glub, x FROM mytab....

  TQL: ...calc(mytab, cols("(a + b) zarg, (m) glub, x")...
I think the column table is a powerful yet simple meta-tool and the most novel thing about TQL. If you have specific suggestions for equally powerful alternatives, I would like to consider them. (Note that the design of TQL allows alternative syntaxes for column table specification syntax without changing the language.) Perhaps I should give the equivalent SQL in some of the examples above so that the similarity is readily identified. I suppose we could stick with the SQL column specifier syntax approach. I just prefer parentheses to the "as" (implied or explicit). It fits into the aggregate and default operation pattern seamlessly, and maps directly to the Column Table schema, providing a comfortable consistency in my opinion. I figured if we are going to replace SQL, then replace it without historical baggage. But if the difference and benefits are only minor, maybe it does make sense to stick with the original. Good question either way. -- top

The column table seems like a wonderful idea. My (possibly temporary) stumbling block is just the 'cols(' and ')' syntax. When reading it, it implies that I need to understand the cols function in order to understand the line of code. In fact, I usually do not need to think through the cols function - the argument of the "cols" table has all the information I need to understand the line of code. Maybe I will learn to ignore the 'cols(' ')' as I read the code. -- AnonymousDonor

One of the goals, and test for simplicity, is to be able to implement the language as close as possible in a "regular" language in case somebody wants a small-scale implementation. But a "naked" expression would not parse. Perhaps you are suggesting that a string be in the parameter without "col("..")" around it like this?

  calc(top, "(dept) dept2, order")
Instead of

  calc(top, cols("(dept) dept2, order"))
I suppose we could do that, but then the parameter processor needs to be able to tell the difference between a table "type" and a string. Remember that such a parameter needs a table with the necessary Column Table shape. I don't want the risks and complications associated with parameter overloading. It bumps into the implementability/parsability/portability goal. Alternative suggestions welcome. Maybe just define "c" as a shortcut to "cols":

  calc(top, c("(dept) dept2, order"))    // "c" operator shortcut
But, I won't rule out the overloading option just yet. We just have not yet found a way to do it without going against TqlDesignGoals.

-- top

------

'''Native Versus API Style'''

Note that there are two "styles": the "native style" and the "API style". The native style would be how a big RDBMS would normally see it, but the API style is designed to be used directly as imperative functions for very NimbleDatabase needs. This is part of the dual nature described in TqlDesignGoals.

Native:

 x = filter(counts, site_count > 1)
 t2 = group(srt, ((dept) dept2, max(order) order))  // perenths to avoid comma ambiguity
     or perhaps...
 t2 = group(srt, cols((dept) dept2, max(order) order))  // require "cols(...)"? ponder

API:

 x = filter(counts, "site_count > 1")
 t2 = group(srt, cols("(dept) dept2, max(order) order"))

Other possible API views:

  x = filter(counts, "site_count > 1");   // C-like API syntax

  x = tql.filter(counts, "site_count > 1");   // Java-like API syntax

  tql("x", "filter", "counts", "site_count > 1");    // A highly "internal" API

Since there may be unavoidable quoting differences between native syntax and API syntax anyhow, perhaps overloading column table parameters (for native mode) is not that big of a deal after all. Still in ponder-mode. Is this an issue that ''any'' relational languague would have to face with regard to low-scale API design/translation, or particular to Tql/Smeql? If the latter, then perhaps there is a problem with Tql/Smeql.

Or perhaps require "cols" without the quotes. Compare:

 t2 = group(srt, cols("(dept) dept2, max(order) order)") // original

 t2 = group(srt, ((dept) dept2, max(order) order)) //parenths to avoid comma confusion

 t2 = group(srt, cols((dept) dept2, max(order) order))  // column wrapper only

 t2 = group(srt, [(dept) dept2, max(order) order]) // different symbol 

 t2 = group(srt, {(dept) dept2, max(order) order}) // different symbol - curly

I'm leaning toward the '''square brackets''' right now and have updated some of the sample queries accordingly.

Or, perhaps rework it so that column specifications are always the last parameter such that extra commas are always considered part of the "columns" parameter. However, this may limit future expansion.

-- top

----
CategoryTql, TqlRoadmap