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=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A, 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: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: project euler 26 Date: Thu, 14 Sep 2023 08:33:35 +0200 Organization: A noiseless patient Spider Message-ID: 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> <87il8entv7.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 14 Sep 2023 06:33:34 -0000 (UTC) Injection-Info: dont-email.me; posting-host="331e1744756620e00f22b9faf2b77ce0"; logging-data="2669315"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/VOsIy503fP8ATWH+TGMlIEHTrcMqS2WY=" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Cancel-Lock: sha1:tlId+funmSRBbt/jF6xNE55a+aE= In-Reply-To: <87il8entv7.fsf@bsb.me.uk> Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:65648 List-Id: On 2023-09-13 14:24, Ben Bacarisse wrote: > "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. Each language feature has a purpose. Roughly it is called language paradigm: how routine programming activities are approached when using the language. Ada's paradigm is different from what you expect. E.g. sunroof might be a simple car feature, but a submarine user would not be impressed. >>>> 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. No difference to Ada. Integer belongs to an integer class and there is a formal generic type for the class members. The problem I am talking about is that there is no run-time objects of and no non-integer type can be put in that class. > 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. Can I take integer type, derive a new *integer* type from it such that it would also implement an array interface? So that I could access integer decimal digits? Or use your "fibledychops" with on it? This is impossible in Ada. Which is in particular why Ada ordered containers do not implement array interface. They simply cannot. Ada has a generic array interface declared as generic type Index_Type is ... type Element_Type is ... type Array_Type is array (Index_Type range <>) of Element_Type; but even that is not implementable by anything except by a proper array. Yes, there is an ugly iterator hack Georg mentioned in another thread. The hack allows containers to *look* like arrays in syntax, e.g. you can loop and index a container this way. This is possibly what you meant referencing ML. But I do not know ML. >>> 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. Index and element types always same? When I derive a new type from the array element type, would an array of such elements related to an array of base element type? Can I control the decision? Can I have an array of elements from both element types? How such arrays are related to the specific element type arrays. Then add the index types hierarchy to the picture... You would say: uninterested. So I am in "fibledychops"... (:-)) > 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. No, in Ada it is both. You can add "free functions" as you wish, anytime, anywhere. It is the classes and their primitive operations (AKA methods) that pose problems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de