From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.ada Subject: Re: project euler 26 Date: Wed, 13 Sep 2023 13:24:44 +0100 Organization: A noiseless patient Spider Message-ID: <87il8entv7.fsf@bsb.me.uk> References: <8734ztttpc.fsf@bsb.me.uk> <87fs3ssl6v.fsf@bsb.me.uk> <87a5u0rts0.fsf@bsb.me.uk> <87jzt3qqlb.fsf@bsb.me.uk> <87o7ieq3ne.fsf@bsb.me.uk> <8734zpo3fz.fsf@bsb.me.uk> <87a5twmbum.fsf@bsb.me.uk> <87tts2kenf.fsf@bsb.me.uk> <87bke9kf3l.fsf@bsb.me.uk> <87wmwwr8lx.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="d402efe92178590df0c731029dbf3024"; logging-data="2241315"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18UhVciBDrjsMoyxIQy6vC/lbjn69vatW4=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:FD0x4G+hm0hSlTWTPFm26ZfC6+A= sha1:DbRJ0b/onXj0xselO1P6bkPBl/s= X-BSB-Auth: 1.0e7c7c99d38614ea35b3.20230913132444BST.87il8entv7.fsf@bsb.me.uk Xref: news.eternal-september.org comp.lang.ada:65644 List-Id: "Dmitry A. Kazakov" writes: > On 2023-09-11 18:13, Ben Bacarisse wrote: >> "Dmitry A. Kazakov" writes: >>> You should think about whether storing >>> represents an issue, e.g. in terms of performance and/or space. If it does >>> you should consider suitable implementation of storage that provides >>> required overall performance of needed operations, like insertion, search, >>> cleaning up etc. >> >> Yes, in Ada. Since I can't use universal algorithms, it pays to decide >> all this first because changes will be costly. > > There are no universally applicable algorithms. This may be just a case where we are using terms to refer to different things. I find it hard to believe you don't know what I am referring to since we've had a productive exchange examining an example in detail, but I can agree it's not a good term. I simply could not come up with a better one on the fly. So I'll re-phrase it avoiding the disputed term: simple fibledychops are not available to the Ada programmer, but they are available in some other languages. I suspect you are not interested in what simple fibledychops are, since their absence from Ada means they are not of any importance (and may even be, in your opinion, detrimental to writing good programs). If you really want to know what a fibledychop is, I can have a go at saying more about what they it, but would that be worthwhile? I think you are sure they are a bad idea already. >>> My understanding was that you wanted to see how to use the Ada standard >>> library containers with generics. >> >> Well that's what it turned out to be. At first I did not know that >> built-in types like arrays can't be covered in the same way. > > I know no language where primitive built-in types may have classes. Haskell's type classes are very nice -- every type belongs to one or more classes that determine the permitted operations. And in some languages there are essentially no "built-in" types. In ML for example, the interface to arrays is defined in ML so they can support a universal set of operations shared with many other types, but they are usually implemented by the run-time environment for speed. >> What matters is what types the >> language offers, and what the interfaces to those types are. > > That does not matter at all. Matters the type algebra by which programmer > can create types suitable to model the problem space entities. Yes, but... First, almost every language comes with some predefined types. If the problem space needs fast indexed access to a set of entities, we don't usually have to define our own arrays or vectors. It's so often needed that we expect something to be provided, so what types the language offers /does/ matter. Secondly, the problem space has two components -- data and actions on that data. I suspect by "problem space entities" you mean just the data because that what Ada focuses on. But programming languages can offer tool that help to model the actions in the problem space as well. -- Ben.