Quote from Erwin on October 3, 2022, 7:49 pm

SQL has <don'tcarevalue>s too.  Try and count the number of times D&D have moaned in their writings about

SELECT ... FROM (nested query expression here) AS POINTLESS

(or some such) and made the point that it's plain bad language design.

Quote from AntC on October 3, 2022, 9:13 pm

Quote from tobega on October 3, 2022, 2:52 pm

Then TupleRename is built from <tuple> TupleProject TUPLE{ <attrName> <don'tcarevalue> } to get THE_<attrName> value at the as-was attribute; TupleRemove to snip off that attribute (again with a `don'tcarevalue' in a singleton Tuple literal); TupleExtend to glue on the to-be attribute (as a singleton Tuple literal).

The <don'tcarevalue> is perhaps the only questionmark here. TupleProject would never care about the value on the right hand side, so for ergonomic reasons I would like to have a <don'tcarevalue> in my toolbox.

Fair enough. De gustibus no disputandum. In Haskell we spell it undefined -- it's a standard name/used in standard algorithms.

I'm expecting most of the time you're going to use tuples laying to hand to supply your sets-of-attribute-names. So you won't much be called on to code <don'tcarevalue>.

The alternative seemed to me to introduce bare attribute names as 'stand-alone values'; but then have to introduce a load of side rules as to what syntactic positions they could appear in -- because they're not first-class values.

Quote from AntC on October 3, 2022, 9:59 pm

Quote from Erwin on October 3, 2022, 5:31 pm

Quote from Erwin on October 3, 2022, 5:12 pm

SIRA_PRISE version of the query :

PROJECT ( RESTRICT ( RELVARATTRIBUTE , EQ ( ATTRIBUTENAME , NAME(RELVARNAME) ) ) , (RELVARNAME) )

Incidentally, looking at that entire expression, one could observe that there is almost not a single word in there that is not a name. ALMOST NOT A SINGLE WORD.  Operator name, operator name, relvar name, operator name, attribute name, type name, something that has to be a name or everything will fail entirely (though admittedly that is only the case because the type name at hand happened to be NAME(NAME) ), attribute name.  So why would it be interesting to have a NAME type ?

I can see there are no literals (as I'd understand them in a Algol/C/Java -like language). Are you saying none of those sequences-of-letters denote variables in this language? Then I'm bemused/left in the dark as to what you think this achieves that isn't already achievable.

TTM requires there be a catalog, but doesn't specify what form it should take. In particular, it doesn't take a position on the types of the relvars/attributes in those relvars. If some D's catalog held relvar names and attribute names (and types thereof) in string form, it would still support answering a query such as your above. Instead of your NAME(RELVARNAME) would be 'RELVARNAME' -- in which the single quotes surround a CHAR literal, to follow Tutorial D convention.

What Pre/Pro/VSS in TTM is it breaking for catalog attributes to be strings?

Is all your hullabaloo no more than this?

The reason I (and @dandl) started talking about variables ranging over attribute names was because I assumed you were after something more powerful than my o.p. Something like (I'm guessing some syntax):

nameString  := getUserInput('Which attribute name?:');
valueString := getUserInput('What value?:');
attrName    := NAME(nameString);

relvarNames := PROJECT ( RESTRICT ( RELVARATTRIBUTE , EQ ( ATTRIBUTENAME , attrName ) , (RELVARNAME) );

FOR relvar IN relvarNames
    { result    := PROJECT ( RESTRICT ( relvar , EQ ( toString( attrName ) , valueString ) , (attrName) );
      showValue( result )
    };

in which I've spelled variables (and functions) starting lower-case. Except for NAME( ) -- because I suspect that's not as simple as a function taking a scalar-type argument and returning a scalar-type result. It feels like hard-wired syntax masquerading as a function call.

(Also I've not put any error handling. I guess if the user mis-spells the attrName or includes characters not allowed in names, there'll be no attributes named that, so relvarNames will be empty. So the PROJECT/RESTRICT won't get evaluated; so (maybe) that it is ill-formed won't come to light.)

Quote from AntC on October 3, 2022, 10:37 pm

Quote from Erwin on October 3, 2022, 5:12 pm

Quote from AntC on October 3, 2022, 6:36 am

Quote from Erwin on October 2, 2022, 12:56 pm

The effects you'd be getting if users start querying the catalog to find, e.g. all the relvars that have an attribute named 'RELVARNAME' (the query might be something like 'RELVARATTRIBUTE WHERE ATTRIBUTENAME = "RELVARNAME" {RELVARNAME}' are as follows :

...

I'm afraid your two uses of RELVARNAME in that query don't mean anything to me. Why the double-quotes? Is the suffixed-in-curly-braces doing Tutorial D's projection? I think I mentioned I'd prefer Tutorial D had an explicit operator for projection. If it is projection, please show parens ( ... ) so I can see what the projection scopes over.

Am I allowed a value selector NAME(SST(stringyvar, 2, 10)) or NAME( CONCAT(stringyvar1, stringyvar2) )? Is my query allowed to search for wildcard matches like all attribute names containing '%NAME%'? I think there'd be a lot of pragmatic reasons that names in the catalog could be (convertible to) String.

Note: SQL '%NAME%' for a wildcard search is at first look a CHAR; but it has syntax inside it that gets interpreted at run time, because it's an argument of LIKE rather than =. SQL is exhibiting the sort of syntactic schizophrenia that good language design ( RM Pre 26) is prescribing against.

Ok. Two things that stand out to me as features I _don't_ want in my language.

SIRA_PRISE version of the query :

PROJECT ( RESTRICT ( RELVARATTRIBUTE , EQ ( ATTRIBUTENAME , NAME(RELVARNAME) ) ) , (RELVARNAME) )

PROJECT & RESTRICT : invocation names of the relational operators (operator generators, in fact, but let's stick with the territory) of that name

What's an 'operator generator'? Why are they not simply operators/functions? Is there some sort of generics going on here? Does the invocation need to know the full type of its arguments for the form to be valid? That is, to know the exact Heading of the relvar/relation? Note my proposed set of functions is polymorphic over the tuples' Headings. It maybe needs to know the Heading includes some specific named attribute; then abstracts over the 'leftover' part of the tuple.

RELVARATTRIBUTE : reference to the database relvar whose name is the NAME value NAME(RELVARATTRIBUTE)

EQ : invocation name of the equality operator generator

ATTRIBUTENAME : reference to the attribute within the RELVARATTRIBUTE relvar whose [attribute] name is the NAME value NAME(ATTRIBUTENAME)

NAME(RELVARNAME) : selector of the NAME value that we want to query for / filter on / ...  More verbosely, NAME(STRING(RELVARNAME)) but that is often not needed, depending on the set of possreps

Allowing STRING(  ) there suggests you have a string literal -- but you aren't surrounding by quotes(?) Would quotes be allowed? Are only letters allowed? How do I in the language at large denote a string containing arbitrary graphics chars or digits? How do I denote a string including char ')'? Does that need to be escaped?

All you seem to be achieving is smuggling in Strings without the conventional notation. What I'd call an anti-feature. (System/38, AS/400 Command Language did this. I rolled with it because CL programs were usually short enough you could see them on one screen, so you could tell which letter-sequences were declared as variables. Never liked it.)

I'm now left with a nervous cluelessness about all the other letter-sequences appearing in your stuff. Which could be written in the form NAME(STRING(   ))/which are the appearance of variables? Or at least which are appearing as tokens denoting something other than themselves as strings?

"Why the double-quotes?"  Because I thought quoting would be more familiar as a way for denoting STRING/CHAR values, rather than the more lisp-ish NAME(...) or STRING(...)

I suspect you're confusing your syntax with LISP (QUOTE ...) -- which is a different thing entirely. (And manipulating code as data is not a requirement under TTM.)

 

Quote from Erwin on October 4, 2022, 6:47 am

All value selectors are introduced by the type name.  Only exception being STRING itself where this is optional.  Specifying string literals as STRING(...) is always possible, but rarely needed.  No quotes, no distinction between " and ' for multi-char and single-char, no appending 'L' for indicating LONG instead of INT, no appending '#' to indicate a value that looks like an integer should be a double, no appending '$' to indicate String type, no tokens to tell the system that something that looks like a DATE should actually be a DATETIME or TIMESTAMP, no using quotes for DATE/TIME/DATETIME/TIMESTAMP values and leaving it to the parser/whatever to figure out which it is etc. etc.  None of that shit.  One simple principle.  All value selectors are introduced by the type name.  You don't want that because you think it's a bad feature ?  Fine.  Stick with your 'modifiers' shit.  When specifying String values, '(' ')' and '\' must be escaped with '\'.  Thinking about this now, perhaps ',' should have been among the escapable characters too because comma too is a token of the meta-language.

The basic reason is that all types always have some textual representation for their values (as one of you has so wisely pointed out to me), therefore it is possible to mandate at least one possrep for system-defined types too : the one that has one CHAR component.  Except thus for CHAR itself because that one "is its own possrep", so to speak.

The reference to LISP was merely in relation to the syntactic style with "overdoses" of parentheses.  (And please note that you criticized me in this very thread for not writing enough of them in an example in a language style that matches common current language practices more than mine does.)

Quote from AntC on October 4, 2022, 9:23 am

Quote from Erwin on October 4, 2022, 6:47 am

All value selectors are introduced by the type name.

So can I introduce my own types? How would I declare a value selector for my type?

Or is there a fixed set of types? Then the type names are tantamount to reserved words. And I have to read NAME( BLAGH ) as fixed syntax, not a function invocation(?)

Offensive language ignored.

 

Quote from Erwin on October 4, 2022, 12:02 pm

Quote from AntC on October 4, 2022, 9:23 am

Quote from Erwin on October 4, 2022, 6:47 am

All value selectors are introduced by the type name.

So can I introduce my own types? How would I declare a value selector for my type?

Or is there a fixed set of types? Then the type names are tantamount to reserved words. And I have to read NAME( BLAGH ) as fixed syntax, not a function invocation(?)

Offensive language ignored.

Selectors become available in the expression language for each declared possrep.  Possreps are declared depending on "what the type is backed by" : types can be "backed by" a java type implementation object (which has all the methods for the system to detect the possreps and their components) or they can be "backed by" the UDT mechanism in which case possreps are declared by (a.o.) registering the possreps and their components in the UDTPOSSREP and UDTPOSSREPCOMPONENT catalog relvars.

Possrep component names are required to be unique within a type, so one component name suffices to determine which possrep and corresponding selector is being used.  If there is no component at all, the type is singleton anyway and that single value gets selected.