Prepass means essentially that this happens after word formation but before parsing. That does eliminate some problems, but creates new ones. It also suggests that you would be supporting explicit control words. But it also means that you need to put a lot more thought into how these would be represented (and stored) - there's no inherent point to using linear representation to "unparse" here.
(Do inner (. ). definitions get reparsed every time the outer expression gets evaluated? That might be the simplest approach, but does require significant changes in explicit handling.) Multiline means that you get into behavior somewhat like you get when m :0 appears on a line. But getting out of that might be more complicated than it is now (because you might not know if you need ). or a sequence of them or ) to end it - for example after pasting something big into your session). The complexities introduced by multi-line probably means that interactive environments would want to colorize (. ). definitions (especially incomplete definitions while being entered) based on the presence/absence of mnuvxy seen so far (probably not the current line though). Thanks, -- Raul On Tue, Sep 26, 2017 at 3:34 PM, Henry Rich <[email protected]> wrote: > My idea is that (. and ). be handled before parsing, as a prepass. Thus, > the (. construct can be spread across multiple lines. [Perhaps this would > be supported ONLY for lines coming from a script, for ease of > implementation.] Normal function definition would look like > > name =: (. > lines... > )."0 > > I think that nesting becomes a non-issue, since (. ). will simply be > replaced by > (m : string). > > Display of a verb value, especially one containing nested definitions, will > require some thought. > > Henry Rich > > > On 9/26/2017 3:20 PM, Raul Miller wrote: >> >> The line "Use (. ... ). to be recognized as m : '...' where m is >> chosen based on occurrence of xyuvmn" in >> >> http://code.jsoftware.com/wiki/System/Interpreter/Requests#Fast_Function_Definition >> suggests that we would use m : '...' for the display format of those >> function definitions. >> >> That said, (. x u . v y ). would need to be something like >> 2 :(':',LF,'x u . v y') >> >> Still, we could at least lay out the rules for picking the value of m >> and for adding to the definition: >> >> if n (or v) is present in the parsed words of defn, we generate 2 : defn >> if not, but if m (or u) is present, we generate 1 : defn >> >> if x is present, we precede defn with ':',LF, >> >> If neither u nor v is present but x or y is, we generate 3 : defn >> >> Note also, though, this is a much bigger problem than it might first >> appear to be, since it would require new parsing rules for the syntax >> table. And we have not nailed down some of the other specifics: >> >> First (minor problem): this leaves unspecified what to do if none of >> the key names are present. Hypothetically, that could be 0 : defn or 3 >> : defn or 4 : defn or something else. Perhaps an error condition, on >> the grounds that the programmer probably did not mean to be doing >> that. >> >> Second (bigger issue): we have not said whether (. ). would nest. If >> implemented at the parsing level, it could easily nest. But that's a >> different syntax than an unnestable implementation, and creates >> further problems >> >> Third issue (potential side effect of using the parser to handle >> nesting): we would probably have to treat u and v as special >> placeholder verbs during that parsing process, then hope that the >> resulting linear representation does not create conflicts if we pass >> noun arguments. >> >> Fourth (potential breaking issue): if they nest we would need to use a >> linear representation of the inner instances in the outer instances. >> This would break if the (. ). contained an explicit definition with a >> non-evaluatable linear representation (for example an explicit >> definition with more than two lines). >> >> As a crude illustration of that fourth issue, imagine: >> (. v (2 :(':',LF,'t=. x v . u y',LF,'t')) u ). >> >> That said, depending on the details of how this was implemented, some >> of these "issues" might turn out to be non-issues. Forbidding nesting, >> for example, would defeat most of these problems (and, probably, a lot >> of the motivation for doing this in the first place). >> >> But, anyways... implementing this might be a bit more involved than it >> first appears, depending on how these kinds of subtleties are handled. >> (And, that has implications for documentation). >> >> 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
