From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,39579ad87542da0e
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.224.130.195 with SMTP id u3mr22376839qas.1.1368583259897;
        Tue, 14 May 2013 19:00:59 -0700 (PDT)
MIME-Version: 1.0
X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 78.192.65.63
Path: 
 y6ni44319qax.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nrc-news.nrc.ca!News.Dal.Ca!citadel.nobulus.com!goblin1!goblin.stu.neva.ru!proxad.net!feeder1-2.proxad.net!nntpfeed.proxad.net!news.muarf.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Seeking for papers about tagged types vs access to subprograms
Date: Wed, 8 May 2013 15:27:50 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <kmecg6$et4$1@loke.gir.dk>
References: <op.wv8jh1c1ule2fv@cardamome> <op.wwbvqzkeule2fv@cardamome>
 <op.wwnp2zkrule2fv@cardamome> <u3jaslg5kca7.1gk5ds3d4sx2y$.dlg@40tude.net>
 <op.wwnsmtteule2fv@cardamome> <17ceq51ydy3s0.s94miqqzbg5w.dlg@40tude.net>
 <op.wwny5jerule2fv@cardamome> <1vrhb7oc4qbob$.q02vuouyovp5$.dlg@40tude.net>
 <op.wwn4oak8ule2fv@cardamome> <19lrzzbgm77v6.1dzpgqckptaj6.dlg@40tude.net>
 <kmbohm$elb$1@loke.gir.dk> <p0pf97g5w6xg.jhca6ztjwpde$.dlg@40tude.net>
 <op.wwq9s4l6ule2fv@cardamome> <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net>
 <op.wwrefx1pule2fv@cardamome> <cps71yzogw24$.7ol98fxcaurj$.dlg@40tude.net>
 <op.wwriky0dule2fv@cardamome> <nd22gfeezrwf$.tlj4yyygrwq3$.dlg@40tude.net>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: loke.gir.dk 1368044871 15268 69.95.181.76 (8 May 2013 20:27:51 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 8 May 2013 20:27:51 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Date: 2013-05-08T15:27:50-05:00
List-Id: <comp.lang.ada>

"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.