Quote from Dave Voorhis on April 30, 2020, 8:26 am

Quote from dandl on April 30, 2020, 1:45 am

Why? The whole point is to keep native Java syntax, semantics and implementation. Java syntax already conforms to TTM/D and can provide an adequate scalar type system, as long as the scalar types implement value semantics. Nothing new there.

The main language extension is the non-scalar types conforming to TTM: a tuple type and relation type with a heading as per TTM. Why is that so hard?

What TTM effectively obligates is a static tuple type where

tuple p {int x, int y}

tuple p {int x, int y} equals

tuple q {int y, int x}

tuple q {int y, int x} but Java has no such thing as a 'tuple' and its closest static equivalent

class p {int x, int y}

class p {int x, int y} does not equal

class q {int y, int x}

class q {int y, int x}.

However you handle tuples -- and by extension, relations -- you either adhere to Java syntax and semantics, which isn't TTM (and is how I'm doing it), or you make it TTM-compliant and either change Java semantics or extend Java semantics and syntax.

The TTM-compliant approach is not Java.

Not so, not even close. TTM requires that, in addition to any other features of the language, the type system provide:

1. A set of system value types
   1. they support isequal and assign; also compare for ordered types.
2. User-defined value types with
   1. selector (argument is list of component values)
   2. named getters and non-mutating setters (returns a new value with just that component changed)
3. User-defined tuple value types with
   1. a unique heading (set of attribute names)
   2. selector (argument is list of attribute values)
   3. named getters and non-mutating setters
4. User-defined relation value types with
   1. a unique heading (set of attribute names)
   2. a key (set of attributes names)
   3. selector (argument is set of tuples with same heading).

You can easily hand-code all of that in Java,and with these types as a base, it seems easy enough to add just about all of the rest of TTM.

Well, sure. That's what Rel and other Java-based/JVM-based D implementations do internally, but the surface language isn't Java.

These types look somewhat laborious to write and perhaps prone to errors, so a code generator could help by:

• creating/ensuring matching attribute/component names, types, heading, selector, getters and setters
• checking for uniqueness of the heading (no two tuple types or relation types may have the same heading)
• performing non-scalar type inference across RA operators
• generating additional non-scalar types for intermediate values if required.

What's not Java about that?

What language is the input to the code generator?

Unless the "code generator" is based entirely on Java annotations, it's a distinct language. Even if it is using Java annotations, it's arguably a preprocessor language rather than Java per se.

If code generation is being used to provide semantics that aren't in native Java, then the difference between it and a distinct JVM/Java-based language like Rel or SIRA_PRISE is a matter of degree rather than categorical distinction.

Native Java isn't TTM compliant. If you use code generation to make a TTM compliant system, then by definition it isn't Java any more.