Pascal Jasmin wrote:
> to clarify, its not that I don't understand hooks. Its that a fork can
> replace any hook,
> and if all trains were forks, then the extra step of figuring out what kind
> of train we
> are reading wouldn't be necessary.
Leaving aside my personal affinity for hooks, which I admit I take to
counterproductive extremes sometimes (a tendency I've tried to
moderate in recent years), some hooks have broadly recognized value:
#~ filter
<;.1~ partition
</.~ categorization
These are so common as be instantly recognizable (aka idioms), which reduces
cognitive load while saving keystrokes. I would not
want to give up that value for the sake of knowing every verb train is a fork.
But then, I also have to admit that I can't
remember "counting" a verb train to determine its parity and hence its
hookness. I find most hooks "obvious", I think. Maybe this
is because most code I read is code I wrote, and I know how I write code?
We can actually use this kind of thinking to alleviate the parity problem:
since in most "real world" circumstances, the majority
of the code we read is directly under our control, we could locally enforce the
fork-only rule (and even have code that polices
this), which should suffice.
Of course, there's no way to enforce e.g. that no post to the Forum uses a
hook, but I think this is less important.
-Dan
PS: If we don't think the idioms above are enough to burden ourselves with
verb train semantics based on parity, can we think of
*any* semantic which would make this burden worthwhile?
That is, (f g) is currently defined as (y f g y) in the monadic case and (x f g
y) in the dyadic case: Pascal suggests that a more
useful definition would be no definition at all (i.e. error). Can we think of
a definition even more useful than that? Bearing in
mind that any definition (other than "no definition") comes at the price of
having to know the parity of every verb train to
interpret correctly.
I ask because I think one of J's formative philosophies is that information
density is good, and of course to pack a "lot" into "a
little", one often pays a price. For example, is - "subtract" or "negate"?
The answer is ambiguous; the symbol is overloaded.
This is even more "unpredictable" than a verb train, because in the case of a
verb train, at least you can determine its parity
(hence, its meaning) at definition time. This is in contrast to the overloaded
symbol - , where we can only determine its valence
(and hence its meaning) at run time. Put another way, the parity of a train is
fixed; the valence of a verb isn't, and can only be
resolved by context (the same verb can be used with different valences at
different times).
So permitting ambivalent verbs cost us some ambiguity, but it benefitted us
power and brevity. Can we, should we, make the same
tradeoff with even-parity verb trains? If so, and if we had the luxury of
breaking backwards compatibility, what would be the best
way to achieve that?
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
