Hi all!
It seems like fast function definitions is only for creating explicit J
verbs, adverbs and conjunctions?
This means it is only vaguely related to my proposal of tacit verbs with
explicit J syntax?
Maybe the fast function definition discussion should therefore have it's
own thread?
Let's say we wanted to implement tacit-v verbs.
-Is there a construct like { ... } or (. ... ). that could possibly be
used for a new kind of bracket notation?
-Would x and y or [ and ] be suitable as symbols of the left and right
arguments? If so, which of them ? If not, what would be a suitable
representation of the left and right argument ?
-Could the interpreter be easily modified to allow the explicit J syntax
in this new bracket construct, or would it be difficult or impossible to
achieve?
In the JWithATwist interpreter the difference between how brackets with
explicit J code are handled and how tacit-v brackets are handled is
about four lines of code. It think this indicates that this might not be
such a revolutionary change in terms of actual code changes.
Cheers,
Erling
On 2017-09-26 22:34, Henry Rich wrote:
Good point, colorization. I never thought about that.
The big difference between Fast Functions and 3 : functions is that
Fast Functions are recognized when a script is loaded, instead of when
the 3 : is executed. It is the fact that 3 : is executed like any
other conjunction that prevents nesting of multiline verbs: the nested
verb can't be defined until it is executed, and by then its definition
is long gone.
The innermost (. ). is analyzed and replaced by (m : string). The
process continues for all nesting levels. This completes the prepass.
The generated verbs - (m : string) forms - are handled as they are
now, when the : is executed. That means nested verbs are not
processed until they are encountered during execution.
Linear representation is used to make the (3 : string) form atomic.
Yes, you would need to balance (. .
Henry Rich
On 9/26/2017 4:02 PM, Raul Miller wrote:
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,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
