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.68.112.65 with SMTP id io1mr5139651pbb.6.1368583730371; Tue, 14 May 2013 19:08:50 -0700 (PDT) MIME-Version: 1.0 Path: bp1ni2341pbd.1!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.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!goblin2!goblin.stu.neva.ru!aioe.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Fri, 10 May 2013 19:42:37 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <17ceq51ydy3s0.s94miqqzbg5w.dlg@40tude.net> <1vrhb7oc4qbob$.q02vuouyovp5$.dlg@40tude.net> <19lrzzbgm77v6.1dzpgqckptaj6.dlg@40tude.net> <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net> <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> <1oy5rmprgawqs.1jz36okze0xju$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368232958 31877 69.95.181.76 (11 May 2013 00:42:38 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 11 May 2013 00:42:38 +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 X-Received-Bytes: 6792 Date: 2013-05-10T19:42:37-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1oy5rmprgawqs.1jz36okze0xju$.dlg@40tude.net... > On Thu, 9 May 2013 17:19:14 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net... >>> On Wed, 8 May 2013 15:27:50 -0500, Randy Brukardt wrote: >>> >>>> "Dmitry A. Kazakov" 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. >>> >>> Weak typing is better? >> >> Yes, because we need to move beyond typing to other forms of static error >> detection. > > Based on what? On individual values? What I was calling profiles; Nicolas has provided a reference that says its known as "typestate" analysis. It sits on top of types providing more information for static checking. ... >> I want checking that is *stronger* than what can be provided by >> statically >> applied types. Trying to get it by extending the type model directly is >> madness, especially as it makes sharing much less possible. > > No, you will lose a whole universe of checks without gaining anything > useful. Checks of individual values have limits imposed by computability. > Furthermore, focusing on values, you will kill software engineering. Reuse > is what is really important. Checks are only a tool to make reuse safer. I'm adding on top of types, not in place of them. And I don't see what would change about software engineering -- that's about visibility control (i.e. packages) and strong checking. OOP-madness (inheritance and the like) adds little to the ability for reuse -- in large part because it's almost never appropriate. (The fact that inheritance is only additive kills most reuse -- a different abstraction is, for the lack of a better term, different -- it's not going to share all or even a lot of the operations.) ... > Not at all. It is substitutability which is context-depended ... Bow down to the great god of "substitutability". The real crux of OOP-madness -- this is fantasy that does not exist in real problems. ... >> In particular, I think the Ada model of few types (essentially, initial >> declaration equivalent) is the way to go; all of the action should be on >> enhancing subtypes and subprograms such that static checks are possible >> (by >> combining constraints, null exclusions, predicates, parameter/result >> profiles, and possibly other things into an integrated concept). > > Concept of what? You are not yet ready with types and want to introduce > something of unknown nature? How these new things will interact each > other, > values, types, classes, packages. What is there to check if the properties > of are nowhere stated, meaning is undefined? Yes, because I'm starting over. That means a nearly clean slate. I want to clean up all of those interactions (which are currently a mess), and that means rethinking everything. There's no point to small tweaks to Ada (if you want model changes), you simply can't get there. You'll just end up adding more "gazebos", as you once put it. >>> Strong typing is an ability to distinguish types. Not mixing types means >>> that you could not have subprograms with more than one argument. It is >>> just crazy. >> >> Certainly when you invent ideas like this, which have nothing to do with >> anything that I said or was thinking about. Obviously, operations of one >> type need parameters of another type. But your OOP-fever means that you >> think that this somehow implies the types are related. > > What else a relationship is? Types deal with values and operations. There > is nothing else. Since values are not shared (Ada is typed so far), the > only thing which may bind two types is a shared operation. I don't think operations have anything to do with types: they *use* types, they aren't part of them in any way. The "profile" of objects determines what operations can be used with them. Keep in mind that what I've trying to do here is to get the sort of statically checked preconditions that you keep saying are necessary. That requires formalizing at least part of the state of objects, because a model that can't statically check whether files are open in I/O is a pretty useless model. You may describe this is terms of a different formalism, but as far as I'm concerned, that's simply trying to confuse the issue. It's confusing enough without that kind of "help". Randy.