On Thu, Nov 26, 2015 at 10:58 AM, 'Pascal Jasmin' via Programming <programm...@jsoftware.com> wrote: > Let me make up a term and call it "ambivalent coherence". Referring to a > function that behaves coherently under both monad and dyad use. Where > coherent is defined as the only mental effort required to know the monad form > is substitution of a default parameter for x.
That is a good and interesting construct. But I would like to point out that there are related concepts, both for ambivalence and for data conditioning, that this is not sufficient in the general case, and that J is not the only language which has such issues. So... (1) There can be hints which eliminate ambivalence in some cases. You know, for example, that the left verb of an @ phrase is used monadically. Or, the even tines of a fork are used dyadically. (2) You also need to understand the data. What is it's shape or shapes? Is it character, boxed, numeric, complex, integer, ...? What does the data represent? What is its purpose? Knowing that the data represents frequency information or amplitude information (or in the case of a self inverting fourier transformation - either) tells you that we're doing something very different than knowing that the data represents combinations or permutations or something of that nature (for example). But you get similar issues with other languages. If you have ever chased down a race condition you will know the pain of trying to figure out whether data has been initialized properly. If you've ever needed to speed up a transactional system you'll understand just how awfully much a program can differ from what people understand it to be. If you've ever worked with a code coverage tool you'll understand the difficulties imposed by conditionals and/or the trickiness of dealing with exceptional cases. And if you have ever worked with the APIs provided by a company which has been in business for a while, you'll probably have experienced the quirkiness of data structures which have been in use for a long time. So... documentation, examples, simplification, etc. all have their place here. And, the larger a system gets, the quirkier it gets and the simpler you have to e, to deal with it. Roughly speaking. (There are contrary trends also...) Anyways, you've got a worthy effort here, but I would not lose sight of the related issues. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
