The audience would be people like me when I started. I came from VB and dabbling in lisp python ruby. Not APL.
The best tip for reading tacit code that is not published very prominently is that a fork is A D A - (A)mbivalent (D)yad which still leaves the interpretation step of is A actually M or D? Its extremely rare for a train to be meaningful under both M and D. The first objective is readability. Seeing a verbose built in name would clue you in that this is primarily a monadic verb. In terms of less error prone, when you write i. (or #) you mean either iota or indexof. Not some flexible ambivalent version of i. So if you used iota as one of the edges of your fork, you can still make the whole fork dyadic while one tine is monadic. You can also use iota@[ to refer to x side. While you can remember for any sentence that you intended i. to be iota for the next 5 to 30 minutes, that memory fades. A month later you are in the same position as if I were to try to guess what you intended. With a coding style of word for monad, symbol for dyad, it seems to me to be an obvious significant boost in clarity. What originally gave me the idea is that if every verb in J had a dyad implementation, then J can be implemented in every other language. For example in python add(y, x=0) is a function signature where x is an optional parameter. Removing monad as a verb category makes it possible to handle missing parameters at the function level in some languages, and with an adverb equivalent to @] in others. Implementation in other languages is as far as I can tell good for J in that J is likely to retain a performance advantage, and it can only risk infecting others into J-ing. Both the implementation in other languages and newcommers ability to understand is easier if there are fewer categories of functions to understand and implement. see also https://www.reddit.com/r/dailyprogrammer_ideas/comments/3tz8ds/3_part_series_turn_your_favorite_language_into_an/see When everything is a dyad with default : ($:@]) implementation (if not a "real" dyad) then it also makes conjunctions easier to write/use. a cute implementation of the proposal: Monad =: : ($:@]) count =: # Monad Consider: hook_z_ =: 2 : '([: u v) : (u v) ' The core issue in this conjunction is that u can be monadic or dyadic, but for some reason v must be monadic. There are plenty of more sophisticated conjunctions that have to deal with this issue and make these tradeoffs, but the actual best solution for a conjunction here would be to return: ([ u v) if the user of the conjunction wants to use monadic v then he passes (v@]). if he wants monadic u then passes u@]. And it call all be part of a larger dyadic train. This is already possible of course, but the design temptation when writting the conjunction is to guess whether u and v will be monadic most of the time and so create restrictions around optimizing the most frequent use case. With this convention, you can now always use monads when dyads are expected, and so can freely design modifiers as though dyads are the only relevant consideration. While I have what I think are useful enhancements for built-in monads, one good case for making them all : ($:@]) is that a useful alternative hook conjunction above is that ([ u v) has useful intuitive interpretations for M M, M D , D M , and D D. Similar to the Monad definition above, Dyad =: 2 : 'm&$: : v' For all dyads, there exists a default x that is at least not inconvenient. In the worst case that x is ERROR/null/i.0 0.5 _ ----- Original Message ----- From: Dan Bron <j...@bron.us> To: J Programming <programm...@jsoftware.com> Sent: Tuesday, November 24, 2015 3:13 PM Subject: Re: [Jprogramming] dyadic J It would be interesting and helpful to see some motivating examples — code that is shorter, clearer, less error-prone, whatever, using “dyadic J” than the original “standard J”. Would also be helpful to describe the intended audience. For example, are the motivating examples shorter, clearer, less error-prone, whatever, for novices? Calculus students? Immigrants from APL? J veterans? -Dan > On Nov 24, 2015, at 3:02 PM, 'Pascal Jasmin' via Programming > <programm...@jsoftware.com> wrote: > > A simple project whose benefits are described shortly: > > replace (add shaddow names) most of the monadic built-in verbs with > ambivalent definitions that may add extra utility. > > count =: # : #@] > > all monads have an obviously intuitive dyad alternative of v@], but some > monads can be given additional utility in a way that is still providing the > fundamental function. For instance > > iota =: i. : (+ i.) > > > 1 iota 3 > 1 2 3 > > roll =: ? : ?@# > > 5 roll 6 > 1 1 5 4 2 > > > benefits: > > providing extra utility to verbs is nice, but not the main reason. > > It would make J more approachable if every verb is a dyad whose monadic > interpretation can be understood as an ommitted default parameter. > > Its easier to read tacit code, for instance if iota and i. look different, > and the verbose version is verbose for the specific reason that it is a > monad. Tacit forks would look more like (word symbol word) if they are > intended as monadic forks, but may have dyadic tweaks. examples: > > > (3 * iota) 3 > 0 3 6 > 1 (3 * iota) 3 > 3 6 9 > > > The above tweak is a practical dyadic variation of essentially the same fork, > whereas with i. in the fork, the dyad use is likely a misapprehension of the > function. > > this may be cool too, > > > 1 (iota"0 iota) 4 > 0 0 0 > 1 0 0 > 1 2 0 > 1 2 3 > > The main benefit stated more succinctly is that real dyads would look > different than real monads, but overall fewer errors would occur as a result > of valence errors, and it also shortens some code. > > details: > > % - ^ ^. #. #: ] [ 0: ": j. p: r. p.. are examples of monads that would not > get a shaddow name, because their dyad is already a "default x" > implementation. > > * %. [: ". I. { ;: may have useful dyad tweaks I can't think of > > > Some verbs would have weird names > > real_imag =: +. : ({ +.) > length_ang =: *. : ({ *.) > > these may be bad ideas, but are interesting: > > double =: +: : (+:@]^:[) NB. double x times. -:*: > > curtail =: }: : (-@[ }. ]) NB. but }:@] would be more useful > > do =: ". : (".@(, ' ' , ])) > > Another approach is to avoid providing any improvements to the dyadic version > of monadic functions and instead make them all have dyad version of v@] > > Assuming that improvements are useful, can you think of any alternate > implementations for ambivalent: > > * %. [: ". I. { ;: > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
