[Jprogramming] Noun type assessment

[j at bron.us]

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 <kaleidic at gmail.com>
Date: Wed, 21 Oct 2009 10:55:04 
To: Programming forum<programming at jsoftware.com>
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