My previous examples did have a bug (inadvertant declarations in 'ttt' too)
'tttx' (floor [ cocurrent@[ ]] ) 3.5 |value error: floor this behaviour or code style is terrible though. if cocurrent is inside another verb, then it does get switched back on exit of that verb. inl =: (cocurrent@] ".@] [)"1 0 'floor' inl 'base' (or through an adverb) is a better way to dynamically invoke floor within a tacit expression. The example of calling from a single tacit expression code that reassigns a name used later in the expression also has plenty of alternatives. So if J were changed such that all names in a tacit expression were evaluated at start of application it would be fine. Nouns are evaluated at definition time. Maybe a global foreign that lets you specify an adverb (f.) to apply to each tacit expression prior to execution, it would allow the optimizations. But even enabling the optimization without regard to backward compatibility on such (tacit locale/search path changes, or reassignment call from the same verb that uses it) code, would still allow it to be done much more cleanly through explicit code. ----- Original Message ----- From: Henry Rich <henryhr...@gmail.com> To: programm...@jsoftware.com Sent: Friday, November 27, 2015 9:20 PM Subject: Re: [Jprogramming] dyadic J On 11/27/2015 9:09 PM, 'Pascal Jasmin' via Programming wrote: >> Now, you would like to turn that into +/@:times, but what if times contains >> a reassignment of plus? > I mentioned looking inside tacit named verbs, which wouldn't be an issue. Here I was showing that looking inside the tacit named verb plus would not work. >> Or if it modifies the search path? > floor_base_ =: <.@] > > floor@:((cocurrent 'ttt') ]] ) 3.5 > 3 > > or > > 'ttt' (floor [ cocurrent@[ ]] ) 3.5 > 3 > > > times =: 3 : ' floor_base_ =: >. label_. y' > (floor [ times ] ] ) 3.5 NB. def of floor read prior to times executed. > 3 > > a tacit expression can't change the locale of its entire expression. > (basically it is changed back) floor is dereferenced when it is executed, or > otherwise gets its locale from the calling code. ". will execute strings in > the changed locale though. I didn't say change the locale, I said change the search path, which a tacit verb can certainly do. But in any case, tacit verbs can call explicit verbs; are you saying that this work applies only to all-tacit programs? I think beginners shouldn't be shown tacit code for the first six months. And last: a tacit verb CAN change the locale of its caller, if it ends with 18!:4 . How else could cocurrent work? Henry Rich > J pretty much already works as though it should be able to look inside names > correctly, because it gets the right name "correctly" > > (floor [ cocurrent@[ ]] ) f. > <.@] [ 18!:4@(<^:(L. < *@#))@[ ] ] > > > basically, TACIT code with f. and without f. runs identically, afaik. > > > btw, my proposal only shaddows slightly under half of the monadic verbs... so > no modifiers. > > > ----- Original Message ----- > From: Henry Rich <henryhr...@gmail.com> > To: programm...@jsoftware.com > Sent: Friday, November 27, 2015 8:35 PM > Subject: Re: [Jprogramming] dyadic J > > Yes. If you are going to replace symbols with names on the grounds that > the names are mnemonic... you ought to choose names that actually ARE > mnemonic. > > Looking inside named verbs opens a can of worms. Consider > > plus =: + > plus/@:times"1 somenoun > > Now, you would like to turn that into +/@:times, but what if times > contains a reassignment of plus? Or if it modifies the search path? > Only the name is stacked; the value is looked up as the name is executed. > > Making plus/ work like +/ is IMO effort that should be put elsewhere, > like fixing bugs or supporting multiprocessing. If the user wants > something that works like +/, let em write +/ . > > Henry Rich > > On 11/27/2015 6:44 PM, 'Pascal Jasmin' via Programming wrote: >> Is the purpose of your quiz to point out that the names are not ideally >> descriptive? >> >> To discuss just the compose/appose question, I would think compose would be >> a good name for @: . & is special for its dyad form. I just looked up >> appose in dictionary (http://www.thefreedictionary.com/appose ), and don't >> see the relevance. >> >> Anyways, as a language design idea, not overloading symbols/verbs would be >> helpful (limiting variation to the concept of default parameters, and I've >> always liked the idea of default parameter implementations, and like the >> concept of dual arguments to every function). I think its also possible to >> improve the J interpreter with: >> >> looking inside named tacit verbs for SC and integrated rank. >> substituting @]@ with @ >> substituting (u : w)@v with u@v >> >> actually I think all of these are possible with a J adverb enhancement to f. >> ... but requires use of an equivalent to f. >> >> >> >> >> ----- Original Message ----- >> From: Henry Rich <henryhr...@gmail.com> >> To: programm...@jsoftware.com >> Sent: Friday, November 27, 2015 4:49 PM >> Subject: Re: [Jprogramming] dyadic J >> >> >> >> On 11/27/2015 4: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? >> Yes, that's what we're saying. Integrated Rank Support is an >> interpreter feature. >> >>> 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. >> You're right about English's being required to read J docs, but that is >> a regrettable fact, not an advantage to build on. >> >> The J language itself does not use English. Having cover names in >> different languages would only make things worse, by making beginners' >> code meaningless outside their own language. If they have to use a >> lingua franca, it might as well be J rather than JayForBeginners. >> >> [I want to reiterate that I think the idea has merit to steepen the >> learning curve, but only the bottom fifth of it. That could be a help: >> if you realize that users are going to use the names only as a beginning >> crutch, you don't have to worry about things like performance so much.] >> >> >> I have my doubts about the mnemonic value of using the Dictionary >> names. We've all seen the names a hundred times; now take this quiz: >> >> 1. What is the rank of: >> >> Appose >> At >> Atop >> Bond >> Compose >> >> 2. Describe the difference between Appose and Compose in words, and >> explain why the names were chosen. >> >> 3. Use the word Ravel in a sentence, and explain why it is a good name >> for (, y). >> >> 4. Does (x Residue y) calculate x(mod y) or y(mod x), and why is it that >> way? >> >> 5. Describe the action of (; y) and explain why Raze is a good name for it. >> >> 6. In ItemAmend, does an Item Amend something, or is an Item being >> Amended, or is something else happening? >> >> 7. Why is the name Agenda appropriate, if only one item on the agenda is >> actually executed? Are the rest tabled? >> >> 8. How does the name MemberOfInterval describe the action of (x E. y)? >> >> 9. What direction do the diagonals defined by Oblique run? >> >> 10. Select a more mnemonic name than Tally for (# y). >> >> >>> The entire criticism could be applied to "you should never assign a verb to >>> any name" >> Change it to "you should never assign a primitive to any name" and I'd >> agree - except for beginners. >> >> Henry Rich >> >> >> >> >>> >>> >>> ----- 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
