The missing tuple
Quote from Dave Voorhis on September 8, 2019, 11:14 pmQuote from Darren Duncan on September 8, 2019, 10:59 pmThere is no problem here. How such a thing would work is exactly the same as how it works in Tutorial D now. When T is a tuple of type (x Float, y Int, z String) you don't have any problem determining the types of any attribute. Likewise, when T is a type of type (0 Float, 1 Int, 2 String) you would also have no problem. Whatever generic operators work for x,y,z would work the same for 0,1,2 identifiers. Just as you say "x from t" you say "0 from t". The signature of "from" is the same either way. Works perfectly well in a statically typed language.
Let n FROM T be a feature of the language, where n is an integer reference to the nth attribute of T. Let RAND() return a random integer. Evaluate the expression RAND() FROM T. What is the type of the expression?
To that I say:
Let n FROM T be a feature of the language, where n is a character string reference to some arbitrary named attribute of T. Let RAND() return a random character string. Evaluate the expression RAND() FROM T. What is the type of the expression?
The solution to both questions is the same. And no one seems to have a problem with the second one, which is named attributes. I say if you have no problem with the second, you solve the first exactly the same way.
Quote from Dave Voorhis on September 8, 2019, 11:07 pmQuote from Darren Duncan on September 8, 2019, 10:54 pmQuote from dandl on September 8, 2019, 1:38 amIt does not have an unnamed tuple/list (list of values of different types, identified by position). You may not need it often, but when you need it nothing else will do.
I think you would need it often. Since Tutorial D has positional rather than named operator arguments, a tuple whose attributes are identified by position is very important. The type of the argument list of an operator as a whole is that kind of tuple.
You'd only need it often if you've defined operator argument/parameter lists to belong to the type of "unnamed tuple/list".
If you haven't defined it in that manner, I don't think you'd need it often if at all. I've been writing Tutorial D code to do real things for years, and have not yet come across a need for it.
It's not a feature likely to be used often in a 'concrete' language used for writing business applications, but I find I use something like it rather often at a more 'abstract' level, writing generic tools. You might not use it in TD, but you might use it to implement TD. Isn't the test of a language the ability to implement itself?
The problem comes up twice (that I recall) in Andl. One is the generation of a stream of IL instructions for the runtime VM. The other (which triggered this thought) is the representation of the result set returned by a query host to a client written in a different language. One C# solution is to represent the value as a stream/list/array of object and cast them into the desired type (determined at runtime), and you can sweeten that with generics. Java would be similar.
You don't find out whether there is a need for a language feature by excluding it from the language and asking whether anyone noticed. (Most likely, the ones who did have left the building.) You find out by adding the feature to the language and asking whether anyone used it.
Quote from dandl on September 9, 2019, 1:22 amQuote from Dave Voorhis on September 8, 2019, 11:07 pmQuote from Darren Duncan on September 8, 2019, 10:54 pmQuote from dandl on September 8, 2019, 1:38 amIt does not have an unnamed tuple/list (list of values of different types, identified by position). You may not need it often, but when you need it nothing else will do.
I think you would need it often. Since Tutorial D has positional rather than named operator arguments, a tuple whose attributes are identified by position is very important. The type of the argument list of an operator as a whole is that kind of tuple.
You'd only need it often if you've defined operator argument/parameter lists to belong to the type of "unnamed tuple/list".
If you haven't defined it in that manner, I don't think you'd need it often if at all. I've been writing Tutorial D code to do real things for years, and have not yet come across a need for it.
It's not a feature likely to be used often in a 'concrete' language used for writing business applications, but I find I use something like it rather often at a more 'abstract' level, writing generic tools. You might not use it in TD, but you might use it to implement TD. Isn't the test of a language the ability to implement itself?
The problem comes up twice (that I recall) in Andl. One is the generation of a stream of IL instructions for the runtime VM. The other (which triggered this thought) is the representation of the result set returned by a query host to a client written in a different language. One C# solution is to represent the value as a stream/list/array of
objectand cast them into the desired type (determined at runtime), and you can sweeten that with generics. Java would be similar.You don't find out whether there is a need for a language feature by excluding it from the language and asking whether anyone noticed. (Most likely, the ones who did have left the building.) You find out by adding the feature to the language and asking whether anyone used it.
I suppose if we're just talking about Tutorial D, I wouldn't see any value in a numerically-indexed tuple for its usual desktop data-crunching and educational purposes. If I were to extend Tutorial D for the sort of things you're describing, I wouldn't stop at numerically-indexed tuples. I'd implement full generics and reflection.
Quote from Darren Duncan on September 9, 2019, 12:05 amQuote from Dave Voorhis on September 8, 2019, 11:14 pmQuote from Darren Duncan on September 8, 2019, 10:59 pmThere is no problem here. How such a thing would work is exactly the same as how it works in Tutorial D now. When T is a tuple of type (x Float, y Int, z String) you don't have any problem determining the types of any attribute. Likewise, when T is a type of type (0 Float, 1 Int, 2 String) you would also have no problem. Whatever generic operators work for x,y,z would work the same for 0,1,2 identifiers. Just as you say "x from t" you say "0 from t". The signature of "from" is the same either way. Works perfectly well in a statically typed language.
Let n FROM T be a feature of the language, where n is an integer reference to the nth attribute of T. Let RAND() return a random integer. Evaluate the expression RAND() FROM T. What is the type of the expression?
To that I say:
Let n FROM T be a feature of the language, where n is a character string reference to some arbitrary named attribute of T. Let RAND() return a random character string. Evaluate the expression RAND() FROM T. What is the type of the expression?
The solution to both questions is the same. And no one seems to have a problem with the second one, which is named attributes. I say if you have no problem with the second, you solve the first exactly the same way.
The difference is that the language -- Tutorial D, presumably -- doesn't currently support dynamic resolution of the name of the attribute. If it did, the problem and solution would be the same as my example with dynamic resolution of the index of the attribute.
A dialect of Tutorial D that only permits statically resolving the attribute by a numeric literal index would be rather pointless.
Quote from Dave Voorhis on September 8, 2019, 11:07 pmQuote from Darren Duncan on September 8, 2019, 10:54 pmQuote from dandl on September 8, 2019, 1:38 amIt does not have an unnamed tuple/list (list of values of different types, identified by position). You may not need it often, but when you need it nothing else will do.
I think you would need it often. Since Tutorial D has positional rather than named operator arguments, a tuple whose attributes are identified by position is very important. The type of the argument list of an operator as a whole is that kind of tuple.
Darren, Tutorial D is like many languages in that the ( ... ) argument to an operator function invocation is hard-coded syntax, not 'first class'. That is, the parens-thing can't be assigned to a variable, can't be the result of a function, etc. That's the case even in languages which do have positional tuples (sequences) as first-class values. You can't go
x := (5, "Hello", True) y := foo x -- invalid syntax for a function invocation y := foo (x) -- invalid: foo expects 3 arguments, first must be an INT z := foo (5, "Hello", True) -- OK
Even in Haskell, for which tuples are first-class and function invocation is just written as adjacent terms like foo x or foo (x), that would still be ill-typed if foo expects 3 arguments, as opposed to expecting one argument that's a three-ple.
You'd only need it often if you've defined operator argument/parameter lists to belong to the type of "unnamed tuple/list".
Even then, some languages (variants of ALGOL 60, BCPL, C?) allow a variable number of arguments to a function invocation, along with some sort of reflection technique (BCPL has system function numbargs()), but still don't support tuples as first-class.
If you haven't defined it in that manner, I don't think you'd need it often if at all. I've been writing Tutorial D code to do real things for years, and have not yet come across a need for it.
Seeing as TTM/Tutorial D does have first-class attribute-named tuples, I think there would be a valid (and useful) variant in which function invocation syntax is a function name written adjacent to a tuple, where the function definition extracts arguments by pattern-matching on attribute name. Indeed rather a lot of IBM's Command Languages work like that; does PL/1? And why didn't the idea get adopted into Tutorial D?
x := TUPLE{Name "hello", ID 5, Proper FALSE} -- freely reorder
z := foo x
FUNCTION foo TUPLE{INT ID, STRING Name, BOOL Proper} = ... ID ... Name ... Proper ...
Quote from AntC on September 9, 2019, 3:37 amSeeing as TTM/Tutorial D does have first-class attribute-named tuples, I think there would be a valid (and useful) variant in which function invocation syntax is a function name written adjacent to a tuple, where the function definition extracts arguments by pattern-matching on attribute name. Indeed rather a lot of IBM's Command Languages work like that; does PL/1? And why didn't the idea get adopted into Tutorial D?
x := TUPLE{Name "hello", ID 5, Proper FALSE} -- freely reorder z := foo x FUNCTION foo TUPLE{INT ID, STRING Name, BOOL Proper} = ... ID ... Name ... Proper ...
I haven't written anything useful in PL/I since about 1985 so I might be misremembering, but I don't think PL/I did this.
Quote from AntC on September 9, 2019, 3:37 amDarren, Tutorial D is like many languages in that the
( ... )argument to anoperatorfunction invocation is hard-coded syntax, not 'first class'. That is, the parens-thing can't be assigned to a variable, can't be the result of a function, etc. That's the case even in languages which do have positional tuples (sequences) as first-class values. You can't goEven in Haskell, for which tuples are first-class and function invocation is just written as adjacent terms like
foo xorfoo (x), that would still be ill-typed iffooexpects 3 arguments, as opposed to expecting one argument that's a three-ple.
I will say in contrast to this that Perl 5 and Perl 6 both explicitly DO support taking a collection type value and using it as the arguments to a function, or taking the arguments to a function as a single collection type value. And so whole argument lists in those languages have a type. I consider this a very useful feature, both for regular and advanced users of the language.
See https://docs.perl6.org/type/Capture for documentation on the data type representing a Perl 6 argument list. It can be characterized by a tuple that can have both positional and named attributes, corresponding to supporting both positional and named arguments.
Keyword arguments didn't get adopted in Tutorial D probably because its inventors didn't claim to be au courant with PL design.
PL/I doesn't have keyword arguments, at least not in Subset G, which is the only PL/I I actually know much about. Lua accepts a table (really a mapping/dictionary) as an argument, but it's just syntactic sugar: you can write foo({x = 0, y = 0}) as foo{x = 0, y = 0} instead, giving the appearance of keyword arguments.
Mesa, a Pascal offshoot with many extensions used internally to Xerox, is the only language I know where both the argument and the result of a procedure are always named tuples, though Perl 6 comes close. The result, if it is the left side of an assignment, can be automatically disaggregated, just as calls are automatically aggregated.
I guess C# now has it all. Anonymous types and named arguments since v4 or earlier; more recently anonymous tuples, deconstructors and pattern matching.
[Plus heaps of other stuff, so it's getting hard to even keep track.]
Quote from dandl on September 10, 2019, 12:29 amI guess C# now has it all. Anonymous types and named arguments since v4 or earlier; more recently anonymous tuples, deconstructors and pattern matching.
[Plus heaps of other stuff, so it's getting hard to even keep track.]
It will be interesting to see whether this dog's breakfast of language features will help stave off the growing irrelevancy of .NET in an increasingly post-Microsoft world.