That's a rather frustrating response because we are not discussing the meaning of your post, nor of mine.
But, ok, I guess that means I need to simplify: (1) You are wrong in your statements about how the J interpreter works and how J's parsing works. (2) You are correct that omitting processing of arguments for operations like *. would be bad. Thanks, -- Raul On Tue, Nov 7, 2017 at 8:24 AM, Erling Hellenäs <erl...@erlinghellenas.se> wrote: > Hi all! > > I did not write the post because I want information about the J interpreter > but to describe why *. can not be used as an if structure. > I welcome comments about what is wrong with the text, but what I mainly > expect is that responders look at the meaning of my post and the question we > discuss and continues with this discussion. > > Cheers, > Erling Hellenäs > > > Den 2017-11-07 kl. 13:58, skrev Raul Miller: >> >> (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, >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
