Your description of Javascript's || is reminiscent of Perl's implementation,
though Perl's is even more permissive (eg 'zero' is false). When I used Perl,
I definitely got a lot of use out if it, especially since it was shortcutted
(IIRC).
One idiom that particularly saw a lot of use in my code was:
$var ||= 'default value if $var not yet defined'
I sorely missed this idiom when I first transitioned to J, but left it behind
as I began to think more in J and less in Perl. [1]
Your investigations in this thread are interesting, and as you concluded mostly
hinge on how to define "undefined". The code will fall out of that easily.
Some notes:
+ I wouldn't name this "or", I would prefer something like "defaultTo" .
+ I would make it an adverb that takes a predicate (boolean valued verb)
parameter that indicates the "undefinedness" of its argument, and futhermore
provide a convenient example predicate along the lines you've been exploring.
+ I would avoid tricks along the lines of +/@:, etc. Let the user decide
what cells he wants to test for "definedness" (eg atoms, items, total array),
and let him use the normal J mechanisms to do this (ie rank). The definiton of
"undefined" can be domain-dependent (witness Perl's 'zero'), so permit that
flexibility (eg by making your convenience predicate infinite rank).
Incidentally, this saves you both more design decisions and coding work.
+ In designing my convenience predicate, I would bear in mind that unlike
Javascript and Perl, J has no explicit "undefined" marker, so this utility
would bear a different meaning in J. In fact, the only way to indicate
"undefined" argument in J is the complete absence of that argument. And even
that is only possible in very limited circumsrances, eg 'default'&$ :
dyadic_verb . Where else can you elide an argument and still have meaningful
execution occur?
+ On the topic of the convenience predicate, I would avoid any explicit
decisions based on type, and maintain J's egalitarian nature. For example, for
'is null', I might choose 0 = # or 0 e. $ . Let any necessary type
dependencies fall out naturally, as in 'zero'&-: (as opposed to isLiteral *.
'zero'&-: which is both redundant and brittle [it fails on unicode
arguments]) or maybe even (s:<'zero')-:s:@boxopen .
-Dan
[1] Though sometimes I still use a pattern like:
accumulator =. (accumulator"_ :: (initial_value"_) ) , new_item
to avoid having to explicitly initialize. accumulator. as a separate step.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Tracy Harms <[email protected]>
Date: Wed, 21 Oct 2009 10:55:04
To: Programming forum<[email protected]>
Subject: Re: [Jprogramming] Noun type assessment
I just noticed that my move from
(= ])
to
(= +/)
did not generalize "entirely false" for arrays of any rank. I should have used
(= +/@:,)
And, as noted in my prior posting, we can't necessarily presume that
this (+/@:,) fits what will be needed for the expanded meaning of
"false". The expansion of meaning would have to be tamed by giving it
specific context, as a start.
T
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
