gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic mutidimensional arrays


From: Benjamin Kowarsch
Subject: Re: Dynamic mutidimensional arrays
Date: Sat, 8 Apr 2023 02:13:24 +0900



On Sat, 8 Apr 2023 at 01:03, Fischlin Andreas <andreas.fischlin@env.ethz.ch> wrote:

This all sounds good to me and doable.

Thank you for your support.
 
A notation such as

vector^.data[index]
or
mat^.data[i,j]

is IMHO already very nice, while avoiding any feature creep, yet lessening the admitted difficulty to work with matrices and similar data objects in classical M2.

Keep in mind though that a decision has to be made whether such a type is exposed in the public interface or hidden in the implementation and only exposed opaque. If it is an opaque type, then you won't be able to use the vector^.data[index] notation in any client library, but you have to use the mutator and accessor function provided in the public interface, which is less convenient.

This then provides ample incentive to most developers to expose the type in the public interface and not use opaque types. That isn't a good thing. A good design is a design where the best practice approach has the most convenient notation so that there is an incentive to do the right thing.

It is for this very reason that we introduced syntax binding for these situations. And because we have that, we could then afford to permit the use of record types with indeterminate array fields only in implementation modules, so they can only ever be provided as opaque types.

The syntax binding facility is a small price to pay for not opening Pandora's box.

Back in the day of the ISO standardisation, Albert Wiedemann and I tabled a proposal for binary coded decimals (BCDs) in the language so that infix notation could be used with BCD numbers. The entire room then howled in protest. Why? Because at one of the previous meetings that we didn't attend and weren't aware of, they had just gone through the same thing when Rick Sutcliffe proposed to have complex numbers in the language. So, they told us "If we grant you BCDs, this guy [pointing at Rick] will want to have his complex numbers, and in the next meeting some other guy will want vectors, matrices and what else, you're opening Pandora's box there". So, we withdrew our proposal and everybody cheered.

When Rick and I started out working on our revision, one of the first things that we discussed was complex numbers. As a mathematician he wanted them in the language of course, but I did not in order to avoid opening Pandora's box. So we agreed if we could work out a reasonable way to have infix notation with library based complex number types, then they would be kept out, only if we couldn't, would they be in.

Sometimes you need to invest a little extra upfront in your design to earn a dividend in the long term.

regards
benjamin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]