SLSB is an extension of the SQL framework. You should be able to use SQL normally, but with additional functionality. The main things this extension implements are:

• The ability to store/access "metrics", which are essentially a predefined set of instructions to retrieve a set of columns from a set of rows, and then append those columns to an another set of rows (existing or derived).
• FOR EACH functionality, similar to that found in other programming languages
• CHAIN commands, which allows you to easily combine several metrics
• Shortened function syntax
• Ability to dynamically add additional sql, based on the commands you enter.

The below represents the syntax as it is likely to evolve. The current syntax is an alternative to SQL, but the project is moving away from an alternative, and towards an extension of SQL.

ADD METRIC //name 
TO //table
JOINS //conditions
INDEX(//indices);

*This command appends a predefined set of columns to another set of rows (existing or derived), and stores the result to a table add_metric_name_. *

CREATE METRIC //name AS 
COLUMNS //col1, col2 , col3
FROM //data source, can be either explicit or derived table
JOINS //suggested joins
INDICES(//indices)
ADD TO //collection
DESC: "//desc";

This command creates a new metric for later use. It stores columns, a data source, suggested joins and indices, and storing it a collection of the user's designation (user's personal library by default, with an optional description).

FOR EACH (//thing1, thing2, thing3)
DO //sql where <each> represents the object;

This command performs some SQL code for a number of different values.

CHAIN //metric1 a, metric2 b, metric3, c, etc... e
TO //table
JOINS //conditions
INDEX(//(indices));

This command chains several metrics together, appending the resulting columns from all metrics to another set of rows (existing or derived), using a set of specified joins. If aliases are not provided, the metric_name is the default alias. Any indices specified will be used as the indices in the final table, otherwise the distinct indices from all the metrics will be used.

arg/f, such that f is the abbreviation for one of the following transformations:

/c = count(arg)
/m = multiset
/v = volatile
/t = temp
/s = sum(arg)
/a = avg(arg)
/min = min(arg)
/max = max(arg)
/left(n) = left(arg, n)
/d = distinct
/in(n1, n2, n3...) = IN(n1, n2, n3)
/nin(n1, n2, n3) = NOT IN (n1, n2, n3)
/lk('thing') = LIKE 'thing'
/lk_any('thing1', 'thing2') = LIKE ANY ('thing1', 'thing2')
/nlk('thing') = NOT LIKE ('thing')
/nlk_any('thing1', 'thing2') = NOT LIKE ANY ('thing1', 'thing2')
/bt(start, end) = BETWEEN START AND END
/as(name) = AS NAME
/cast(spec) = CAST(arg as spec)

Additionally, transformations can be combined, such that:

/m+v = MULTISET VOLATILE
/d+c = COUNT(DISTINCT arg) 

Where the args are processed in order, with each transformation being applied to the result of the transformation before it.

You can also set up default code to be placed before/after specific types of commands. For example, you could choose to place the SQL:

Before

--drop table %table;
--help table %table;

After

collect statistics on %table column(%indices);

Before and after all of your CREATE TABLE (and ADD METRIC, CHAIN) commands, to allow for easier debugging, modification, and better efficiency.

Or you could add some comments, making it easier for others to follow your work.

To reference clauses in your SQL stmts, you can use the following:

%table = the table name
%indices = the table indices
%columns = the column names in the table
%from = the aliases/table names of the sets referenced