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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,70414f56d810c10c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.46.193 with SMTP id x1mr10483581pbm.7.1317136265688; Tue, 27 Sep 2011 08:11:05 -0700 (PDT) Path: lh7ni6029pbb.0!nntp.google.com!news1.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!newsfeed.straub-nv.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 27 Sep 2011 17:11:03 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: discriminant questions References: <9f37b726-d80b-4d24-bf3f-28a14255f7fd@s20g2000yql.googlegroups.com> <14tiipigyejtc$.hyp7e82egqwq$.dlg@40tude.net> <34d856bd-19a3-4bbf-b9d8-c0f100000ef4@k7g2000vbd.googlegroups.com> <1tpl2pc36ptr4$.txv4v3wmkjlm.dlg@40tude.net> <1malv6h6q31j3.uz9ws5j0glnm.dlg@40tude.net> <4e81a2f4$0$7624$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Message-ID: <4e81e788$0$6542$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 27 Sep 2011 17:11:04 CEST NNTP-Posting-Host: 35834aa2.newsspool4.arcor-online.net X-Trace: DXC=ijo?Ph9W;k?LNKYb?b>0764IUK]NnbY2nc\616M64>:Lh>_cHTX3j=a?Nn]]O[TD3 X-Complaints-To: usenet-abuse@arcor.de Xref: news1.google.com comp.lang.ada:18170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2011-09-27T17:11:04+02:00 List-Id: On 27.09.11 14:14, Dmitry A. Kazakov wrote: > On Tue, 27 Sep 2011 12:18:28 +0200, Georg Bauhaus wrote: > >> On 27.09.11 10:10, Dmitry A. Kazakov wrote: >> >>> Consider a type system where your precious kludges of old Ada would become >>> some type expressions and library implementations rather than built-in >>> stuff. >> >> In the opposite direction, an alternative effort would set out >> to find language for the field tested patterns hidden in libraries. > > No the opposite direction is to have built-in "patterns". That's what I meant to say; to design some language for those "patterns" being now "emulated" in libraries seems harder. Harder because you need to decide that (1) This is it! and (2) Though shalt not be a language designer, but a programmer. Even when you write reusable libraries. These built-ins might be harder for compiler makers to implement, IIUC. A use case: "Run these independent procedures concurrently. They share one variable." With a normal, practical programmer in mind, a typical "pattern" of language extension into the domain of concurrency is to enable writing, in pseudo code: concurrent procedure one (a, b: input; c: out output) is begin ... lock shared.do(b, 42) end lock; ... end; This reuses the notion of "procedure", the word "concurrent" being a hint, the lock being automatic; critical region isolated, perfectly easy! (If lousy, but quality issues needs to be addressed with care.) Now in Ada, they tell you to write a task, task one is begin ... (interrupting) "Where do I put a, b, and c?" "In entries, moment please!" ... "Oh, gosh, more mechanism, why can't it be easy?" "OK, wait: task worker is begin one (a, b, c); end; Does this look easy?" "OK, where do a, b, c come from?" "You make them visible, the task could be local : procedure one (a, b: input; c: output) is task worker is begin ... end; begin null; end;" "OK (boring, verbose, so many ways), how about the shared variable?" "Just define a protected object." "What?" ... etc The increasingly annoyed questioner might be right or wrong from a software engineering point of view, the language design will have to address his concerns or else he does not buy. A library, or a pattern, might seem to help: task type Run_Once (job : access procedure (a, b: input; c : out output)) is pragma Storage_Size (N); end Run_Once; But when is `c` filled? So you end up explaining tasks and protected objects anyway. And you might be able to explain why seemingly advantageous "primitives" like "concurrent" and "lock" had been preferred to a library based approach. > It is also interesting how non-implemented "patterns", and as I understand, > your desire is to keep them such, could be tested in the field, before > being incorporated into the language core? Was for example limited type > return tested in the field? Accessibility rules? Anonymous access types? At Ada-auth, they usually say something about customer response to implementation defined pragmas and such. I should hope that new languages are made the way that matches the way a certain requirements document was made, reviewed, parts dismissed, reviewed again, compared, etc.