Re: project euler 26

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2023-09-13 14:24, Ben Bacarisse wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 2023-09-11 18:13, Ben Bacarisse wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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