On 2015-06-16 11:44 AM, James K. Lowden wrote: > On Tue, 16 Jun 2015 09:56:38 +1000 <david at andl.org> wrote: > >> The question is: what should a database language do? Andl can already >> match or surpass SQL on database programming tasks, but is that >> interesting enough? >> >> What would make a database programming better, or best? > > Two things I've often pointed to are namespaces and regular > expressions. Another is compound datatypes. > > SQL and C both suffer from a single variable namespace. We get around > it by using prefixes, e.g., "local_memcpy" or "annualized_returns". > > C++ added namespaces to the language. I suggest SQL's successor do the > same, but use the Unix filesystem's hierarchical namespace as a model. > Putatively,
SQL in general actually DOES have namespaces in practice, though they are fixed-depth rather than variable-depth. Depending on the DBMS, you have the "catalog" level, the "schema" level, the Oracle "package" level, and then your functions and tables etc have otherwise unqualified names beneath those. Depending on the DBMS, each of those levels may exist or not, but the number of levels is fixed, that part unlike the Unix filesystem. I think the SQL standard specifies catalog/schema/object itself. For my part with my database-savvy Muldis D programming language (that I hope to have executing within a few months), namespaces for both routines and relations (tables) etc are arbitrary/variable depth like you propose, like either the Unix file system or like programming languages such as Perl or C# or others. Note that Muldis D and Andl have some influences in common, but David beat me to market as it were with an executable. -- Darren Duncan
