Re: Seeking for papers about tagged types vs access to subprograms

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nd22gfeezrwf$.tlj4yyygrwq3$.dlg@40tude.net...
...
> Each time you do something with a type you get another one. Otherwise it
> becomes untyped.

That way leads to madness, I think. It's better for "types" to be fairly 
weak and interoperable. In this model, "types" are the low-level view of 
entities (with things like representation, "kind" [integer, float, array, 
etc.]). On top of that, you have some thing else, let's call them "profiles" 
(as "interfaces" imply dynamic behavior, which is not what we're talking 
about here). In my language, "profiles" are statically checked and apply to 
objects as well as subprograms (objecting being overloadable). "Profiles" 
provide the high-level view of entities, and would be where properties like 
"apples" and "oranges" would be dealt with. There'd be a shorthand for 
adding a profile to all uses of a type (just as subtypes provide that for 
constraints in Ada). If the profiles "match", then the items are compatible, 
and if they don't, then they're not.

If done right, this would provide a lot more static checking opportunities 
than Ada could ever have, and it would get away from the stale notion of 
"type", which is just not powerful enough by itself.

                                        Randy.