value type pardox

[Nilone]

Sadly you are both missing the fathers of this line of work
namely (as far as I know) Guttag, Birkhoff, and Lispon. See
for example

  Birkhoff and Lipson
  Heterogeneous Algebras
  Journal of Combinatorial Theory, 8:115-133, 1970

  Guttag
  Abstract Data Types and the Development of Data Structures
  Communications of the ACM, 20(6):396-404, 1977

which are exactly relevant. Not to mention that Jeannette Wing
who with Liskov developed LSP subtyping notions was trained, as
a PhD student, by Guttag. So one can hardly "start and end with
Liskov" and expect to actually learn the topic appreciatively.

And really, depending on where you draw the line of exactly
what we are talking about here, you can trace further back to
the earliest 1900s to say Russell.

But really, what does all this name dropping have to do with
anything? It would be better to point a few (say 1 to 2) of
the specific works that you think best describe the notion
of type that you think most applies here.

KHD

Thanks for the references, I'll check them out. As for the name
dropping, that's just my current reading list.

 

[Nilone]

* Nilone:




Much of the point is that there's no single definition of "type" that's suitable
for all types and programming languages.

To take but one simple example, you started out with a requirement that a type
has a name. And in the example I gave of a practically useful incomplete C++
type the name was crucial: the name, and its scope attribute, was the /only/
property of that type! But when in C++ you write (void*)p, perhaps in order to
output a textual representation of p, then you're using an anonymous type, one
with no name  --  so these two types have apparently /nothing/ in common...

Of course what they do have in common is what you can do with them in an outer
environment, such as (in C++) using them as template parameters.

And that leads to an operative definition of "type": something is a "type" if it
can be used as a type  --  inherent properties such as a possible value set
don't really count, they merely serve to help one particular usage or another.

That's what makes purported general definitions of "type" so hopelessly
misguided. A lot of rigor applied to defining a chair as having a seat and four
legs and back and so on. Thus excluding quite a lot of real-world chairs
(they're chairs because they can be used or are used as chairs)...

And different programming languages have different notions of type, and some,
like C++, have a multitude of notions of type.

And so much of the point is also what James Kanze wrote: that "value type" is a
design level notion, which can't really be rigorously defined (because the act
of doing so loses the concept's usefulness, like a rigorous definition of chair)
but is mostly understood in terms of whether object identity matters or not.
When you see it you can recognize it, and when you say it, most people
understand what you mean, in the sense that it refers to the things they will
recognize as value types. But I strongly doubt that a general definition of the
formal kind is possible, and even if it were, would be of practical value..

Formal definitions are nice & useful for reasoning about things as long as one
is very aware that one is considering a very limited, simplified model.

But it's just ungood to try to impose them on the world, or use them as
classifiers, lest you end up with a baggy chair classified as non-chair....

Cheers & hth.,

- Alf

Point taken, although I find irony in the fact that you argue against
the exact definition while also arguing against a rigorous definition.

I'm not aiming for a perfectly rigorous definition of type, but rather
for a reasonable one. "It's a type if it can be used as a type"
simply defers the question. As long as you leave it there, the common
misconception will remain.

I was specifically focusing on finding a pragmatic definition by
looking at the uses of types when I mentioned value and variable
types, classes and interfaces. I believe usable definitions of these
concepts are possible and I believe my definitions are decent attempts
at achieving that. If not, this thread is a good way to refine them.

Here's another definition for the bag: a type is equivalent to a non-
terminal in a formal grammar, and its values are the strings that can
be successfully recognized as instances of that non-terminal. What do
think about that?

 

[Alf P. Steinbach]

* Nilone:

Here's another definition for the bag: a type is equivalent to a non-
terminal in a formal grammar, and its values are the strings that can
be successfully recognized as instances of that non-terminal. What do
think about that?

It seems to be either meaningless or one of those where there's some stumble-on
context that supplies meaning but can't just be guessed or figured out (that's a
favorite pastime of technicians, stumbling upon something and then asking others
about it without supplying the information that would enable them to see what
the heck they're talking about, at least not without doing a web-search or w/e).

There is a relationship, by way of values, between formal grammars and types,
since one kind of formal grammar is a simple set of substitution rules, and one
way to specify one kind of abstract datatype is a set of substitution rules for
generating values of the type. Then you additionally need rules for reducing the
generated strings to canonical forms (e.g. "pop(push(push(T(),1),2)) =
push(T(),1)"), that is, equivalence classes of strings, strings that denote the
same values. And then the definition would be "A formal grammar plus a set of
equivalence rules for the generated strings can correspond to a kind of type,
where the generated strings correspond to values of the type", where first of
all it's the /grammar/ that corresponds to type, not a non-terminal symbol, and
second the grammar's type is an example of a type, not that a type is a grammar.

But that's as far as I can free-associate the above.

Possibly you can explain what you meant.

And then I can learn something, but it'll probably be off-topic in this group...


Cheers & hth.,

- Alf

 

[Nilone]

* Nilone:




It seems to be either meaningless or one of those where there's some stumble-on
context that supplies meaning but can't just be guessed or figured out (that's a
favorite pastime of technicians, stumbling upon something and then asking others
about it without supplying the information that would enable them to see what
the heck they're talking about, at least not without doing a web-search or w/e).

There is a relationship, by way of values, between formal grammars and types,
since one kind of formal grammar is a simple set of substitution rules, and one
way to specify one kind of abstract datatype is a set of substitution rules for
generating values of the type. Then you additionally need rules for reducing the
generated strings to canonical forms (e.g. "pop(push(push(T(),1),2)) =
push(T(),1)"), that is, equivalence classes of strings, strings that denote the
same values. And then the definition would be "A formal grammar plus a set of
equivalence rules for the generated strings can correspond to a kind of type,
where the generated strings correspond to values of the type", where first of
all it's the /grammar/ that corresponds to type, not a non-terminal symbol, and
second the grammar's type is an example of a type, not that a type is a grammar.

But that's as far as I can free-associate the above.

Possibly you can explain what you meant.

it was just an idle thought in response to perceived similarities in
construction. your free-association was exactly what i was looking
for, thanks.