Notes and comments about the implementation of SmeQl (or lack of).
-------
Is there an implementation in the works? -AnonymousDonor

''You know, I started working on a proof-of-concept implementation using ExBase, but found that dealing with column types and lengths for schema-creating operations such as joins was a bit of a pain. I am now considering using it to help demo a DynamicRelational database such that column types and lengths are not an issue. As a short-cut from parsing I was going to implement it using "query tables" with a structure resembling: ''

* table_alias
* operation
* parameter_1
* parameter_2
* parameter_3 ...

Thus, something like this:

  a = filter(j, b < c)
  b = join(a, x, q = b.z)
  orderBy(b, r)

Would be:

  Seqnc.|Alias...|Operator|.p1.|..p2..|.p3
  ------|--------|--------|----|------|-------
  ...1..|a.......|filter..|.j..|.b<c..|
  ...2..|b.......|join....|.a..|.x....|q=b.z
  ...3..|(blank).|orderBy.|.b..|.r....| 
  ...4..|(blank).|orderBy.|.b..|.r....| 

[Reworked with periods to avoid TabMunging]

I realize that such is a bit odd, but it is visually easy to use. Also, those who prefer the nested approach may not want it represented this way. But, it was intended for experimentation, not production work. (As far as whether sequence numbers turn it into an inherently imperative language, see TqlChainedJoin.)

--top

A "run" operation could perhaps be included to run a table like the above as a SmeQl query set. However, it probably should not be enabled as a default permission level because it's also an injection hacker's gold-mine. -t
   result = '''run'''(table_with_list_of_operations)

-----
Can SMEQL code be compiled entirely to SQL, or will a full implementation require some kind of intermediary layer? --AnonymousDonor

An interesting question. The ability to create temp tables may be needed to get around syntax translation/convention differences. And, the sequence number of the Sort operation may be difficult in many SQL dialects.  

Actually, I've been thinking of a quicker way to use SQL to implement it, or at least create a proof of concept, by ignoring efficiency. Each statement would essentially use an INTO clause to create a temporary table with the name of the "receiving table", or at least as a suffix. 

Another approach is to generate nested SELECT clauses, but some RDBMS have a nesting limit. But then again, this would be mostly a proof-of-concept during the first go-around anyhow.

Another problem is that many dialects lack sequencing by ordering, limiting implementation of the orderBy() operation.

More to come...

4/2009 - Kicking around ModernizingExBase reminded me of SMEQL's finer decomposability (smaller granularity) than SQL. These two "projects" might be related (SolutionsSought).

--top
--------------------------
'''Optimization Example'''

Take the following example:

  x = (table01, 
  Under construction...

-------------------
See also: ExperimentalQueryLanguageDiscussion