Hi Dan. I appreciate your thoughts. While you fully understood my proposal, I am more or less evangelizing my coding style rather than claiming tenfold productivity increases if only J could signal more errors.
A bit about filter Filter=: 1 : 'u # ]' makes a better adverb (or fork component) than '#~ u' because it works for dyad u as well. 2 < Filter i.8 3 4 5 6 7 or even numbers > 2, 2 (< *. 0 = |) Filter i.8[or without the adverb, 2 (] #~ < *. 0 = |) i.8 4 6 As pretty as the above version might be, I think it is idiomatic for most of us (especially beginers) to avoid dyads whenever possible by currying, even though predicate functions fed to filter are almost always dyadic. I (speaking for beginers/intermediates) would typically write the above as: (] #~ 2&< *. (0&=)@(2&|)) i.8 4 6 but I had to futz with the parentheses to get it to run, and I don't fully understand why (2&|) needs a parenthesis, though (0&=) not needing them should give me a clue. Forks make great hammers. The 'odd positioned' verbs have access to both arguments. Any odd positioned element except the rightmost can be a noun. I find that I can be more productive thinking what can I hammer with a fork instead of what kind of trains should I consider to....(should I use this lighter but lesser hammer called a hook in this instance or my great hammer) ----- Original Message ---- From: Dan Bron <[email protected]> To: Programming forum <[email protected]> Sent: Tue, February 2, 2010 4:54:49 PM Subject: Re: [Jprogramming] remove hooks or add h. ? 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 __________________________________________________________________ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
