Dan's question is relevant and, for me, very timely as I am preparing a
talk for a week from now and am wrestling with how to convey the notion of
J as a tool of thought.  It's hard because what Dan wrote, for instance,
looks like gibberish unless you know enough J to make sense of it but who
would want to learn such gibberish?

For my own practice w/tacit reading, I parsed much of Dan's code in my head
and found it fairly readable, up to a point.

Here's what I did - first I confirmed that it does what it claims to do:

   eg=. 0 : 0
   # This is the fullname parameter
   FULLNAME Foo Barber

   # This is a favourite fruit
   FAVOURITEFRUIT banana

   # This is a boolean that should be set
   NEEDSPEELING

   # This boolean is commented out
   ; SEEDSREMOVED
)
   nameValPair=: deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&'
=')&>@(#~a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut)
   nameValPair eg
+--------------+----------+
|FULLNAME      |Foo Barber|
+--------------+----------+
|FAVOURITEFRUIT|banana    |
+--------------+----------+
|NEEDSPEELING  |          |
+--------------+----------+

OK - that's good.  Now how does it achieve this?  Starting my evaluation on
the right and working leftward, here's what I was able to figure out.

nameValPair=: deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&'
=')&>@(#~a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut)

...@:(LF&cut)
    ^Cutting
     into lines.

...(dlb&.>)   ...
   ^Deblanking
    the lines

... (#~a:&~: > ';#' e. ~{.&>)  @:  ...
    ^ Removing  ^^  lines starting
      with either of these
      characters

Actually, not removing the comment lines: more strictly, keeping
the non-comment lines.

Continuing leftward,

... (}.~>:)) i.&1@:e.&' =')&>@ ...
    ^ Increment where we find the
      first space or equals sign.

This tells me we're missing a test case, so I'll check if this is
doing what I think it is:

   eg=. eg,0 : 0
# Try NAME=value
NAME=value
)
   nameValPair eg
+--------------+----------+
|FULLNAME      |Foo Barber|
+--------------+----------+
|FAVOURITEFRUIT|banana    |
+--------------+----------+
|NEEDSPEELING  |          |
+--------------+----------+
|NAME          |value     |
+--------------+----------+

OK - looks good so far.  Continuing...
... ',' cut ...
    ^ Cutting comma-delimited items

Looks like we need another test case:

   eg=. eg,0 : 0
# Test comma-delimited value
COMMADELIMITED Here,are,several,values
)
   nameValPair eg
+--------------+-------------------------+
|FULLNAME      |Foo Barber               |
+--------------+-------------------------+
|FAVOURITEFRUIT|banana                   |
+--------------+-------------------------+
|NEEDSPEELING  |                         |
+--------------+-------------------------+
|NAME          |value                    |
+--------------+-------------------------+
|COMMADELIMITED|+----+---+-------+------+|
|              ||Here|are|several|values||
|              |+----+---+-------+------+|
+--------------+-------------------------+

OK - continuing...

;^:(1=#) ...
^ Simplify if only 1 value

... (({.~ ; [:    <  [:
      ^ First item
        w/other(s) following...

Finally,
deb L:0@:...
^ Remove blanks at
  lowest level?

I'm not quite sure about this w/o testing, but I think that's
a fairly accurate explanation of the code, perhaps having sluffed
the exact meaning of a few of the "@:"s.

This brings up the dichotomy between writing and reading code: one
of the important reasons J is a tool of thought is because it gives
us this powerful, logical, consistent vocabulary for talking about
computational concepts.

As an example of how this affects our thinking, I'll mention a time
when a colleague asked me how I'd written a file differencer in APL.

At the time he asked, I didn't have the code available and had been
working mostly in ksh (Korn shell scripting) at that time.  I outlined
the method I thought I'd used but only later realized I had completely
mis-informed him: I told him a method I would have used working with
Unix shell tools, not how I'd actually done it in APL which was something
like this (in J):

   'fl0 fl1'=. <;._2&.>CR-.~&.>fread (<'\directory\),&.>'fl0.txt';'fl1.txt'
   'fl0 fl1'=. deb&.>&.>fl0;<fl1
   fl0 -. fl1
   fl0 -.~ fl1

My approach to the algorithm was changed by the toolset I had foremost
in my mind at that time.



On Mon, Jan 13, 2014 at 9:32 PM, Pascal Jasmin <godspiral2...@yahoo.ca>wrote:

>  deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&' =')&>@(#~
> > a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut)
>
>
>
> completely untested if the following is equivalent, but:
> 3 : ' deb leaf (({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&'
> =')&>@(#~
>
> > a:&~: > ';#' e.~ {.&>) dlb each LF cut y'
>
> is a little better?  (took out "unnecessary" @:, and spaced out verb
> trains)
>
> further clarity could be achieved with verb names:
> docomment
> doassign
> doboolean
>
> which I am guessing would take care of replacing the longer trains (or
> parts thereof) in the middle.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>



-- 
Devon McCormick, CFA
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to