Raul wrote: > Those would be rank errors, not length errors. I don't understand where the topic of length errors comes in (unless you mean the original example of extending the "selection universe" by 1 element to supply a default?). Either way, what I was driving at was the higher-level philosophy of "graceful degradation", whether that's over rank errors, length errors, valence errors (I miss valence error!), edge cases....
> The [DoJ] says: > "Since the domain of the cap is empty, it can be used (with :) to > define a function whose monadic or dyadic case invokes an error." Fair point. But..... > 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). 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. > [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)". > PS: All that said, I publish and maintain very little "public" code, and my > primary user is myself. So my views might be parochial. > Ok... does this mean we should drop this line of discussion? (I don't see how one statement follows from the other, but we can do so if you like. From the beginning, I did explicitly [try to] present all my comments as preferences/opinion. ) -Dan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Raul Miller Sent: Tuesday, July 24, 2012 4:17 PM To: [email protected] Subject: Re: [Jprogramming] cap On Tue, Jul 24, 2012 at 3:59 PM, Dan Bron <[email protected]> wrote: > Raul wrote: >> This kind of reasoning -- that a language primitive should >> not be treated as having utility explicitly stated in the >> documentation of that primitive, and obviously present in >> the implementations -- does not make sense to me. > > Maybe an analogy would help: using [: for its (empty) domain is kind of > like entering a building through the fire escape. It's in the documentation > (blueprints, official building records, etc), and clearly the implementation > permits it (there's no such thing as stairs that only go down), but it > ignores the intent and evades the spirit. The dictionary says: "Since the domain of the cap is empty, it can be used (with :) to define a function whose monadic or dyadic case invokes an error." So I disagree that using it for this purpose "evades the spirit". > I wrote: >> I think we can agree that one of the guiding principles in the >> design of J is "graceful degradation"; witness, e.g., %. which >> has rank 2 but works "as expected" on vector and scalar >> arguments. > > Raul responded: >> But those are not cases where either the implementation or >> the dictionary state that there should be an error. So >> I am not sure how this observation is relevant in this context. > > That the Dictionary (& implementation) do not define this to be an error was > the very point of the observation. It would be reasonable for %. ("matrix > inverse") to reject vectors and scalars ("buddy, that's not a matrix"). But > it doesn't. Instead, it does something useful, and related. That's the > philosophy I was advocating, with my comment. Those would be rank errors, not length errors. That said, I will grant that it's plausibly dictionary legal to have a J implementation without length errors (where arrays are considered to be an infinite field of fill elements except that some values are not fill elements). But I have not explored this idea in any depth, and I expect that it would have some difficulties in dealing with shapes (at the very least, shapes of non-empty arrays cannot have any zeros -- but $. lets us specify the fill element for an array) and with ranks (ranks are defined as operating on shape prefixes which would not be a meaningful concept in this context). Nevertheless, even in such a case, since [: has been defined to have an empty domain it must still have an empty domain. > PS: All that said, I publish and maintain very little "public" code, and my > primary user is myself. So my views might be parochial. Ok... does this mean we should drop this line of discussion? That said, note that in your original statement, I did not find "I constrain my use of cap to the left tine of forks." to be at all controversial. My problem was with "I do not apply it as a verb, because I don't like to rely on its domain(s) being empty." Personally, I not only cannot see any valid interpretations where its domain is not empty. And I anticipate potential future uses of the language which depend on cap's domain being empty. (For example, 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.) Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
