Re: Beginners question: Compound types, how-to?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 04.11.10 12:06, Yannick Duchêne (Hibou57) wrote:

>> Another argument about formal things.  Ada's type declarations
>> make me think that _Type was never intended:
>>
>>     type Foo_Type is range 1 .. 10;
>>     ^^^^     ^^^^
> This is not about type declaration/definition, this is about usage/reference.
> 
> Somewhere else in this thread, you talked about “Meaning, not function” :
> function is part of the meaning hold. A word, a symbol, is a Signifier, the
> Signifier tell us about a Signified, and the function is part of that Signified.

I think that a Signified's function is not normally part of the
definition of a Signified thing that is to become a type. Example:

We never know *how* a Knife is going to be used when defining
the type Knife. I.e., What its function is going to be.  That's
abstraction.  The objects using the knife have a role in this.

We do provide *operations* such as Cut.  But what the cuts will
do is beyond the reach of the definition in the following sense:

The knife can serve as a weapon in cutting someone's throat
It can serve as a tool for cutting fish. But this is *not*
part of the definition of the type Knife.  Function
is part of the way the program's uses objects of type Knife,
"cooperating" with objects of other types, such as "Vegetable".

Knife_Type instead of just Knife does not change the definition,
so Knife_Type does not predict the function either.

The grammar should tell whether a word names a type or an object.
Ada's does. If it didn't, Ada was ambiguous.

One possible exception where _Type make a lot of sense is
actual generic units that have formal type parameter.
In this case a _Type suffix is meaningful:
The formal parameter signifies no type yet.
But is says that the actual type needs to have certain
characteristics. That is, the actual type "is a" type.

generic
  type Float_Type is digits <>;
function ...

Float_Type signals that Float_Type is not a type in the unit.
But is stands for a real type in instances.


> Know it is redundant, but the reason of this redundancy has been explained
> (dedicated name-space).

Counterarguments and alternative ways have been presented:
Redundancy is not an excuse for lack of proper names, IHMO.


> If this was not Ada, Eiffel instead, will you bother ? Would you have noticed
> this “problem” ?

I have noticed this problem in Eiffel, as have others.

In fact, separate name spaces in Eiffel are not everyone's
favorite feature. One convention that some use is to write

  string_ : STRING

That's a little underscore in addition to the legal declaration

  string : STRING

or even

  STRING : STRING

A terrible choice in the presence of real-world programming where
a programmer's work requires at least reading more than one language
(Also, imagine rewriting the above declaration in another language;
this can be solved, but again, needs mechanical, arbitrary,
non-grammatical conventions.).

I remember having difficulty compiling classes defined
using either convention with one Eiffel dialect compiler.

In Ada, the problem is aggravated by attributes, and separate
name spaces won't solve it. They can be applied to both types
and objects.

So when a reader sees

 T'Something

she will not be getting additional cues from separate
name spaces.  In fact, separate namespaces have no visible
counterpart in source text.  On the contrary, they add
a possibility of mistaking a name in namespace-for-types
for one in namespace-for-objects when they are homographs
usable in the same inner region.