The Forum for Discussion about The Third Manifesto and Related Matters

Please or Register to create posts and topics.

Another better sample of 'C# as D'

dandl@david-bennett-2
#1 · June 16, 2020, 2:54 am

This is what the code looks like.

Show("Q2. Get suppliers names who supply at least one red part.",
   S.Project("S#,SNAME")
    .Join(SP.Project("S#,P#"))
    .Join(P.Project("P#,COLOR"))
    .Restrict("COLOR", Where.Text(v => v == "Red"))
    .Project("SNAME"));

It's one of the standard samples from an SQL web site I use. The code reads almost identically to any of the other D languages, with due adjustment for syntax. [I wrote this by translating the Andl version literally.]

The expected performance is as for native code, there is no reflection and no type conversions (apart from one downcast for the string comparison).

To make it fully type safe would need a pre-processor or compiler extension to check the heading inference, and check the Where expression. Right now this is done at runtime.

To make it a full-scale D language would need a language extension to make headings part of the syntax. Maybe:

Show("Q2. Get suppliers names who supply at least one red part.",
   S.Project(<<S#,SNAME>>)
   .Join(SP.Project(<<S#,P#>>))
   .Join(P.Project(<<P#,COLOR>>))
   .Restrict(<<COLOR>>, v => v == "Red")
   .Project<<SNAME>>);

We could debate whether C# follows the principles of good language design, but it's hard to see that this fails to satisfy TTM otherwise (tThe missing IM and multiple POSSREPs notwithstanding).

Andl - A New Database Language - andl.org
Dave Voorhis@Dave
#2 · June 16, 2020, 8:09 am
Quote from dandl on June 16, 2020, 2:54 am

This is what the code looks like.

Show("Q2. Get suppliers names who supply at least one red part.",
S.Project("S#,SNAME")
.Join(SP.Project("S#,P#"))
.Join(P.Project("P#,COLOR"))
.Restrict("COLOR", Where.Text(v => v == "Red"))
.Project("SNAME"));
Show("Q2. Get suppliers names who supply at least one red part.", S.Project("S#,SNAME") .Join(SP.Project("S#,P#")) .Join(P.Project("P#,COLOR")) .Restrict("COLOR", Where.Text(v => v == "Red")) .Project("SNAME"));
Show("Q2. Get suppliers names who supply at least one red part.",
   S.Project("S#,SNAME")
    .Join(SP.Project("S#,P#"))
    .Join(P.Project("P#,COLOR"))
    .Restrict("COLOR", Where.Text(v => v == "Red"))
    .Project("SNAME"));

It's one of the standard samples from an SQL web site I use. The code reads almost identically to any of the other D languages, with due adjustment for syntax. [I wrote this by translating the Andl version literally.]

The expected performance is as for native code, there is no reflection and no type conversions (apart from one downcast for the string comparison).

To make it fully type safe would need a pre-processor or compiler extension to check the heading inference, and check the Where expression. Right now this is done at runtime.

To make it a full-scale D language would need a language extension to make headings part of the syntax. Maybe:

Show("Q2. Get suppliers names who supply at least one red part.",
S.Project(<<S#,SNAME>>)
.Join(SP.Project(<<S#,P#>>))
.Join(P.Project(<<P#,COLOR>>))
.Restrict(<<COLOR>>, v => v == "Red")
.Project<<SNAME>>);
Show("Q2. Get suppliers names who supply at least one red part.", S.Project(<<S#,SNAME>>) .Join(SP.Project(<<S#,P#>>)) .Join(P.Project(<<P#,COLOR>>)) .Restrict(<<COLOR>>, v => v == "Red") .Project<<SNAME>>);
Show("Q2. Get suppliers names who supply at least one red part.",
   S.Project(<<S#,SNAME>>)
   .Join(SP.Project(<<S#,P#>>))
   .Join(P.Project(<<P#,COLOR>>))
   .Restrict(<<COLOR>>, v => v == "Red")
   .Project<<SNAME>>);

We could debate whether C# follows the principles of good language design, but it's hard to see that this fails to satisfy TTM otherwise (tThe missing IM and multiple POSSREPs notwithstanding).

Having to forgo static typing and rely on a distinct language -- whether a "heading sublanguage" like your "S#,SNAME" string argument or <<S#,SNAME>> meta-language -- seems to be the standard and inevitable approach for TTM-compliant relational libraries. That's certainly what Rel's underlying relational library does. Though the meta-language in Rel's case is a full separate language, the underlying relational library is notionally very similar to yours and is no doubt similar to that in SIRA_PRISE, Duro, CsiDB, and so on.

That's what we all run into when implementing TTM constructs using usual popular programming languages like C#, Java, and C++.

Retaining static type guarantees in the host language without relying on meta-languages or sub-languages seems to inevitably require sacrificing or significantly changing the TTM operators.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org
Erwin@erwin
#3 · June 16, 2020, 11:06 am
Quote from Dave Voorhis on June 16, 2020, 8:09 am
Quote from dandl on June 16, 2020, 2:54 am

This is what the code looks like.

Show("Q2. Get suppliers names who supply at least one red part.",
S.Project("S#,SNAME")
.Join(SP.Project("S#,P#"))
.Join(P.Project("P#,COLOR"))
.Restrict("COLOR", Where.Text(v => v == "Red"))
.Project("SNAME"));
Show("Q2. Get suppliers names who supply at least one red part.", S.Project("S#,SNAME") .Join(SP.Project("S#,P#")) .Join(P.Project("P#,COLOR")) .Restrict("COLOR", Where.Text(v => v == "Red")) .Project("SNAME"));
Show("Q2. Get suppliers names who supply at least one red part.",
   S.Project("S#,SNAME")
    .Join(SP.Project("S#,P#"))
    .Join(P.Project("P#,COLOR"))
    .Restrict("COLOR", Where.Text(v => v == "Red"))
    .Project("SNAME"));

It's one of the standard samples from an SQL web site I use. The code reads almost identically to any of the other D languages, with due adjustment for syntax. [I wrote this by translating the Andl version literally.]

The expected performance is as for native code, there is no reflection and no type conversions (apart from one downcast for the string comparison).

To make it fully type safe would need a pre-processor or compiler extension to check the heading inference, and check the Where expression. Right now this is done at runtime.

To make it a full-scale D language would need a language extension to make headings part of the syntax. Maybe:

Show("Q2. Get suppliers names who supply at least one red part.",
S.Project(<<S#,SNAME>>)
.Join(SP.Project(<<S#,P#>>))
.Join(P.Project(<<P#,COLOR>>))
.Restrict(<<COLOR>>, v => v == "Red")
.Project<<SNAME>>);
Show("Q2. Get suppliers names who supply at least one red part.", S.Project(<<S#,SNAME>>) .Join(SP.Project(<<S#,P#>>)) .Join(P.Project(<<P#,COLOR>>)) .Restrict(<<COLOR>>, v => v == "Red") .Project<<SNAME>>);
Show("Q2. Get suppliers names who supply at least one red part.",
   S.Project(<<S#,SNAME>>)
   .Join(SP.Project(<<S#,P#>>))
   .Join(P.Project(<<P#,COLOR>>))
   .Restrict(<<COLOR>>, v => v == "Red")
   .Project<<SNAME>>);

We could debate whether C# follows the principles of good language design, but it's hard to see that this fails to satisfy TTM otherwise (tThe missing IM and multiple POSSREPs notwithstanding).

Having to forgo static typing and rely on a distinct language -- whether a "heading sublanguage" like your "S#,SNAME" string argument or <<S#,SNAME>> meta-language -- seems to be the standard and inevitable approach for TTM-compliant relational libraries. That's certainly what Rel's underlying relational library does. Though the meta-language in Rel's case is a full separate language, the underlying relational library is notionally very similar to yours and is no doubt similar to that in SIRA_PRISE, Duro, CsiDB, and so on.

That's what we all run into when implementing TTM constructs using usual popular programming languages like C#, Java, and C++.

Retaining static type guarantees in the host language without relying on meta-languages or sub-languages seems to inevitably require sacrificing or significantly changing the TTM operators.

Yes.

SIRA_PRISE has things like

SiraPriseServer host = new SiraPriseServer(...);
IRelation S = new RelvarProxy(host, NameIdentifier.get("S"));
IRelation SP = new RelvarProxy(host, NameIdentifier.get("SP"));
IRelation SSP = S.join(SP);
IRelation SSPP = SSP.project (NameIdentifier.get("CITY"), NameIdentifier.get("STATUS"));

Has existed for some 8 yrs now, and while verbosity or percentage perceived boilerplate (*) may differ, fundamentally it's the same.

And :

  • static type safety for relational expressions as per TTM is inachievable even if only because the language as such cannot constrain the "heading arguments" (shiver) to just literals
  • Multiple assignment as per TTM is inachievable because the host language doesn't offer it
  • Constraints as per TTM are typically left entirely unaddressed because it's such a difficult and thorny problem
  • The language per se still exhibits the pointer semantics of the host language (iff the host language is one such of course)
  • ...

(*) Could also be made to look more like

SiraPriseServer host = new SiraPriseServer(...);
IRelation S = new RelvarProxy(host, R_S);
IRelation SP = new RelvarProxy(host, R_SP);
IRelation SSP = S.join(SP);
IRelation SSPP = SSP.project (A_CITY, A_STATUS);

And imo, the ability to write code like this comes nowhere near to what it means to "be a D".

 

Last edited on June 16, 2020, 11:12 am by Erwin