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
