This is an interesting idea and a slick implementation. I think this style of programming needs names for the dyadic verbs to be consistent.
for example: (box 6) e. box every iota 10 should probably be memberin=:e. (box 6) memberin box every iota 10 1 a newcomer still needs to worrry about parentheses in the right places box 6 memberin box every iota 10 ┌─┐ │0│ └─┘ I am not sure it's a better style, but it's an interesting style and might be an entry for some into J. It reminds me a bit of this: http://code.jsoftware.com/wiki/Primitives_to_Mnemonics On Tue, Nov 24, 2015 at 10:03 PM, 'Pascal Jasmin' via Programming < programm...@jsoftware.com> wrote: > Here's my suggested implementation. The only linebreaks are at empty > lines. > > > *`<`>`<.`>.`<:`>:`#`=`+:`-:`|`|.`+`-.`*:`{`}:`{:`{.`}.`;`,`,.`,:`;:`C.`A.`q:`e.`/:`\: > 4 : '(> y) =: (x `:6) : (x `:6@]) label_. y '"0 ;: 'sign box open floor > ceiling decr incr tally self double halve magnitude reverse conjugate not > square catalog curtail tail head behead raze ravel items itemize words > cycle anagramindex factors razein gradeup gradedown' > > i.`i: 4 : '(> y) =: (x `:6) : (+ x `:6) label_. y '"0 ;: 'iota steps' > > > ?`?. 4 : '(> y) =: (x `:6) : (x `:6@#) label_. y '"0 ;: 'roll rollf' > > > +.`*. 4 : '(> y) =: (x `:6) : (({ x `:6)"0) label_. y '"0 ;: 'real length' > > > indices =: I. : ( I.@:=) > > The only special monad not previously mentioned > > 3 indices 3 5 1 3 2 3 > 0 3 5 > > > all names are lowercase, and match the dictionary except > > sign incr decr iota rollf items factors > > > ----- Original Message ----- > From: 'Pascal Jasmin' via Programming <programm...@jsoftware.com> > To: "programm...@jsoftware.com" <programm...@jsoftware.com> > Sent: Tuesday, November 24, 2015 4:39 PM > Subject: Re: [Jprogramming] dyadic J > > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
