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: 103376,bb7cc916bd63ab43
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder.news-service.com!feeder4.cambrium.nl!feed.tweaknews.nl!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 22 Jan 2009 11:01:36 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Performance of element access in Vector
References: 
 <0a8baaf0-19f7-40c0-a041-884e93fa7020@w39g2000prb.googlegroups.com>
 	<gl3c7s$m6i$1@munin.nbi.dk>
 <f7594970-ade3-4ad8-9a30-41e877da194e@m2g2000vbp.googlegroups.com>
 	<1fp3pbmn4q3o5.1b0fk6lircbld.dlg@40tude.net>
 <d21122ad-db41-4cfb-a66c-142157de2e07@p36g2000prp.googlegroups.com>
 	<4c38e681-3996-4ce9-ad33-6f7bd790fdbf@u18g2000pro.googlegroups.com>
 <edac070e-bc97-4665-8279-5b82ff55dfb8@b1g2000yqg.googlegroups.com>
In-Reply-To: 
 <edac070e-bc97-4665-8279-5b82ff55dfb8@b1g2000yqg.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <49784401$0$31872$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 22 Jan 2009 11:01:37 CET
NNTP-Posting-Host: 55ade562.newsspool3.arcor-online.net
X-Trace: 
 DXC=Pi<e3bGQL9Ij7E:bke<5HFMcF=Q^Z^V3H4Fo<]lROoRA^YC2XCjHcbIVFX03I1?Jb@;9OJDO8_SKFNSZ1n^B98iJ3=nWLKnNOKE
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:4447
Date: 2009-01-22T11:01:37+01:00
List-Id: <comp.lang.ada>

george.priv@gmail.com schrieb:

> If you just try to get away from C++ paradigm you can find other ways
> to address these issues with raw arrays.  Think in functional
> programming framework for a change.


I'm curious.  Vector algorithms use the STL paradigm specifically,
rather than some C++ paradigm.  The STL with its generic algorithms
has a Scheme history (and an Ada one).  FP languages tend to start
from sequential access to data, using recursion on the tail of some
list as their model.  The STL notions of ::iterator and
::reverse_iterator, in particular considering their const variants,
suggest the same, to me at least.  So I have two questions:

1) How does straight forward STL iteration differ from
FP recursion on lists? (Only thing I can think of is
that non-pure languages can use destructive update
of array components, so to speak (tampering in some Ada sense).)

2) Can we rely on pure FPL style compilation techniques
(as if there were neither refs nor monads) to achieve
compact representation of lists/arrays in memory,
and little copying?
(I am assuming that memory use is an important criterion
when targetting small capacity hardware.)