This RFC is an early probe, and is only being sent to 2 discussion
lists for now, dbi-users and poop-group. If necessary, I may derive
a better version later for wider dissemination, based on your
feedback.
In the course of my rewrite of the Rosetta database access framework
(started on October 1st), the system has evolved so much that it is
now based a lot more on relational algrebra than on SQL, and I am now
doubting that the major component named SQL::Routine should keep that
name.
To put things in context, the main purpose of "SQL::Routine" right
now is to define a language, similarly to the purposes of the Perl 6
Synopsis, but that it also provides objects to store something akin
to a parse tree of it; I say "akin" because the tree is actually the
native form; there is no native string version like Perl 6 is.
Continuing this context, the main purpose of "Rosetta" is to be a
federated implementation of that language, similarly to what
Pugs/Parrot do.
This RFC is concerned with whether SQL::Routine should continue with
its current name or be rebranded into a different name that doesn't
contain 'SQL' in it, and is otherwise more appropriate to its altered
direction.
Part of the issue is that the new system is meant to be centered
around the concept of a "truly relational" database, such as Codd,
Date, Pascal, Darwen, etc promote, rather than the "sort of but not
really relational" model of a database that SQL describes. While it
is popularly thought that SQL = Relational, there are strong
arguments from serious database people that say otherwise.
I want to distance my project from the word 'SQL', using the term
only to indicate something in a similar problem domain to my project,
also taking examples for the purpose of explanation; I do not want to
say that my project *is* a SQL model or implementation.
Now, while a lot of influence is taken from the SQL language, various
database products implementing flavors of it, languages like Tutorial
D, and even the Perl 6 language itself, and other mathematics, the
language of my project is my own new language in the end. It is
sufficiently different than SQL that it shouldn't have 'SQL' in its
name, just to not confuse users if nothing else.
At the same time, still focused on serving the interests of both
portability and practicality, my language still supports all the
significant concepts of SQL that are frowned upon by "truly
relational" people, such as nulls and duplicate rows, but you have to
explicitly indicate that you want to use them, and in the absense of
that, relations can not contain duplicates or nulls. Both types of
behaviour can be mixed; it is the data types that you choose to use
on a per-container or per-value basis that determine whether those
are allowed. The distinct data types in question are implemented
separately, and the ones not allowing nulls or duplicates will happen
to be simpler and perform faster, since there is less logical
complexity to deal with. So both "truly relational" and "SQL" people
can have their cake and eat it too. And porting between the both
types (and other types) of systems can be accomplished with little
trouble.
For some details of the new language, see either of the following
(they are not on CPAN yet):
1.
http://svn.openfoundry.org/pugs/ext/Rosetta-Incubator/lib/SQL/Routine/Language.pod
2. http://svn.utsl.gen.nz/trunk/Rosetta-Incubator/lib/SQL/Routine/Language.pod
That document is in the process of being written right now, but a
substantial portion already exists. By the time you see this RFC,
more may be done. See also the DESCRIPTION pod of lib/SQL/Routine.pm
and lib/Rosetta.pm in either repository.
Now, the documentation currently refers to the language as "the
SQL::Routine language", but that seems very cumbersome. What I
really want to do is come up with some new catchy and/or descriptive
name for the language that I can use by itself as a noun, and people
generally know what I'm referring to. Eg, just as people can say
"Perl 6" or "SQL" or "Tutorial D" and readers just know that those
are language names, I want someone to say "<Foo>" and it is fairly
unambiguous that this is a language name, and not, say, just a module
name.
The main kind of feedback I need is, what a good *language name*
would be for what I'm making here. The new name of the module can be
determined afterwards, and be derived from the language name.
The name of the language should say "relational" or "relational
database", but not so much just using those words, since they are too
generic and are used as adjectives everywhere. It could just be a
catchy made up name or acronym too. Being short is good. (Note that
I can't use "Rel" as a name since its already in use by Dave Voorhis'
project at http://dbappbuilder.sourceforge.net/ . It shouldn't be
the same name as any other project either.)
Moreover, I suspect that the renamed module should perhaps be
reclassified on CPAN to a different category than "string language
processing"; perhaps it should go where ever PPI is classified,
though I don't know where that is, or perhaps where PDL is, or
perhaps under "database interfaces" even though it only defines one
and doesn't implement it. (In any event, Rosetta sits under
"database interfaces" and will reference it.)
Thank you in advance for the feedback.
-- Darren Duncan
P.S. The chosen names would be used for and identical in the perl 5
and perl 6 versions of this.
