[Sorry for the delays in my replies - I didn't have as much time to get
engaged in this topic as I expected.]
Raul wrote:
> I disagree that [: capping a fork is unrelated to its definition.
I simply can't see it any other way.
Capped fork is a grammatical rule, and the parser recognizes it by the
presence of the token [: as the left tine of a 3-verb train. At this point,
it's all symbolic manipulation, and [: is treated as an opaque symbol, and
the capped-fork rule is invoked. At no point is the definition, domain,
codomain, rank, valence, interpretation, color, flavor, scent, or any other
aspect of [: relevant except its spelling, viz a [ followed by a : . [1]
To understand why, we must recall that capped fork is a grammatical
_exception_. In order to provide its benefit, it trades off some
consistency, and over-rides the standard rule of a 3-verb train (fork).
Whereas (f g h) would normally invoke f (and g and h) when applied to
arguments, in the case of ([: g h), f, which is [:, is _never invoked_.
This is opposed to the concept that [: is invoked and its empty domain
somehow passes a "null" LHA to g which then (lacking a left argument)
applies itself monadically to the output of h . There is simply no concept
of a "null argument" in J, nor of a suppressed error (which also somehow
conveys information). Otherwise E. : ~. would work as a substitute for [: ,
because their domains are identical. That [: is _never invoked_ is the
key.
What that means is [: would serve to cap a fork, //no matter what its
definition//. In other words: provided it is a verb, [: could have any
definition at all. For example, the following sequence
([: +/ i.) 5
10
[: 123
1 2 3
(+/@:[:) 123
6
([: +/ [:) 123
6
... would be perfectly legitimate, in the sense that we could change the
Vocabulary entry for [: to define it to mean 10&#.^:_1 , without any impact
on the interpretation or function of capped fork.
Meaning, of course, we don't need [: at all. Because the definition of the
capping verb is arbitrary, J (KEI) could have chosen to use _any verb_ to
serve as a the cap. For example, §II.F could have defined capped fork with
a left tine of # . If that were done, and _keeping the definition of #
exactly the way it is now_, (# %: */) y would mean "square root of product"
rather than "geometric mean" as it does today.
Of course, that example highlights exactly why we don't use # or any other
useful verb as the fork cap: because doing so would preclude it from
participating as the left tine of an uncapped fork. In effect, you'd
handicap the verb, and as a consequence, the language. It would take more
effort to say many (simple) things.
So, rather than handicapping a useful verb, a useless verb was introduced;
one that you'd never want to use as the left tine of a fork. What's the
best way to ensure that no one would want to use [: as the left tine of a
fork? By making that impossible. By giving [: an empty domain, so it will
produce errors under all circumstances. To invent useless verb of all time.
Except, of course, when you want to cap a fork.
So, I hope it is clear now that [: f g is a grammatical rule that doesn't
care about the definition of [:, why [: was introduced, why it has an empty
domain, and that its empty domain is simply a side-effect of offering capped
forks: in effect, a favor to the user.
[Aside to Raul: I'm sure you don't find any of this surprising, but I just
wanted to expand on some of the subtler points for anyone reading this who
isn't as familiar with the material.]
> I imagine that there are people that would be confused by this
> distinction, [...] and the only sure way to avoid them being
> confused by [...] would be to avoid coding entirely.
Maybe I should have presented this position -of constraining my use of [: to
capping forks- as a way to honor [: and its purpose. In effect, to promote
the language and recognize its elegant design. To allow newcomers, through
repeated exposure, and the absence of distractions, to start learning to
make these fine distinctions.
Or maybe I'm just being a doctrinaire. I'm certainly not insisting this is
a hard-and-fast rule, or that everyone needs to follow it. Use what works.
Just understand what you use.
-Dan
[1] That's why, as you said:
> alternative phrasings using the definition of [: do not have the same
consequence.
That said, the interpreter does take special steps to allow for cap to have
aliases, as in cap=:[: . See, for example, Henry's discovery in
http://www.jsoftware.com/pipermail/programming/2006-May/002349.html :
> It looks like f in (f g h) is inspected to see if it is [:, and
> if it is, special steps are taken.
This special casing can be found in
https://github.com/openj/core/blob/master/cf.c . Personally, I'm with Henry
when he said:
> If someone wants cap, let 'em write [: .
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
