On Tue, Jul 24, 2012 at 4:52 PM, Dan Bron <[email protected]> wrote: > Raul wrote: >> Personally, I not only cannot see any valid interpretations where its >> domain is not empty. > > This is the crux. The use of [: to cap a fork is _unrelated to its > definition_ (including domain, codomain, interpretation, rank, and > everything else). Capped fork is a _grammatical rule_, and is applied by > the parser before the definition of [: is needed or relevant. Capped fork > could just have easily been defined by (+ f g) as ([: f g) and + could still > have worked as usual - except, of course, as the left tine of a fork (where > its definition is irrelevant and invocation precluded).
I disagree that [: capping a fork is unrelated to its definition. I will agree that when [: caps a fork that: (a) the result of [: is not used (it can produce no result) (b) alternative phrasings using the definition of [: do not have the same consequence. ([:"_ -: %) 0 |domain error But I suppose your point here is that [: having an empty domain is not, by itself, sufficient to make a fork's domain empty when [: is used in the left tine of a fork. > So, granted that it is a verb, _any_ interpretation (definition) of [: is > valid. But, of course, it would just be confusing to the user to give it a > non-meaningless definition outside of capped fork, so that was not done. Anything the user has not seen before can be confusing, so I routinely ignore that issue. Instead, I stick with avoiding things that confuse me. (Note that this can mean that I will come back to code that I have written and that I will want to rephrase it so that it is clearer.) But, to me, this approach you are taking is like avoiding using the word "bird" to refer to avian creatures because the phrase "the early bird gets the worm" is not really about avian creatures but instead is about scheduling, and this can confuse people. I imagine that there are people that would be confused by this distinction, but they are likely to also be confused by other issues, and the only sure way to avoid them being confused by my code (or my english) would be to avoid coding entirely (and/or to avoid english entirely). For me, this "don't confuse people [too much]" issue gets into all the usual techniques we use to express our code: structuring it so that the important parts are visible, clear examples, notes about the purpose of key phrases, intelligible names, references to larger bodies of work, interface specifications, statements of need, and so on. And, sometimes, repetition and going back over the same territory multiple times. >> [If] we ever implement type inference, using [:^:predicate >> could be a convenient way of expressing some type constraints >> -- of restricting a hypothetical J compiler's activity so that >> we do not need to generate irrelevant code bulk in a compiled verb. > > I find it difficult to predict J's future (one reason I shy from usages I > consider unreliable), but my initial reaction to this suggestion is "I would > use assert (which is specifically designed to carry this meaning)". Yes... and, in general, we should probably avoid coding to future requirements, because it's painful to support unnecessary requirements. Also, past experience suggests that "coding to future requirements" typically results in brittle and baroque code which stalls implementation of actual future requirements when they become available. So I agree with you here... Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
