tcr=: [ ((= +/"1) # ]) #:@i.@^ The only ambivalent verb in this expression is ^ . The only primitives I want to use names for are monads useable in ambivalent contexts... and then only those monads that are "ambivalently incoherent" to their dyad interpretation. ^ is ambivalently coherent, and so not a monad I would name.
In this case, the monad expression gives error not because ^ does something unexpected, but rather, integer arguments are expected. Something pretty helpful I posted earlier is "automatically" making all verbs ambivalent. Dyad =: 2 : 'if. (0 = 4!:0 <''u'') do. v =. 4 : m end. v&$: : u' tcr=: ([ ((= +/"1) # ]) #:@i.@^) Dyad 2 tcr 2&$: :([ ((= +/"1) # ]) #:@i.@^) tcr 5 0 0 0 1 1 0 0 1 0 1 0 0 1 1 0 0 1 0 0 1 0 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 0 1 0 1 0 1 0 0 1 1 0 0 0 This happens to satisfy one of my main goals for naming ambiguous builtins: Is the whole verb "supposed to be" (main definitional intent) monadic/dyadic? I repeat the "main intent" Monad construct Monad =: 1 : 'if. (0 = 4!:0 <''u'') do. u =. 3 : m end. u : ($:@])' Both Monad and Dyad handle explicit single and multiline explicit definitions too. ----- Original Message ----- From: Raul Miller <rauldmil...@gmail.com> To: Programming forum <programm...@jsoftware.com> Sent: Saturday, November 28, 2015 12:41 PM Subject: Re: [Jprogramming] dyadic J For what it's worth, I do not think that (cr) was written in a form that really plays to the strengths of tacit coding. Here's how I would write a tacit (cr): tcr=: [ ((= +/"1) # ]) #:@i.@^ Now a person might want to introduce formal changes to this algorithm: I think Linda would prefer to eliminate the (@) conjunctions and use ([:) in their place. I suspect the motive there is to obtain an expression which could be derived automatically by (13 :) but I'm not completely sure about that. I think Pascal would prefer to mask the use of primitives with names, and then have each name wrapped in additional code to protect against improper ambivalence. I have not yet been exposed to enough of Pascal's thinking to guess at a motive, though. And each of those approaches does have some merit - in the proper contexts. I suspect that both contexts for the above examples are related to education. But I guess my issue is that ultimately the language is a tool for getting other stuff done. If you focus purely on the language itself you miss out on what you can get done with it. Thanks, -- Raul On Sat, Nov 28, 2015 at 2:27 AM, Linda A Alvord <lindaalv...@verizon.net> wrote: > Pascal and others. I am curious to know if you find tacit code easy to read. > > cr=:([ = [: +/ [: |: #~ #: [: i. ^) #"2 #~ #: [: i. ^ > divy=:([: ,. [: <"1 '*' $~ ] ,~ [: <. %) , [: < '*' $~ [ - ] * [: <. % > > Those two tacit lines seem hard to translate for me. Instead I find the > expressions below are quite easy to follow. > > cr=: 13 :'(x= +/ |:(y#x)#:i.x^y) #"2 (y#x)#:i.x^y' > divy=: 13 :'(,.<"1((<.x%y),y)$''*''),<(x-y*<.x%y)$''*''' > > In most cases, with examples there is little documentation that is > necessary. > > 2 cr 5 > 0 0 0 1 1 > 0 0 1 0 1 > 0 0 1 1 0 > 0 1 0 0 1 > 0 1 0 1 0 > 0 1 1 0 0 > 1 0 0 0 1 > 1 0 0 1 0 > 1 0 1 0 0 > 1 1 0 0 0 > 18 divy 5 > ------┐ > │*****│ > +-----+ > │*****│ > +-----+ > │*****│ > +-----+ > │*** │ > L------ > Maybe it is just that the explicit code looks like mathematics. It might be > interesting and useful to hear how programmers and J users read code most > easily. > > Linda > -----Original Message----- > From: programming-boun...@forums.jsoftware.com > [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Don Kelly > Sent: Friday, November 27, 2015 10:37 PM > To: programm...@jsoftware.com > Subject: Re: [Jprogramming] dyadic J > > there is nothing wrong with saying something like plus =: + conjugate =:+ > and knowing that plus is intended to be monadic (although +(real > number) is the real number in either case. If you want one to work as > monadic onlyand the other as dyadic only-then you have to dress them up a > bit with some test and error message. > you can do mean=: sum divideby count in any language. > J has 2 meanings for + -which are dependent on the context. English also is > like that in that some words have two unrelated meanings (e.g bow , can, > twig, butt ) as well as having some with related meanings (e.g rise, level) > and a lot of other things that depend on context It would be possible to > build up a long list of names so that all uses of the primitives have > different names and do just what the names indicate but is that of any more > than limited use? > > > > On 11/27/2015 1:08 PM, 'Pascal Jasmin' via Programming wrote: >> Are you saying that if I define >> >> floor =: (<. : (<.@]))"0 _ 0 >> >> that it does not have integrated rank support? >> >> The criticism about english and documentation seems hollow to me. I don't > say that Nuvoc is useless because it hasn't been implemented in 150 > languages. An ability to read the dictionary in English is essential to > learn J, and code typically uses english shaddows from profile.ijs. Making > foreign language cover verbs including autotranslating the english ones is > straightforward, and answers that part of the criticism. Using the exact > names from the dictionary (what I'm refering to as autodocumentation because > the exact same place you would look up i. is where iota will be explained.) > seems like an elegant way to ease a shallow learning curve on the process. >> >> The entire criticism could be applied to "you should never assign a verb > to any name" >> >> >> >> >> ----- Original Message ----- >> From: Raul Miller <rauldmil...@gmail.com> >> To: Programming forum <programm...@jsoftware.com> >> Sent: Friday, November 27, 2015 3:27 PM >> Subject: Re: [Jprogramming] dyadic J >> >> On Thu, Nov 26, 2015 at 4:12 PM, 'Pascal Jasmin' via Programming >> <programm...@jsoftware.com> wrote: >>> The only disadvantage I recognize is the point about special code. >> It would be interesting to go over the reasons you do not recognize >> the other disadvantages. >> >>> As to your other points, because the primitives are tacit, I believe > there is integrated rank support. >>> >>> floor b. 0 >>> 0 _ _ >> You might want to read >> http://www.jsoftware.com/pipermail/general/1998-October/000041.html >> >> All verbs have rank support, even verbs which contain explicit >> definitions. However, for some combinations of primitives, the >> interpreter takes special steps - bypassing the default implementation >> of rank support with something more efficient. >> >>> English is needed to read dictionary, and all of the primitives are the > monad dictionary entries, so everything is autodocumented. >> In my experience, documentation is difficult and autodocumentation >> quickly falls victim to entropy. It sounds great, but most examples I >> have seen become incredibly useless in practice. It's possible to work >> around this with manual effort, but the effort involved often seems to >> be greater than the effort of simply doing it manually in the first >> place. Where automation shines is replicating the useful manual >> efforts. >> >>> The advantage bigger than the one you mentioned is better seeing the > intent of code. >> Agreed. >> >> Thanks, >> > > ---------------------------------------------------------------------- > 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
