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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,32d9aa9d79729b31 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.219.170 with SMTP id pp10mr8809250pbc.1.1341472128652; Thu, 05 Jul 2012 00:08:48 -0700 (PDT) Path: l9ni10941pbj.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Any easy/build-in construct to extract submatrices from larger matrix? Date: Thu, 5 Jul 2012 09:08:53 +0200 Organization: cbb software GmbH Message-ID: <3u95tkqb1l8t$.t7lzt049tvq8.dlg@40tude.net> References: <788af57d-750d-418d-94bb-75c6557e36a9@g4g2000pbn.googlegroups.com> <3f8db781-fd78-4505-837d-1811c0f9b96f@googlegroups.com> <18bqgllh2jdwg$.upj6crleq9nv$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-07-05T09:08:53+02:00 List-Id: On Wed, 4 Jul 2012 20:33:32 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:18bqgllh2jdwg$.upj6crleq9nv$.dlg@40tude.net... >> On Mon, 2 Jul 2012 23:22:46 -0500, Randy Brukardt wrote: >> >>> All which means that the result would be too complex to use for most >>> people. >> >> Too complex compared to writing it manually? > > Yes. If the meaning of the syntax is not immediately obvious, you run a > significant risk of reading/writing something other than what you really > want. I can think of at least two meanings for A(2..3, 4..4), and that is > where the problem arises. It is unambiguous. 4..4 is a set of indices. 4 is an index. No difference compared to A(4..4) vs. A(4), or, for that matter, "a" vs 'a'. >>> Not to mention the extra overhead. >> >> Again, compared to what? > > Compared to a language without 2-d slices. > > This is distributed overhead, which programs would have to pay whether or > not they used any 2-d slices. It would make all array parameters more > expensive. By-value passed slices should impose no overhead. >> Slices should be first class, that would remove the burden of >> implementation from compiler writers. The rest is just same problematic as >> with referencing single array/container element. There is no big >> difference for one element or a set of elements. > > That's not really possible so long as slices are what C calls l-values. The > problem is passing slices as parameters and allowing assignments into them. Why does this work for array elements then? As for assignments in general, yes, there is a fundamental problem that the user is not allowed to define them as a doubly dispatching operation. But this is not specific to arrays. It is same for all containers. >> The language should support that for all container types, array is one. Ada >> 2012 has a kludge for doing that by reference. There should be another for >> doing that using value semantics (copy-out, copy-in). > > Value semantics only works for a small subset of types (for most compilers, > that subset is elementary types). Moreover, Ada has many types for which > value semantics is not allowed (immutably limited types and tagged types are > the best known). So this would be a feature of fairly limited value. I don't see big problem here. Arrays of referential elements are most likely internally are array of pointers. Slices of such arrays are again arrays of pointers. There is nothing difficult about that, except that usual problems that a reference shall not outlive the object. > I'd rather spend my time getting exception contracts to work. Yes, exceptions (assignments, MD) are more important. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de