(quoted thoughts itemized and numbered here so I can respond to them individually)
EH 1> The verbs are passed only noun arguments. There is no functional left argument to *. which the verb could omit to execute. As a simplifying assumption, this has been true, largely because of the parsing rules. That said, Jose has illustrated some cases where it's possible to circumvent this. EH 2> The parser curries the program. The interpreter does not see any brackets which it could omit executing. I would not make a distinction between the parser and the interpreter. Currying is also a term which may or may not apply to otherwise similar trains handled by the parser. EH 3> The parser works from left to right, the interpreter from right to left. The parse result is list of pointers to nouns and verbs that is interpreted/executed from right to left. The lexer works from left to right. The parser works from right to left as documented here: http://www.jsoftware.com/help/dictionary/dicte.htm While you can identify list structures in a variety of things generated by the parsers (arrays, for example, can be said to have list structures), using the terminology that way is more shoehorning the J design into a terminology framework oriented around other languages. EH 4> The parser reads the statement until the first bracket start, the bracket contents are then parsed and interpreted/executed, the resulting noun is packed for later interpretation. All brackets are handled this way recursively until the end of the statement. Then the statement is interpreted/executed. Sort of, but no: Yes, content of parenthesis gets evaluated before its immediate context can finish being evaluated, but parsing is interpretation / execution. When parsing has completed on a sentence, that sentence has a single result which may be a noun (array), verb, adverb or conjunction. That said, when a derived verb (or adverb or conjunction) executes, it may not need further use of the parser (if it does, that's where the recursion would come in - other than that, the parser is not recursive - instead it is iterative with an explicit stack data structure). EH 5> The difference in the tacit case is that the execution is delayed. The bracket contents are packed in a composition, a new verb, a "single verb", which is executed by the nearest explicit parent statement. The pointer to this new verb is included in the list to be parsed, instead of it's noun result. Sort of - see above. EH 6> *. in J is a scalar verb. All it receives is its scalar arguments. It could in theory omit executing the And if the right argument is zero, however, you would need an if statement and a comparison to do that and doing the And immediately is cheaper. I am not sure what you mean by "scalar". If you mean "rank zero", you are correct. I am also not sure what you mean by "receive" - there are at least two potentially relevant "receive" concepts here - the rank 0 concept (handling the individual numbers) and the rank wrapper concept (handling the array structures). That said, trying to break the rank mechanism to borrow "short circuit" evaluation from other languages would... break the rank mechanism. EH 7> Then there is a "hidden" rank-like program handling all scalar verbs. This program takes noun arguments and references to the scalar verb. What it executes is the C/C++ code corresponding to the scalar verb. The scalar verb does not actually exist as an entity. There are several corresponding entities - C/C++ programs. One for each type combination. This "hidden" rank-like program is highly optimized and it is very important to keep special cases out of it. Assuming I understand what you mean by "scalar verb", the scalar verbs actually do exist as entities, internal to the interpreter - these are used to implement the visible behavior of the system. Specifically, for *. the interpreter defines four "scalar verb" functions which are used in its implementation. You can see their declarations here: https://github.com/openj/core/blob/master/ve.c#L132 You can see the definition of the APFX macro (which provides the bulk of the function body) here: https://github.com/openj/core/blob/master/va.h#L154 I could go on, but hopefully this is enough to show you this aspect of the implementation. I hope this helps. (But I am not sure it will help enough - I know I have repeated some of these concepts many times already - in particular the parsing process - so maybe there is something wrong with how I try to express these concepts?) To see the execution steps performed by the parser, I recommend using J's trace facility. For example, please try this: require'trace' trace'(2*3)+5' trace'2*3+5' Each block displayed will contain up to five newline separated items: (*) a separator line identifying the relevant rule from the parsing and execution appendix of the dictionary -- http://www.jsoftware.com/help/dictionary/dicte.htm (*) two or three lines identifying the relevant parsing entities (nouns, verbs, adverbs, conjunctions or punctuation) being evaluated in this parsing step. These correspond to the bolded items from the table of that appendix. (*) the result of that evaulation If parsing completes successfully there will be a ============================== line followed by the final result (which will be the same as the result of the final evaluation). Again... I hope this helps. Thanks, -- Raul On Tue, Nov 7, 2017 at 4:36 AM, Erling Hellenäs <erl...@erlinghellenas.se> wrote: > Hi all! > > The &&(And) in many languages is a control statement. If the left argument > evaluates to false, the whole statement to the right is omitted. > As Raul says, ^: contains the corresponding logic. > This is how I think J works, without actually knowing all of it. I welcome > all corrections. I wrote a similar interpreter. > The verbs are passed only noun arguments. There is no functional left > argument to *. which the verb could omit to execute. > The parser curries the program. The interpreter does not see any brackets > which it could omit executing. > The parser works from left to right, the interpreter from right to left. The > parse result is list of pointers to nouns and verbs that is > interpreted/executed from right to left. > The parser reads the statement until the first bracket start, the bracket > contents are then parsed and interpreted/executed, the resulting noun is > packed for later > interpretation. All brackets are handled this way recursively until the end > of the statement. Then the statement is interpreted/executed. > The difference in the tacit case is that the execution is delayed. The > bracket contents are packed in a composition, a new verb, a "single verb", > which is executed by the nearest explicit parent statement. The pointer to > this new verb is included in the list to be parsed, instead of it's noun > result. > *. in J is a scalar verb. All it receives is its scalar arguments. It could > in theory omit executing the And if the right argument is zero, however, you > would need an if statement and a comparison to do that and doing the And > immediately is cheaper. > Then there is a "hidden" rank-like program handling all scalar verbs. This > program takes noun arguments and references to the scalar verb. What it > executes is the C/C++ code corresponding to the scalar verb. The scalar verb > does not actually exist as an entity. There are several corresponding > entities - C/C++ programs. One for each type combination. This "hidden" > rank-like program is highly optimized and it is very important to keep > special cases out of it. > You can read about this 'hidden' program here: > https://github.com/andrimne/JWithATwist.DocBook/raw/master/target/en/JWithATwistReferenceManual.pdf > I call it the Dyadic Scalar Operation Helper program. > You could add new control structures, but it would be hard to combine a > control structure with the present scalar And in J. > > Cheers, > Erling Hellenäs > > > Den 2017-11-06 kl. 19:46, skrev Don Guinn: >> >> Just curious. How much code would it take to determine that the left >> argument need not be computed? If the probability is that the right >> argument would be zero is very low, then the test would be wasting more >> time than it saved for the improbable case. It makes sense to skip the >> left >> argument evaluation if this evaluation were very complicated and took a >> lot >> of time. But a good programmer would be aware of this case and would not >> depend on the interpreter/compiler to take care of it for him. >> >> On Mon, Nov 6, 2017 at 11:19 AM, Raul Miller <rauldmil...@gmail.com> >> wrote: >> >>> ^: is J's short circuit operator. >>> >>> we do not need to overload verbs for this. (Though I understand peer >>> pressure makes us want to incorporate features of other programming >>> languages which would cripple J.) >>> >>> Thanks, >>> >>> -- >>> Raul >>> >>> >>> On Mon, Nov 6, 2017 at 12:41 PM, Moon S <moon.aka....@gmail.com> wrote: >>>> >>>> It could be great to have and. and or. in if. and while. conditions, >>> >>> like >>>> >>>> if. a~:0 and. b<x%a do. ... NB. or right to left? also a question >>>> but I understand the rules for their combination would be difficult >>>> and out of the language discipline. >>>> A pity anyway. >>>> >>>> On Mon, Nov 6, 2017 at 6:42 PM, 'Mike Day' via Programming >>>> <programm...@jsoftware.com> wrote: >>>>> >>>>> ...not forgetting that *. is least common multiple for integer >>> >>> arguments. >>>>> >>>>> eg >>>>> >>>>> 12 *. 16 >>>>> 48 >>>>> >>>>> Mike >>>>> >>>>> Please reply to mike_liz....@tiscali.co.uk. >>>>> Sent from my iPad >>>>> >>>>>> On 6 Nov 2017, at 11:35, Rudolf Sykora <rudolf.syk...@gmail.com> >>> >>> wrote: >>>>>>> >>>>>>> On 6 November 2017 at 12:21, Linda Alvord <lindaalvor...@outlook.com> >>> >>> wrote: >>>>>>> >>>>>>> Wasn't sure so I guess the answer is it gets evaluated: >>>>>> >>>>>> >>>>>> Well, sometimes it doesn't: >>>>>> >>>>>> (>:a) *. (0<a=.1) >>>>>> 2 >>>>>> (>:a) *. (0<a=.0) >>>>>> 0 >>>>>> (>:a) *. (0<a=._5) >>>>>> 0 >>>>>> >>>>>> Ruda >>>>>> ---------------------------------------------------------------------- >>>>>> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
