> 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.
When Ken was designing APL (J), I don't think he thought in terms of "information density is good". The choice was + (or "plus") vs. plus plusvector plusmatrix plusrank3 or even plusboolean plusinteger plusreal pluscomplex plusbooleanvector plusintegervector plusrealvector pluscomplexvector etc. In the special case of -, is it easier to have a single symbol for negate and minus, or two separate symbols? APL and J opt for the one symbol. ----- Original Message ----- From: Dan Bron <[email protected]> Date: Tuesday, February 2, 2010 13:55 Subject: Re: [Jprogramming] remove hooks or add h. ? To: 'Programming forum' <[email protected]> > 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
