The concepts that I will attempt to describe have as objective to
provide a query language that could sit on top of an SQL database.
Say we had a list of atoms (table columns), functions and relations.
Say there was a database schema that would describe the relations (many
to one, functional) between those atoms.
To specify a query; atoms, functions and relations would be listed in
line. This line would effectively be a result set definition
atom1 atom2 function1 atom3 relation.
There is no specific order to the items in the result set. Functions
would be able to look at the values types and names of the atoms for
each row set, and return a value. relations between atoms should only
be specified when the set of atoms had more than one relation
available.
This first part is the main concept, below is more detail to try to
grow this concept.
I see 4 areas where the previous concept needs to expand: context,
naming, conditions and functions.
Context: Normally the names of the tables are required to know what
columns are available on a SQL database, I pretend that a more loose
context name would be used to make atoms, functions and relations
available for the query. Several contexts should be possible. Perhaps
these context would group a wider number of atoms than a table does and
include some named relations too. I think that the reference of two
contexts would not nesesarily make available the union of all of each
context members.
Naming: Aliases are used in SQL language to allow for different
independent references to one table on the same query. Perhaps in this
case aliases could be done at the atom, function and relation level to
allow independent references.
Functions: Currently I have three ideas on how they might behave in
this "Language" they could look at types/categories preasigned to each
atom, and look for several type/category patterns to find out which
atoms will be the parameters to the function. Alternatively they could
look at the atom names instead of preasigned types or categories.
Conditions: Conditions placed on the result set filter the amount of
data that will be brought back from the database. I would like to
expand this concepts to clarifications. Functions might have more than
one set of items to evaluate from. Extra lines of code could be used to
clarify what are the correct bindings for a particular function. Any
other binding that might be unclear would be made clear in this
section.
Disclaimers :)
This are literally several concepts that I have in my head and a lot of
work needs to be done if this concepts were going to be used to make a
query language.
My motivation is to find a "more" powerful and user friendly language
than SQL.
The reason why I posted this on a LISP group is because the query would
be written as a list of words, and it reminded me of LISP. Also I think
LISPers are probably more amenable to this kind of subject than other
programmers.
I ask for some forgiveness in my choice of terms, as I write more about
this subject I'll try to find better terms that these.