Lambda the Ultimate

I don't know of any other language off hand that has similar syntax. That syntax looks pretty good at first glance. The auto-ids are maybe a little awkward repeating the placeholder, perhaps a modifier keyword during the column definition?

var animals = table(auto self:Id, animal:String, sound:String, legs:Int)
  {
    "Dog", "woof", 4;
    "Cat", "meow", 4;
    "Human", "hello", 2;
  };

Perl:

$animals = {
    Dog => {
        legs => 4
    }
};

print $animals->{Dog}->{legs}; # -> 4

Javascript:

animals = {
    Dog : {
        legs : 4
    }
};

alert( animals['Dog']['legs'] ); // -> 4

It might be a good idea for you to allow folks to control the auto-generation of ids w/ an algorithm. The sigil $ is fine, but in my experience what I want the most is the ability to, when quickly scripting things, say, "start an identity insert with this seed and this increment value". The same task in TSQL requires constructing a temporary table with an identity column, and there is no analagous solution in C# w/o hacking the compiler and AST to provide a special compiler service.

In C++, I could do this using macros and template metaprogramming... but the resulting code is hard to read and difficult to debug.

I would take a look at how Lua handles this. It's fairly flexible, although it's not exactly what you want.

val animals = Table('animal -> classOf[String], 'sound->classOf[String], 'legs->classOf[Int])
{
("Dog", "woof", 4),
(Cat", "meow", 4),
("Human", "hello", 2)
};

val animals = Table('self->classOf[Id], 'animal -> classOf[String], 'sound->classOf[String], 'legs->classOf[Int])
{
($, "Dog", "woof", 4),
($, "Cat", "meow", 4),
($, "Human", "hello", 2)
};

In which case the $ is a no-arg method call returning a unique ID each time. You'll need to define one or more of your own, and plug in the right one via an import.

Identifiers are useful for describing relationships in tables and graphs, but if you're going to support them you'll need to handle a few use-cases:

• How do you introduce relationships between entities within the literal?
• Can you introduce relationships on identity between two literals produced together? I.e. suppose you broke the above table into three tables: animal(ID -> String), sound(ID -> String), legs(ID -> Nat). How, in this case, do you ensure corresponding identifiers upon construction of the literals? Is this relationship somehow maintained as the literals are distributed?
• How do you combine literals that were produced independently without collisions in identity? i.e. given two literal tables with identity, produce their union, perhaps with a few relationships or edges between them.

Things get a bit more complicated if you want referential transparency with these identifiers, and yet more so if you want isomorphic identity, such that a graph described by points arbitrarily labeled A B C may be semantically identical to a graph described by points arbitrarily labeled X Y Z. Isomorphic identity helps divorce "how was this graph created?" from "what does this graph mean?".

I've been pondering this off and on for a while. The tentative solution I've been favoring involves introduction of a space/point concept. Points exist only in a given space, and spaces are compared isomorphically. There is a special primitive for mapping a function into a space, at which point it can compare points for equality or wrap points into a new space, but cannot export them. A 'space' literal produces a named function that takes arbitrary labels and produces points. I.e. {space S: (vertices:{set [{S a} {S b} {S c}]} edges:{set [({S a} {S c}) ({S b} {S c})]})} is semantically identical to {space X: (vertices:{set [{X 1} {X 2} {X 3}]} edges:{set [({X 1} {X 3}) ({X 2} {X 3})]})}.

define AnimalDB = {set 
{map@list \(X Y Z)=>(animal:X sound:Y legs:Z) [
  ("Dog" "woof" 4)
  ("Cat" "meow" 4)
  ("Human" "hello" 2)] 
}}

define AnimalDB_wID = {space S: {set 
{map@list \(X Y Z)=>(self:{S X} animal:X sound:Y legs:Z) [
  ("Dog" "woof" 4)
  ("Cat" "meow" 4)
  ("Human" "hello" 2)] 
}}} 

;; it's a tad pointless to use ID at all 
;; unless you use it in a relationship somewhere.
define AnimalDB_Alt = {space S:
{set [
   animal({S 0} "Dog")
   animal({S 1} "Cat")
   animal({S 2} "Human")
   sound({S 0} "Woof!")
   sound({S 1} "meow")
   sound({S 2} "hello")
   legs({S 0} 4)
   legs({S 1} 4)
   legs({S 2} 2)        ]}}

I've recently been favoring 'sets' over 'relations'. A set of labeled records could contain many relations (one per label) and thus serve as a whole database. Compared to a record of relations, sets of labeled records have been more convenient for structural typing and syntactically datalog-style relational queries (where the output may involve as many relationships as the input). YMMV.

This design is aimed at referential transparency, isomorphic identity, and determinism. Given that these are functional - rather than containers - making 'Key' special isn't a worthwhile effort.

One might alternatively utilize ADTs to this end, treating each ID resource as a unique ADT (via sealers/unsealers if in a structurally typed language) which allows some distribution of names without violating transparency. Unfortunately, that design makes it difficult for distinct databases to reference or inherit from one another (you cannot generally compare ADTs, not even for equality). Global (sharable) names supporting equality comparison and avoiding collisions cannot be produced with referential transparency, and demand many of the same security properties as capabilities. A generator of such names could be provided to a function if linearized.

var animals = table(animal:String, sound:String, legs:Int)
  {
    "Dog", "woof", 4;
    "Cat", "meow", 4;
    "Human", "hello", 2;
  };

The first column is used as a key, and the "value" is an anonymous record containing the other columns.

So you you can say: animals["Dog"].legs.

Well as you said, the first column is a key and the other columns part of an anonymous record so that is how you would ideally define it in other languages.

For example the dodo syntax would be:

String[(String sound, int legs) features] animals = [
   "Dog": ("woof", 4),
   "Cat": ("meow", 4),
   "Human": ("hello", 2)
]

As for the auto-generated ID... Can't you assume all objects have one and use that? Like the memory address of the object. If you need the IDs to be successive numbers, it may be preferable to specify it explicitely. At which point you may want to build your table using a map operation or a loop.

You have obviously given the problem a lot of thought!

How do you introduce relationships between entities within the literal?

Don't know if it is a "good idea", but here is what I am thinking:

var prev = $;
var t = table(self:Id, prev:Id, s:String) 
{
  prev = $ => prev, "a";
  prev = $ => prev, "b";
  prev = $ => prev, "c";
}

Can you introduce relationships on identity between two literals produced together? I.e. suppose you broke the above table into three tables: animal(ID -> String), sound(ID -> String), legs(ID -> Nat).
How, in this case, do you ensure corresponding identifiers upon construction of the literals? Is this relationship somehow maintained as the literals are distributed?

Here is how it works:

var names = Table(self:Id, name:String) { };
foreach (var r in animals)
  names.Add(r.self, r.animal); 

var sounds = Table(self:Id, sound:String) { };
foreach (var r in animals)
  sounds.Add(r.self, r.sound); 

var legs = Table(self:Id, legs:Int) { };
foreach (var r in animals)
  legs.Add(r.self, r.legs); 

How do you combine literals that were produced independently without collisions in identity? i.e. given two literal tables with identity, produce their union, perhaps with a few relationships or edges between them.

Nice. Have to think about that one. It may just require brute force programming effort on behalf of the programmer.

Thanks for your insights. Your proposed approach sounds very well thought out, but I fear may not be very accessible to run-of-the-mill programmers if that is your goal.