Re: Another TTM-inspired effort
Date: 12 Feb 2007 04:32:51 -0800
Message-ID: <1171283570.981103.23080_at_k78g2000cwa.googlegroups.com>
On Feb 10, 7:22 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> Just ran across this:
>
> "Inspired by The Third Manifesto, a book by Chris Date
> and Hugh Darwen, we're putting forward an implementation
> of a truly relational language using Python."
>
> I haven't evaluated it at all, but I thought it might
> interest some of y'all.
>
> Strangely enough, the URL is:
>
> http://www.quicksort.co.uk/
>
> Marshall
I would like to comment on the above link and try to establish some snapshot criticism of the technology proposed as well as its overall approach.
Because SQL has deteriorated so much that it makes it easy to improve over its current capability, building a language that reflects more algebric effectiveness than SQL is not difficult. Making it more efficient on a purely relational perspective is another matter. I believe the language proposed is a slight improvement from SQL capbilities but lacks the coherence that would allow it to be called relational.
First, I do despair on the lack of semantics directly reflecting inter relations operations as being producing another relation as output giving the opportunity of doing operation over such output. For instance, the language seems not to propose to manipulate relations independently on how they evaluate which is a downfall. A truly relational language should totally separate evaluation from manipulation. The language proposes however the use of an intermediary *Eval* functions which adds unnecessary complexity to the equations made.
Second, I believe that the presentation layer takes too much room and still has too much influence on how the language is designed and specifically on how relations are actually declared. For example: Before coding the RenderHTML, the coder would have been inspired to code a Render2DTable presentation but this one is unfortunately implicit and imposed. I doubt this reflects a clear understanding of the multidimensional nature of relations (a picture of the thing is not the thing itself). In fact, in the language proposed any relation is primarily by setting up a pointer to the IS_CALLED container
IS_CALLED == Relation(["StudentId", "Name"],
... [('S1', 'Anne'),
... ('S2', 'Boris'),
... ('S3', 'Cindy'),
... ('S4', 'Devinder'),
... ('S5', 'Boris'),
... ])
print IS_CALLED
I would have felt more comfortable with something like
Relation_StudentID = {'S1','S2','S3', 'S4', 'S5'}
Relation_Name = {'Anne', 'Boris', Cindy', 'Devinder', 'Boris'}
Relation_Student = (RelationStudentID.DirectIntersect(RelationName))
Relation_Student.Present2DTable
--> The use of the DirectIntersect implies that each pair StudentId/
Name are is matched according to the order they are exposed in their
declaration.(In this case It would be equivalent to establish several
5 intersects and 4 unions)
--> the header is *implicitely* declared.
Such separation is very important because it determines the level of redundancy on any subsequent operation involving the relation.
For instance, instead of the statement which is error prone and does not integrate the notion of domain derivation. ..
IS_CALLED == Relation(["StudentId", "Name"], [('S1', 'Anne'), ('S2',
'Boris'), ('S3', 'Cindy'), ('S4', 'Devinder'),
('S5', 'Boris'),])
IS_CALLED.where(lambda t: t.Name[0] > 'C') | IS_CALLED.where(lambda t:t.Name[0] < 'B')
...a truely relational language could do the following...
Relation_StudentID = {'S1','S2','S3', 'S4', 'S5'}
Relation_Name = {'Anne', 'Boris', Cindy', 'Devinder', 'Boris'}
Relation_Student = (RelationStudentID.DirectIntersect.RelationName)
Student_Superior_C =
Relation_Student.Intersect(Relation_Name.StrictlySuperior('C')) Student_Inferior_B =
Relation_Student.Intersect(Relation_Name.StrictlySuperior('B'))
Student_Seeked1 = Student_Superior_C.Union(Student_Inferior_B)
note that if we define
Student_Seeked2 = Student_Inferior_B.Union(Student_Superior_C)
Note that a truly relational language should allows us to equate Student_Seeked1 and Student_Seeked2 (for commutativity)
Question is then how the = operator between two relations IS_CALLED and IS_CALLED2 what?
Third, many things give deep syntaxic incoherence to the language proposed...
Ex: If DELETE (MINUS) operator is expressed by *-=* then INSERT should be expressed as *+=*. Why is it expressed as *|=* ?. Why not simply express it as MINUS/UNION or -/+ .
...And several incoherences which basically make this language to unpractical to justify making the effort of learning it. Received on Mon Feb 12 2007 - 13:32:51 CET