Which Result?
Quote from Dave Voorhis on November 16, 2021, 12:45 pmSo in other words...
...you'd create a type definition! :-)
I'm not sure I would name the set.
But sure, for a given value (or sets of values), you could ask the system to return the set of operators/functions which would return a non empty result when used with the value(s). If that set, whether named or unnamed, constitutes a type definition in your terms, so be it.
However, there is one problem. As EQUAL is defined for all values, the set would be the same for all values. It would be the universal set. To overcome that, I guess you would have to exclude from consideration all operators that are defined for all values. You might need to take away some other "really generic" kind of operators.. and maybe continue the process of removing operators until you can partition your atoms into a useful number of mostly non-overlapping sets. Then you would emerge with a set of sets that you can usefully call types.
Again, my position is that types are not fundamental. Types (as a general concept) emerge later once you have first defined axiomatic atoms and sets, and start to add some useful functions that are not total on all values.
Now if you're saying every operator applies to every value (type), then you're effectively implementing the semantics of your type system within the operators themselves. That's fine;
Yes, that (in your terms) is what I am doing. Finding interesting sets (aka types) via the sets of values of input and output "parameters" of "functional" relations. E.g. the type "non-zero number" is the set of divisors from the divide operator.
Once named, those interesting sets can then be referenced in safety/correctness constructs, such as not allowing any pair with a name ending "Number" to have any value that is not a "Number" (and hence, annoy people that want a field named, e.g. "Phone Number" ), or such as "I expect this expression to return the same number of values as are in this set here (and if, system, you can't prove that to be the case given the current database constants, please let me know, and I might 'take the risk', or change things about)"
Quote from Paul Vernon on November 16, 2021, 2:31 pm***Once named***, those interesting sets can ***then*** be referenced in safety/correctness constructs, ...
It looks to me like this is admitting that types are fundamental to at least those "safety/correctness constructs". Which feels like it makes your question moot because (1) TTM is built on the exact same observation and (2) I can't really imagine anyone left wanting for a language that does not have any of those "safety/correctness constructs" (and I'm reasonably confident the TTM authors operated on the same assumption).
Quote from Erwin on November 16, 2021, 3:09 pmQuote from Paul Vernon on November 16, 2021, 2:31 pm***Once named***, those interesting sets can ***then*** be referenced in safety/correctness constructs, ...
It looks to me like this is admitting that types are fundamental to at least those "safety/correctness constructs". Which feels like it makes your question moot because (1) TTM is built on the exact same observation and (2) I can't really imagine anyone left wanting for a language that does not have any of those "safety/correctness constructs" (and I'm reasonably confident the TTM authors operated on the same assumption).
safety/correctness constructs would just be expressions. They would not need to reference named sets of value. E.g. you might limit pairs that have a name (i.e. the first component of the pair) of say "Pet" to only have values (the second component of the pair) from the set {"Cat","Dog","Fish"}, you might give that set a name (say `"Pets"`) and thing about the pets type, or you might choose not to name the set and/or not consider it a type.
I think my question is not moot partly because TTM is "infused by types" - 3418 instances of (elements of the case insensitive set of) the word "type" in DTARTM, and 1102 of (case insensitive) "types" . It is one of the manifesto's four foundational concepts. I think the cart is being put before the horse.
Quote from Paul Vernon on November 16, 2021, 3:36 pmQuote from Erwin on November 16, 2021, 3:09 pmQuote from Paul Vernon on November 16, 2021, 2:31 pm***Once named***, those interesting sets can ***then*** be referenced in safety/correctness constructs, ...
It looks to me like this is admitting that types are fundamental to at least those "safety/correctness constructs". Which feels like it makes your question moot because (1) TTM is built on the exact same observation and (2) I can't really imagine anyone left wanting for a language that does not have any of those "safety/correctness constructs" (and I'm reasonably confident the TTM authors operated on the same assumption).
safety/correctness constructs would just be expressions. They would not need to reference named sets of value. E.g. you might limit pairs that have a name (i.e. the first component of the pair) of say
"Pet"to only have values (the second component of the pair) from the set{"Cat","Dog","Fish"}, you might give that set a name (say `"Pets"`) and thing about the pets type, or you might choose not to name the set and/or not consider it a type.I think my question is not moot partly because TTM is "infused by types" - 3418 instances of (elements of the case insensitive set of) the word
"type"in DTARTM, and1102of (case insensitive)"types". It is one of the manifesto's four foundational concepts. I think the cart is being put before the horse.
Perhaps your goal is to create a symbolic logic processor?
If so, manipulating symbols or atoms would be typical -- perhaps even the only category of operation available, depending on your intent -- and so it may be reasonable for it not to be typeful (or at least for types not to have primacy) in the usual programming language or database language sense.
But note that TTM is about defining a family of general-purpose programming languages that embed database management capability -- or a family of database management languages that embed general-purpose programming language capability -- and so is inevitably and unavoidably "infused by types", because types are an essential, fundamental, and necessary component of general-purpose programming and database languages.
You can dispense with types, or at least their primacy, but that unavoidably takes you in a different direction than TTM's intent.
Quote from Dave Voorhis on November 16, 2021, 4:14 pm
Perhaps your goal is to create a symbolic logic processor?
It's possible, although I rather doubt it. One for me to add to my reading list. Got a good link to start from (https://en.wikipedia.org/wiki/Symbolic_programming did not inspire me)?
... note that TTM is about defining a family of general-purpose programming languages that embed database management capability -- or a family of database management languages that embed general-purpose programming language capability -- and so is inevitably and unavoidably "infused by types", because types are an essential, fundamental, and necessary component of general-purpose programming and database languages.
It is true that I am not comfortable with the goal of "general-purpose programming languages that embed database management capability". I've always hated the "embedded sub-language" idea that (early) SQL embodied. But then so do Chris and Hugh (well, not sure about the word 'hate"):
> It must be possible to write entire applications in D, instead of having to use one language for database access and another for general computation. In other words, we do not endorse the“embedded data sublanguage” approach adopted in SQL
I don't want to "embed". I want to "infuse" - and not within any existing language. That is just too dam hard to avoid compromises.
You can dispense with types, or at least their primacy, but that unavoidably takes you in a different direction than TTM's intent.
I'm not so sure that my goals are all that different. The motivation is pretty much the same as far as I can tell. A love of the relational model mixed with a love/hate (ok, mostly hate) of SQL, with the desire for simple answers for things that are simple, and well, various other things, but I'm sure more unites us all than separates us.
Quote from Paul Vernon on November 16, 2021, 6:02 pmQuote from Dave Voorhis on November 16, 2021, 4:14 pmPerhaps your goal is to create a symbolic logic processor?
It's possible, although I rather doubt it. One for me to add to my reading list. Got a good link to start from (https://en.wikipedia.org/wiki/Symbolic_programming did not inspire me)?
... note that TTM is about defining a family of general-purpose programming languages that embed database management capability -- or a family of database management languages that embed general-purpose programming language capability -- and so is inevitably and unavoidably "infused by types", because types are an essential, fundamental, and necessary component of general-purpose programming and database languages.
It is true that I am not comfortable with the goal of "general-purpose programming languages that embed database management capability". I've always hated the "embedded sub-language" idea that (early) SQL embodied. But then so do Chris and Hugh (well, not sure about the word 'hate"):
> It must be possible to write entire applications in D, instead of having to use one language for database access and another for general computation. In other words, we do not endorse the“embedded data sublanguage” approach adopted in SQL
I don't want to "embed". I want to "infuse" - and not within any existing language. That is just too dam hard to avoid compromises.
Perhaps "embed" was a poor choice of word on my part due to its somewhat loaded nature.
What TTM describes is a family of computer languages where general-purpose programming and database querying are equivalent.
You can dispense with types, or at least their primacy, but that unavoidably takes you in a different direction than TTM's intent.
I'm not so sure that my goals are all that different. The motivation is pretty much the same as far as I can tell. A love of the relational model mixed with a love/hate (ok, mostly hate) of SQL, with the desire for simple answers for things that are simple, and well, various other things, but I'm sure more unites us all than separates us.
If your goals are the same as TTM's, then types are inevitably an essential, fundamental, and necessary component -- at least if you're going to cover the general-purpose programming part in anything like the usual way. Languages like Prolog aren't really general-purpose.
Indeed, if you're not aiming for general-purpose programming, then you can explore quite radical directions. You might want to look at Executable English -- which has had proponents on this forum. See http://www.reengineeringllc.com/
Thanks Dave.
Yes. What I think is that "database querying" when done the the fullest extent (so including, for example say a transitive closure operator and general recursion, and other things besides) should get you pretty close to "general-purpose" programming. I'm happy to cover the "general-purpose" part by "database querying" and hence "not in the usual way".
How close you can get is a very good question. Close enough to cover most general-purpose "business" programming, or at least "data-centric" business processing, I would hope. The inroads that such a thing could make into more "hard" programming is possibly best discovered by actual attempts at such.
I did note the Executable English threads here (not at the time, but when idly trying to catch up on old postings some time ago), and took a cursory look back then, but not sure I spent enough time to "get it" .
I've been running headlong down the set theory branch line.. I could do with jumping over to the logic track to see if there is much to see there (especially any babies I've thrown out with the bathwater) ... Executable English might help when I get to that point.
Quote from Paul Vernon on November 16, 2021, 7:03 pmThanks Dave.
Yes. What I think is that "database querying" when done the the fullest extent (so including, for example say a transitive closure operator and general recursion, and other things besides) should get you pretty close to "general-purpose" programming. I'm happy to cover the "general-purpose" part by "database querying" and hence "not in the usual way".
How close you can get is a very good question. Close enough to cover most general-purpose "business" programming, or at least "data-centric" business processing, I would hope. The inroads that such a thing could make into more "hard" programming is possibly best discovered by actual attempts at such.
Data-centric business processing is fundamentally typeful. Executable English, Prolog, Datalog, SQL, Tutorial D, Java, C#, Python, BASIC, Fortran, FORTH, LISP, APL, RPG, bash, machine language and every other practical computer language that supports calculation (thus excluding HTML and other simple markup languages, but including XML, JSON and other general-purpose markup languages) must ultimately, in one way or another, deal with types -- or force the user-programmer to deal with them on its behalf. Some languages make every effort to -- or by their nature -- hide that fact, but it's inevitably there.
OK. I suspect ultimately we agree on your point. That the atoms and sets that we want to work with do practically have to be collected together into various named sets. This allows us to say things like "this field can only contain a number", "this field can only contain a rational number", "if you try to add true to any number you will get an empty result, which might not be what you wanted" without having to enumerate all numbers in such rules.
I'm still a trifle unsure if we agree on my point however or, more to the point, agree on what my point is (we are in the wrong thread actually, as the above relates more to the question at the start of the "Which Type?" thread, but no matter). Still, I'm content to belabour the point no longer. Best thing, as I'm sure I've seen you say a few times on the forum, is to build a prototype and then determine if the result is A) fundamentally typeful and B) capable of general data-centric business processing.
Quote from Paul Vernon on November 16, 2021, 8:28 pmOK. I suspect ultimately we agree on your point. That the atoms and sets that we want to work with do practically have to be collected together into various named sets. This allows us to say things like "this field can only contain a number", "this field can only contain a rational number", "if you try to add
trueto any number you will get an empty result, which might not be what you wanted" without having to enumerate all numbers in such rules.
Indeed, you don't want to have special rules for 3 that don't apply to 2, or vice versa.
Though having some notion of types is essentially avoidable if you allow expressions like p + q. If p is 2 and q is 3, what is the result? If p is 2 and q is 3.54, what is the result? If p is 'Dave' and q is 3, what is the result? If p is 2 and q is empty, what is the result?
And so on. Of course it is desirable to make things behave in an intuitive or obvious fashion, but it's precisely an understanding of (at least) your own type system that allows behaviour to be intuitive and obvious, rather than sometimes surprising and peculiar *cough*JavaScript*cough*.
I'm still a trifle unsure if we agree on my point however or, more to the point, agree on what my point is (we are in the wrong thread actually, as the above relates more to the question at the start of the "Which Type?" thread, but no matter). Still, I'm content to belabour the point no longer. Best thing, as I'm sure I've seen you say a few times on the forum, is to build a prototype and then determine if the result is A) fundamentally typeful and B) capable of general data-centric business processing.
Very reasonable.