Raul wrote:
>  I agree with John.

As do I.  

> Though I agree with Randy MacDonald that this might
> be better handled with a different foreign.

I think it should be a script.  One reason is as John laid out:  foreigns are 
(supposedly) simple functions that I can't (easily, effectively) reproduce in 
J.  Another reason is scripts are transparent and therefore extensible and 
correctable by the user (me).  Foreigns are not.  

Further, if JSoftware takes on the responsibility to maintain this 
functionality, and bugs are discovered, it can publish a fix to the standard 
library much faster than to the executable.  Similarly for extensions (as many 
others pointed out, date formats vary widely, so this will be fertile ground 
for feature requests).

My JAL bug report [i] provides an example:  I was able to get JAL running by 
hacking task.ijs.  If JAL used  2!:0 , and that foreign were problematic in the 
way the verb  shell  is problematic, I would not have been able to run JAL 
until a new j.dll binary were released.

A counterexample is provided by the formatting foreign family  8!:  (compare  
load 'printf'  ).  OTOH, if time-formatting is provided by a foreign, distinct 
from  6!:0  , then this family would provide it with a good home.

All that aside, the strongest disincentive for me (aside from envy [ii]) is the 
the inconsistency of semantics for the new proposed  6!:0  .  If  6!:0'YYYYMM'  
provides a 6-element literal vector, and  6!:0 'YYYY' provides a 4-element 
literal vector, and  6!:0'MM'  provides a 2-element literal vector, then we 
might reasonably expect that  6!:0''  would provide a 0-element literal vector. 
 But it does not; it provides a 6-element numeric vector.  Does no one else 
find this incongruous?  

So, even with Roger's philosophy (viz [iii]) firmly entrenched, we are still 
constrained by backwards compatibility.

I cannot find a way to redefine  6!:0  such that it:

   (A)  Preserves backwards compatibility, and
   (B)  is semantically consistent, and
   (C)  is endowed with the new capabilities desired.

even if I limit "the new capabilities desired" to the ones Roger proposes at 
[iv].  I've put some other thoughts up regarding this matter at [v],  but 
they're rather unstructured at the moment.  

-Dan

  [i]  http://www.jsoftware.com/pipermail/beta/2007-October/002540.html
 [ii]  http://www.jsoftware.com/jwiki/DanBron/Temp/Timestamps#envy
[iii]  http://www.jsoftware.com/pipermail/programming/2007-October/008566.html
 [iv]  http://www.jsoftware.com/jwiki/Essays/Timestamp_Extension
  [v]  http://www.jsoftware.com/jwiki/DanBron/Temp/Timestamps

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to