On Tue, Jul 24, 2012 at 3:59 PM, Dan Bron <j...@bron.us> 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
