Re: [Jprogramming] @: and capped fork (and puzzles)

[Jose Mario Quintana]

Dan,

On the one hand, I understand your points, one can easily,

   cheat=. (`'') ("_)

   u=. [: - %
   v=. [ -@] %

   (u -: v) 1 2 3
1

   (u cheat -: v cheat) 1 2 3
0

Here the verbs do not break down “during _derivation_”; they just
compute different results ignoring, the values of, the arguments.

Nevertheless, I also agree that when posing puzzles it could be
advisable to “discriminate between tautologies which break during
_application_ and those which break during _derivation_.”

On the other hand, in my mind two verbs, that are meant to be
functions, are equal if (and only if) they have the same domain and
they yield the same result for every value of their common domain
(even when considering the practical issues inherent in this
approach).  For example, I am careful about interchanging (!) and ((*/
@: >: @: i. "0); granted, I also should be very careful about
interchanging (^. @: *:) and (2 * ^.).

Also, although one can cheat during the derivation, assuming that I am
using the term in the same sense that you are, sometimes is difficult
to disentangle it from the application. For example, as described in
the bonus puzzle,

   inv
^:_1

   u f.
[: - %

   u f. inv
([: - %)^:_1

   u f. b. _1 NB. even if...
[: % -

   v f.
[ -@] %

   v f. inv NB. and
([ -@] %)^:_1

   v f. b. _1 NB. even if...
|domain error
|   v f.b._1
|[-14]

So, apparently, the actual derivation of (u f. inv) and (v f. inv) is
only triggered during the application,

   (u f. inv) 1 2 3
_1 _0.5 _0.33

   (v f. inv) 1 2 3
|domain error
|   (v f.inv)1 2 3
|[-3]

Besides, the inverse of a function (verb), when exists, seems to me an
intrinsically associated to the function.  In other words, (inv) is
not cheating (or at least not too much) and neither is (&.) from my
point of view.

___

On Sat, Dec 8, 2012 at 5:27 PM, Dan Bron  wrote:
> Pepe wrote:
>> You are allowed to show "sneaky" cases where the
>> domain of a verb involving (Ca f p g)  is reduced
>
> For future identity puzzles, I think we should explicitly discriminate
> between tautologies which break during _application_ and those which break
> during _derivation_.  If I claim f and g are identical verbs, it is much
> more interesting to find cases where (f y) vs (g y) or (x f y) vs (x g y)
> differ than to find cases where I can distinguish (or get the interpreter to
> distinguish) f from g.
>
> Such puzzles are analogous to invalidating the claim that 32 and 16b20 are 
> identical.  I'd expect that to be impossible based on their values, but
> trivial based on their forms (i.e. if you give me access to '32' and
> '16b20'). If you showed me a way to do it based on their values alone, I
> would be wowed (and report it as a bug to Roger)!
>
> In short, if I claim the verbs f and g are identical, but =/ f`g doesn't
> hold, it won't be too hard to find a way to get the interpreter to tell you
> that.  Of course, interesting new ways to get the interpreter to tell you
> that are always welcome!
>
> I wrote:
>> does "favoring" require that the interpreter generate code
>> involving  @ (instead of [: ) of arbitrary complexity?
>
> Pepe wrote:
>> Yes...
>
> Ok, I checked out your original solution.  I like the approach; it follows
> the lines of thought I was going to pursue next if you were unsatisfied with
> my formulation.  I was particularly pleased that the approach you outlined
> produced @s (and @:s) irrespective of whether the input was phrased as  f@:g
> or  ([: f g) .
>
> -Dan
>
> PS:  I haven't thought about the bonus puzzle yet.  If I get some time
> tomorrow, I'll do that, and maybe check out 13 : in early J versions, too.
>
>
> Please excuse typos; composed on a handheld device.
>
> On Dec 8, 2012, at 11:30 AM, Jose Mario Quintana 
>  wrote:
>
>> Dan,
>>
>>> Let me put it a different way:  must I find a combination of  f g x y  such
>>> that  ( (Ca f p g) y ) -: ( ([: f g) y )   or   ( x (Ca f p g) y ) -: ( x
>>> ([: f g) y )  does not result in a 1?  Or am I allowed sneakier tactics?  An
>>> example of the kind of sneaky tactic I'm considering is given in the
>>> postscript (after some spaces to hide the spoilers).
>>
>> You are allowed to show "sneaky" cases where the domain of a verb
>> involving (Ca f p g)  is reduced because its execution breaks down
>> reporting a domain error whereas the corresponding verb involving (Ca
>> f p g) produces a result, when both are given the same arguments.
>> Thus, replacing literally ([: f g), within a sentence, by (Ca f p g)
>> does not work in these cases because the new version fails to produce
>> a result.
>>
>>> whether "favoring" requires that the interpreter generate code involving  @
>>> (instead of [: ) of arbitrary complexity
>>
>> Yes, and your question is related to the bonus puzzle.
>>
>>> PS:  I noticed your original "(This is a tricky puzzle thought)", and felt
>>> it was hinting at something, but haven't grasped what.
>>
>> You already pa

Re: [Jprogramming] @: and capped fork (and puzzles)

[Linda Alvord]

   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda Alvord
Sent: Sunday, December 09, 2012 3:17 AM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

 I have found that if you change a message to "rich text" before you paste
anything it will look better (I hope)

   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda Alvord
Sent: Sunday, December 09, 2012 3:07 AM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

Maybe some of you who are just beginning to learn J, and I who occasionally
has to "figure out what is going on" might find this helpful.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
   f 23
_0.0434783
   
   g=: 13 :'(>.y)%<.(+y)*-y'
   g 23
_0.0434783
  
   h=: 13 :'(x>.y)%<.(x+y)*x-y'
   2.5 h 4
_0.4


The surprise is that the tacit version is the same for f, g and h

   f
>. % [: <. + * -
   g
>. % [: <. + * -
   h
>. % [: <. + * -


It requires you to "read" the same tree differently in a monadic and a
dyadic situation.
   
 5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

Enjoy your day.  Linda
 

-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda
fiAlvord
Sent: Friday, December 07, 2012 8:55 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

If you replace each expression with  @: with one without it:


2.5 (>. % <. @: + * -) 4
_0.44u
   2.5 (>. % <. @ + * -) 4
_0.44

   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4  


Now you can see the difference in the removal of parentheses better.


2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @ + * -) 4
_0.44
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

When the dictionary was written, there was the cost of printing books and
articles to consider.  The forum provides the luxury of giving sufficient
examples that a concept can be presented from different perspectives which
may make understanding easier.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
  
   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

I find a tree helpful here.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Jose Mario
Quintana
Sent: Friday, December 07, 2012 7:11 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

To Linda,

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @: + * -) 4
_0.4
   2.5 (>. % <. @: (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

NB. This is the example given in the Dictionary's entry for Cap.


To Dan,

I am glad that somebody is having fun.  These are very good questions and
the necessary clarifications give away some clues:

- re (Ca f p g) vs ([: f g) :   the equivalence fails because the
execution of sentences involving (Ca f p g) break down when applied to
(meaningful) identical arguments.

- re the interpreter "preferring" @: to [: in certain cases: actually, the
puzzle was to find "instances where the interpreter even favors atop (@)
over ([:)" but there are also instances where the interpreter favors (@:)
over ([:)  and, yes, this preferences are demonstrated in other contexts not
involving (13 :)  (I could not help to leave behind a red herring behind,
hence:  "(This is a tricky puzzle thought)").
:)

By the way, there is a bonus puzzle within the solutions.
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork (and puzzles)

[Linda Alvord]

 I have found that if you change a message to "rich text" before you paste
anything it will look better (I hope)

   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda Alvord
Sent: Sunday, December 09, 2012 3:07 AM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

Maybe some of you who are just beginning to learn J, and I who occasionally
has to "figure out what is going on" might find this helpful.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
   f 23
_0.0434783
   
   g=: 13 :'(>.y)%<.(+y)*-y'
   g 23
_0.0434783
  
   h=: 13 :'(x>.y)%<.(x+y)*x-y'
   2.5 h 4
_0.4


The surprise is that the tacit version is the same for f, g and h

   f
>. % [: <. + * -
   g
>. % [: <. + * -
   h
>. % [: <. + * -


It requires you to "read" the same tree differently in a monadic and a
dyadic situation.
   
 5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

Enjoy your day.  Linda
 

-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda
fiAlvord
Sent: Friday, December 07, 2012 8:55 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

If you replace each expression with  @: with one without it:


2.5 (>. % <. @: + * -) 4
_0.44u
   2.5 (>. % <. @ + * -) 4
_0.44

   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4  


Now you can see the difference in the removal of parentheses better.


2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @ + * -) 4
_0.44
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

When the dictionary was written, there was the cost of printing books and
articles to consider.  The forum provides the luxury of giving sufficient
examples that a concept can be presented from different perspectives which
may make understanding easier.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
  
   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

I find a tree helpful here.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Jose Mario
Quintana
Sent: Friday, December 07, 2012 7:11 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

To Linda,

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @: + * -) 4
_0.4
   2.5 (>. % <. @: (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

NB. This is the example given in the Dictionary's entry for Cap.


To Dan,

I am glad that somebody is having fun.  These are very good questions and
the necessary clarifications give away some clues:

- re (Ca f p g) vs ([: f g) :   the equivalence fails because the
execution of sentences involving (Ca f p g) break down when applied to
(meaningful) identical arguments.

- re the interpreter "preferring" @: to [: in certain cases: actually, the
puzzle was to find "instances where the interpreter even favors atop (@)
over ([:)" but there are also instances where the interpreter favors (@:)
over ([:)  and, yes, this preferences are demonstrated in other contexts not
involving (13 :)  (I could not help to leave behind a red herring behind,
hence:  "(This is a tricky puzzle thought)").
:)

By the way, there is a bonus puzzle within the solutions.
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork (and puzzles)

[Linda Alvord]

Maybe some of you who are just beginning to learn J, and I who occasionally
has to "figure out what is going on" might find this helpful.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
   f 23
_0.0434783
   
   g=: 13 :'(>.y)%<.(+y)*-y'
   g 23
_0.0434783
  
   h=: 13 :'(x>.y)%<.(x+y)*x-y'
   2.5 h 4
_0.4


The surprise is that the tacit version is the same for f, g and h

   f
>. % [: <. + * -
   g
>. % [: <. + * -
   h
>. % [: <. + * -


It requires you to "read" the same tree differently in a monadic and a
dyadic situation.
   
 5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

Enjoy your day.  Linda
 

-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda
fiAlvord
Sent: Friday, December 07, 2012 8:55 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

If you replace each expression with  @: with one without it:


2.5 (>. % <. @: + * -) 4
_0.44u
   2.5 (>. % <. @ + * -) 4
_0.44

   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4  


Now you can see the difference in the removal of parentheses better.


2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @ + * -) 4
_0.44
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

When the dictionary was written, there was the cost of printing books and
articles to consider.  The forum provides the luxury of giving sufficient
examples that a concept can be presented from different perspectives which
may make understanding easier.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
  
   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

I find a tree helpful here.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Jose Mario
Quintana
Sent: Friday, December 07, 2012 7:11 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

To Linda,

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @: + * -) 4
_0.4
   2.5 (>. % <. @: (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

NB. This is the example given in the Dictionary's entry for Cap.


To Dan,

I am glad that somebody is having fun.  These are very good questions and
the necessary clarifications give away some clues:

- re (Ca f p g) vs ([: f g) :   the equivalence fails because the
execution of sentences involving (Ca f p g) break down when applied to
(meaningful) identical arguments.

- re the interpreter "preferring" @: to [: in certain cases: actually, the
puzzle was to find "instances where the interpreter even favors atop (@)
over ([:)" but there are also instances where the interpreter favors (@:)
over ([:)  and, yes, this preferences are demonstrated in other contexts not
involving (13 :)  (I could not help to leave behind a red herring behind,
hence:  "(This is a tricky puzzle thought)").
:)

By the way, there is a bonus puzzle within the solutions.
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork (and puzzles)

[Dan Bron]

Pepe wrote:
> You are allowed to show "sneaky" cases where the 
> domain of a verb involving (Ca f p g)  is reduced

For future identity puzzles, I think we should explicitly discriminate
between tautologies which break during _application_ and those which break
during _derivation_.  If I claim f and g are identical verbs, it is much
more interesting to find cases where (f y) vs (g y) or (x f y) vs (x g y)
differ than to find cases where I can distinguish (or get the interpreter to
distinguish) f from g.  

Such puzzles are analogous to invalidating the claim that 32 and 16b20 are 
identical.  I'd expect that to be impossible based on their values, but
trivial based on their forms (i.e. if you give me access to '32' and
'16b20'). If you showed me a way to do it based on their values alone, I
would be wowed (and report it as a bug to Roger)!

In short, if I claim the verbs f and g are identical, but =/ f`g doesn't
hold, it won't be too hard to find a way to get the interpreter to tell you
that.  Of course, interesting new ways to get the interpreter to tell you
that are always welcome!

I wrote:
> does "favoring" require that the interpreter generate code 
> involving  @ (instead of [: ) of arbitrary complexity?

Pepe wrote:
> Yes...

Ok, I checked out your original solution.  I like the approach; it follows
the lines of thought I was going to pursue next if you were unsatisfied with
my formulation.  I was particularly pleased that the approach you outlined
produced @s (and @:s) irrespective of whether the input was phrased as  f@:g
or  ([: f g) .

-Dan

PS:  I haven't thought about the bonus puzzle yet.  If I get some time
tomorrow, I'll do that, and maybe check out 13 : in early J versions, too.


Please excuse typos; composed on a handheld device.

On Dec 8, 2012, at 11:30 AM, Jose Mario Quintana 
 wrote:

> Dan,
> 
>> Let me put it a different way:  must I find a combination of  f g x y  such
>> that  ( (Ca f p g) y ) -: ( ([: f g) y )   or   ( x (Ca f p g) y ) -: ( x
>> ([: f g) y )  does not result in a 1?  Or am I allowed sneakier tactics?  An
>> example of the kind of sneaky tactic I'm considering is given in the
>> postscript (after some spaces to hide the spoilers).
> 
> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g)  is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving (Ca
> f p g) produces a result, when both are given the same arguments.
> Thus, replacing literally ([: f g), within a sentence, by (Ca f p g)
> does not work in these cases because the new version fails to produce
> a result.
> 
>> whether "favoring" requires that the interpreter generate code involving  @
>> (instead of [: ) of arbitrary complexity
> 
> Yes, and your question is related to the bonus puzzle.
> 
>> PS:  I noticed your original "(This is a tricky puzzle thought)", and felt
>> it was hinting at something, but haven't grasped what.
> 
> You already passed that hurdle by not following the red herring (13 :).
> 
>> 
>> **SPOILERS BELOW HERE**
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>  +/&.([: #: +:) 1 2 3
>>   6
>> 
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork (and puzzles)

[Jose Mario Quintana]

I wrote:

> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g)  is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving (Ca
> f p g) produces a result, when both are given the same arguments.

and

> I vaguely remember that initially (@:) was used (and (13 :) had a
> different code?).  Perhaps you could try to find out if my

I should have written respectively:

> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g)  is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving
> ([: f p g) produces a result, when both are given the same arguments.

and

> I vaguely remember that initially (@:) was used (and (13 :) had a
> different number code?).  Perhaps you could try to find out if my




On Sat, Dec 8, 2012 at 11:30 AM, Jose Mario Quintana
 wrote:
> Dan,
>
>> Let me put it a different way:  must I find a combination of  f g x y  such
>> that  ( (Ca f p g) y ) -: ( ([: f g) y )   or   ( x (Ca f p g) y ) -: ( x
>> ([: f g) y )  does not result in a 1?  Or am I allowed sneakier tactics?  An
>> example of the kind of sneaky tactic I'm considering is given in the
>> postscript (after some spaces to hide the spoilers).
>
> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g)  is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving (Ca
> f p g) produces a result, when both are given the same arguments.
> Thus, replacing literally ([: f g), within a sentence, by (Ca f p g)
> does not work in these cases because the new version fails to produce
> a result.
>
>> whether "favoring" requires that the interpreter generate code involving  @
>> (instead of [: ) of arbitrary complexity
>
> Yes, and your question is related to the bonus puzzle.
>
>> PS:  I noticed your original "(This is a tricky puzzle thought)", and felt
>> it was hinting at something, but haven't grasped what.
>
> You already passed that hurdle by not following the red herring (13 :).
>
>>
>> **SPOILERS BELOW HERE**
>
>
>
>
>
>
>
>
>
>>   +/&.([: #: +:) 1 2 3
>>6
>>
>>   +/&.(Ca #:p +:) 1 2 3
>>|domain error
>>|   +/&.(Ca#:p+:)1 2 3
>
> Yes, that is definitely the kind of instance that the elimination of
> ([:) requires a little more effort ; well done!
>
>
> Since,
>
>([: (2&#.)(2&#.)) b. _1
> [: ($&2@>:@(2&(<.@^.))@(1&>.)@(>./)@:|@, #: ]) :.(2&#.)
> ($&2@>:@(2&(<.@^.))@(1&>.)@(>./)@:|@, #: ]) :.(2&#.)
>
> and so on, one can force the interpreter to generate code of arbitrary
> complexity (although built from a finite number of hand-rolled
> inverses).  However, this not completely satisfying, because, unlike
> (13 :), (v b. _1) is generating a string representing code as opposed
> to generating a verb (and on top a ([:) shows up).
>
>> the machine J, which automatically generates the [:s from  13 : .  Though
>> perhaps there are ways to induce the interpreter to use @ instead of [: when
>> (automatically) generating inverses of compound verbs.  Hmm
>>
>
> I do not know about that.  By the way, did Ken and Roger decided to
> favor ([:) over (@:) when generating verbs via (13 :) or just Roger?
> I vaguely remember that initially (@:) was used (and (13 :) had a
> different code?).  Perhaps you could try to find out if my
> recollection is correct using very early versions of the J interpreter
> in your collection.
>
>> Anyway, are these solutions on the right tracks?
>
> Perhaps I am too picky regarding the last solution and you should be
> declared a winner and have a look at the bonus puzzle.  At the very
> least you are red hot.
>
>
>
> _
>
>
> On Fri, Dec 7, 2012 at 10:08 PM, Dan Bron  wrote:
>> Pepe,
>>
>> The specification for the first puzzle is still a bit ambiguous, because:
>>
>>> the equivalence fails because the execution of
>>> sentences involving (Ca f p g) break down when
>>> applied to (meaningful) identical arguments
>>
>> Can apply equally to the cases I was trying to distinguish:
>>
>>(1) a difference .. in the /output/ of these two verbs when applied
>> to identical arguments
>>(2) show differences in products /derived/ from these two
>> ("identical") verbs
>>
>> Both cases are "sentences involving (the constructs in question)" and both
>> involve application to "(meaningful) identical arguments".  In the latter
>> case, the "(meaningful) identical arguments" are, in fact, the constructs in
>> question.
>>
>> Let me put it a different way:  must I find a combination of  f g x y  such
>> that  ( (Ca f p g) y ) -: ( ([: f g) y )   or   ( x (Ca f p g) y ) -: ( x
>> ([: f g) y )  does not result in a 1?  Or am I allowed sneakier tactics?  An
>> example of the kind of sneaky tactic I'm considering is given in the
>> postscript (after some spaces to hide th

Re: [Jprogramming] @: and capped fork (and puzzles)

[Dan Bron]

Pepe,

The specification for the first puzzle is still a bit ambiguous, because:

> the equivalence fails because the execution of 
> sentences involving (Ca f p g) break down when 
> applied to (meaningful) identical arguments

Can apply equally to the cases I was trying to distinguish:  

   (1) a difference .. in the /output/ of these two verbs when applied
to identical arguments
   (2) show differences in products /derived/ from these two
("identical") verbs

Both cases are "sentences involving (the constructs in question)" and both
involve application to "(meaningful) identical arguments".  In the latter
case, the "(meaningful) identical arguments" are, in fact, the constructs in
question.

Let me put it a different way:  must I find a combination of  f g x y  such
that  ( (Ca f p g) y ) -: ( ([: f g) y )   or   ( x (Ca f p g) y ) -: ( x
([: f g) y )  does not result in a 1?  Or am I allowed sneakier tactics?  An
example of the kind of sneaky tactic I'm considering is given in the
postscript (after some spaces to hide the spoilers).

I've also given a potential solution to the second puzzle, depending on the
definition of "the interpreter" or how it "favors" things.  In particular,
whether "favoring" requires that the interpreter generate code involving  @
(instead of [: ) of arbitrary complexity, or whether simply producing a @
(instead of [:) without my asking for it suffices (meaning, the number of
cases I can provoke is finite).   

For euphony, I've made this first pair of solutions "rhyme".

-Dan

PS:  I noticed your original "(This is a tricky puzzle thought)", and felt
it was hinting at something, but haven't grasped what.

**SPOILERS BELOW HERE**



















With Ca =. [ and p =. @] is (Ca #:p  +:) "identical" to ([: #: +:) ?

  ([: #: +:) b. _1
   [: -: #.

  (Ca #:p  +:) b. _1
   |domain error
   |   (Ca#:p+:)b._1


  +/&.([: #: +:) 1 2 3
   6

  +/&.(Ca #:p +:) 1 2 3
   |domain error
   |   +/&.(Ca#:p+:)1 2 3



Does the interpreter ever favor @ or @: over [:  ?

  2&#. b. _1
   ($&2@>:@(2&(<.@^.))@(1&>.)@(>./)@:|@, #: ]) :.(2&#.)
   
  '@ @: [:' e.&;: 2&#. b. _1
   1 1 0
   
  +/"1 '@ @: [:' =/&;: 2&#. b. _1
   6 1 0

Using this approach, I am inclined to take up Henry's usage and name the
interpreter "Roger", because it feels more to me like these results convey
the preferences of the man Roger, who hand-rolled particular inverses, than
the machine J, which automatically generates the [:s from  13 : .  Though
perhaps there are ways to induce the interpreter to use @ instead of [: when
(automatically) generating inverses of compound verbs.  Hmm

Anyway, are these solutions on the right tracks?

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

Re: [Jprogramming] @: and capped fork (and puzzles)

[Linda Alvord]

If you replace each expression with  @: with one without it:


2.5 (>. % <. @: + * -) 4
_0.44
   2.5 (>. % <. @ + * -) 4
_0.44

   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4  


Now you can see the difference in the removal of parentheses better.


2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @ + * -) 4
_0.44
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % <. @ (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

When the dictionary was written, there was the cost of printing books and
articles to consider.  The forum provides the luxury of giving sufficient
examples that a concept can be presented from different perspectives which
may make understanding easier.

   f=:>. % [: <. + * -
   2.5 f 4
_0.4
  
   5!:4 <'f'
  -- >. 
  +- %  
--+-- [:
  │+- <.
  L+-- +
   L+- *
L- -

I find a tree helpful here.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Jose Mario
Quintana
Sent: Friday, December 07, 2012 7:11 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

To Linda,

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % <. @: + * -) 4
_0.4
   2.5 (>. % <. @: (+ * -)) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

NB. This is the example given in the Dictionary's entry for Cap.


To Dan,

I am glad that somebody is having fun.  These are very good questions and
the necessary clarifications give away some clues:

- re (Ca f p g) vs ([: f g) :   the equivalence fails because the
execution of sentences involving (Ca f p g) break down when applied to
(meaningful) identical arguments.

- re the interpreter "preferring" @: to [: in certain cases: actually, the
puzzle was to find "instances where the interpreter even favors atop (@)
over ([:)" but there are also instances where the interpreter favors (@:)
over ([:)  and, yes, this preferences are demonstrated in other contexts not
involving (13 :)  (I could not help to leave behind a red herring behind,
hence:  "(This is a tricky puzzle thought)").
:)

By the way, there is a bonus puzzle within the solutions.
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork (and puzzles)

[Dan Bron]

I haven't read the spoilers yet, so I'd like to ask a couple of clarifying 
questions:

- re (Ca f p g) vs ([: f g) :  must a difference be identified in the 
/output/ of these two verbs when applied to identical arguments, or are 
solutions allowed which show differences in products derived from these two 
("identical") verbs?  In the extreme, is it sufficient to show significant 
(orders of magnitude) differences in performance?

- re the interpreter "preferring" @: to [: in certain cases:  is puzzle 
limited to the output of 13 : n , or may we demonstrate the preference in other 
contexts?

Fun stuff! Thanks for posing the puzzles.

-Dan



On Dec 5, 2012, at 6:01 PM, Jose Mario Quintana  
wrote:

> Ian writes:
> 
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
> 
> The lesser known fork form (Ca u p v) where (Ca=. [)  (or (Ca=.
> AnyVerb)) and (p=. @]) (or (p=. @:])), which has been identified at
> least for a decade (
> http://www.jsoftware.com/pipermail/general/2002-September/008617.html
> ), can replace literally ([: u v) in instances where (u@:v) would
> require additional parenthesis.  For example,
> 
>   ([: +: +/)3 4 5
> 24
>   (Ca +:p +/)3 4 5
> 24
>   ([ +:@] +/)3 4 5
> 24
> 
>   2.5 (>. % [: <. + * -) 4
> _0.4
>   2.5 (>. % Ca <.p + * -) 4
> _0.4
>   2.5 (>. % [ <.@] + * -) 4
> _0.4
> 
> The reason is that (Ca u p v) is also a fork and it bonds to its
> context in the same manner as ([: u v) does.  Yet, there are
> exceptions to the equivalance!  How come? Under what circumstances?
> Finding the answer to this questions can be seen by tacit fans as a
> puzzle to be solved and a solution is given at the end of this
> message.
> 
> Ric writes:
>> If you restrict yourself to writing explicit J then it is perfectly
>> possible to get away without using capped fork.
> 
> Although I agree with the statement above the complementary statement
> (if you restrict yourself to writing tacit J then it is perfectly
> possible to get away without using capped fork) also holds.
> Furthermore, some (myself included) routinely avoid it.  Incidentally,
> my attitude is the reverse of Linda's attitude.  I have an easier task
> because generally is fairly easy to replace ([:) using (@) (together
> with ([) and (])) than to replace (@) in terms of ([:) without
> introducing (").  A reason given for favoring ([:) over (@ :) is that
> (13 :) does so; however, there are instances where the interpreter
> even favors atop (@) over ([:) .  Finding such an instance is another
> puzzle and one solution is also shown at the end of this message.
> (This is a tricky puzzle thought.)
> 
> Don writes,
> 
>> BASIC is the programming language that was popularized when personal
>> computing became common. It and the popular programming languages today are
>> all essentially scalar. They handle one element at a time and use loops to
>> handle arrays. APL, J and a few other languages running around today are
>> array oriented. Loops and so many techniques used to write good programs in
>> scalar languages are for the most part unnecessary in array languages like
>> J. But once one learns the scalar approach to programming these scalar
>> techniques are well entrenched.
> 
> It is also possible even if you restrict yourself to writing tacit J,
> to code verbs using loops handling one element at a time; however,
> this is not only pointless but is also generally quite more difficult
> in this case.  In other words, tacit programming naturally compels the
> array approach and, in my opinion, beginners should be encouraged to
> (try to) code simple verbs tacitly.  I began translating simple verbs
> from explicit code to tacit code because these tasks were entertaining
> puzzles to solve and I used (13 :) to get hints when I was stuck.  At
> some point I realized that any verb, simple or complex, could be coded
> tacitly and later I convinced myself that coding tacitly, and fixing
> the tacit code of, large systems made a lot of sense and others and I
> have been coding in this manner for many years; I now use (13 :)  to
> translate alien explicit code to a familiar dialect.
> 
> My answer to my own questions follows:  How come? Under what
> circumstances?  Because, and when, the interpreter is both very smart
> and yet not smart enough.  For example,
> 
>   - &. (^. @: *:)  1 2 3
> 1 0.5 0.33
>   - &. ([: ^. *:)  1 2 3
> 1 0.5 0.33
>   - &. ([ ^.@] *:) 1 2 3
> |domain error
> |   -&.([^.@]*:)1 2 3
> 
>   (^. @: *:) (d.1)
> +: * %@*:
>   ([: ^. *:) (d.1) NB. This is an instance where the interpreter
> favors @ over [:
> +: * %@*:
>   ([ ^.@] *:) (d.1)
> |domain error
> |   ([^.@]*:)(d.1)
> 
> Incidentally, I am also puzzled:
> 
> Does anybody know why the interpreter resolves,
> 
>   (^. @: *:) (d.1)
> +: * %@*:
> 
> but it does not resolve the following sentence of the same kind,
> 
>   (^. @: *:) (^:_1)
> ^.@:*:^:_1
> 
> considering that it knows,
> 
>   (^. @:

Re: [Jprogramming] @: and capped fork (and puzzles)

[Linda Alvord]

What is the advantage of defining  Ca  and  p  when the first statement has
no added parentheses?

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % Ca <.p + * -) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

Linda

Original Message-n 
From: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Jose Mario
Quintana
Sent: Wednesday, December 05, 2012 6:01 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork (and puzzles)

Ian writes:

> If u and v are verbs, do (u@:v) and ([: u v) really behave the same 
> under all circumstances?

The lesser known fork form (Ca u p v) where (Ca=. [)  (or (Ca=.
AnyVerb)) and (p=. @]) (or (p=. @:])), which has been identified at least
for a decade (
http://www.jsoftware.com/pipermail/general/2002-September/008617.html
), can replace literally ([: u v) in instances where (u@:v) would require
additional parenthesis.  For example,

   ([: +: +/)3 4 5
24
   (Ca +:p +/)3 4 5
24
   ([ +:@] +/)3 4 5
24

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % Ca <.p + * -) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

The reason is that (Ca u p v) is also a fork and it bonds to its context in
the same manner as ([: u v) does.  Yet, there are exceptions to the
equivalance!  How come? Under what circumstances?
Finding the answer to this questions can be seen by tacit fans as a puzzle
to be solved and a solution is given at the end of this message.

Ric writes:
> If you restrict yourself to writing explicit J then it is perfectly 
> possible to get away without using capped fork.

Although I agree with the statement above the complementary statement (if
you restrict yourself to writing tacit J then it is perfectly possible to
get away without using capped fork) also holds.
Furthermore, some (myself included) routinely avoid it.  Incidentally, my
attitude is the reverse of Linda's attitude.  I have an easier task because
generally is fairly easy to replace ([:) using (@) (together with ([) and
(])) than to replace (@) in terms of ([:) without introducing (").  A reason
given for favoring ([:) over (@ :) is that
(13 :) does so; however, there are instances where the interpreter even
favors atop (@) over ([:) .  Finding such an instance is another puzzle and
one solution is also shown at the end of this message.
(This is a tricky puzzle thought.)

Don writes,

> BASIC is the programming language that was popularized when personal 
> computing became common. It and the popular programming languages 
> today are all essentially scalar. They handle one element at a time 
> and use loops to handle arrays. APL, J and a few other languages 
> running around today are array oriented. Loops and so many techniques 
> used to write good programs in scalar languages are for the most part 
> unnecessary in array languages like J. But once one learns the scalar 
> approach to programming these scalar techniques are well entrenched.

It is also possible even if you restrict yourself to writing tacit J, to
code verbs using loops handling one element at a time; however, this is not
only pointless but is also generally quite more difficult in this case.  In
other words, tacit programming naturally compels the array approach and, in
my opinion, beginners should be encouraged to (try to) code simple verbs
tacitly.  I began translating simple verbs from explicit code to tacit code
because these tasks were entertaining puzzles to solve and I used (13 :) to
get hints when I was stuck.  At some point I realized that any verb, simple
or complex, could be coded tacitly and later I convinced myself that coding
tacitly, and fixing the tacit code of, large systems made a lot of sense and
others and I have been coding in this manner for many years; I now use (13
:)  to translate alien explicit code to a familiar dialect.

My answer to my own questions follows:  How come? Under what circumstances?
Because, and when, the interpreter is both very smart and yet not smart
enough.  For example,

   - &. (^. @: *:)  1 2 3
1 0.5 0.33
   - &. ([: ^. *:)  1 2 3
1 0.5 0.33
   - &. ([ ^.@] *:) 1 2 3
|domain error
|   -&.([^.@]*:)1 2 3

   (^. @: *:) (d.1)
+: * %@*:
   ([: ^. *:) (d.1) NB. This is an instance where the interpreter favors @
over [:
+: * %@*:
   ([ ^.@] *:) (d.1)
|domain error
|   ([^.@]*:)(d.1)

Incidentally, I am also puzzled:

Does anybody know why the interpreter resolves,

   (^. @: *:) (d.1)
+: * %@*:

but it does not resolve the following sentence of the same kind,

   (^. @: *:) (^:_1)
^.@:*:^:_1

considering that it knows,

   (^. @: *:) b._1
%:@:^

?




On Thu, Nov 29, 2012 at 11:49 AM, Ian Clark  wrote:
> Department of Sudden Doubts...
>
> If u and v are verbs, do (u@:v) and ([: u v) 

Re: [Jprogramming] @: and capped fork (and puzzles)

[Jose Mario Quintana]

Ian writes:

> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
> under all circumstances?

The lesser known fork form (Ca u p v) where (Ca=. [)  (or (Ca=.
AnyVerb)) and (p=. @]) (or (p=. @:])), which has been identified at
least for a decade (
http://www.jsoftware.com/pipermail/general/2002-September/008617.html
), can replace literally ([: u v) in instances where (u@:v) would
require additional parenthesis.  For example,

   ([: +: +/)3 4 5
24
   (Ca +:p +/)3 4 5
24
   ([ +:@] +/)3 4 5
24

   2.5 (>. % [: <. + * -) 4
_0.4
   2.5 (>. % Ca <.p + * -) 4
_0.4
   2.5 (>. % [ <.@] + * -) 4
_0.4

The reason is that (Ca u p v) is also a fork and it bonds to its
context in the same manner as ([: u v) does.  Yet, there are
exceptions to the equivalance!  How come? Under what circumstances?
Finding the answer to this questions can be seen by tacit fans as a
puzzle to be solved and a solution is given at the end of this
message.

Ric writes:
> If you restrict yourself to writing explicit J then it is perfectly
> possible to get away without using capped fork.

Although I agree with the statement above the complementary statement
(if you restrict yourself to writing tacit J then it is perfectly
possible to get away without using capped fork) also holds.
Furthermore, some (myself included) routinely avoid it.  Incidentally,
my attitude is the reverse of Linda's attitude.  I have an easier task
because generally is fairly easy to replace ([:) using (@) (together
with ([) and (])) than to replace (@) in terms of ([:) without
introducing (").  A reason given for favoring ([:) over (@ :) is that
(13 :) does so; however, there are instances where the interpreter
even favors atop (@) over ([:) .  Finding such an instance is another
puzzle and one solution is also shown at the end of this message.
(This is a tricky puzzle thought.)

Don writes,

> BASIC is the programming language that was popularized when personal
> computing became common. It and the popular programming languages today are
> all essentially scalar. They handle one element at a time and use loops to
> handle arrays. APL, J and a few other languages running around today are
> array oriented. Loops and so many techniques used to write good programs in
> scalar languages are for the most part unnecessary in array languages like
> J. But once one learns the scalar approach to programming these scalar
> techniques are well entrenched.

It is also possible even if you restrict yourself to writing tacit J,
to code verbs using loops handling one element at a time; however,
this is not only pointless but is also generally quite more difficult
in this case.  In other words, tacit programming naturally compels the
array approach and, in my opinion, beginners should be encouraged to
(try to) code simple verbs tacitly.  I began translating simple verbs
from explicit code to tacit code because these tasks were entertaining
puzzles to solve and I used (13 :) to get hints when I was stuck.  At
some point I realized that any verb, simple or complex, could be coded
tacitly and later I convinced myself that coding tacitly, and fixing
the tacit code of, large systems made a lot of sense and others and I
have been coding in this manner for many years; I now use (13 :)  to
translate alien explicit code to a familiar dialect.

My answer to my own questions follows:  How come? Under what
circumstances?  Because, and when, the interpreter is both very smart
and yet not smart enough.  For example,

   - &. (^. @: *:)  1 2 3
1 0.5 0.33
   - &. ([: ^. *:)  1 2 3
1 0.5 0.33
   - &. ([ ^.@] *:) 1 2 3
|domain error
|   -&.([^.@]*:)1 2 3

   (^. @: *:) (d.1)
+: * %@*:
   ([: ^. *:) (d.1) NB. This is an instance where the interpreter
favors @ over [:
+: * %@*:
   ([ ^.@] *:) (d.1)
|domain error
|   ([^.@]*:)(d.1)

Incidentally, I am also puzzled:

Does anybody know why the interpreter resolves,

   (^. @: *:) (d.1)
+: * %@*:

but it does not resolve the following sentence of the same kind,

   (^. @: *:) (^:_1)
^.@:*:^:_1

considering that it knows,

   (^. @: *:) b._1
%:@:^

?




On Thu, Nov 29, 2012 at 11:49 AM, Ian Clark  wrote:
> Department of Sudden Doubts...
>
> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
> under all circumstances?
>
> If so, where would I go to find this fact written up?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm


On Sat, Dec 1, 2012 at 3:03 AM, Ric Sherlock  wrote:
> Hi Alex,
> Not sure if you're aware of the trig script available as part of the
> 'math/misc' addon, but it may contain at least some definitions you'd like
> to use. If you have the addon installed then you can load the definitions
> using:
>require 'trig'
>
> If you restrict yourself to writing explicit J then it is perfectly
> possible to get away without usin

Re: [Jprogramming] @: and capped fork

[Don & Cathy Kelly]

I've used Turbo Basic which, as I recall, didn't use line numbers, 
compiled very quickly, and was superior to the Fortran of its day -as 
well as being superior in programming and application to the Pascal or 
C++ of its day.  It was tedious to program (less so than C++) but 
debugging was easy - however the APL+PC  V11 which was all I had as a 
reasonable alternative was much more compact and allowed concentration 
on the problem to be solved rather than the details which, in most cases 
could be assigned to the " idiot which counts really fast on his 
fingers"; but somewhat slower for iterative applications. I then 
converted some stuff to visual Basic- which allowed a nice interface but 
really no better performance.


I prefer J over the alternatives but - believe me- the dictionary of J 
is not equivalent to what Gilbert &Rose did for APL. It does seem to 
have a steeper learning curve than APL but, at my age all hills are 
steep. Recognize that the first program I wrote was in MAD (Michigan 
Algorithmic Decoder) with punch card input - about 1961. It was superior 
to the Fortran of it's day and errors were greeted by  an ASCII cartoon 
of Alfred E. Neuman  and the message "This is MAD!"


I do a lot of experimentation to get what I want in a compact form- try 
this- Oh S--t! it doesn't work - try a variation- OK but then it fails 
for something I didn't consider- This forum has provided a lot of 
support and assistance that is very much appreciated.

 Don Kelly


On 02/12/2012 1:52 AM, Linda Alvord wrote:

After quite a few years teaching J, I taught Basic for a semester (poorly). I struggled 
to consider teaching the High School course in Advanced Placement Computer Science and 
could make no sense of it and declined the "opportunity".

I did find that several years of teaching Visual Basic at a two year community college 
was helpful for manipulating images and actually doing practical things. It was as close 
as I ever came to "real programming" as opposed to J.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of R.E. Boss
Sent: Sunday, December 02, 2012 4:25 AM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html

or, as I heard him say much shorter: "Basic ruins your life".


R.E. Boss
  


-Oorspronkelijk bericht-
Van: programming-boun...@forums.jsoftware.com
[mailto:programming-boun...@forums.jsoftware.com] Namens Boyko
Bantchev
Verzonden: zondag 2 december 2012 0:10
Aan: programm...@jsoftware.com
Onderwerp: Re: [Jprogramming] @: and capped fork

On 1 December 2012 16:17, Ian Clark  wrote:

A "training wheels" form of J, tailored to people who know BASIC,
would be so easy to write.

Not necessarily.  A BASIC thinking can be so different that hardly any
tailoring could possibly exist as a bridge to J.

Here is a story.

True BASIC is the modern realization of Kemeny & Kurtz's original
BASIC.  The product is priced at $500.  Its web site says that
'thousands of schools, colleges, corporations, and laboratories use
True BASIC'.  Like the original BASIC, True BASIC's principal target
area of application is education.

But … there are no first-class Boolean values in this language, or
anything in their place.  There are no Boolean (or equivalent)
constants.  Boolean expressions can only be used as conditions in
statements like IF and DO WHILE, but they are not supposed to have
values.  The outcome of Boolean expressions cannot be stored in a
variable, passed as an argument or returned from a function.

Among other things said of this BASIC is that 'it helps … teach the
foundational principles of logic'.  Yet, in the tutorials and other
teaching and learning aids one never finds problems that explicitly
involve logic.  The latter is no surprise: logical calculations are a
hard thing to do without logical values.

'True BASIC' programmers don't even realize that not having a form of
Boolean in the language is a limitation.  This is a world with almost
no common points with the expression-based world of J.
--
For information about J forums see http://www.jsoftware.com/forums.htm

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

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


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

Re: [Jprogramming] @: and capped fork

[Raul Miller]

Note that I never bothered to create an object in either of the two
examples in my previous post.  The second example used a class rather
than an object.

A more literal transliteration of the javascript would be something like this:

a=: cocreate''
b__a=: 'bee'
c__a=: 'see'
do_something@do__a&> nl__a 0

cocreate'' in J is pretty close to new Object in javascript, but
normally you would use conew to create new objects.  But the
javascript could have been written using a= {} instead of using 'new
Object' or even:

a= {b: 'bee', c: 'see'}

And the point here is that javascript uses objects to represent
name/value pairs.  These do correspond to J's variables, so the above
examples are not too bad.  But another way of implementing name/value
pairs in J is to have a couple of parallel lists, one with names, the
other with values.

names=: ;:'b c'
values=: ;:'bee see'

Now it's something like do_something@> values to do the processing you
asked for.  And this should be faster than doing a name lookup -- you
were wanting to process all the values and not caring about the names.
Anyways, "fast" means "do not do unnecessary, useless work".

And, if you do not like the syntax here, you can of course add code to
make things look different.  Here's a hasty example:

begin=: 2 :0
  (m)=: ''
  (n)=: ''
  is=: m 2 :(':';m,'=:',m,', wrote:
> Thanks Marshall and Raul, and yes, of course the question assumed that
> there /was/ a need for an object.
>
> My guess is you'd get that asked a lot if people were arriving at J from OO
> languages, I'd hate to be the one making the case that you don't always
> need objects, even when I agree with that statement.
>
> On 3 December 2012 19:21, Raul Miller  wrote:
>
>> There are several ways of translating that javascript code into J, I
>> would have to know something about the larger context to know which of
>> them I would pick.
>>
>> That said, one of the simplest would be:
>>
>> do_something 'bee'
>> do_something 'see'
>>
>> Another variation would be:
>>
>> b_a_=: 'bee'
>> s_a_=: 'see'
>> do_something@do_a_&> nl_a_ 0
>>
>> But obviously one of my questions would be: why do we even have an
>> object here, and does a different arrangement make sense?
>>
>> --
>> Raul
>>
>> On Mon, Dec 3, 2012 at 1:09 PM, Alex Giannakopoulos
>>  wrote:
>> > On 3 December 2012 15:59, Raul Miller  wrote:
>> >
>> >> That said, when I want to translate J into a language other people
>> >> understand, Javascript is usually my first choice.
>> >>
>> >
>> > Why does that not surprise me?  :-)
>> >
>> >
>> > Incidentally, and if you have nothing better to do, how would you code
>> this
>> > Javascript into J?
>> >  a = new Object();
>> >  a.b = "bee";
>> >  a.c = "see";
>> >  for (var prop in a)
>> >   do_something(a[prop]) ;
>> > --
>> > For information about J forums see http://www.jsoftware.com/forums.htm
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[bill lam]

A workaround has been committed to JAL, please update and try again.

Пнд, 03 Дек 2012, David Ward Lambert писал(а):
> Sadly, the current j version 7 version of the "Object Oriented
> Programming" is broken.
> 
> Lab: Object Oriented Programming
> To advance the lab, press Ctrl-. in JHS or Ctrl-J in Gtk.
> On a tablet your mileage may vary.
> 
> ── (1 of 70) Overview ───
> This lab is about Object Oriented Programming.
> 
> It covers OOP ideas and terminology and shows how to do it.
> )
> callback run error: psel_row_activated_3_
> |value error: wdforms
> |   fms=.wdforms''
> 
> ---
> 
> I was struck, by an earlier post in this thread, of differing
> impressions of j.  I see j as having been carefully crafted with names
> and symbols carefully chosen.  Were I to offer an introduction for
> intended users, say to a j club, the circle functions o. would be among
> the first things I'd show off as mnemonic, easy to learn.  Then again, I
> think the standard emacs key sequences make good sense.  My only gripe
> is that having been a Pascal programmer, and a Makefile writer, and a
> Mathematica user, I often write  noSpace:=  causing spelling error that
> gives me a devil of a time to spot.
> 
> > From: bob therriault 
> > To: programm...@jsoftware.com
> > Subject: Re: [Jprogramming] @: and capped fork
> > Message-ID: <12873c55-cc7c-4ee2-98bf-8e63d61e5...@mac.com>
> > Content-Type: text/plain; CHARSET=US-ASCII
> > 
> > Alex,
> > 
> > I think I would point them towards first the 'Locales" lab and then
> > the "Object Oriented Programming" lab. I think that these two labs
> > would give object oriented people lots of information about how J can
> > be used as an object oriented language.
> > 
> > Cheers, bob
> >>>>>...
> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[bob therriault]

I find myself using J602 for labs (the instructional value is still valid in 
most cases).

Cheers, bob
On 2012-12-03, at 1:06 PM, David Ward Lambert wrote:

> Sadly, the current j version 7 version of the "Object Oriented
> Programming" is broken.
> 
> Lab: Object Oriented Programming
> To advance the lab, press Ctrl-. in JHS or Ctrl-J in Gtk.
> On a tablet your mileage may vary.
> 
> ── (1 of 70) Overview ───
> This lab is about Object Oriented Programming.
> 
> It covers OOP ideas and terminology and shows how to do it.
> )
> callback run error: psel_row_activated_3_
> |value error: wdforms
> |   fms=.wdforms''
> 
> ---
> 
> I was struck, by an earlier post in this thread, of differing
> impressions of j.  I see j as having been carefully crafted with names
> and symbols carefully chosen.  Were I to offer an introduction for
> intended users, say to a j club, the circle functions o. would be among
> the first things I'd show off as mnemonic, easy to learn.  Then again, I
> think the standard emacs key sequences make good sense.  My only gripe
> is that having been a Pascal programmer, and a Makefile writer, and a
> Mathematica user, I often write  noSpace:=  causing spelling error that
> gives me a devil of a time to spot.
> 
>> From: bob therriault 
>> To: programm...@jsoftware.com
>> Subject: Re: [Jprogramming] @: and capped fork
>> Message-ID: <12873c55-cc7c-4ee2-98bf-8e63d61e5...@mac.com>
>> Content-Type: text/plain; CHARSET=US-ASCII
>> 
>> Alex,
>> 
>> I think I would point them towards first the 'Locales" lab and then
>> the "Object Oriented Programming" lab. I think that these two labs
>> would give object oriented people lots of information about how J can
>> be used as an object oriented language.
>> 
>> Cheers, bob
>>>>>> ...
> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

Re: [Jprogramming] @: and capped fork

[David Ward Lambert]

Sadly, the current j version 7 version of the "Object Oriented
Programming" is broken.

Lab: Object Oriented Programming
To advance the lab, press Ctrl-. in JHS or Ctrl-J in Gtk.
On a tablet your mileage may vary.

── (1 of 70) Overview ───
This lab is about Object Oriented Programming.

It covers OOP ideas and terminology and shows how to do it.
)
callback run error: psel_row_activated_3_
|value error: wdforms
|   fms=.wdforms''

---

I was struck, by an earlier post in this thread, of differing
impressions of j.  I see j as having been carefully crafted with names
and symbols carefully chosen.  Were I to offer an introduction for
intended users, say to a j club, the circle functions o. would be among
the first things I'd show off as mnemonic, easy to learn.  Then again, I
think the standard emacs key sequences make good sense.  My only gripe
is that having been a Pascal programmer, and a Makefile writer, and a
Mathematica user, I often write  noSpace:=  causing spelling error that
gives me a devil of a time to spot.

> From: bob therriault 
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] @: and capped fork
> Message-ID: <12873c55-cc7c-4ee2-98bf-8e63d61e5...@mac.com>
> Content-Type: text/plain; CHARSET=US-ASCII
> 
> Alex,
> 
> I think I would point them towards first the 'Locales" lab and then
> the "Object Oriented Programming" lab. I think that these two labs
> would give object oriented people lots of information about how J can
> be used as an object oriented language.
> 
> Cheers, bob
>>>>>...

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

Re: [Jprogramming] @: and capped fork

[bob therriault]

Alex,

I think I would point them towards first the 'Locales" lab and then the "Object 
Oriented Programming" lab. I think that these two labs would give object 
oriented people lots of information about how J can be used as an object 
oriented language.

Cheers, bob

On 2012-12-03, at 11:29 AM, Alex Giannakopoulos wrote:

> Thanks Marshall and Raul, and yes, of course the question assumed that
> there /was/ a need for an object.
> 
> My guess is you'd get that asked a lot if people were arriving at J from OO
> languages, I'd hate to be the one making the case that you don't always
> need objects, even when I agree with that statement.
> 
> On 3 December 2012 19:21, Raul Miller  wrote:
> 
>> There are several ways of translating that javascript code into J, I
>> would have to know something about the larger context to know which of
>> them I would pick.
>> 
>> That said, one of the simplest would be:
>> 
>> do_something 'bee'
>> do_something 'see'
>> 
>> Another variation would be:
>> 
>> b_a_=: 'bee'
>> s_a_=: 'see'
>> do_something@do_a_&> nl_a_ 0
>> 
>> But obviously one of my questions would be: why do we even have an
>> object here, and does a different arrangement make sense?
>> 
>> --
>> Raul
>> 
>> On Mon, Dec 3, 2012 at 1:09 PM, Alex Giannakopoulos
>>  wrote:
>>> On 3 December 2012 15:59, Raul Miller  wrote:
>>> 
 That said, when I want to translate J into a language other people
 understand, Javascript is usually my first choice.
 
>>> 
>>> Why does that not surprise me?  :-)
>>> 
>>> 
>>> Incidentally, and if you have nothing better to do, how would you code
>> this
>>> Javascript into J?
>>> a = new Object();
>>> a.b = "bee";
>>> a.c = "see";
>>> for (var prop in a)
>>>  do_something(a[prop]) ;
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Thanks Marshall and Raul, and yes, of course the question assumed that
there /was/ a need for an object.

My guess is you'd get that asked a lot if people were arriving at J from OO
languages, I'd hate to be the one making the case that you don't always
need objects, even when I agree with that statement.

On 3 December 2012 19:21, Raul Miller  wrote:

> There are several ways of translating that javascript code into J, I
> would have to know something about the larger context to know which of
> them I would pick.
>
> That said, one of the simplest would be:
>
> do_something 'bee'
> do_something 'see'
>
> Another variation would be:
>
> b_a_=: 'bee'
> s_a_=: 'see'
> do_something@do_a_&> nl_a_ 0
>
> But obviously one of my questions would be: why do we even have an
> object here, and does a different arrangement make sense?
>
> --
> Raul
>
> On Mon, Dec 3, 2012 at 1:09 PM, Alex Giannakopoulos
>  wrote:
> > On 3 December 2012 15:59, Raul Miller  wrote:
> >
> >> That said, when I want to translate J into a language other people
> >> understand, Javascript is usually my first choice.
> >>
> >
> > Why does that not surprise me?  :-)
> >
> >
> > Incidentally, and if you have nothing better to do, how would you code
> this
> > Javascript into J?
> >  a = new Object();
> >  a.b = "bee";
> >  a.c = "see";
> >  for (var prop in a)
> >   do_something(a[prop]) ;
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Raul Miller]

There are several ways of translating that javascript code into J, I
would have to know something about the larger context to know which of
them I would pick.

That said, one of the simplest would be:

do_something 'bee'
do_something 'see'

Another variation would be:

b_a_=: 'bee'
s_a_=: 'see'
do_something@do_a_&> nl_a_ 0

But obviously one of my questions would be: why do we even have an
object here, and does a different arrangement make sense?

-- 
Raul

On Mon, Dec 3, 2012 at 1:09 PM, Alex Giannakopoulos
 wrote:
> On 3 December 2012 15:59, Raul Miller  wrote:
>
>> That said, when I want to translate J into a language other people
>> understand, Javascript is usually my first choice.
>>
>
> Why does that not surprise me?  :-)
>
>
> Incidentally, and if you have nothing better to do, how would you code this
> Javascript into J?
>  a = new Object();
>  a.b = "bee";
>  a.c = "see";
>  for (var prop in a)
>   do_something(a[prop]) ;
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Thanks Stefano, that's what I meant, viz. how can you access a structure
within a variable, whether its a box or whatever, by a variable that is
only defined within the context of the main variable, i.e. not an index,
but a structure name.  Same as you'd do with a "struct" in C. A property,
or whatever else you choose to call it.

On 3 December 2012 18:42, Stefano Lanzavecchia  wrote:

> The proposed Javascript is more along the lines of: execute a function
> (do_something) on the value of each (for (var prop)) of the variabiles
> contained in a specified locale (a).
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Marshall Lochbaum]

There are a lot of disclaimers here: this code, without context, is
quite useless, and typically there are easier ways to do things in J
than using objects. But here's the way I would probably do this, if I
decided that the best way to store data was to make use of values in a
locale. The key is nl, which lists all the names in the current locale.

If there's only going to be one instance of a:

b_a_ =. 'bee'
c_a_ =. 'see'
do_something&.> ".@:(,&'_a_')&.> nl_a_ ''

And if you really want a to be a new object and avoid name conflicts
(this is the more literal translation):

a =. cocreate ''
b__a =. 'bee'
c__a =. 'see'
s =. '_',(>a),'_'
do_something&.> ".@:(,&s)&.> nl__a ''

I have used something like this before. The main benefit is that a
locale, as opposed to a noun storing data, can be easily modified from
anywhere, so it allows for more extensible code.

Marshall

On Mon, Dec 03, 2012 at 06:09:56PM +, Alex Giannakopoulos wrote:
> On 3 December 2012 15:59, Raul Miller  wrote:
> 
> > That said, when I want to translate J into a language other people
> > understand, Javascript is usually my first choice.
> >
> 
> Why does that not surprise me?  :-)
> 
> 
> Incidentally, and if you have nothing better to do, how would you code this
> Javascript into J?
>  a = new Object();
>  a.b = "bee";
>  a.c = "see";
>  for (var prop in a)
>   do_something(a[prop]) ;
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Stefano Lanzavecchia]

The proposed Javascript is more along the lines of: execute a function
(do_something) on the value of each (for (var prop)) of the variabiles
contained in a specified locale (a).
So, a literal translation would involve the retrieval of the list of the
variable names (b and c in the exampple, but it could be anything, including
an empty list) defined in the locale "a", the extraction of their values.
In a relatively recent version of Dyalog APL (sorry I can't do it in J) you
could write:

a<-[]NS ''
a.b<-'bee'
a.c<-'see'
do_something each a.(execute each []nl -2)

where "<-" stands for the left-arrow assignement, "[]" for the "quad"
symbol, "each" and "execute" for the primitives with the said name.

--
Stefano

> -Original Message-
> From: programming-boun...@forums.jsoftware.com [mailto:programming-
> boun...@forums.jsoftware.com] On Behalf Of Devon McCormick
> Sent: Monday, December 03, 2012 7:32 PM
> To: J-programming forum
> Subject: Re: [Jprogramming] @: and capped fork
> 
> I'm sure I don't understand the Javascript-specific nuances of your
question,
> but is a J version much different than this?
> 
>do_something"0 a=. 'bee';'see'
> 
> 
> 
> On Mon, Dec 3, 2012 at 1:09 PM, Alex Giannakopoulos
>  > wrote:
> 
> > On 3 December 2012 15:59, Raul Miller  wrote:
> >
> > > That said, when I want to translate J into a language other people
> > > understand, Javascript is usually my first choice.
> > >
> >
> > Why does that not surprise me?  :-)
> >
> >
> > Incidentally, and if you have nothing better to do, how would you code
> > this Javascript into J?
> >  a = new Object();
> >  a.b = "bee";
> >  a.c = "see";
> >  for (var prop in a)
> >   do_something(a[prop]) ;
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> 
> 
> 
> --
> Devon McCormick, CFA
> ^me^ at acm.
> org is my
> preferred e-mail
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

Re: [Jprogramming] @: and capped fork

[Devon McCormick]

I'm sure I don't understand the Javascript-specific nuances of your
question, but is a J version much different than this?

   do_something"0 a=. 'bee';'see'



On Mon, Dec 3, 2012 at 1:09 PM, Alex Giannakopoulos  wrote:

> On 3 December 2012 15:59, Raul Miller  wrote:
>
> > That said, when I want to translate J into a language other people
> > understand, Javascript is usually my first choice.
> >
>
> Why does that not surprise me?  :-)
>
>
> Incidentally, and if you have nothing better to do, how would you code this
> Javascript into J?
>  a = new Object();
>  a.b = "bee";
>  a.c = "see";
>  for (var prop in a)
>   do_something(a[prop]) ;
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>



-- 
Devon McCormick, CFA
^me^ at acm.
org is my
preferred e-mail
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

On 3 December 2012 15:59, Raul Miller  wrote:

> That said, when I want to translate J into a language other people
> understand, Javascript is usually my first choice.
>

Why does that not surprise me?  :-)


Incidentally, and if you have nothing better to do, how would you code this
Javascript into J?
 a = new Object();
 a.b = "bee";
 a.c = "see";
 for (var prop in a)
  do_something(a[prop]) ;
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

On 3 December 2012 15:59, Raul Miller  wrote:

> Also, there isn't anything you can do with lambda notation that you
> cannot do in J.  J's gerunds have all the expressiveness of lambdas,
> and you can implement anything in them up to and including call/cc.
>

Raul, you know your stuff and I always enjoy your posts, even if I don't
necessarily agree that it's as "easy" as you make it sound!...
For instance, I suspected that what you state about gerunds was the case,
but I have really resisted getting into them big time.  It's still at a
hobby level for me, so no rush.  Good to know.

Your description of gerunds does make it sound a bit like J would be too
slow for symbolic processing though, which I am sure is not true.


> And, for that matter, J is something of a dual of Scheme.


Interesting and cool viewpoint.


> Anyways, it's great that arrays are starting to appear in other
> languages.  I can hope that within the next years languages like
> python will have the array expressiveness that APL had back in the
> 60s.


My main concern would be that other languages will rush to exploit
CUDA/OpenCL as soon as they have adequate array implementations.  Here's
(+/ .*)~ ? 10 10 $ 300 in Mathematica, from their current blurb.
CUDADot [RandomInteger[300,{10,10}],RandomInteger[300,{10,10}] ]
They are learning fast.
I haven't tested it, don't have Mathematica, but I don't think the
execution will be slow.
Something to pore on.
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[John Baker]

That getting paid bit is always a bummer


On Mon, Dec 3, 2012 at 9:59 AM, Raul Miller  wrote:

> J's performance is a blend of the language design, Roger Hui's years
> of implementation, and probably Arthur Whitney's influence.
>
> Also, there isn't anything you can do with lambda notation that you
> cannot do in J.  J's gerunds have all the expressiveness of lambdas,
> and you can implement anything in them up to and including call/cc.
> But you probably should not go down that path because:
>
> * This kind of programming is mostly only meaningful for things that
> you can do in other ways, and
>
> * the current implementation gives awful performance for
> gerunds-each-step-of-the-way code, and
>
> * J's arrays give you most of the power of lambdas (and what it leaves
> off is arguably a good thing).
>
> For example, a list of 1s and 0s is semantically equivalent to a list
> of variables in a constrained domain.  And if you are using something
> like (gensym), you should not look down your nose at array indices.
>
> In other words: you could easily implement threads using gerunds, but
> the performance will be so awful that you would not want to use them
> in the current implementation of J.
>
> Anyways, if you like Scheme, I'm not sure why you would have a problem
> with syntax from the 60s.  And, for that matter, J is something of a
> dual of Scheme.  For example, J's dyads serve a role similar to
> Scheme's cons cell, but without bogging down data representation.
>
> Also, as for booleans -- I have a strong opinion that booleans should
> be 1s and 0s and not some other data type.  If you are calling them
> booleans, instead of truth values, it just makes sense to be
> consistent with what George Boole was doing.
>
> That said, when I want to translate J into a language other people
> understand, Javascript is usually my first choice.
>
> But one of the nicest things about J is one of its most reviled
> features: it's line oriented.  So I can iterate testing an expression
> by recalling the previous line, editing it, and hitting enter.  In
> contrast, for example, in DrRacket I have the annoyance of having to
> position the cursor at the end of the input region before hitting
> enter, and even then I do not get a session log showing the history of
> statements with their associated results.
>
> Anyways, it's great that arrays are starting to appear in other
> languages.  I can hope that within the next years languages like
> python will have the array expressiveness that APL had back in the
> 60s. But languages like python have so many irregularities that I
> don't see any reason to use them over something like perl (well...
> except I'm getting paid to use them...).
>
> --
> Raul
>
> On Sun, Dec 2, 2012 at 12:43 AM, Alex Giannakopoulos
>  wrote:
> > I am not sure Ian really meant BASIC when he said "people who know
> BASIC".
> > Perhaps the gist of what he meant was "people who want to do basic
> > programming".
> >
> > No-one really uses old-style BASIC today, regardless of what marketing
> > blurbs may say.  I have *never* seen anyone recommend it to people who
> ask
> > "what language should I start with?" on any programming forum whatsoever.
> >
> > OTOH, the languages that J would be competing with, if it wanted to
> become
> > more widespread, would be today's popular scripting languages - the likes
> > of javascript, python, ruby, even PHP.  These are today's "BASIC"s.  And
> > believe me, they certainly have facilities for booleans  and not only
> that,
> > many of them are functional, or functionally oriented, as well as having
> > popular features like-object orientation and other modern concepts.
> >
> > The J community would be doing itself a disservice (perhaps even
> absenting
> > itself from reality) if it thought it was competing with the world of
> > BASIC!!  We are not in the 80s any more.  Javascript will easily do maps,
> > and its default container is basically a dictionary.  It features an
> > interesting and very powerful way of doing OOP using prototypes.  Python
> > has handy things like list comprehensions, several tons of (established)
> > libraries and is fast moving towards becoming the sane individual's Perl.
> > Even my own favourite (if not widespread) educational language, Scheme,
> is
> > starting to make a serious appearance with systems like PLT/Racket which
> > are pretty complete.   All these languages can be used to make teaching
> > examples as elegant as Bo's, in almost as few lines.  And elegant though
> J
> > might be, nothing will ever beat lambda-calculus in that arena, not even
> > Iverson notation! (personal opinion, I know)
> >
> > So let us not kid ourselves with anachronisms re line-numbers in BASIC...
> > sheesh.
> >
> > The question is what is the real advantage of J.  Why are we using it?
> > For me the answer would be power of expression and PERFORMANCE.  I doubt
> > that I would use it if it wasn't about 100x faster than a good Scheme
> > inte

Re: [Jprogramming] @: and capped fork

[Raul Miller]

J's performance is a blend of the language design, Roger Hui's years
of implementation, and probably Arthur Whitney's influence.

Also, there isn't anything you can do with lambda notation that you
cannot do in J.  J's gerunds have all the expressiveness of lambdas,
and you can implement anything in them up to and including call/cc.
But you probably should not go down that path because:

* This kind of programming is mostly only meaningful for things that
you can do in other ways, and

* the current implementation gives awful performance for
gerunds-each-step-of-the-way code, and

* J's arrays give you most of the power of lambdas (and what it leaves
off is arguably a good thing).

For example, a list of 1s and 0s is semantically equivalent to a list
of variables in a constrained domain.  And if you are using something
like (gensym), you should not look down your nose at array indices.

In other words: you could easily implement threads using gerunds, but
the performance will be so awful that you would not want to use them
in the current implementation of J.

Anyways, if you like Scheme, I'm not sure why you would have a problem
with syntax from the 60s.  And, for that matter, J is something of a
dual of Scheme.  For example, J's dyads serve a role similar to
Scheme's cons cell, but without bogging down data representation.

Also, as for booleans -- I have a strong opinion that booleans should
be 1s and 0s and not some other data type.  If you are calling them
booleans, instead of truth values, it just makes sense to be
consistent with what George Boole was doing.

That said, when I want to translate J into a language other people
understand, Javascript is usually my first choice.

But one of the nicest things about J is one of its most reviled
features: it's line oriented.  So I can iterate testing an expression
by recalling the previous line, editing it, and hitting enter.  In
contrast, for example, in DrRacket I have the annoyance of having to
position the cursor at the end of the input region before hitting
enter, and even then I do not get a session log showing the history of
statements with their associated results.

Anyways, it's great that arrays are starting to appear in other
languages.  I can hope that within the next years languages like
python will have the array expressiveness that APL had back in the
60s. But languages like python have so many irregularities that I
don't see any reason to use them over something like perl (well...
except I'm getting paid to use them...).

-- 
Raul

On Sun, Dec 2, 2012 at 12:43 AM, Alex Giannakopoulos
 wrote:
> I am not sure Ian really meant BASIC when he said "people who know BASIC".
> Perhaps the gist of what he meant was "people who want to do basic
> programming".
>
> No-one really uses old-style BASIC today, regardless of what marketing
> blurbs may say.  I have *never* seen anyone recommend it to people who ask
> "what language should I start with?" on any programming forum whatsoever.
>
> OTOH, the languages that J would be competing with, if it wanted to become
> more widespread, would be today's popular scripting languages - the likes
> of javascript, python, ruby, even PHP.  These are today's "BASIC"s.  And
> believe me, they certainly have facilities for booleans  and not only that,
> many of them are functional, or functionally oriented, as well as having
> popular features like-object orientation and other modern concepts.
>
> The J community would be doing itself a disservice (perhaps even absenting
> itself from reality) if it thought it was competing with the world of
> BASIC!!  We are not in the 80s any more.  Javascript will easily do maps,
> and its default container is basically a dictionary.  It features an
> interesting and very powerful way of doing OOP using prototypes.  Python
> has handy things like list comprehensions, several tons of (established)
> libraries and is fast moving towards becoming the sane individual's Perl.
> Even my own favourite (if not widespread) educational language, Scheme, is
> starting to make a serious appearance with systems like PLT/Racket which
> are pretty complete.   All these languages can be used to make teaching
> examples as elegant as Bo's, in almost as few lines.  And elegant though J
> might be, nothing will ever beat lambda-calculus in that arena, not even
> Iverson notation! (personal opinion, I know)
>
> So let us not kid ourselves with anachronisms re line-numbers in BASIC...
> sheesh.
>
> The question is what is the real advantage of J.  Why are we using it?
> For me the answer would be power of expression and PERFORMANCE.  I doubt
> that I would use it if it wasn't about 100x faster than a good Scheme
> interpreter.  I won't even mention the superiority in terms of space
> requirements.  You can get near-C performance, without the associated
> overhead baggage, plus functions for free.
>
> These are *real* issues, otherwise why bother?  So, I see J as an
> incredibly flexible and powerful R

Re: [Jprogramming] @: and capped fork

[Bo Jacoby]

Alex Giannakopoulos wrote: "it's the *spirit* that counts."

1361: CREDO IN SPIRITUM QUI LOCUTUS EST PER PROPHETAS AMEN

- Bo



>
> Fra: Alex Giannakopoulos 
>Til: programm...@jsoftware.com 
>Sendt: 12:37 mandag den 3. december 2012
>Emne: Re: [Jprogramming] @: and capped fork
> 
>*> Don Guinn* donguinn at gmail.com
>
>*> Sun Dec 2 14:12:01 UTC 2012
>>
>>* [BASIC] and the popular programming languages today are all essentially
>scalar.
>> They handle one element at a time and use loops to handle arrays.
>
>While the central point of what you are saying is definitely true, remember
>that it is not necessarily true for people using the *functional
>approach*.  Before I came to J all my array code was comprised of maps and
>composition of basic functions like transposes, reversals, etc.  Nary a
>loop in sight.
>And I said before I had no problem with that notation, which shares much
>with J, in any language that has lambda calculus.  So Lispers, Haskellers,
>MLers, etc, would not find J quite as alien as one might think!
>The main reason I was attracted to J was the huge performance jump, and
>also that I didn't want to use something like Matlab, even though it's
>great with matrices, but not-so-great with other, general, language
>features.
>
>> Telling someone to look at the script in the library to find out how to
>use [J] won't work.
>
>Quite!
>OK, I am a still only a casual J user, but I never cease to be amazed by
>how many of its basic features I am still unfamiliar with!
>
>> We need to thoroughly document these extensions and consider them part of
>the J language.
>
>Oh, yes.
>Maybe we need an intro J book that doesn't deal so much with programming
>concepts, but how to do simple things that are considered integral to a RAD
>programming IDE.
>How to change display modes, open a graphics window, build a form, use an
>external library, link to a db, manage modules, etc.
>
>On which note, I must ask:  What's the status of Labs under J701(gtk)?
>Seem to be missing.  A few good labs on this sort of thing would be great,
>and could easily be written cooperatively by the community.
>
>Regards
>AG
>
>*> Joey K Tuttle* jkt at qued.com
>
>*> Sun Dec 2 17:32:03 UTC 2012
>>
>*> Also, people still have nostalgic memories of BASIC, e.g.
>>
>http://www.slate.com/articles/technology/books/2012/11/computer_programming_10_print_chr_205_5_rnd_1_goto_10_from_mit_press_reviewed.html
>*
>*
>Great link!  J-stylee programming in BASIC!
>Made me smile.
>Just shows you, it's the *spirit* that counts.
>--
>For information about J forums see http://www.jsoftware.com/forums.htm
>
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

> *Ric Sherlock* tikkanz at gmail.com

> *Sun Dec 2 20:58:35 UTC 2012
>
> *The issue becomes - are we writing scripts/libraries to showcase J to
beginners
> or to provide performant utilities for users?

IMO, = if you want to push J =, there is only one answer to that question.
The old hands will write the optimised stuff anyway, because they need it.

> The tacit formulation of the same algorithm is twice as fast and 3 times
leaner...
> So if we were to include a version in a script which should it be?
> Should we have two scripts, one for beginners & another for normal use?

Absolutely, why not?
I'd much rather a beginner sees your 'nice' cosrule, than your (or my)
implicit one.
I am certain a beginner would feel the same way too, ask any high school
student.
And a fairly serious (novice) user, would obviously rather use implicit for
performance, but the simple version could help him get up to speed by
himself.
require 'trig_beginner' or 'trig_implicit'.  No rocket science here.

Obviously I'm only stating my opinion, but I think this would have applied
to every single technical question I have asked so far on this forum!  I do
really enjoy the communities deep and stimulating answers, of course, but
if I had got the basics pat by myself, I would be in a position to ask more
interesting questions, rather than the boring stuff I usually come up with.
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

*> Don Guinn* donguinn at gmail.com

*> Sun Dec 2 14:12:01 UTC 2012
>
>* [BASIC] and the popular programming languages today are all essentially
scalar.
> They handle one element at a time and use loops to handle arrays.

While the central point of what you are saying is definitely true, remember
that it is not necessarily true for people using the *functional
approach*.  Before I came to J all my array code was comprised of maps and
composition of basic functions like transposes, reversals, etc.  Nary a
loop in sight.
And I said before I had no problem with that notation, which shares much
with J, in any language that has lambda calculus.  So Lispers, Haskellers,
MLers, etc, would not find J quite as alien as one might think!
The main reason I was attracted to J was the huge performance jump, and
also that I didn't want to use something like Matlab, even though it's
great with matrices, but not-so-great with other, general, language
features.

> Telling someone to look at the script in the library to find out how to
use [J] won't work.

Quite!
OK, I am a still only a casual J user, but I never cease to be amazed by
how many of its basic features I am still unfamiliar with!

> We need to thoroughly document these extensions and consider them part of
the J language.

Oh, yes.
Maybe we need an intro J book that doesn't deal so much with programming
concepts, but how to do simple things that are considered integral to a RAD
programming IDE.
How to change display modes, open a graphics window, build a form, use an
external library, link to a db, manage modules, etc.

On which note, I must ask:  What's the status of Labs under J701(gtk)?
Seem to be missing.  A few good labs on this sort of thing would be great,
and could easily be written cooperatively by the community.

Regards
AG

*> Joey K Tuttle* jkt at qued.com

*> Sun Dec 2 17:32:03 UTC 2012
>
*> Also, people still have nostalgic memories of BASIC, e.g.
>
http://www.slate.com/articles/technology/books/2012/11/computer_programming_10_print_chr_205_5_rnd_1_goto_10_from_mit_press_reviewed.html
*
*
Great link!  J-stylee programming in BASIC!
Made me smile.
Just shows you, it's the *spirit* that counts.
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Paul Jackson]

I agree.  There is a lot more to programming than functions.  There is also
the ability to access the outside world.  As a language for algorithms, I
prefer APL.  As a tool to access the rest of the world, I prefer VB.

There are two forms of VB.  The early version provided for exploiting
objects.  That version still lives today inside most Microsoft Office
products (Word, Excel, Outlook, etc).  The .Net version turned a lot of us
on our ear, but in the end the effort was worth it because I finally came
to appreciate what objects really provided.  I've managed enough Java
programmers to understand that they can do everything I can do with VB.Net,
but I know the VB language, tools and development environment and I haven't
bothered to learn most of that for Java.

When I retired, I tried writing my own APL in VB.Net.  I was pleased to
learn that objects gave me the ability to create functions that behave like
operators (read adverbs and conjunctions).  VB also does one thing very
like APL, it provides for automatic type conversion.  Languages like C#
either blow up, or give wildly wrong answers.

For several years, Microsoft has given developer copies of VB.Net away to
anyone willing to register for a Microsoft passport.  Occasionally, if you
sign up as a beta tester for a major .Net release you can get the full
professional version free when it is released.

-- 
Paul

On Sun, Dec 2, 2012 at 9:55 AM, Eldon Eller  wrote:

> A language you know is more useful than a language you don't know
> regardless of its intrinsic virtues.
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Joey K Tuttle]

Sorry, my bad - I suffered a brain fart... Thanks for the correction.

On 2012/12/02 13:28 , Roger Hui wrote:

The tree representation is 5!:4 and it was implemented in v4.0, 1991-11-23
http://www.jsoftware.com/help/release/status.htm#v4.0

Also described in comp.lang.apl on 1991-09-28 (at the time the J Forum did
not exist).
http://groups.google.com/group/comp.lang.apl/browse_thread/thread/5f1c1df7bd72fe51/32691205433c3152



On Sun, Dec 2, 2012 at 1:00 PM, Joey K Tuttle  wrote:


The Tree view is great too (was it really there in 602??)



Yes -

 From ... j701/addons/docs/help/release/**status.htm#v5.1

Changes in Version 5.1, 1992 07 28
   ...
   5!:5   implemented
   ...


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

Re: [Jprogramming] @: and capped fork

[Roger Hui]

The tree representation is 5!:4 and it was implemented in v4.0, 1991-11-23
http://www.jsoftware.com/help/release/status.htm#v4.0

Also described in comp.lang.apl on 1991-09-28 (at the time the J Forum did
not exist).
http://groups.google.com/group/comp.lang.apl/browse_thread/thread/5f1c1df7bd72fe51/32691205433c3152



On Sun, Dec 2, 2012 at 1:00 PM, Joey K Tuttle  wrote:

> > The Tree view is great too (was it really there in 602??)
> >
>
> Yes -
>
> From ... j701/addons/docs/help/release/**status.htm#v5.1
>
> Changes in Version 5.1, 1992 07 28
>   ...
>   5!:5   implemented
>   ...
>
> Browsing the release notes, (Rel) on the DoJ menu, is a good history
> lesson.
>
> On 2012/12/01 22:00 , Alex Giannakopoulos wrote:
>
>> Thanks Ric,
>>
>> I'd been looking all over the config files, but somehow I missed it.
>> The Tree view is great too (was it really there in 602??)
>>
>> A fantastic feature, this too should have pride of place in any J intro
>> blurb.  Man, 701 seriously undersells itself!
>>
>>
>> On 1 December 2012 12:24, Ric Sherlock  wrote:
>>
>>  You can alter the display like you could in j602 by setting the noun
>>> DisplayForm in the base.cfg file. You can access it from the jgtk menu
>>> using
>>> Edit|Configure|Base
>>>
>>>  --**--**
>> --
>> For information about J forums see 
>> http://www.jsoftware.com/**forums.htm
>>
>>  --**--**
> --
> For information about J forums see 
> http://www.jsoftware.com/**forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Joey K Tuttle]

> The Tree view is great too (was it really there in 602??)
>

Yes -

From ... j701/addons/docs/help/release/status.htm#v5.1

Changes in Version 5.1, 1992 07 28
  ...
  5!:5   implemented
  ...

Browsing the release notes, (Rel) on the DoJ menu, is a good history lesson.

On 2012/12/01 22:00 , Alex Giannakopoulos wrote:

Thanks Ric,

I'd been looking all over the config files, but somehow I missed it.
The Tree view is great too (was it really there in 602??)

A fantastic feature, this too should have pride of place in any J intro
blurb.  Man, 701 seriously undersells itself!


On 1 December 2012 12:24, Ric Sherlock  wrote:


You can alter the display like you could in j602 by setting the noun
DisplayForm in the base.cfg file. You can access it from the jgtk menu
using
Edit|Configure|Base


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


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

Re: [Jprogramming] @: and capped fork

[Ric Sherlock]

The issue becomes - are we writing scripts/libraries to showcase J to
beginners or to provide performant utilities for users?
The tacit formulation of the same algorithm is twice as fast and 3 times
leaner (and I'm sure could be improved). The original version was written
to make it similar to the
So if we were to include a version in a script which should it be? Should
we have two scripts, one for beginners & another for normal use?

getang_cosrule=. dfr@arccos@(+:@(*/)@}: %~ +/@:*:@}: - *:@{:)
getlen_cosrule=. %:@(+/@:*:@] - 2 * cos@rfd@[ * */@])
cosrule=: getang_cosrule : getlen_cosrule f.

IMO if user scratch their itches (build stuff they are interested in) and
share the result with the community. If it is of use to you then it will
probably be of use to (some) others too. Of course that doesn't mean
community contributions couldn't be better organized or curated.

On Sun, Dec 2, 2012 at 6:43 PM, Alex Giannakopoulos  wrote:

>
> Love the cos rule suggestion by the way Ric, THAT'S what I'm on about,
> that's the way to showxase J for beginners!
>
> Should be included in the math/misc/trig file.  (At the moment it only has
> the most basic of stuff, function redefinitions and some dfr-rfd stuff -
> hardly a beginners trig library.)
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Eldon Eller]

A language you know is more useful than a language you don't 
knowregardless of its intrinsic virtues.


On 12/2/2012 9:32 AM, Joey K Tuttle wrote:

Also, people still have nostalgic memories of BASIC, e.g.

http://www.slate.com/articles/technology/books/2012/11/computer_programming_10_print_chr_205_5_rnd_1_goto_10_from_mit_press_reviewed.html 



On 2012/12/02 01:49 , Roger Hui wrote:

I don't think that is true, either the long or the short version.  In
general, knowing bad programming helps you appreciate good 
programming when

you see it; the people for whom this is not true would have trouble
learning good programming regardless.  IMO.


On Sun, Dec 2, 2012 at 1:25 AM, R.E. Boss  wrote:


http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html

or, as I heard him say much shorter: "Basic ruins your life".


R.E. Boss


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


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2634/5432 - Release Date: 12/02/12




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

Re: [Jprogramming] @: and capped fork

[Joey K Tuttle]

Also, people still have nostalgic memories of BASIC, e.g.

http://www.slate.com/articles/technology/books/2012/11/computer_programming_10_print_chr_205_5_rnd_1_goto_10_from_mit_press_reviewed.html

On 2012/12/02 01:49 , Roger Hui wrote:

I don't think that is true, either the long or the short version.  In
general, knowing bad programming helps you appreciate good programming when
you see it; the people for whom this is not true would have trouble
learning good programming regardless.  IMO.


On Sun, Dec 2, 2012 at 1:25 AM, R.E. Boss  wrote:


http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html

or, as I heard him say much shorter: "Basic ruins your life".


R.E. Boss


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

Re: [Jprogramming] @: and capped fork

[Don Guinn]

BASIC is the programming language that was popularized when personal
computing became common. It and the popular programming languages today are
all essentially scalar. They handle one element at a time and use loops to
handle arrays. APL, J and a few other languages running around today are
array oriented. Loops and so many techniques used to write good programs in
scalar languages are for the most part unnecessary in array languages like
J. But once one learns the scalar approach to programming these scalar
techniques are well entrenched.

Take a person who has never programmed and there is nothing to unlearn.
They don't keep looking for all those neat techniques they spent years
mastering but are not needed in J. It is difficult to convince a programmer
to ignore what he knows and loves. This makes it hard to teach J to
programmers.

BASIC in this discussion represents all languages which are scalar in their
approach to programming. What we think of as the "original" BASIC is the
version developed by Apple and other micro computer vendors to fit on a 4K
micro computer. Not the real original BASIC developed at Cambridge to run
on a mainframe.

Many of the popular programming languages are adding array handling, but
the array handling is an add-on. It doesn't fit well. The scalar approach
is still their primary approach to programming.

The library extensions to VB, C, Java etc. are well documented and
considered part of the language. One really can't write a decent
application in them without extensive use of those library extensions.

J is well documented in the J dictionary and vocabulary. One can write
decent applications in J without using much from the J library extensions.
It is being kind to say that the library extensions for J are poorly
documented. But today's applications need graphics, GUI, access to data
bases and used on devices only accessible through library extensions.
Telling someone to look at the script in the library to find out how to use
it won't work.

J7 is addressing this change in programming. But the library extensions
necessary for J to build an application for what people expect requires
extensive use of these library extensions.

We need to thoroughly document these extensions and consider them part of
the J language.

On Sat, Dec 1, 2012 at 10:43 PM, Alex Giannakopoulos <
aeg...@blueyonder.co.uk> wrote:

> I am not sure Ian really meant BASIC when he said "people who know BASIC".
> Perhaps the gist of what he meant was "people who want to do basic
> programming".
>
> No-one really uses old-style BASIC today, regardless of what marketing
> blurbs may say.  I have *never* seen anyone recommend it to people who ask
> "what language should I start with?" on any programming forum whatsoever.
>
> .. . .
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ian Clark]

On Sun, Dec 2, 2012 at 5:43 AM, Alex Giannakopoulos
 wrote:
> I am not sure Ian really meant BASIC when he said "people who know BASIC".
> Perhaps the gist of what he meant was "people who want to do basic
> programming".

When I wrote that, I immediately tried qualifying it: "And again for
Fortran, and C, (and Javascript, and Python...?)" Then I decided to
keep it simple, and deleted all that.

I wanted to say "the one language everyone knows, and is free, and
works on any machine, and you can guarantee it's there without having
to be installed." But wasn't I appealing to a world which no longer
exists?

I agree with Boyko. Stripped of these essential qualities, BASIC in
itself is comparatively lacking in merit.
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Linda Alvord]

The down side of Visual Basic was the cost of the program. It was quite 
expensive to buy and I didn't. All the things I wrote are still on my laptop 
and useless.

Sadly, many of the things I wrote in early versions of J stopped working in 
later versions. I keep hoping someday to rescue some of them. It is hard to 
keep up with the forum and all the exciting things people all over the planet 
are thinking about and writing about in wiki and other places.  At the present, 
I'm trying to play catch up with many new ways of doing things in j701. Time is 
of the essence and there isn't enough it seems

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Linda Alvord
Sent: Sunday, December 02, 2012 4:52 AM
To: preogramm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

After quite a few years teaching J, I taught Basic for a semester (poorly). I 
struggled to consider teaching the High School course in Advanced Placement 
Computer Science and could make no sense of it and declined the "opportunity".

I did find that several years of teaching Visual Basic at a two year community 
college was helpful for manipulating images and actually doing practical 
things. It was as close as I ever came to "real programming" as opposed to J.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of R.E. Boss
Sent: Sunday, December 02, 2012 4:25 AM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html

or, as I heard him say much shorter: "Basic ruins your life".


R.E. Boss
 

> -Oorspronkelijk bericht-
> Van: programming-boun...@forums.jsoftware.com
> [mailto:programming-boun...@forums.jsoftware.com] Namens Boyko 
> Bantchev
> Verzonden: zondag 2 december 2012 0:10
> Aan: programm...@jsoftware.com
> Onderwerp: Re: [Jprogramming] @: and capped fork
> 
> On 1 December 2012 16:17, Ian Clark  wrote:
> > A "training wheels" form of J, tailored to people who know BASIC, 
> > would be so easy to write.
> 
> Not necessarily.  A BASIC thinking can be so different that hardly any 
> tailoring could possibly exist as a bridge to J.
> 
> Here is a story.
> 
> True BASIC is the modern realization of Kemeny & Kurtz's original 
> BASIC.  The product is priced at $500.  Its web site says that 
> 'thousands of schools, colleges, corporations, and laboratories use 
> True BASIC'.  Like the original BASIC, True BASIC's principal target 
> area of application is education.
> 
> But … there are no first-class Boolean values in this language, or 
> anything in their place.  There are no Boolean (or equivalent) 
> constants.  Boolean expressions can only be used as conditions in 
> statements like IF and DO WHILE, but they are not supposed to have 
> values.  The outcome of Boolean expressions cannot be stored in a 
> variable, passed as an argument or returned from a function.
> 
> Among other things said of this BASIC is that 'it helps … teach the 
> foundational principles of logic'.  Yet, in the tutorials and other 
> teaching and learning aids one never finds problems that explicitly 
> involve logic.  The latter is no surprise: logical calculations are a 
> hard thing to do without logical values.
> 
> 'True BASIC' programmers don't even realize that not having a form of 
> Boolean in the language is a limitation.  This is a world with almost 
> no common points with the expression-based world of J.
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

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

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

Re: [Jprogramming] @: and capped fork

[Linda Alvord]

After quite a few years teaching J, I taught Basic for a semester (poorly). I 
struggled to consider teaching the High School course in Advanced Placement 
Computer Science and could make no sense of it and declined the "opportunity".

I did find that several years of teaching Visual Basic at a two year community 
college was helpful for manipulating images and actually doing practical 
things. It was as close as I ever came to "real programming" as opposed to J.

Linda


-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of R.E. Boss
Sent: Sunday, December 02, 2012 4:25 AM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html

or, as I heard him say much shorter: "Basic ruins your life".


R.E. Boss
 

> -Oorspronkelijk bericht-
> Van: programming-boun...@forums.jsoftware.com 
> [mailto:programming-boun...@forums.jsoftware.com] Namens Boyko 
> Bantchev
> Verzonden: zondag 2 december 2012 0:10
> Aan: programm...@jsoftware.com
> Onderwerp: Re: [Jprogramming] @: and capped fork
> 
> On 1 December 2012 16:17, Ian Clark  wrote:
> > A "training wheels" form of J, tailored to people who know BASIC, 
> > would be so easy to write.
> 
> Not necessarily.  A BASIC thinking can be so different that hardly any 
> tailoring could possibly exist as a bridge to J.
> 
> Here is a story.
> 
> True BASIC is the modern realization of Kemeny & Kurtz's original 
> BASIC.  The product is priced at $500.  Its web site says that 
> 'thousands of schools, colleges, corporations, and laboratories use 
> True BASIC'.  Like the original BASIC, True BASIC's principal target 
> area of application is education.
> 
> But … there are no first-class Boolean values in this language, or 
> anything in their place.  There are no Boolean (or equivalent) 
> constants.  Boolean expressions can only be used as conditions in 
> statements like IF and DO WHILE, but they are not supposed to have 
> values.  The outcome of Boolean expressions cannot be stored in a 
> variable, passed as an argument or returned from a function.
> 
> Among other things said of this BASIC is that 'it helps … teach the 
> foundational principles of logic'.  Yet, in the tutorials and other 
> teaching and learning aids one never finds problems that explicitly 
> involve logic.  The latter is no surprise: logical calculations are a 
> hard thing to do without logical values.
> 
> 'True BASIC' programmers don't even realize that not having a form of 
> Boolean in the language is a limitation.  This is a world with almost 
> no common points with the expression-based world of J.
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

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

Re: [Jprogramming] @: and capped fork

[Roger Hui]

I don't think that is true, either the long or the short version.  In
general, knowing bad programming helps you appreciate good programming when
you see it; the people for whom this is not true would have trouble
learning good programming regardless.  IMO.


On Sun, Dec 2, 2012 at 1:25 AM, R.E. Boss  wrote:

> http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html
>
> or, as I heard him say much shorter: "Basic ruins your life".
>
>
> R.E. Boss
>
>
> > -Oorspronkelijk bericht-
> > Van: programming-boun...@forums.jsoftware.com [mailto:
> programming-boun...@forums.jsoftware.com] Namens Boyko
> > Bantchev
> > Verzonden: zondag 2 december 2012 0:10
> > Aan: programm...@jsoftware.com
> > Onderwerp: Re: [Jprogramming] @: and capped fork
> >
> > On 1 December 2012 16:17, Ian Clark  wrote:
> > > A "training wheels" form of J, tailored to people who know BASIC,
> > > would be so easy to write.
> >
> > Not necessarily.  A BASIC thinking can be so different that hardly
> > any tailoring could possibly exist as a bridge to J.
> >
> > Here is a story.
> >
> > True BASIC is the modern realization of Kemeny & Kurtz's original
> > BASIC.  The product is priced at $500.  Its web site says that
> > 'thousands of schools, colleges, corporations, and laboratories
> > use True BASIC'.  Like the original BASIC, True BASIC's principal
> > target area of application is education.
> >
> > But … there are no first-class Boolean values in this language,
> > or anything in their place.  There are no Boolean (or equivalent)
> > constants.  Boolean expressions can only be used as conditions in
> > statements like IF and DO WHILE, but they are not supposed to have
> > values.  The outcome of Boolean expressions cannot be stored in a
> > variable, passed as an argument or returned from a function.
> >
> > Among other things said of this BASIC is that 'it helps … teach the
> > foundational principles of logic'.  Yet, in the tutorials and other
> > teaching and learning aids one never finds problems that explicitly
> > involve logic.  The latter is no surprise: logical calculations are
> > a hard thing to do without logical values.
> >
> > 'True BASIC' programmers don't even realize that not having a form
> > of Boolean in the language is a limitation.  This is a world with
> > almost no common points with the expression-based world of J.
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[R.E. Boss]

http://www.brainyquote.com/quotes/quotes/e/edsgerdijk201164.html

or, as I heard him say much shorter: "Basic ruins your life".


R.E. Boss


> -Oorspronkelijk bericht-
> Van: programming-boun...@forums.jsoftware.com 
> [mailto:programming-boun...@forums.jsoftware.com] Namens Boyko
> Bantchev
> Verzonden: zondag 2 december 2012 0:10
> Aan: programm...@jsoftware.com
> Onderwerp: Re: [Jprogramming] @: and capped fork
> 
> On 1 December 2012 16:17, Ian Clark  wrote:
> > A "training wheels" form of J, tailored to people who know BASIC,
> > would be so easy to write.
> 
> Not necessarily.  A BASIC thinking can be so different that hardly
> any tailoring could possibly exist as a bridge to J.
> 
> Here is a story.
> 
> True BASIC is the modern realization of Kemeny & Kurtz's original
> BASIC.  The product is priced at $500.  Its web site says that
> 'thousands of schools, colleges, corporations, and laboratories
> use True BASIC'.  Like the original BASIC, True BASIC's principal
> target area of application is education.
> 
> But … there are no first-class Boolean values in this language,
> or anything in their place.  There are no Boolean (or equivalent)
> constants.  Boolean expressions can only be used as conditions in
> statements like IF and DO WHILE, but they are not supposed to have
> values.  The outcome of Boolean expressions cannot be stored in a
> variable, passed as an argument or returned from a function.
> 
> Among other things said of this BASIC is that 'it helps … teach the
> foundational principles of logic'.  Yet, in the tutorials and other
> teaching and learning aids one never finds problems that explicitly
> involve logic.  The latter is no surprise: logical calculations are
> a hard thing to do without logical values.
> 
> 'True BASIC' programmers don't even realize that not having a form
> of Boolean in the language is a limitation.  This is a world with
> almost no common points with the expression-based world of J.
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

Re: [Jprogramming] @: and capped fork

[bob therriault]

Hi Alex,

Oleg, Ric, Bill, Brian, Don and I collaborated on this script 3 years ago. If 
it is of use to you feel free to use it. It runs on J602 and uses radio buttons 
to select the viewing style on a wd form. It was never picked up since it is 
generally quicker to just change the display as you work with the interpreter. 
In an educational environment it may prove to be more useful, feel free to use 
it if you like. 

The actual correspondence on the development date back to this thread in the 
programming forum. 
http://jsoftware.com/pipermail/programming/2009-April/014508.html

Cheers, bob

coerase<'rgtVisual' NB. debug - clear traces of globals
coclass 'rgtVisual'

NB. -
NB. This script creates a form that takes tacit sentences
NB. entered by the user in a text box and displays the
NB. selected format in a listbox.
NB. -

DISPLAY=: 0 : 0
pc display dialog;pn "Tacit Display";
xywh 9 156 216 22;cc box edit topmove rightmove bottommove;
xywh 248 24 60 11;cc cbFormatBox checkbox leftmove rightmove;cn "Box  Format";
xywh 248 40 60 11;cc cbFormatTree checkbox leftmove rightmove group;cn  "Tree 
Format";
xywh 248 56 60 11;cc cbFormatLinear checkbox leftmove rightmove  group;cn 
"Linear Format";
xywh 248 72 60 11;cc cbFormatParens checkbox leftmove rightmove  group;cn 
"Parens Format";
xywh 240 12 95 80;cc format groupbox leftmove rightmove;cn "Display  Style";
xywh 0 0 225 150;cc tdisp editm ws_hscroll ws_vscroll es_readonly  rightmove 
bottommove;
xywh 248 114 60 11;cc rbDAscii radiobutton leftmove rightmove;cn  "Ascii";
xywh 248 131 60 11;cc rbDLine radiobutton leftmove rightmove group;cn  "Line";
xywh 240 103 95 47;cc gbDrawStyle groupbox leftmove rightmove;cn  "Drawing 
Style";
pas 6 6;pcenter;
rem form end;
)

CBFORMAT=: 'cbFormat'&,each ;:'Box Tree Linear Parens'
RBD=: 'rbD'&,each ;:'Ascii Line'
LINEDRAW =: (16+i.11) { a.
ASCIIDRAW=: '+|-'

rbDstate =: 3 : '>((9!:6 ) -: ASCIIDRAW){;:''rbDLine rbDAscii'''


display_run=: 3 : 0
  wd DISPLAY
  wd 'set box *',y
  wd 'setfont box ',FIXFONT,'; setfocus box;'
  wd 'setfont tdisp ',FIXFONT,'; setenable tdisp 1;'
  wd 'set ',(0{::CBFORMAT),' 1;'
  wd 'set ',(rbDstate ''),' 1;'
  box=: y
  update ''
  wd 'pshow;'
)

display_resume=: 3 : 0
  wd 'psel display'
  wd 'set ',(rbDstate ''),' 1;'
  wd 'set box *',box=: y
  update''
)

display_close=: 3 : 0
  wd'pclose'
)

styles=: (4 : 0)"0 _
  ".'zzz=. ' , y
  res=. 5!: x <'zzz'
  ({.RBD) wdget wd 'qd'){ LINEDRAW ,: ASCIIDRAW
y
)

rstD=: 3 : '9!:7 UDRAW'
drw=:  stD :. rstD

update=: 3 : 0
try.
  (3 : 'wd ''set tdisp *'', utf8 ; (2 4 5 6#~ 99".> CBFORMAT wdget wd ''qd'') 
styles y') &. drw box
catch.
  wd 'set tdisp *',13!:12 ''
  rstD ''
end.
)

display_box_button=: update

('display_'&,each RBD,each<'_button')=: update

('display_'&,each CBFORMAT,each<'_button')=: update

display=: display_run`display_resume @.((<'display') e. {."1 @wdforms)

display_z_=: display_rgtVisual_

display_cancel=: display_close


display '+/ % #'

On 2012-12-01, at 10:02 PM, Alex Giannakopoulos wrote:

> Would be amazing, and really useful for educational purposes too, if we
> could change between modes on the fly.
> 
> On 2 December 2012 06:00, Alex Giannakopoulos wrote:
> 
>> Thanks Ric,
>> 
>> I'd been looking all over the config files, but somehow I missed it.
>> The Tree view is great too (was it really there in 602??)
>> 
>> A fantastic feature, this too should have pride of place in any J intro
>> blurb.  Man, 701 seriously undersells itself!
>> 
>> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Would be amazing, and really useful for educational purposes too, if we
could change between modes on the fly.

On 2 December 2012 06:00, Alex Giannakopoulos wrote:

> Thanks Ric,
>
> I'd been looking all over the config files, but somehow I missed it.
> The Tree view is great too (was it really there in 602??)
>
> A fantastic feature, this too should have pride of place in any J intro
> blurb.  Man, 701 seriously undersells itself!
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Thanks Ric,

I'd been looking all over the config files, but somehow I missed it.
The Tree view is great too (was it really there in 602??)

A fantastic feature, this too should have pride of place in any J intro
blurb.  Man, 701 seriously undersells itself!


On 1 December 2012 12:24, Ric Sherlock  wrote:

> You can alter the display like you could in j602 by setting the noun
> DisplayForm in the base.cfg file. You can access it from the jgtk menu
> using
> Edit|Configure|Base
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

I am not sure Ian really meant BASIC when he said "people who know BASIC".
Perhaps the gist of what he meant was "people who want to do basic
programming".

No-one really uses old-style BASIC today, regardless of what marketing
blurbs may say.  I have *never* seen anyone recommend it to people who ask
"what language should I start with?" on any programming forum whatsoever.

OTOH, the languages that J would be competing with, if it wanted to become
more widespread, would be today's popular scripting languages - the likes
of javascript, python, ruby, even PHP.  These are today's "BASIC"s.  And
believe me, they certainly have facilities for booleans  and not only that,
many of them are functional, or functionally oriented, as well as having
popular features like-object orientation and other modern concepts.

The J community would be doing itself a disservice (perhaps even absenting
itself from reality) if it thought it was competing with the world of
BASIC!!  We are not in the 80s any more.  Javascript will easily do maps,
and its default container is basically a dictionary.  It features an
interesting and very powerful way of doing OOP using prototypes.  Python
has handy things like list comprehensions, several tons of (established)
libraries and is fast moving towards becoming the sane individual's Perl.
Even my own favourite (if not widespread) educational language, Scheme, is
starting to make a serious appearance with systems like PLT/Racket which
are pretty complete.   All these languages can be used to make teaching
examples as elegant as Bo's, in almost as few lines.  And elegant though J
might be, nothing will ever beat lambda-calculus in that arena, not even
Iverson notation! (personal opinion, I know)

So let us not kid ourselves with anachronisms re line-numbers in BASIC...
sheesh.

The question is what is the real advantage of J.  Why are we using it?
For me the answer would be power of expression and PERFORMANCE.  I doubt
that I would use it if it wasn't about 100x faster than a good Scheme
interpreter.  I won't even mention the superiority in terms of space
requirements.  You can get near-C performance, without the associated
overhead baggage, plus functions for free.

These are *real* issues, otherwise why bother?  So, I see J as an
incredibly flexible and powerful RAD environment, which frankly, I think
has no peer at the moment.  From concept to production in amazing time.
Not to mention that if it ever gets to use CUDA-like GPU technology, it
will blow *everything* out of the water.

So I think that *THIS* is what has to be emphasised when people ask why the
should bother with the steep learning curve.  Frankly. I'd struggle to
think of a reason why anyone would otherwise bother with concepts like
capped forks, a binary infix syntax from the 60s (which may be very wise,
but certainly not in today's mainstream) and boxes.  And while I love the
array operation philosophy, it is starting to appear in other languages
too, you know no disrespect meant to anyone or anything, just trying to
reflect something of the attitudes I see out there every day.

==

Love the cos rule suggestion by the way Ric, THAT'S what I'm on about,
that's the way to showxase J for beginners!

Should be included in the math/misc/trig file.  (At the moment it only has
the most basic of stuff, function redefinitions and some dfr-rfd stuff -
hardly a beginners trig library.)



On 1 December 2012 23:10, Boyko Bantchev  wrote:

> On 1 December 2012 16:17, Ian Clark  wrote:
> > A "training wheels" form of J, tailored to people who know BASIC,
> > would be so easy to write.
>
> Not necessarily.  A BASIC thinking can be so different that hardly
> any tailoring could possibly exist as a bridge to J.
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Raul Miller]

I think "training wheels" versions of J should just be J, with
documentation tailored to the interests of the audience.

For example, if you want a language like basic, you can easily add
line numbers to a program.

example=: verb define
[1] 'this is line one'
[2] 'this is line two'
[3] 'this is line three'
[4] NB. ...
)

They are not mechanically useful, but they can give the user a way of
referring to a specific line and the familiarity of line numbers might
make the learning transition easier for someone that takes comfort
from them.

Anyways, it's quite true that for a specific task you probably only
need a handful of J primitives, but that handful will tend to vary,
based on the task.

FYI,

-- 
Raul


On Sat, Dec 1, 2012 at 9:17 AM, Ian Clark  wrote:
> Bravo, Alex. These are the right questions you're asking. And -- yes
> -- I too liked Bo's suggestion.
>
> A "training wheels" form of J, tailored to people who know BASIC,
> would be so easy to write. Plus its accompanying textbook (essential
> to write, if not to read). But it really would need testing on
> bona-fide beginners, to see whether the shells are landing on-target.
>
> When I first came to J, I was dismayed at its alien-ness. So
> unnecessary, I thought. A glance inside the _z_ locale convinced me
> this was implicitly recognised, if not publicly admitted. Years later,
> J now seems perfectly natural to me, and I'm shocked at my past
> attitude.
>
> But "users can get used to anything", a respected ergonomist assured
> me once. "They kiss the whip. They grow to love the systems they are
> forced to use". (That's not me, of course. Oh no no no :-)
>
> The need for "training wheels" soon goes away. Gradually. Any
> programmer is amenable to the invitation "ok now, wouldn't you like to
> get rid of an inessential layer...?" I still habitually use smoutput,
> inv and each, instead of 1!:2, ^:_1 and &.>, but I no longer have much
> use for pick, rows and define.
>
> Once upon a time, "implementation languages" (ILs) were in fashion.
> The idea was that every problem domain, like linear algebra or
> electronic circuitry, had its own domain-specific language, or IL,
> typically residing in a library of subroutines. The thing to do (so
> the idea ran) was to write an app (starting with J, say) in 2 clear
> stages:
>  J --> IL --> app
> Most developers do this automatically, though unconsciously and
> unevenly. The proponents of the idea wanted to systematise it,
> especially for developer teams. Also for "courseware", eg a sandbox to
> support a course called: IT for electrical engineers, or IT for
> biology technicians (two actual examples I used to teach.) Such
> courseware would then face becoming a standard in education, acquiring
> its own bestseller textbooks. In the UK in the 80s, the govt actually
> put money behind organisations like BECTa to promote some of the more
> successful ILs. These were typically originated by some university
> dept of education, in cooperation with one or two trial schools.
>
> I mention all this just to say that J is a super language for
> implementing an IL. Even better than APL and FORTH (not forgetting the
> C preprocessor!) -- and these lend themselves to writing an IL far
> better than most of the leading industry languages. Typically an IL
> "primitive" is defined in a single terse line, eg:
>rfd=: 180 %~ o.NB. Radians from degrees
>sin=: 1&o.
>SIN=: sin@rfd
> making the given IL easy to publish, and distribute to students.
>
> On Sat, Dec 1, 2012 at 4:14 AM, Alex Giannakopoulos
>  wrote:
>> On 30 November 2012 16:17, Bo Jacoby  wrote:
>>
>>> J is a rich language, and it might be a good idea to define an elementary
>>> subset for beginners.
>>
>>
>> Couldn't agree more.
>> A simple startup configuration file.  Define verbs for trig functions so
>> they don't look stupidly arbitrary.
>> Some other elementary functions too, like polar2rect and rect2polar
>> conversions that act on vectors (none of this xfy binary stuff here
>> please), you know, stuff like you can find on *calculators*.
>> Define dot-product, matrix-multiplication, cross-product, determinant, etc,
>> as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
>> NOT want to know about the . operator at the level of the jdict, it is a
>> highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
>> want to do matrix ops.  I was told this was a language for linear algebra.
>> It would probably be a good idea, then, if we could do some linalg -
>> straight out of the box - without serious brain damage.  I have had abuse
>> hurled at me by math teachers who have seen J's linalg primitives (LOL).
>> Add some nice libs for equation solving while we're at it.  Simultaneous
>> and also some numeric solvers.  This is what people want.  A language, not
>> an assembler for a language.
>>
>>
>>> J is a nice calculator for elementary computations. You can do a lot of
>>> computing without knowing anything 

Re: [Jprogramming] @: and capped fork

[Bo Jacoby]

Alex, What I had in mind is even more elementary, such as using J for 
explaining addition and multiplication of  nonnegative integers like this.

   1 NB. this is a one
1
   14#1 NB. this is a list of fourteen ones
1 1 1 1 1 1 1 1 1 1 1 1 1 1
   9#2 NB. this is a list of nine twos
2 2 2 2 2 2 2 2 2
   (14#1),(9#2) NB. here are the two lists concatenated
1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2
      #((14#1),(9#2)) NB. counting the concatenated list
23
   plus=. 4 : '#((x#1),(y#2))' NB.make a program 'plus' to count such 
concatenated lists
   14 plus 9 NB. test the program
23
   14+9 NB. the same  program is provided by the J system in a more efficient 
version called +
23
   3#1 NB. three ones
1 1 1
   9#(3#1) NB. nine examples of the three ones
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
   #(9#(3#1)) NB. count it
27
   times=. 4 : '#(x#(y#1))' NB. make a program 'times'
   9 times 3 NB. test the program
27
   9*3 NB. the program is provided by the J system in a faster and smaller 
version called *
27


I see no reason to tell the beginner that some of his parentheses are 
superfluous. Let him write them until he is familiar with elementary 
programming and arithmetic.

- Bo



>
> Fra: Alex Giannakopoulos 
>Til: programm...@jsoftware.com 
>Sendt: 5:14 lørdag den 1. december 2012
>Emne: Re: [Jprogramming] @: and capped fork
> 
>On 30 November 2012 16:17, Bo Jacoby  wrote:
>
>> J is a rich language, and it might be a good idea to define an elementary
>> subset for beginners.
>
>
>Couldn't agree more.
>A simple startup configuration file.  Define verbs for trig functions so
>they don't look stupidly arbitrary.
>Some other elementary functions too, like polar2rect and rect2polar
>conversions that act on vectors (none of this xfy binary stuff here
>please), you know, stuff like you can find on *calculators*.
>Define dot-product, matrix-multiplication, cross-product, determinant, etc,
>as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
>NOT want to know about the . operator at the level of the jdict, it is a
>highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
>want to do matrix ops.  I was told this was a language for linear algebra.
>It would probably be a good idea, then, if we could do some linalg -
>straight out of the box - without serious brain damage.  I have had abuse
>hurled at me by math teachers who have seen J's linalg primitives (LOL).
>Add some nice libs for equation solving while we're at it.  Simultaneous
>and also some numeric solvers.  This is what people want.  A language, not
>an assembler for a language.
>
>
>> J is a nice calculator for elementary computations. You can do a lot of
>> computing without knowing anything about binomial coefficients and taylor
>> expansions and capped forks.
>
>
>Agree with the first two, NO way on the third.  Even the 13 verb gives you
>capped verbs, there is no way to begin learning J without it.  Also they
>solve the problem of having to figure if you should use At or Atop,
>invaluable for a beginner who hasn;t quite mastered rank yet.
>
>This problem, which once again gives rise to a long thread, could easily be
>solved by a highly visible Programming FAQ page, with lots of links to.
>Deal with capped forks, @ and @:  and why you can't have things like   +/ a
>b c   You know, the questions people *keep asking*.   Remove ancient
>irrelevant stuff like the use of x. and y.   We are not at J401 any more.
>
>
>> If you need to understand everything in order to be happy, then you may be
>> unhappy. I taught my son elementary APL when he was 10 years old, and he
>> loved it!
>>
>
>Would he have been just as happy at 14 when he had to use the cosine rule
>to solve a triangle?  Would he really prefer
>cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
>or
>cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
>to
>cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
>Just wondering...
>
>These are simple enough things to do, and I speak as a J newcomer.  There's
>not many languages you can say that about after two and a half years!  The
>Zen of J, grasshopper.
>
>Incidentally, is there a way to cap a monadic hook on the left?
>For example (=<.) was mentioned, but obviously it allows dyadic arguments,
>and fails if they are offered.
>Short of wrting monad : 'y=<.y'  is there a way I can keep it monadic (and
>implicit)?
>--
>For information about J forums see http://www.jsoftware.com/forums.htm
>
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ian Clark]

Bravo, Alex. These are the right questions you're asking. And -- yes
-- I too liked Bo's suggestion.

A "training wheels" form of J, tailored to people who know BASIC,
would be so easy to write. Plus its accompanying textbook (essential
to write, if not to read). But it really would need testing on
bona-fide beginners, to see whether the shells are landing on-target.

When I first came to J, I was dismayed at its alien-ness. So
unnecessary, I thought. A glance inside the _z_ locale convinced me
this was implicitly recognised, if not publicly admitted. Years later,
J now seems perfectly natural to me, and I'm shocked at my past
attitude.

But "users can get used to anything", a respected ergonomist assured
me once. "They kiss the whip. They grow to love the systems they are
forced to use". (That's not me, of course. Oh no no no :-)

The need for "training wheels" soon goes away. Gradually. Any
programmer is amenable to the invitation "ok now, wouldn't you like to
get rid of an inessential layer...?" I still habitually use smoutput,
inv and each, instead of 1!:2, ^:_1 and &.>, but I no longer have much
use for pick, rows and define.

Once upon a time, "implementation languages" (ILs) were in fashion.
The idea was that every problem domain, like linear algebra or
electronic circuitry, had its own domain-specific language, or IL,
typically residing in a library of subroutines. The thing to do (so
the idea ran) was to write an app (starting with J, say) in 2 clear
stages:
 J --> IL --> app
Most developers do this automatically, though unconsciously and
unevenly. The proponents of the idea wanted to systematise it,
especially for developer teams. Also for "courseware", eg a sandbox to
support a course called: IT for electrical engineers, or IT for
biology technicians (two actual examples I used to teach.) Such
courseware would then face becoming a standard in education, acquiring
its own bestseller textbooks. In the UK in the 80s, the govt actually
put money behind organisations like BECTa to promote some of the more
successful ILs. These were typically originated by some university
dept of education, in cooperation with one or two trial schools.

I mention all this just to say that J is a super language for
implementing an IL. Even better than APL and FORTH (not forgetting the
C preprocessor!) -- and these lend themselves to writing an IL far
better than most of the leading industry languages. Typically an IL
"primitive" is defined in a single terse line, eg:
   rfd=: 180 %~ o.NB. Radians from degrees
   sin=: 1&o.
   SIN=: sin@rfd
making the given IL easy to publish, and distribute to students.

On Sat, Dec 1, 2012 at 4:14 AM, Alex Giannakopoulos
 wrote:
> On 30 November 2012 16:17, Bo Jacoby  wrote:
>
>> J is a rich language, and it might be a good idea to define an elementary
>> subset for beginners.
>
>
> Couldn't agree more.
> A simple startup configuration file.  Define verbs for trig functions so
> they don't look stupidly arbitrary.
> Some other elementary functions too, like polar2rect and rect2polar
> conversions that act on vectors (none of this xfy binary stuff here
> please), you know, stuff like you can find on *calculators*.
> Define dot-product, matrix-multiplication, cross-product, determinant, etc,
> as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
> NOT want to know about the . operator at the level of the jdict, it is a
> highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
> want to do matrix ops.  I was told this was a language for linear algebra.
> It would probably be a good idea, then, if we could do some linalg -
> straight out of the box - without serious brain damage.  I have had abuse
> hurled at me by math teachers who have seen J's linalg primitives (LOL).
> Add some nice libs for equation solving while we're at it.  Simultaneous
> and also some numeric solvers.  This is what people want.  A language, not
> an assembler for a language.
>
>
>> J is a nice calculator for elementary computations. You can do a lot of
>> computing without knowing anything about binomial coefficients and taylor
>> expansions and capped forks.
>
>
> Agree with the first two, NO way on the third.  Even the 13 verb gives you
> capped verbs, there is no way to begin learning J without it.  Also they
> solve the problem of having to figure if you should use At or Atop,
> invaluable for a beginner who hasn;t quite mastered rank yet.
>
> This problem, which once again gives rise to a long thread, could easily be
> solved by a highly visible Programming FAQ page, with lots of links to.
> Deal with capped forks, @ and @:  and why you can't have things like   +/ a
> b c   You know, the questions people *keep asking*.   Remove ancient
> irrelevant stuff like the use of x. and y.   We are not at J401 any more.
>
>
>> If you need to understand everything in order to be happy, then you may be
>> unhappy. I taught my son elementary APL when he was 10 years old, and 

Re: [Jprogramming] @: and capped fork

[Ric Sherlock]

You can alter the display like you could in j602 by setting the noun
DisplayForm in the base.cfg file. You can access it from the jgtk menu using
Edit|Configure|Base

As others have described in this thread, beginners come in many different
shapes & sizes which makes it pretty hard to come up with the "right" set
of tools for beginners. I know for example that it took me at least 18
months before I really started to understand tacit. I was happy and
productive without it. For others tacit J is why they're drawn to the
language.

Here's one relatively understandable way of defining the cosine rule that
might work for beginners.

require 'trig'
NB.*cosrule v Uses cosine rule to calc missing angle/side
NB. monadic result: length of missing side
NB. dyadic result: size of missing angle
NB. y is: lengths of known sides
NB. x is: size of angle opposite unknown side
NB. eg: cosrule 4.2 6.9 4
NB. eg: 31.8183 cosrule 4.2 6.9
cosrule=: 3 : 0
  'a b c'=. 3 {. y
  dfr arccos ((+/ *: a,b) - *:c) % 2*a*b
:
  'a b'=. 2 {. y
  C=. rfd x
  %: (+/ *: a,b) - 2*a*b*cos C
)



On Sun, Dec 2, 2012 at 12:15 AM, Alex Giannakopoulos <
aeg...@blueyonder.co.uk> wrote:

> Thanks Ric
>
> I wasn't thinking of myself so much, I've got used to the J convention now,
> but more of what would make a good default startup for a newcomer.  I will
> look at the script though, always nice to see how others do it.
>
> As for the capped fork, yes I can live without it, just about, but I
> certainly couldn't when I stared out, especially - as I said - since this
> is the format returned by the 13 : verb.
>
> OK, here's another one:
> I have recently switched over to j701(gtk) from j602.
> On the whole, I like the new colour-coded approach to verb description, but
> sometimes, in complex cases, I really appreciated j602's boxing of the
> structure, which went a long way to make things clear.  (one of J's best
> debugging tools).  Is there a way to emulate this under 702gtk?
>
>
> On 1 December 2012 08:03, Ric Sherlock  wrote:
>
> > Hi Alex,
> > Not sure if you're aware of the trig script available as part of the
> > 'math/misc' addon, but it may contain at least some definitions you'd
> like
> > to use. If you have the addon installed then you can load the definitions
> > using:
> >require 'trig'
> >
> > If you restrict yourself to writing explicit J then it is perfectly
> > possible to get away without using capped fork.
> >
> > Ric
> >
> >
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Thanks Ric

I wasn't thinking of myself so much, I've got used to the J convention now,
but more of what would make a good default startup for a newcomer.  I will
look at the script though, always nice to see how others do it.

As for the capped fork, yes I can live without it, just about, but I
certainly couldn't when I stared out, especially - as I said - since this
is the format returned by the 13 : verb.

OK, here's another one:
I have recently switched over to j701(gtk) from j602.
On the whole, I like the new colour-coded approach to verb description, but
sometimes, in complex cases, I really appreciated j602's boxing of the
structure, which went a long way to make things clear.  (one of J's best
debugging tools).  Is there a way to emulate this under 702gtk?


On 1 December 2012 08:03, Ric Sherlock  wrote:

> Hi Alex,
> Not sure if you're aware of the trig script available as part of the
> 'math/misc' addon, but it may contain at least some definitions you'd like
> to use. If you have the addon installed then you can load the definitions
> using:
>require 'trig'
>
> If you restrict yourself to writing explicit J then it is perfectly
> possible to get away without using capped fork.
>
> Ric
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ric Sherlock]

Hi Alex,
Not sure if you're aware of the trig script available as part of the
'math/misc' addon, but it may contain at least some definitions you'd like
to use. If you have the addon installed then you can load the definitions
using:
   require 'trig'

If you restrict yourself to writing explicit J then it is perfectly
possible to get away without using capped fork.

Ric


On Sat, Dec 1, 2012 at 5:14 PM, Alex Giannakopoulos  wrote:

> On 30 November 2012 16:17, Bo Jacoby  wrote:
>
> > J is a rich language, and it might be a good idea to define an elementary
> > subset for beginners.
>
>
> Couldn't agree more.
> A simple startup configuration file.  Define verbs for trig functions so
> they don't look stupidly arbitrary.
> Some other elementary functions too, like polar2rect and rect2polar
> conversions that act on vectors (none of this xfy binary stuff here
> please), you know, stuff like you can find on *calculators*.
> Define dot-product, matrix-multiplication, cross-product, determinant, etc,
> as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
> NOT want to know about the . operator at the level of the jdict, it is a
> highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
> want to do matrix ops.  I was told this was a language for linear algebra.
> It would probably be a good idea, then, if we could do some linalg -
> straight out of the box - without serious brain damage.  I have had abuse
> hurled at me by math teachers who have seen J's linalg primitives (LOL).
> Add some nice libs for equation solving while we're at it.  Simultaneous
> and also some numeric solvers.  This is what people want.  A language, not
> an assembler for a language.
>
>
> > J is a nice calculator for elementary computations. You can do a lot of
> > computing without knowing anything about binomial coefficients and taylor
> > expansions and capped forks.
>
>
> Agree with the first two, NO way on the third.  Even the 13 verb gives you
> capped verbs, there is no way to begin learning J without it.  Also they
> solve the problem of having to figure if you should use At or Atop,
> invaluable for a beginner who hasn;t quite mastered rank yet.
>
> This problem, which once again gives rise to a long thread, could easily be
> solved by a highly visible Programming FAQ page, with lots of links to.
> Deal with capped forks, @ and @:  and why you can't have things like   +/ a
> b c   You know, the questions people *keep asking*.   Remove ancient
> irrelevant stuff like the use of x. and y.   We are not at J401 any more.
>
>
> > If you need to understand everything in order to be happy, then you may
> be
> > unhappy. I taught my son elementary APL when he was 10 years old, and he
> > loved it!
> >
>
> Would he have been just as happy at 14 when he had to use the cosine rule
> to solve a triangle?  Would he really prefer
> cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
> or
> cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
> to
> cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
> Just wondering...
>
> These are simple enough things to do, and I speak as a J newcomer.  There's
> not many languages you can say that about after two and a half years!  The
> Zen of J, grasshopper.
>
> Incidentally, is there a way to cap a monadic hook on the left?
> For example (=<.) was mentioned, but obviously it allows dyadic arguments,
> and fails if they are offered.
> Short of wrting monad : 'y=<.y'  is there a way I can keep it monadic (and
> implicit)?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[km]

(1) You could also have done

   isint =: [: (= >.) ]  NB. ignores left argument if given
   isint 2 0.5
1 0
   13 isint 2 0.5
1 0

(2) Check out the monad/dyad "core" lab.  The following is from the iPad 
version of J.

   Hlab  NB. Help for labs
labs are interactive tutorials
manage labs with the following sentences:
   jx '' NB. category list
   jx 'core' NB. labs in category core
   jx 0  NB. open lab 0
   jx -1 NB. close lab

↵ with empty textfield advances lab

   jx 'core'
  0 A J Introduction  
  1 A Taste of J (1)  
  2 A Taste of J (2)  
  3 An Idiosyncratic Introduction to J
  4 An Introductory Course in J   
  5 Function Display  
  6 Locales   
  7 Monad/Dyad
  8 Object Oriented Programming   
  9 Sparse Arrays 
   jx 7
-
Lab: Monad/Dyad
To advance the lab, press ↵

-- (1 of 4) INTRODUCTION 

If u and v are functions, then f=: u : v defines f to be a
function whose monadic case is u and whose dyadic case is v

For example, if v=: +, then 3 v 4 is 7 and v 4 is 4, i.e.
since the monadic case of + is the conjugate, which produces
an effect only on a complex argument such as 6j10.

We may, however, define a function add that performs addition
on two arguments, and increments a single argument. Thus:
)
   add=: >: : +
   
   3 add 4
7
   
   add 4
5
   
   add 4 5 6 7 8
5 6 7 8 9
   
   v=: +
   
   3 v 4
7
   
   v 4
4

(3) The use of Cap [: is explained in this four-step lab.


Kip Murray

Sent from my iPad


On Nov 30, 2012, at 10:41 PM, Alex Giannakopoulos  
wrote:

> Hm, yes, I hadn't realised both cases could be specified implicitly, that's
> really useful.
> Another one for the FAQ!
> 
> On 1 December 2012 04:37, Alex Giannakopoulos wrote:
> 
>> Great, thanks, hadn't seen that technique before!
>> 
>> 
>> On 1 December 2012 04:35, km  wrote:
>> 
>>> About your closing question, you can do
>>> 
>>>   isint =: (= <.) : [:
>>>   isint 2 0.5
>>> 1 0
>>>   2 isint 3
>>> |domain error: isint
>>> |   2 isint 3
>>> 
>>> 
>>> The definition of isint specifies [: as the dyadic case, and [; rejects
>>> every argument with a domain error.
>>> 
>>> Kip Murray
>>> 
>>> Sent from my iPad
>>> 
>>> 
>>> On Nov 30, 2012, at 10:14 PM, Alex Giannakopoulos <
>>> aeg...@blueyonder.co.uk> wrote:
>>> 
 On 30 November 2012 16:17, Bo Jacoby  wrote:
 
> J is a rich language, and it might be a good idea to define an
>>> elementary
> subset for beginners.
 
 
 Couldn't agree more.
 A simple startup configuration file.  Define verbs for trig functions so
 they don't look stupidly arbitrary.
 Some other elementary functions too, like polar2rect and rect2polar
 conversions that act on vectors (none of this xfy binary stuff here
 please), you know, stuff like you can find on *calculators*.
 Define dot-product, matrix-multiplication, cross-product, determinant,
>>> etc,
 as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
 NOT want to know about the . operator at the level of the jdict, it is a
 highly advanced subject, intriguing - yes, but not for newbies.  Yet I
>>> do
 want to do matrix ops.  I was told this was a language for linear
>>> algebra.
 It would probably be a good idea, then, if we could do some linalg -
 straight out of the box - without serious brain damage.  I have had
>>> abuse
 hurled at me by math teachers who have seen J's linalg primitives (LOL).
 Add some nice libs for equation solving while we're at it.  Simultaneous
 and also some numeric solvers.  This is what people want.  A language,
>>> not
 an assembler for a language.
 
 
> J is a nice calculator for elementary computations. You can do a lot of
> computing without knowing anything about binomial coefficients and
>>> taylor
> expansions and capped forks.
 
 
 Agree with the first two, NO way on the third.  Even the 13 verb gives
>>> you
 capped verbs, there is no way to begin learning J without it.  Also they
 solve the problem of having to figure if you should use At or Atop,
 invaluable for a beginner who hasn;t quite mastered rank yet.
 
 This problem, which once again gives rise to a long thread, could
>>> easily be
 solved by a highly visible Programming FAQ page, with lots of links to.
 Deal with capped forks, @ and @:  and why you can't have things like
>>> +/ a
 b c   You know, the questions people *keep asking*.   Remove ancient
 irrelevant stuff like the use of x. and y.   We are not at J401 any
>>> more.
 
 
> If you need to understand everything in order to be happy, then you
>>> may be
> unhappy. I taught my son elementary APL when he was 10 years old, and
>>> he
> loved it!
 
 W

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Hm, yes, I hadn't realised both cases could be specified implicitly, that's
really useful.
Another one for the FAQ!

On 1 December 2012 04:37, Alex Giannakopoulos wrote:

> Great, thanks, hadn't seen that technique before!
>
>
> On 1 December 2012 04:35, km  wrote:
>
>> About your closing question, you can do
>>
>>isint =: (= <.) : [:
>>isint 2 0.5
>> 1 0
>>2 isint 3
>> |domain error: isint
>> |   2 isint 3
>>
>>
>> The definition of isint specifies [: as the dyadic case, and [; rejects
>> every argument with a domain error.
>>
>> Kip Murray
>>
>> Sent from my iPad
>>
>>
>> On Nov 30, 2012, at 10:14 PM, Alex Giannakopoulos <
>> aeg...@blueyonder.co.uk> wrote:
>>
>> > On 30 November 2012 16:17, Bo Jacoby  wrote:
>> >
>> >> J is a rich language, and it might be a good idea to define an
>> elementary
>> >> subset for beginners.
>> >
>> >
>> > Couldn't agree more.
>> > A simple startup configuration file.  Define verbs for trig functions so
>> > they don't look stupidly arbitrary.
>> > Some other elementary functions too, like polar2rect and rect2polar
>> > conversions that act on vectors (none of this xfy binary stuff here
>> > please), you know, stuff like you can find on *calculators*.
>> > Define dot-product, matrix-multiplication, cross-product, determinant,
>> etc,
>> > as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
>> > NOT want to know about the . operator at the level of the jdict, it is a
>> > highly advanced subject, intriguing - yes, but not for newbies.  Yet I
>> do
>> > want to do matrix ops.  I was told this was a language for linear
>> algebra.
>> > It would probably be a good idea, then, if we could do some linalg -
>> > straight out of the box - without serious brain damage.  I have had
>> abuse
>> > hurled at me by math teachers who have seen J's linalg primitives (LOL).
>> > Add some nice libs for equation solving while we're at it.  Simultaneous
>> > and also some numeric solvers.  This is what people want.  A language,
>> not
>> > an assembler for a language.
>> >
>> >
>> >> J is a nice calculator for elementary computations. You can do a lot of
>> >> computing without knowing anything about binomial coefficients and
>> taylor
>> >> expansions and capped forks.
>> >
>> >
>> > Agree with the first two, NO way on the third.  Even the 13 verb gives
>> you
>> > capped verbs, there is no way to begin learning J without it.  Also they
>> > solve the problem of having to figure if you should use At or Atop,
>> > invaluable for a beginner who hasn;t quite mastered rank yet.
>> >
>> > This problem, which once again gives rise to a long thread, could
>> easily be
>> > solved by a highly visible Programming FAQ page, with lots of links to.
>> > Deal with capped forks, @ and @:  and why you can't have things like
>> +/ a
>> > b c   You know, the questions people *keep asking*.   Remove ancient
>> > irrelevant stuff like the use of x. and y.   We are not at J401 any
>> more.
>> >
>> >
>> >> If you need to understand everything in order to be happy, then you
>> may be
>> >> unhappy. I taught my son elementary APL when he was 10 years old, and
>> he
>> >> loved it!
>> >
>> > Would he have been just as happy at 14 when he had to use the cosine
>> rule
>> > to solve a triangle?  Would he really prefer
>> > cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
>> > or
>> > cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
>> > to
>> > cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
>> > Just wondering...
>> >
>> > These are simple enough things to do, and I speak as a J newcomer.
>>  There's
>> > not many languages you can say that about after two and a half years!
>>  The
>> > Zen of J, grasshopper.
>> >
>> > Incidentally, is there a way to cap a monadic hook on the left?
>> > For example (=<.) was mentioned, but obviously it allows dyadic
>> arguments,
>> > and fails if they are offered.
>> > Short of wrting monad : 'y=<.y'  is there a way I can keep it monadic
>> (and
>> > implicit)?
>> > --
>> > For information about J forums see http://www.jsoftware.com/forums.htm
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Great, thanks, hadn't seen that technique before!

On 1 December 2012 04:35, km  wrote:

> About your closing question, you can do
>
>isint =: (= <.) : [:
>isint 2 0.5
> 1 0
>2 isint 3
> |domain error: isint
> |   2 isint 3
>
>
> The definition of isint specifies [: as the dyadic case, and [; rejects
> every argument with a domain error.
>
> Kip Murray
>
> Sent from my iPad
>
>
> On Nov 30, 2012, at 10:14 PM, Alex Giannakopoulos 
> wrote:
>
> > On 30 November 2012 16:17, Bo Jacoby  wrote:
> >
> >> J is a rich language, and it might be a good idea to define an
> elementary
> >> subset for beginners.
> >
> >
> > Couldn't agree more.
> > A simple startup configuration file.  Define verbs for trig functions so
> > they don't look stupidly arbitrary.
> > Some other elementary functions too, like polar2rect and rect2polar
> > conversions that act on vectors (none of this xfy binary stuff here
> > please), you know, stuff like you can find on *calculators*.
> > Define dot-product, matrix-multiplication, cross-product, determinant,
> etc,
> > as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
> > NOT want to know about the . operator at the level of the jdict, it is a
> > highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
> > want to do matrix ops.  I was told this was a language for linear
> algebra.
> > It would probably be a good idea, then, if we could do some linalg -
> > straight out of the box - without serious brain damage.  I have had abuse
> > hurled at me by math teachers who have seen J's linalg primitives (LOL).
> > Add some nice libs for equation solving while we're at it.  Simultaneous
> > and also some numeric solvers.  This is what people want.  A language,
> not
> > an assembler for a language.
> >
> >
> >> J is a nice calculator for elementary computations. You can do a lot of
> >> computing without knowing anything about binomial coefficients and
> taylor
> >> expansions and capped forks.
> >
> >
> > Agree with the first two, NO way on the third.  Even the 13 verb gives
> you
> > capped verbs, there is no way to begin learning J without it.  Also they
> > solve the problem of having to figure if you should use At or Atop,
> > invaluable for a beginner who hasn;t quite mastered rank yet.
> >
> > This problem, which once again gives rise to a long thread, could easily
> be
> > solved by a highly visible Programming FAQ page, with lots of links to.
> > Deal with capped forks, @ and @:  and why you can't have things like
> +/ a
> > b c   You know, the questions people *keep asking*.   Remove ancient
> > irrelevant stuff like the use of x. and y.   We are not at J401 any more.
> >
> >
> >> If you need to understand everything in order to be happy, then you may
> be
> >> unhappy. I taught my son elementary APL when he was 10 years old, and he
> >> loved it!
> >
> > Would he have been just as happy at 14 when he had to use the cosine rule
> > to solve a triangle?  Would he really prefer
> > cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
> > or
> > cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
> > to
> > cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
> > Just wondering...
> >
> > These are simple enough things to do, and I speak as a J newcomer.
>  There's
> > not many languages you can say that about after two and a half years!
>  The
> > Zen of J, grasshopper.
> >
> > Incidentally, is there a way to cap a monadic hook on the left?
> > For example (=<.) was mentioned, but obviously it allows dyadic
> arguments,
> > and fails if they are offered.
> > Short of wrting monad : 'y=<.y'  is there a way I can keep it monadic
> (and
> > implicit)?
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[km]

About your closing question, you can do

   isint =: (= <.) : [:
   isint 2 0.5
1 0
   2 isint 3
|domain error: isint
|   2 isint 3


The definition of isint specifies [: as the dyadic case, and [; rejects every 
argument with a domain error.

Kip Murray

Sent from my iPad


On Nov 30, 2012, at 10:14 PM, Alex Giannakopoulos  
wrote:

> On 30 November 2012 16:17, Bo Jacoby  wrote:
> 
>> J is a rich language, and it might be a good idea to define an elementary
>> subset for beginners.
> 
> 
> Couldn't agree more.
> A simple startup configuration file.  Define verbs for trig functions so
> they don't look stupidly arbitrary.
> Some other elementary functions too, like polar2rect and rect2polar
> conversions that act on vectors (none of this xfy binary stuff here
> please), you know, stuff like you can find on *calculators*.
> Define dot-product, matrix-multiplication, cross-product, determinant, etc,
> as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
> NOT want to know about the . operator at the level of the jdict, it is a
> highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
> want to do matrix ops.  I was told this was a language for linear algebra.
> It would probably be a good idea, then, if we could do some linalg -
> straight out of the box - without serious brain damage.  I have had abuse
> hurled at me by math teachers who have seen J's linalg primitives (LOL).
> Add some nice libs for equation solving while we're at it.  Simultaneous
> and also some numeric solvers.  This is what people want.  A language, not
> an assembler for a language.
> 
> 
>> J is a nice calculator for elementary computations. You can do a lot of
>> computing without knowing anything about binomial coefficients and taylor
>> expansions and capped forks.
> 
> 
> Agree with the first two, NO way on the third.  Even the 13 verb gives you
> capped verbs, there is no way to begin learning J without it.  Also they
> solve the problem of having to figure if you should use At or Atop,
> invaluable for a beginner who hasn;t quite mastered rank yet.
> 
> This problem, which once again gives rise to a long thread, could easily be
> solved by a highly visible Programming FAQ page, with lots of links to.
> Deal with capped forks, @ and @:  and why you can't have things like   +/ a
> b c   You know, the questions people *keep asking*.   Remove ancient
> irrelevant stuff like the use of x. and y.   We are not at J401 any more.
> 
> 
>> If you need to understand everything in order to be happy, then you may be
>> unhappy. I taught my son elementary APL when he was 10 years old, and he
>> loved it!
> 
> Would he have been just as happy at 14 when he had to use the cosine rule
> to solve a triangle?  Would he really prefer
> cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
> or
> cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
> to
> cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
> Just wondering...
> 
> These are simple enough things to do, and I speak as a J newcomer.  There's
> not many languages you can say that about after two and a half years!  The
> Zen of J, grasshopper.
> 
> Incidentally, is there a way to cap a monadic hook on the left?
> For example (=<.) was mentioned, but obviously it allows dyadic arguments,
> and fails if they are offered.
> Short of wrting monad : 'y=<.y'  is there a way I can keep it monadic (and
> implicit)?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

Incidentally, does Jsoftware have an individual responsible for
presentation, marketing, outreach, holy-rolling etc?

If, say, I wanted to contribute something, who would coordinate?  Or does
it all just get (somehow) vetted through the community here?
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

On 30 November 2012 16:17, Bo Jacoby  wrote:

> J is a rich language, and it might be a good idea to define an elementary
> subset for beginners.


Couldn't agree more.
A simple startup configuration file.  Define verbs for trig functions so
they don't look stupidly arbitrary.
Some other elementary functions too, like polar2rect and rect2polar
conversions that act on vectors (none of this xfy binary stuff here
please), you know, stuff like you can find on *calculators*.
Define dot-product, matrix-multiplication, cross-product, determinant, etc,
as user-friendly built-in verbs.  When I am a beginner, I DO NOT, repeat
NOT want to know about the . operator at the level of the jdict, it is a
highly advanced subject, intriguing - yes, but not for newbies.  Yet I do
want to do matrix ops.  I was told this was a language for linear algebra.
It would probably be a good idea, then, if we could do some linalg -
straight out of the box - without serious brain damage.  I have had abuse
hurled at me by math teachers who have seen J's linalg primitives (LOL).
Add some nice libs for equation solving while we're at it.  Simultaneous
and also some numeric solvers.  This is what people want.  A language, not
an assembler for a language.


> J is a nice calculator for elementary computations. You can do a lot of
> computing without knowing anything about binomial coefficients and taylor
> expansions and capped forks.


Agree with the first two, NO way on the third.  Even the 13 verb gives you
capped verbs, there is no way to begin learning J without it.  Also they
solve the problem of having to figure if you should use At or Atop,
invaluable for a beginner who hasn;t quite mastered rank yet.

This problem, which once again gives rise to a long thread, could easily be
solved by a highly visible Programming FAQ page, with lots of links to.
Deal with capped forks, @ and @:  and why you can't have things like   +/ a
b c   You know, the questions people *keep asking*.   Remove ancient
irrelevant stuff like the use of x. and y.   We are not at J401 any more.


> If you need to understand everything in order to be happy, then you may be
> unhappy. I taught my son elementary APL when he was 10 years old, and he
> loved it!
>

Would he have been just as happy at 14 when he had to use the cosine rule
to solve a triangle?  Would he really prefer
cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
or
cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
to
cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
Just wondering...

These are simple enough things to do, and I speak as a J newcomer.  There's
not many languages you can say that about after two and a half years!  The
Zen of J, grasshopper.

Incidentally, is there a way to cap a monadic hook on the left?
For example (=<.) was mentioned, but obviously it allows dyadic arguments,
and fails if they are offered.
Short of wrting monad : 'y=<.y'  is there a way I can keep it monadic (and
implicit)?
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ian Clark]

> In other words, I got to J the same way Arthur Rubinstein directed the 
> tourist to Carnegie Hall.

I didn't know this, and had to google it. Here it is, for any other
ignoramus on this list ...

http://quotationsbook.com/quote/31803/
Apparently, he was approached in the street near the Carnegie Hall in
NY by a man who asked, "Pardon me sir, how do I get to Carnegie
Hall?“; to which he replied, "Practice, practice, practice!”.

On Thu, Nov 29, 2012 at 10:15 PM, Dan Bron  wrote:
> I can't disagree with your contention about how people (try to) approach J or 
> other programming languages.
>
> For my part, when I started J, I found the DoJ impenetrable and eschewed it 
> for the first year or two of my career.  I learned J through the collective 
> wisdom and generosity of these Forums, combined with innumerable 
> conversations (ok: arguments) with the interpreter.  Once I already knew J, 
> the DoJ became valuable (in fact, invaluable).
>
> In other words, I got to J the same way Arthur Rubinstein directed the 
> tourist to Carnegie Hall. And, as far as I know, there is no other way to get 
> there.
>
> -Dan
>
> PS:  I'm not trying to be glib.  Like any project, our documentation can 
> always be improved and never be "finished".  And over the years many 
> intelligent, generous people have expanded and contributed to it in many 
> different voices, media, styles, and methods.  And I'm sure that will 
> continue.
>
> But I'm equally sure there is no silver bullet (which is the flip side of 
> "our documentation can never be finished").  Ultimately, it comes down to the 
> individual aspirant.
>
>
> -Original Message-
> From: programming-boun...@forums.jsoftware.com 
> [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Ian Clark
> Sent: Thursday, November 29, 2012 3:16 PM
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] @: and capped fork
>
>> What provoked your doubt?
>
> In learning J, I've stumbled from one false assumption to another.
> Mainly about verb composition. Were I to be the only person to experience 
> this, it could be put down to a weak intellect. But if my experience is not 
> uncommon, it points to a need for J documentation to be better.
>
> Just today, whilst testing an explication utility I have on the chocks, I 
> thought I'd stumbled on yet another unwarranted assumption I'd been making in 
> the code. It was one I could not easily check from the standard reference 
> material. To be sure I needed to ask on the forum.
>
> The problem with J documentation as it's structured, is that to compose 2 
> verbs you naturally think of a conjunction -- and J has a wealth of those. 
> Far more than APL. If you want to choose a suitable conjunction you can read 
> its description in Voc. But hooks and forks, especially Capped Fork, compose 
> verbs too, yet they're not documented in a comparable way. You have to be 
> au-fait with the Dic chapter on Trains, or Chapter 40 of JforC.
>
> It's my contention that experienced programmers learn a new language by 
> reading the reference manual as they go along, one feature at a time. They 
> don't digest an armful of primers or textbooks up-front, no matter how 
> exciting and readable. Learning J, that approach just happens to induce a 
> blind spot over Capped Fork -- and verb-trains in general.
>
> Ian
>
> On Thu, Nov 29, 2012 at 5:44 PM, Dan Bron  wrote:
>> Right.  For this reason (or similar ones, like when g is a train), I
>> phrase the identity as  ([: f g) ↔ f@:(g)  .
>>
>> As to where this is stated: well, it's recorded informally in
>> innumerable documents and J learning materials.  If you're looking for
>> formal guarantees in canonical material (the DoJ), you'll have to
>> arrive at the equivalence through a chain of logic.
>>
>> First, we have the the definition of capped fork in §II.F, following
>> the definition of non-capped fork [1]:
>>
>> (A) "If f is a cap ([:)  the capped branch simplifies the forks to
>> i.   g   h y and
>> ii.  g x h y"
>> (B) "The ranks of the hook and fork are infinite."
>>
>> Then, we have the definition of @: in the vocabulary [2]:
>>
>> (C) "@: is equivalent to @ except that ranks are infinite."
>>
>> Which refers back to the definition of @, which is given in the
>> Vocabulary as [3]:
>>
>> (D) "  u@v y ↔ u v y"
>> (E) "x u@v y ↔ u x v y .
>>
>> So, after adjusting for the different names given to the v

Re: [Jprogramming] @: and capped fork

[Ian Clark]

> I taught my son elementary APL when he was 10 years old, and he loved it!

I remember APL rapidly catching on with IBM salesmen in the 1970s. At
Long Last, they were free of the programming dept (and the extended
wait for their services). No IBM salesman I ever met had the slightest
difficulty learning APL (provided it was their first programming
language, i.e. nearly all of them).

Some salesmen created very nifty support systems for themselves. A
company founded by an ex-IBMer (sales planner actually, not salesman)
on just such a hacked-out APL app was sold in 2003 for $10 million.
(I'm talking about FREGI--> KPS --> Adaytum Planning) -- IBM have
since bought it back :-D

By the same token, IBM salesmen were damn' careful not to sell APL to
customers. For fear of "losing control of the account"!!

Reminds me of the old old story about Ronson Lighters and the
Everlasting Matchstick.


On Fri, Nov 30, 2012 at 4:17 PM, Bo Jacoby  wrote:
> J is a rich language, and it might be a good idea to define an elementary 
> subset for beginners. J is a nice calculator for elementary computations. You 
> can do a lot of computing without knowing anything about binomial 
> coefficients and taylor expansions and capped forks. If you need to 
> understand everything in order to be happy, then you may be unhappy. I taught 
> my son elementary APL when he was 10 years old, and he loved it!
>
> - Bo
>
>
>
>
>>
>> Fra: Ian Clark 
>>Til: programm...@jsoftware.com
>>Sendt: 16:06 fredag den 30. november 2012
>>Emne: Re: [Jprogramming] @: and capped fork
>>
>>I too have felt the need for Really Prominent Pages (RPPs?) and I've
>>regretfully come to conclude that the only workable solution for the
>>beginner is the forum, as Dan hints. Hence certain issues will turn up
>>over and over again in the threads.
>>
>>Experienced programmers, trying to pick-up J from the reference manual
>>as they go along, are especially vulnerable. What "experience" can
>>prepare you for J?
>>
>>Trains are indeed a pratfall, and I think it boils down to this. When you see
>>   f g h noun   NB. (1)
>>even if you've read and re-read all the stuff about J's bracketing
>>rules, you're still tempted to think you can write:
>>   v=: f g h NB. (2)
>>   v noun
>>...and it gives a different result. So you begin to suspect J is only
>>for people addicted to brain-teasers. It doesn't help to be told that
>>(2) is a "train" and (1) isn't. (sic)
>>
>>But I didn't start this thread just to gripe (yet again) about the
>>opaqueness of J and its documentation. Researching computer
>>(un)usability and how to fix it has been my career, and I was drawn
>>into J in the first place by these very considerations. It has proved
>>a rich hunting-ground, even more so than APL, which hitherto had been
>>the best I'd encountered. Industrial experience has taught me you need
>>to spend millions to write good documentation -- unless you want to
>>stick to telling people things they know perfectly well already, which
>>J emphatically doesn't.
>>
>>Oh, don't get the idea I only value J the way a doctor values a sick
>>patient. Having climbed the learning curve, it's my language of
>>choice, and I don't regret it. Why, I'd even pay good money for it.
>>(And if you're an APL user you say that with a gulp!)
>>
>>On Fri, Nov 30, 2012 at 2:50 AM, Alex Giannakopoulos
>> wrote:
>>> I agree that all this needs more and *clear* and *visible* explanation!
>>> It was the first question I asked, and in the two+ years (on-and-off) that
>>> I have been mucking around with J I have seen asked on this forum umpteen
>>> times.
>>> I have also seen it debated at length (and breadth and depth).  By
>>> experienced users, experts and newbies alike.  Unfortunately these
>>> discussions get buried in the (not easily searchable) list archives and the
>>> question keeps popping up, kind of like Nosferatu.
>>>
>>> Maybe we need a REALLY prominent page explaining it once and for all.
>>> I must add that for someone coming from another language, the idea of
>>> trains is massively alien (and a pain until you see their utility).
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>--
>>For information about J forums see http://www.jsoftware.com/forums.htm
>>
>>
>>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Don Guinn]

>
>
>
>Floor (and Ceiling (<.)) can be useful for forcing
>floating point representations of integers to be
>integers in order to save memory (8 vs 4 bytes per value).
>
> Only for J32.
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ian Clark]

Oops, a better link: http://jsoftware.com/help/phrases/hooks.htm

On Fri, Nov 30, 2012 at 11:48 PM, Ian Clark  wrote:
>> If someone asked me to encapsulate "whether values are integers or not", I
>> would use
>>
>>   (= <.) 3 3.14 5
>
> See 1st entry in:
> file:///Applications/j602/help/phrases/hooks.htm
>
> IanClark
>
> On Fri, Nov 30, 2012 at 11:36 PM, Peter B. Kessler
>  wrote:
>> And having read that statement about parentheses, you then come to the
>> bottom of http://www.jsoftware.com/help/jforc/common_mistakes.htm where it
>> says
>>
>>As a stopgap, you can imagine that each name's value is enclosed in
>> parentheses
>>before it is substituted.  This still isn't exactly right but it gets you
>> the
>>right result in all situations you are likely to encounter.
>>
>> which, when things don't work the way I think they should, makes me wonder
>> if I've found one of the "unlikely" situations.
>>
>> That said, I'm slowly getting better at reading J (or more consistent about
>> using things like (5!:2)
>>
>> ... peter
>>
>> P.S. If you are reviving http://www.jsoftware.com/jwiki/ControlNuVoc, then
>> someone should fix http://www.jsoftware.com/jwiki/Vocabulary/ltdot, which
>> under "Common uses" says
>>
>>Floor (and Ceiling (<.)) can also be useful for testing
>>whether values are integers or not.
>>
>> and
>>
>>Floor (and Ceiling (<.)) can be useful for forcing
>>floating point representations of integers to be
>>integers in order to save memory (8 vs 4 bytes per value).
>>
>> where the glyph for Ceiling should be  >.  in both sentences.  (That just
>> happened to be the first page I looked at, and I think I only noticed the
>> problem because I was staring at the glyph for Floor.)  Those look like
>> copy-n-pasto's from the Ceiling page.
>>
>> If someone asked me to encapsulate "whether values are integers or not", I
>> would use
>>
>>   (= <.) 3 3.14 5
>>1 0 1
>>
>> but maybe you don't want to get into hooks this soon.  (Or the equivalent
>> fork  (] = <.)  .)
>>
>>
>> David Ward Lambert wrote:
>>>
>>> The DoJ is perhaps the best technical writing I've seen,
>>> even having admitted that it was 2 years before I understood how to
>>> decipher headings conjunction and adverb headings such as
>>> Atopu@v  mv lv rv
>>> Let's continue the NuVoc project.
>>> http://www.jsoftware.com/jwiki/ControlNuVoc
>>> Maybe we'll decide to emphasize what as I recall was but a mere sentence
>>> in the DoJ "when proverbs are substituted into a sentence it is as if
>>> they were parenthesized."  WITH POTENTIALLY DRAMATIC CONSEQUENCE
>>>
>>>> Date: Fri, 30 Nov 2012 15:06:29 +
>>>> From: Ian Clark 
>>>> To: programm...@jsoftware.com
>>>> Subject: Re: [Jprogramming] @: and capped fork
>>>> Message-ID:
>>>> >>> +0...@mail.gmail.com>
>>>> Content-Type: text/plain; charset=UTF-8
>>>>
>>>> I too have felt the need for Really Prominent Pages (RPPs?) and I've
>>>> regretfully come to conclude that the only workable solution for the
>>>> beginner is the forum, as Dan hints. Hence certain issues will turn up
>>>> over and over again in the threads.
>>>
>>>
>>>
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ian Clark]

> If someone asked me to encapsulate "whether values are integers or not", I
> would use
>
>   (= <.) 3 3.14 5

See 1st entry in:
file:///Applications/j602/help/phrases/hooks.htm

IanClark

On Fri, Nov 30, 2012 at 11:36 PM, Peter B. Kessler
 wrote:
> And having read that statement about parentheses, you then come to the
> bottom of http://www.jsoftware.com/help/jforc/common_mistakes.htm where it
> says
>
>As a stopgap, you can imagine that each name's value is enclosed in
> parentheses
>before it is substituted.  This still isn't exactly right but it gets you
> the
>right result in all situations you are likely to encounter.
>
> which, when things don't work the way I think they should, makes me wonder
> if I've found one of the "unlikely" situations.
>
> That said, I'm slowly getting better at reading J (or more consistent about
> using things like (5!:2)
>
> ... peter
>
> P.S. If you are reviving http://www.jsoftware.com/jwiki/ControlNuVoc, then
> someone should fix http://www.jsoftware.com/jwiki/Vocabulary/ltdot, which
> under "Common uses" says
>
>Floor (and Ceiling (<.)) can also be useful for testing
>whether values are integers or not.
>
> and
>
>Floor (and Ceiling (<.)) can be useful for forcing
>floating point representations of integers to be
>integers in order to save memory (8 vs 4 bytes per value).
>
> where the glyph for Ceiling should be  >.  in both sentences.  (That just
> happened to be the first page I looked at, and I think I only noticed the
> problem because I was staring at the glyph for Floor.)  Those look like
> copy-n-pasto's from the Ceiling page.
>
> If someone asked me to encapsulate "whether values are integers or not", I
> would use
>
>   (= <.) 3 3.14 5
>1 0 1
>
> but maybe you don't want to get into hooks this soon.  (Or the equivalent
> fork  (] = <.)  .)
>
>
> David Ward Lambert wrote:
>>
>> The DoJ is perhaps the best technical writing I've seen,
>> even having admitted that it was 2 years before I understood how to
>> decipher headings conjunction and adverb headings such as
>> Atopu@v  mv lv rv
>> Let's continue the NuVoc project.
>> http://www.jsoftware.com/jwiki/ControlNuVoc
>> Maybe we'll decide to emphasize what as I recall was but a mere sentence
>> in the DoJ "when proverbs are substituted into a sentence it is as if
>> they were parenthesized."  WITH POTENTIALLY DRAMATIC CONSEQUENCE
>>
>>> Date: Fri, 30 Nov 2012 15:06:29 +
>>> From: Ian Clark 
>>> To: programm...@jsoftware.com
>>> Subject: Re: [Jprogramming] @: and capped fork
>>> Message-ID:
>>> >> +0...@mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> I too have felt the need for Really Prominent Pages (RPPs?) and I've
>>> regretfully come to conclude that the only workable solution for the
>>> beginner is the forum, as Dan hints. Hence certain issues will turn up
>>> over and over again in the threads.
>>
>>
>>
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Peter B. Kessler]

And having read that statement about parentheses, you then come to the bottom 
of http://www.jsoftware.com/help/jforc/common_mistakes.htm where it says

   As a stopgap, you can imagine that each name's value is enclosed in 
parentheses
   before it is substituted.  This still isn't exactly right but it gets you the
   right result in all situations you are likely to encounter.

which, when things don't work the way I think they should, makes me wonder if I've found 
one of the "unlikely" situations.

That said, I'm slowly getting better at reading J (or more consistent about 
using things like (5!:2)

... peter

P.S. If you are reviving http://www.jsoftware.com/jwiki/ControlNuVoc, then someone should 
fix http://www.jsoftware.com/jwiki/Vocabulary/ltdot, which under "Common uses" 
says

   Floor (and Ceiling (<.)) can also be useful for testing
   whether values are integers or not.

and

   Floor (and Ceiling (<.)) can be useful for forcing
   floating point representations of integers to be
   integers in order to save memory (8 vs 4 bytes per value).

where the glyph for Ceiling should be  >.  in both sentences.  (That just 
happened to be the first page I looked at, and I think I only noticed the problem 
because I was staring at the glyph for Floor.)  Those look like copy-n-pasto's 
from the Ceiling page.

If someone asked me to encapsulate "whether values are integers or not", I 
would use

  (= <.) 3 3.14 5
   1 0 1

but maybe you don't want to get into hooks this soon.  (Or the equivalent fork  (] 
= <.)  .)

David Ward Lambert wrote:

The DoJ is perhaps the best technical writing I've seen,
even having admitted that it was 2 years before I understood how to
decipher headings conjunction and adverb headings such as
Atopu@v  mv lv rv
Let's continue the NuVoc project.
http://www.jsoftware.com/jwiki/ControlNuVoc
Maybe we'll decide to emphasize what as I recall was but a mere sentence
in the DoJ "when proverbs are substituted into a sentence it is as if
they were parenthesized."  WITH POTENTIALLY DRAMATIC CONSEQUENCE!!!!


Date: Fri, 30 Nov 2012 15:06:29 +
From: Ian Clark 
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork
Message-ID:

Content-Type: text/plain; charset=UTF-8

I too have felt the need for Really Prominent Pages (RPPs?) and I've
regretfully come to conclude that the only workable solution for the
beginner is the forum, as Dan hints. Hence certain issues will turn up
over and over again in the threads.



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

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

Re: [Jprogramming] @: and capped fork

[Ian Clark]

...resending: (Google rejected because of my tinyurl link...)


km says:

> Who are your "beginners"?

That is indeed the Question To Ask.

The whole area was comprehensively researched back in the late 70s by
Morton, Hammond, Barnard, Long (et al), at the Medical Research
Council Applied Psychology Unit, Cambridge, England. They came up with
something known as the BIM (Morton Block Interaction Model), expressed
as a simple but immensely powerful diagram of how users approach a new
computer system. Let me stress this was not some sophomore's
starry-eyed woolly thinking, but the distillation of years of
hard-nosed research by world-class experimental psychologists. IBM
gave it over 9 years of funding from 1975 onwards. The results seeped
out into various areas, including the design of new "task oriented"
computer documentation (though much credit must also go to Alphonse
Chapanis & his students at Johns Hopkins, who liaised closely with
this research).

Quickly Googling: Morton block interaction model
...the only good refs I can find on the web are for pay-for papers.
A free source showing the BIM diagram is here: [tinyurl] bp36fhg
 (see: slides 22 and 23 of this PowerPoint presentation)

Applying it to J and its documentation, you can explain (and even
predict) why students brought up on the Texas Instruments calculator
have difficulty with J, and where.
Ditto why the very word "trains" will invite misunderstanding over the
behaviour of:
   (u v w) noun
 as opposed to:
   u v w noun
You can also predict why a fresh young mind will grasp J with a lot
less trouble than an experienced programmer in whatever language, even
APL. For a junior, the boxes in the BIM are mostly empty, so they
can't interfere with each other. Brief exposure to BASIC at school
will rapidly fill the boxes and ruin the said junior for a quick
uptake.

IMHO...

Hitherto we've all just been dabbling here. A proper analysis of J and
its documentation using the BIM would pay serious dividends. If I were
a silicon valley venture capitalist, I'd demand such a study as part
of a funding program for J. It would hilite the problem areas of
"beginners" using J (especially "experienced" beginners) and inform
the writing of documentation to remedy the problems uncovered.

The pay-off? You could propel J centre-stage for statistics and data
mining worldwide, and knock Mathematica and Python (beloved of Google)
into a cocked hat. The effort? It's the sort of thing you could give a
computer science or human-factors MSc student for his/her
dissertation.

Volunteers?

IanClark


On Fri, Nov 30, 2012 at 6:25 PM, km  wrote:
> Who are your "beginners"?  Beginning calculus students are thrown by right to 
> left evaluation because they are used to Texas Instruments calculators' 
> Algebraic Logic System.  For them J is not a nice calculator.  I gave them 
> rules for how to do arithmetic calculations with J, and showed them only 
> explicit programming.  These were university students.  Roger has reported 
> pleasant experiences with young students, and I notice your son was 10!
>
> Kip Murray
>
> Sent from my iPad
>
>
> On Nov 30, 2012, at 10:17 AM, Bo Jacoby  wrote:
>
>> J is a rich language, and it might be a good idea to define an elementary 
>> subset for beginners. J is a nice calculator for elementary computations. 
>> You can do a lot of computing without knowing anything about binomial 
>> coefficients and taylor expansions and capped forks. If you need to 
>> understand everything in order to be happy, then you may be unhappy. I 
>> taught my son elementary APL when he was 10 years old, and he loved it!
>>
>> - Bo
>>
>>
>>
>>
>>> 
>>> Fra: Ian Clark 
>>> Til: programm...@jsoftware.com
>>> Sendt: 16:06 fredag den 30. november 2012
>>> Emne: Re: [Jprogramming] @: and capped fork
>>>
>>> I too have felt the need for Really Prominent Pages (RPPs?) and I've
>>> regretfully come to conclude that the only workable solution for the
>>> beginner is the forum, as Dan hints. Hence certain issues will turn up
>>> over and over again in the threads.
>>>
>>> Experienced programmers, trying to pick-up J from the reference manual
>>> as they go along, are especially vulnerable. What "experience" can
>>> prepare you for J?
>>>
>>> Trains are indeed a pratfall, and I think it boils down to this. When you 
>>> see
>>>f g h noun   NB. (1)
>>> even if you've read and re-read all the stuff about J's bracketing
>>> rules, you're still tempted to think you can write:
>>>v=: f g h NB. (2)
>>

Re: [Jprogramming] @: and capped fork

[Raul Miller]

Ironically, a good way to improve J documentation would be to write
some (perhaps in blog posts?) and then go through a revision process
with an audience on that.

That said, the best J documentation seems to be "off hand" --
tutorials that focus on some application and cover just enough of J
for it to be useful for that purpose.  Having something concrete to
focus on is incredibly illuminating, and since J borrows deeply from
the traditions of mathematics its concepts often need just a little
explanation when in a context where the student has some idea of the
concrete subject being discussed.

At least, that's my opinion,

-- 
Raul

On Thu, Nov 29, 2012 at 9:50 PM, Alex Giannakopoulos
 wrote:
> I agree that all this needs more and *clear* and *visible* explanation!
> It was the first question I asked, and in the two+ years (on-and-off) that
> I have been mucking around with J I have seen asked on this forum umpteen
> times.
> I have also seen it debated at length (and breadth and depth).  By
> experienced users, experts and newbies alike.  Unfortunately these
> discussions get buried in the (not easily searchable) list archives and the
> question keeps popping up, kind of like Nosferatu.
>
> Maybe we need a REALLY prominent page explaining it once and for all.
> I must add that for someone coming from another language, the idea of
> trains is massively alien (and a pain until you see their utility).
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Devon McCormick]

People with prior exposure to traditional programming languages also seem
to have trouble with array-based approaches as well though it's a more
natural way to think about many kind of problems.


On Fri, Nov 30, 2012 at 1:25 PM, km  wrote:

> Who are your "beginners"?  Beginning calculus students are thrown by right
> to left evaluation because they are used to Texas Instruments calculators'
> Algebraic Logic System.  For them J is not a nice calculator.  I gave them
> rules for how to do arithmetic calculations with J, and showed them only
> explicit programming.  These were university students.  Roger has reported
> pleasant experiences with young students, and I notice your son was 10!
>
> Kip Murray
>
> Sent from my iPad
>
>
> On Nov 30, 2012, at 10:17 AM, Bo Jacoby  wrote:
>
> > J is a rich language, and it might be a good idea to define an
> elementary subset for beginners. J is a nice calculator for elementary
> computations. You can do a lot of computing without knowing anything about
> binomial coefficients and taylor expansions and capped forks. If you need
> to understand everything in order to be happy, then you may be unhappy. I
> taught my son elementary APL when he was 10 years old, and he loved it!
> >
> > - Bo
> >
> >
> >
> >
> >> ________
> >> Fra: Ian Clark 
> >> Til: programm...@jsoftware.com
> >> Sendt: 16:06 fredag den 30. november 2012
> >> Emne: Re: [Jprogramming] @: and capped fork
> >>
> >> I too have felt the need for Really Prominent Pages (RPPs?) and I've
> >> regretfully come to conclude that the only workable solution for the
> >> beginner is the forum, as Dan hints. Hence certain issues will turn up
> >> over and over again in the threads.
> >>
> >> Experienced programmers, trying to pick-up J from the reference manual
> >> as they go along, are especially vulnerable. What "experience" can
> >> prepare you for J?
> >>
> >> Trains are indeed a pratfall, and I think it boils down to this. When
> you see
> >>f g h noun   NB. (1)
> >> even if you've read and re-read all the stuff about J's bracketing
> >> rules, you're still tempted to think you can write:
> >>v=: f g h NB. (2)
> >>v noun
> >> ...and it gives a different result. So you begin to suspect J is only
> >> for people addicted to brain-teasers. It doesn't help to be told that
> >> (2) is a "train" and (1) isn't. (sic)
> >>
> >> But I didn't start this thread just to gripe (yet again) about the
> >> opaqueness of J and its documentation. Researching computer
> >> (un)usability and how to fix it has been my career, and I was drawn
> >> into J in the first place by these very considerations. It has proved
> >> a rich hunting-ground, even more so than APL, which hitherto had been
> >> the best I'd encountered. Industrial experience has taught me you need
> >> to spend millions to write good documentation -- unless you want to
> >> stick to telling people things they know perfectly well already, which
> >> J emphatically doesn't.
> >>
> >> Oh, don't get the idea I only value J the way a doctor values a sick
> >> patient. Having climbed the learning curve, it's my language of
> >> choice, and I don't regret it. Why, I'd even pay good money for it.
> >> (And if you're an APL user you say that with a gulp!)
> >>
> >> On Fri, Nov 30, 2012 at 2:50 AM, Alex Giannakopoulos
> >>  wrote:
> >>> I agree that all this needs more and *clear* and *visible* explanation!
> >>> It was the first question I asked, and in the two+ years (on-and-off)
> that
> >>> I have been mucking around with J I have seen asked on this forum
> umpteen
> >>> times.
> >>> I have also seen it debated at length (and breadth and depth).  By
> >>> experienced users, experts and newbies alike.  Unfortunately these
> >>> discussions get buried in the (not easily searchable) list archives
> and the
> >>> question keeps popping up, kind of like Nosferatu.
> >>>
> >>> Maybe we need a REALLY prominent page explaining it once and for all.
> >>> I must add that for someone coming from another language, the idea of
> >>> trains is massively alien (and a pain until you see their utility).
> >>> --
> >>> For information about J forums see http://www.jsoftware.com/forums.htm
> >> --
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>



-- 
Devon McCormick, CFA
^me^ at acm.
org is my
preferred e-mail
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[km]

Who are your "beginners"?  Beginning calculus students are thrown by right to 
left evaluation because they are used to Texas Instruments calculators' 
Algebraic Logic System.  For them J is not a nice calculator.  I gave them 
rules for how to do arithmetic calculations with J, and showed them only 
explicit programming.  These were university students.  Roger has reported 
pleasant experiences with young students, and I notice your son was 10!

Kip Murray

Sent from my iPad


On Nov 30, 2012, at 10:17 AM, Bo Jacoby  wrote:

> J is a rich language, and it might be a good idea to define an elementary 
> subset for beginners. J is a nice calculator for elementary computations. You 
> can do a lot of computing without knowing anything about binomial 
> coefficients and taylor expansions and capped forks. If you need to 
> understand everything in order to be happy, then you may be unhappy. I taught 
> my son elementary APL when he was 10 years old, and he loved it! 
> 
> - Bo
> 
> 
> 
> 
>> 
>> Fra: Ian Clark 
>> Til: programm...@jsoftware.com 
>> Sendt: 16:06 fredag den 30. november 2012
>> Emne: Re: [Jprogramming] @: and capped fork
>> 
>> I too have felt the need for Really Prominent Pages (RPPs?) and I've
>> regretfully come to conclude that the only workable solution for the
>> beginner is the forum, as Dan hints. Hence certain issues will turn up
>> over and over again in the threads.
>> 
>> Experienced programmers, trying to pick-up J from the reference manual
>> as they go along, are especially vulnerable. What "experience" can
>> prepare you for J?
>> 
>> Trains are indeed a pratfall, and I think it boils down to this. When you see
>>f g h noun   NB. (1)
>> even if you've read and re-read all the stuff about J's bracketing
>> rules, you're still tempted to think you can write:
>>v=: f g h NB. (2)
>>v noun
>> ...and it gives a different result. So you begin to suspect J is only
>> for people addicted to brain-teasers. It doesn't help to be told that
>> (2) is a "train" and (1) isn't. (sic)
>> 
>> But I didn't start this thread just to gripe (yet again) about the
>> opaqueness of J and its documentation. Researching computer
>> (un)usability and how to fix it has been my career, and I was drawn
>> into J in the first place by these very considerations. It has proved
>> a rich hunting-ground, even more so than APL, which hitherto had been
>> the best I'd encountered. Industrial experience has taught me you need
>> to spend millions to write good documentation -- unless you want to
>> stick to telling people things they know perfectly well already, which
>> J emphatically doesn't.
>> 
>> Oh, don't get the idea I only value J the way a doctor values a sick
>> patient. Having climbed the learning curve, it's my language of
>> choice, and I don't regret it. Why, I'd even pay good money for it.
>> (And if you're an APL user you say that with a gulp!)
>> 
>> On Fri, Nov 30, 2012 at 2:50 AM, Alex Giannakopoulos
>>  wrote:
>>> I agree that all this needs more and *clear* and *visible* explanation!
>>> It was the first question I asked, and in the two+ years (on-and-off) that
>>> I have been mucking around with J I have seen asked on this forum umpteen
>>> times.
>>> I have also seen it debated at length (and breadth and depth).  By
>>> experienced users, experts and newbies alike.  Unfortunately these
>>> discussions get buried in the (not easily searchable) list archives and the
>>> question keeps popping up, kind of like Nosferatu.
>>> 
>>> Maybe we need a REALLY prominent page explaining it once and for all.
>>> I must add that for someone coming from another language, the idea of
>>> trains is massively alien (and a pain until you see their utility).
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[David Ward Lambert]

The DoJ is perhaps the best technical writing I've seen,
even having admitted that it was 2 years before I understood how to
decipher headings conjunction and adverb headings such as
Atopu@v  mv lv rv
Let's continue the NuVoc project.
http://www.jsoftware.com/jwiki/ControlNuVoc
Maybe we'll decide to emphasize what as I recall was but a mere sentence
in the DoJ "when proverbs are substituted into a sentence it is as if
they were parenthesized."  WITH POTENTIALLY DRAMATIC CONSEQUENCE

> Date: Fri, 30 Nov 2012 15:06:29 +
> From: Ian Clark 
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] @: and capped fork
> Message-ID:
>  +0...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> I too have felt the need for Really Prominent Pages (RPPs?) and I've
> regretfully come to conclude that the only workable solution for the
> beginner is the forum, as Dan hints. Hence certain issues will turn up
> over and over again in the threads.


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

Re: [Jprogramming] @: and capped fork

[Bo Jacoby]

J is a rich language, and it might be a good idea to define an elementary 
subset for beginners. J is a nice calculator for elementary computations. You 
can do a lot of computing without knowing anything about binomial coefficients 
and taylor expansions and capped forks. If you need to understand everything in 
order to be happy, then you may be unhappy. I taught my son elementary APL when 
he was 10 years old, and he loved it! 

- Bo




>
> Fra: Ian Clark 
>Til: programm...@jsoftware.com 
>Sendt: 16:06 fredag den 30. november 2012
>Emne: Re: [Jprogramming] @: and capped fork
> 
>I too have felt the need for Really Prominent Pages (RPPs?) and I've
>regretfully come to conclude that the only workable solution for the
>beginner is the forum, as Dan hints. Hence certain issues will turn up
>over and over again in the threads.
>
>Experienced programmers, trying to pick-up J from the reference manual
>as they go along, are especially vulnerable. What "experience" can
>prepare you for J?
>
>Trains are indeed a pratfall, and I think it boils down to this. When you see
>   f g h noun   NB. (1)
>even if you've read and re-read all the stuff about J's bracketing
>rules, you're still tempted to think you can write:
>   v=: f g h     NB. (2)
>   v noun
>...and it gives a different result. So you begin to suspect J is only
>for people addicted to brain-teasers. It doesn't help to be told that
>(2) is a "train" and (1) isn't. (sic)
>
>But I didn't start this thread just to gripe (yet again) about the
>opaqueness of J and its documentation. Researching computer
>(un)usability and how to fix it has been my career, and I was drawn
>into J in the first place by these very considerations. It has proved
>a rich hunting-ground, even more so than APL, which hitherto had been
>the best I'd encountered. Industrial experience has taught me you need
>to spend millions to write good documentation -- unless you want to
>stick to telling people things they know perfectly well already, which
>J emphatically doesn't.
>
>Oh, don't get the idea I only value J the way a doctor values a sick
>patient. Having climbed the learning curve, it's my language of
>choice, and I don't regret it. Why, I'd even pay good money for it.
>(And if you're an APL user you say that with a gulp!)
>
>On Fri, Nov 30, 2012 at 2:50 AM, Alex Giannakopoulos
> wrote:
>> I agree that all this needs more and *clear* and *visible* explanation!
>> It was the first question I asked, and in the two+ years (on-and-off) that
>> I have been mucking around with J I have seen asked on this forum umpteen
>> times.
>> I have also seen it debated at length (and breadth and depth).  By
>> experienced users, experts and newbies alike.  Unfortunately these
>> discussions get buried in the (not easily searchable) list archives and the
>> question keeps popping up, kind of like Nosferatu.
>>
>> Maybe we need a REALLY prominent page explaining it once and for all.
>> I must add that for someone coming from another language, the idea of
>> trains is massively alien (and a pain until you see their utility).
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>--
>For information about J forums see http://www.jsoftware.com/forums.htm
>
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Ian Clark]

I too have felt the need for Really Prominent Pages (RPPs?) and I've
regretfully come to conclude that the only workable solution for the
beginner is the forum, as Dan hints. Hence certain issues will turn up
over and over again in the threads.

Experienced programmers, trying to pick-up J from the reference manual
as they go along, are especially vulnerable. What "experience" can
prepare you for J?

Trains are indeed a pratfall, and I think it boils down to this. When you see
   f g h noun   NB. (1)
even if you've read and re-read all the stuff about J's bracketing
rules, you're still tempted to think you can write:
   v=: f g h NB. (2)
   v noun
...and it gives a different result. So you begin to suspect J is only
for people addicted to brain-teasers. It doesn't help to be told that
(2) is a "train" and (1) isn't. (sic)

But I didn't start this thread just to gripe (yet again) about the
opaqueness of J and its documentation. Researching computer
(un)usability and how to fix it has been my career, and I was drawn
into J in the first place by these very considerations. It has proved
a rich hunting-ground, even more so than APL, which hitherto had been
the best I'd encountered. Industrial experience has taught me you need
to spend millions to write good documentation -- unless you want to
stick to telling people things they know perfectly well already, which
J emphatically doesn't.

Oh, don't get the idea I only value J the way a doctor values a sick
patient. Having climbed the learning curve, it's my language of
choice, and I don't regret it. Why, I'd even pay good money for it.
(And if you're an APL user you say that with a gulp!)

On Fri, Nov 30, 2012 at 2:50 AM, Alex Giannakopoulos
 wrote:
> I agree that all this needs more and *clear* and *visible* explanation!
> It was the first question I asked, and in the two+ years (on-and-off) that
> I have been mucking around with J I have seen asked on this forum umpteen
> times.
> I have also seen it debated at length (and breadth and depth).  By
> experienced users, experts and newbies alike.  Unfortunately these
> discussions get buried in the (not easily searchable) list archives and the
> question keeps popping up, kind of like Nosferatu.
>
> Maybe we need a REALLY prominent page explaining it once and for all.
> I must add that for someone coming from another language, the idea of
> trains is massively alien (and a pain until you see their utility).
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Alex Giannakopoulos]

I agree that all this needs more and *clear* and *visible* explanation!
It was the first question I asked, and in the two+ years (on-and-off) that
I have been mucking around with J I have seen asked on this forum umpteen
times.
I have also seen it debated at length (and breadth and depth).  By
experienced users, experts and newbies alike.  Unfortunately these
discussions get buried in the (not easily searchable) list archives and the
question keeps popping up, kind of like Nosferatu.

Maybe we need a REALLY prominent page explaining it once and for all.
I must add that for someone coming from another language, the idea of
trains is massively alien (and a pain until you see their utility).
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Linda Alvord]

Isn't the issue related to  /

(+:@+)/ 3 4 5
42
   (+:@:+)/ 3 4 5
42
   ([:+:+)/ 3 4 5
42
   
All the promises about  @  and  @:  and  [:  seem to do as promised.  Where you 
put the  /  is what matters.

Linda



-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Dan Bron
Sent: Thursday, November 29, 2012 5:15 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

I can't disagree with your contention about how people (try to) approach J or 
other programming languages.  

For my part, when I started J, I found the DoJ impenetrable and eschewed it for 
the first year or two of my career.  I learned J through the collective wisdom 
and generosity of these Forums, combined with innumerable conversations (ok: 
arguments) with the interpreter.  Once I already knew J, the DoJ became 
valuable (in fact, invaluable).

In other words, I got to J the same way Arthur Rubinstein directed the tourist 
to Carnegie Hall. And, as far as I know, there is no other way to get there.

-Dan 

PS:  I'm not trying to be glib.  Like any project, our documentation can always 
be improved and never be "finished".  And over the years many intelligent, 
generous people have expanded and contributed to it in many different voices, 
media, styles, and methods.  And I'm sure that will continue.  

But I'm equally sure there is no silver bullet (which is the flip side of "our 
documentation can never be finished").  Ultimately, it comes down to the 
individual aspirant.


-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Ian Clark
Sent: Thursday, November 29, 2012 3:16 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

> What provoked your doubt?

In learning J, I've stumbled from one false assumption to another.
Mainly about verb composition. Were I to be the only person to experience this, 
it could be put down to a weak intellect. But if my experience is not uncommon, 
it points to a need for J documentation to be better.

Just today, whilst testing an explication utility I have on the chocks, I 
thought I'd stumbled on yet another unwarranted assumption I'd been making in 
the code. It was one I could not easily check from the standard reference 
material. To be sure I needed to ask on the forum.

The problem with J documentation as it's structured, is that to compose 2 verbs 
you naturally think of a conjunction -- and J has a wealth of those. Far more 
than APL. If you want to choose a suitable conjunction you can read its 
description in Voc. But hooks and forks, especially Capped Fork, compose verbs 
too, yet they're not documented in a comparable way. You have to be au-fait 
with the Dic chapter on Trains, or Chapter 40 of JforC.

It's my contention that experienced programmers learn a new language by reading 
the reference manual as they go along, one feature at a time. They don't digest 
an armful of primers or textbooks up-front, no matter how exciting and 
readable. Learning J, that approach just happens to induce a blind spot over 
Capped Fork -- and verb-trains in general.

Ian

On Thu, Nov 29, 2012 at 5:44 PM, Dan Bron  wrote:
> Right.  For this reason (or similar ones, like when g is a train), I 
> phrase the identity as  ([: f g) ↔ f@:(g)  .
>
> As to where this is stated: well, it's recorded informally in 
> innumerable documents and J learning materials.  If you're looking for 
> formal guarantees in canonical material (the DoJ), you'll have to 
> arrive at the equivalence through a chain of logic.
>
> First, we have the the definition of capped fork in §II.F, following 
> the definition of non-capped fork [1]:
>
> (A) "If f is a cap ([:)  the capped branch simplifies the forks to
> i.   g   h y and
> ii.  g x h y"
> (B) "The ranks of the hook and fork are infinite."
>
> Then, we have the definition of @: in the vocabulary [2]:
>
> (C) "@: is equivalent to @ except that ranks are infinite."
>
> Which refers back to the definition of @, which is given in the 
> Vocabulary as [3]:
>
> (D) "  u@v y ↔ u v y"
> (E) "x u@v y ↔ u x v y .
>
> So, after adjusting for the different names given to the verbs, we the 
> following correspondences:
>
> (Ai)  "([: f g) y ↔ g h y"  vs  (D) "f@g y ↔ f g y"
> (Aii) "x ([: f g) y ↔ g x h y"  vs  (E) "x f@g y ↔ u f g y"
>
> (B) "The ranks of the hook and fork are infinite"  vs
>   (C) "@: is equivalent to @ except that ranks are infinite."
>
> Whic

Re: [Jprogramming] @: and capped fork

[Dan Bron]

I can't disagree with your contention about how people (try to) approach J or 
other programming languages.  

For my part, when I started J, I found the DoJ impenetrable and eschewed it for 
the first year or two of my career.  I learned J through the collective wisdom 
and generosity of these Forums, combined with innumerable conversations (ok: 
arguments) with the interpreter.  Once I already knew J, the DoJ became 
valuable (in fact, invaluable).

In other words, I got to J the same way Arthur Rubinstein directed the tourist 
to Carnegie Hall. And, as far as I know, there is no other way to get there.

-Dan 

PS:  I'm not trying to be glib.  Like any project, our documentation can always 
be improved and never be "finished".  And over the years many intelligent, 
generous people have expanded and contributed to it in many different voices, 
media, styles, and methods.  And I'm sure that will continue.  

But I'm equally sure there is no silver bullet (which is the flip side of "our 
documentation can never be finished").  Ultimately, it comes down to the 
individual aspirant.


-Original Message-
From: programming-boun...@forums.jsoftware.com 
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Ian Clark
Sent: Thursday, November 29, 2012 3:16 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

> What provoked your doubt?

In learning J, I've stumbled from one false assumption to another.
Mainly about verb composition. Were I to be the only person to experience this, 
it could be put down to a weak intellect. But if my experience is not uncommon, 
it points to a need for J documentation to be better.

Just today, whilst testing an explication utility I have on the chocks, I 
thought I'd stumbled on yet another unwarranted assumption I'd been making in 
the code. It was one I could not easily check from the standard reference 
material. To be sure I needed to ask on the forum.

The problem with J documentation as it's structured, is that to compose 2 verbs 
you naturally think of a conjunction -- and J has a wealth of those. Far more 
than APL. If you want to choose a suitable conjunction you can read its 
description in Voc. But hooks and forks, especially Capped Fork, compose verbs 
too, yet they're not documented in a comparable way. You have to be au-fait 
with the Dic chapter on Trains, or Chapter 40 of JforC.

It's my contention that experienced programmers learn a new language by reading 
the reference manual as they go along, one feature at a time. They don't digest 
an armful of primers or textbooks up-front, no matter how exciting and 
readable. Learning J, that approach just happens to induce a blind spot over 
Capped Fork -- and verb-trains in general.

Ian

On Thu, Nov 29, 2012 at 5:44 PM, Dan Bron  wrote:
> Right.  For this reason (or similar ones, like when g is a train), I 
> phrase the identity as  ([: f g) ↔ f@:(g)  .
>
> As to where this is stated: well, it's recorded informally in 
> innumerable documents and J learning materials.  If you're looking for 
> formal guarantees in canonical material (the DoJ), you'll have to 
> arrive at the equivalence through a chain of logic.
>
> First, we have the the definition of capped fork in §II.F, following 
> the definition of non-capped fork [1]:
>
> (A) "If f is a cap ([:)  the capped branch simplifies the forks to
> i.   g   h y and
> ii.  g x h y"
> (B) "The ranks of the hook and fork are infinite."
>
> Then, we have the definition of @: in the vocabulary [2]:
>
> (C) "@: is equivalent to @ except that ranks are infinite."
>
> Which refers back to the definition of @, which is given in the 
> Vocabulary as [3]:
>
> (D) "  u@v y ↔ u v y"
> (E) "x u@v y ↔ u x v y .
>
> So, after adjusting for the different names given to the verbs, we the 
> following correspondences:
>
> (Ai)  "([: f g) y ↔ g h y"  vs  (D) "f@g y ↔ f g y"
> (Aii) "x ([: f g) y ↔ g x h y"  vs  (E) "x f@g y ↔ u f g y"
>
> (B) "The ranks of the hook and fork are infinite"  vs
>   (C) "@: is equivalent to @ except that ranks are infinite."
>
> Which, as far as I can tell, establishes the identity ([: f g) ↔ f@:g 
> (provided we heed the advice given in latter's definition, i.e. 
> "because a conjunction applies to the entity immediately to its right, 
> expressions to the right of conjunctions commonly require 
> parenthesization.")
>
> What provoked your doubt?
>
> -Dan
>
> [1]  §II.F, definition of trains
>  http://www.jsoftware.com/help/dictionary/dictf.htm
>
> [2]  V

Re: [Jprogramming] @: and capped fork

[Ian Clark]

> What provoked your doubt?

In learning J, I've stumbled from one false assumption to another.
Mainly about verb composition. Were I to be the only person to
experience this, it could be put down to a weak intellect. But if my
experience is not uncommon, it points to a need for J documentation to
be better.

Just today, whilst testing an explication utility I have on the
chocks, I thought I'd stumbled on yet another unwarranted assumption
I'd been making in the code. It was one I could not easily check from
the standard reference material. To be sure I needed to ask on the
forum.

The problem with J documentation as it's structured, is that to
compose 2 verbs you naturally think of a conjunction -- and J has a
wealth of those. Far more than APL. If you want to choose a suitable
conjunction you can read its description in Voc. But hooks and forks,
especially Capped Fork, compose verbs too, yet they're not documented
in a comparable way. You have to be au-fait with the Dic chapter on
Trains, or Chapter 40 of JforC.

It's my contention that experienced programmers learn a new language
by reading the reference manual as they go along, one feature at a
time. They don't digest an armful of primers or textbooks up-front, no
matter how exciting and readable. Learning J, that approach just
happens to induce a blind spot over Capped Fork -- and verb-trains in
general.

Ian

On Thu, Nov 29, 2012 at 5:44 PM, Dan Bron  wrote:
> Right.  For this reason (or similar ones, like when g is a train), I phrase
> the identity as  ([: f g) ↔ f@:(g)  .
>
> As to where this is stated: well, it's recorded informally in innumerable
> documents and J learning materials.  If you're looking for formal
> guarantees in canonical material (the DoJ), you'll have to arrive at the
> equivalence through a chain of logic.
>
> First, we have the the definition of capped fork in §II.F, following the
> definition of non-capped fork [1]:
>
> (A) "If f is a cap ([:)  the capped branch simplifies the forks to
> i.   g   h y and
> ii.  g x h y"
> (B) "The ranks of the hook and fork are infinite."
>
> Then, we have the definition of @: in the vocabulary [2]:
>
> (C) "@: is equivalent to @ except that ranks are infinite."
>
> Which refers back to the definition of @, which is given in the Vocabulary
> as [3]:
>
> (D) "  u@v y ↔ u v y"
> (E) "x u@v y ↔ u x v y .
>
> So, after adjusting for the different names given to the verbs, we the
> following correspondences:
>
> (Ai)  "([: f g) y ↔ g h y"  vs  (D) "f@g y ↔ f g y"
> (Aii) "x ([: f g) y ↔ g x h y"  vs  (E) "x f@g y ↔ u f g y"
>
> (B) "The ranks of the hook and fork are infinite"  vs
>   (C) "@: is equivalent to @ except that ranks are infinite."
>
> Which, as far as I can tell, establishes the identity ([: f g) ↔ f@:g
> (provided we heed the advice given in latter's definition, i.e. "because a
> conjunction applies to the entity immediately to its right, expressions to
> the right of conjunctions commonly require parenthesization.")
>
> What provoked your doubt?
>
> -Dan
>
> [1]  §II.F, definition of trains
>  http://www.jsoftware.com/help/dictionary/dictf.htm
>
> [2]  Vocabulary entry for @:
>  http://www.jsoftware.com/help/dictionary/d622.htm
>
> [3]  Vocabulary entry for @
>  http://www.jsoftware.com/help/dictionary/d620.htm
>
> -Original Message-
> From: programming-boun...@forums.jsoftware.com [mailto:programming-
> boun...@forums.jsoftware.com] On Behalf Of bob therriault
> Sent: Thursday, November 29, 2012 12:00 PM
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] @: and capped fork
>
> HI Ian,
>
> If your v includes an adverb such as / the long left reach of conjunctions
> could get you into trouble. That would be part of the parsing rules for
> verbs vs conjunctions.
>
> (+:@:+/) 3 4 5
> 42
>([:+:+/) 3 4 5
> 24
>
> Cheers, bob
>
> On 2012-11-29, at 8:49 AM, Ian Clark wrote:
>
>> Department of Sudden Doubts...
>>
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
>>
>> If so, where would I go to find this fact written up?
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[km]

Here is a comment from Chapter 40 of J for C Programmers:

The verb [:, which we met as a way to cause an error, has a special meaning in 
a fork.  As the leftmost verb of the fork, [: means 'ignore the left branch'.  
So, Nx ([: V1 V2) Ny is V1 Nx V2 Ny and ([: V1 V2) Ny is V1 V2 Ny .  In both 
cases, ([: V1 V2) is equivalent toV1@:V2 .  Almost always, the choice between 
one form or the other is a matter of taste.  Do not fear that the extra word in 
the fork leads to slower execution; the [: is not executed--it is recognized by 
the parser when it creates the anonymous verb for the fork.


Kip Murray
Sent from my iPad


On Nov 29, 2012, at 11:38 AM, Ian Clark  wrote:

> Thanks Dan.
> 
> What I'm hearing reassures me.
> 
> I'm in the final testing phase of an explication utility. It assumes
> the production:   ([: f g) ==>  f@:(g)  . I just had a panic attack
> and wondered if (and whereabouts) this was guaranteed.
> 
> IanClark
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Dan Bron]

Right.  For this reason (or similar ones, like when g is a train), I phrase
the identity as  ([: f g) ↔ f@:(g)  .

As to where this is stated: well, it's recorded informally in innumerable
documents and J learning materials.  If you're looking for formal
guarantees in canonical material (the DoJ), you'll have to arrive at the
equivalence through a chain of logic.

First, we have the the definition of capped fork in §II.F, following the
definition of non-capped fork [1]:  

(A) "If f is a cap ([:)  the capped branch simplifies the forks to 
i.   g   h y and
ii.  g x h y"
(B) "The ranks of the hook and fork are infinite."

Then, we have the definition of @: in the vocabulary [2]:

(C) "@: is equivalent to @ except that ranks are infinite."

Which refers back to the definition of @, which is given in the Vocabulary
as [3]:

(D) "  u@v y ↔ u v y" 
(E) "x u@v y ↔ u x v y .  

So, after adjusting for the different names given to the verbs, we the
following correspondences: 

(Ai)  "([: f g) y ↔ g h y"  vs  (D) "f@g y ↔ f g y"
(Aii) "x ([: f g) y ↔ g x h y"  vs  (E) "x f@g y ↔ u f g y"

(B) "The ranks of the hook and fork are infinite"  vs 
  (C) "@: is equivalent to @ except that ranks are infinite."

Which, as far as I can tell, establishes the identity ([: f g) ↔ f@:g
(provided we heed the advice given in latter's definition, i.e. "because a
conjunction applies to the entity immediately to its right, expressions to
the right of conjunctions commonly require parenthesization.") 

What provoked your doubt?

-Dan

[1]  §II.F, definition of trains
 http://www.jsoftware.com/help/dictionary/dictf.htm

[2]  Vocabulary entry for @:
 http://www.jsoftware.com/help/dictionary/d622.htm

[3]  Vocabulary entry for @ 
 http://www.jsoftware.com/help/dictionary/d620.htm

-Original Message-
From: programming-boun...@forums.jsoftware.com [mailto:programming-
boun...@forums.jsoftware.com] On Behalf Of bob therriault
Sent: Thursday, November 29, 2012 12:00 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

HI Ian,

If your v includes an adverb such as / the long left reach of conjunctions
could get you into trouble. That would be part of the parsing rules for
verbs vs conjunctions.

(+:@:+/) 3 4 5
42
   ([:+:+/) 3 4 5
24

Cheers, bob

On 2012-11-29, at 8:49 AM, Ian Clark wrote:

> Department of Sudden Doubts...
> 
> If u and v are verbs, do (u@:v) and ([: u v) really behave the same 
> under all circumstances?
> 
> If so, where would I go to find this fact written up?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

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

Re: [Jprogramming] @: and capped fork

[Ian Clark]

Thanks Dan.

What I'm hearing reassures me.

I'm in the final testing phase of an explication utility. It assumes
the production:   ([: f g) ==>  f@:(g)  . I just had a panic attack
and wondered if (and whereabouts) this was guaranteed.

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

Re: [Jprogramming] @: and capped fork

[Ian Clark]

Thanks for alerting me to this possibility, Bob.

Fortunately it seems, in the situation it's arising in, I can be
confident the tacit code coming to my utility is fully-parenthesised.
Or at least, appropriately parenthesised.

Viz (+:@:+)/ as opposed to: +:@:(+/)


On Thu, Nov 29, 2012 at 5:00 PM, bob therriault  wrote:
> HI Ian,
>
> If your v includes an adverb such as / the long left reach of conjunctions 
> could get you into trouble. That would be part of the parsing rules for verbs 
> vs conjunctions.
>
> (+:@:+/) 3 4 5
> 42
>([:+:+/) 3 4 5
> 24
>
> Cheers, bob
>
> On 2012-11-29, at 8:49 AM, Ian Clark wrote:
>
>> Department of Sudden Doubts...
>>
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
>>
>> If so, where would I go to find this fact written up?
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[Dan Bron]

Right.  For this reason (or similar ones, like when g is a train), I
usually say the identity is  ([: f g) <==>  f@:(g)  .

As to where this is stated: well, it's recorded informally in innumerable
documents and J learning materials.  If you're looking for formal
guarantees in canonical material (the DoJ), you'll have to arrive at the
equivalence through a chance of logic.

First, we have the the definition of capped fork in §II.F, following the
definition of non-capped fork:  

- "If f is a cap ([:)  the capped branch simplifies the forks to g
h y and g x h y . "
- "The ranks of the hook and fork are infinite."

Then, we have the definition of @: in the vocabulary
- "@: is equivalent to @ except that ranks are infinite."



Atopu@v  mv lv rv   

u@v y ↔ u v y . For example, +:@- 7  is _14 (double the negation).
Moreover, the monadic uses of u@v and u&v are equivalent. 
x u@v y ↔ u x v y .  For example, 3 +:@- 7 is _8 (double
the difference). 
  

-Original Message-
From: programming-boun...@forums.jsoftware.com [mailto:programming-
boun...@forums.jsoftware.com] On Behalf Of bob therriault
Sent: Thursday, November 29, 2012 12:00 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] @: and capped fork

HI Ian,

If your v includes an adverb such as / the long left reach of conjunctions
could get you into trouble. That would be part of the parsing rules for
verbs vs conjunctions.

(+:@:+/) 3 4 5
42
   ([:+:+/) 3 4 5
24

Cheers, bob

On 2012-11-29, at 8:49 AM, Ian Clark wrote:

> Department of Sudden Doubts...
> 
> If u and v are verbs, do (u@:v) and ([: u v) really behave the same 
> under all circumstances?
> 
> If so, where would I go to find this fact written up?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

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

Re: [Jprogramming] @: and capped fork

[Ian Clark]

Yup, that's my Bible for it too.

It's the sort of fact you have to know before you can look it up.

On Thu, Nov 29, 2012 at 5:18 PM, km  wrote:
> Oh Ye Of Little Faith,
>
> The only sources I know are the Vocabulary entries for Atop @ and At @: plus 
> the Dictionary reference for Trains.  In particular the comment in the latter 
> that the ranks of fork and hook are infinite.
>
> Kip Murray
>
> Sent from my iPad
>
>
> On Nov 29, 2012, at 10:49 AM, Ian Clark  wrote:
>
>> Department of Sudden Doubts...
>>
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
>>
>> If so, where would I go to find this fact written up?
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[km]

Oh Ye Of Little Faith,

The only sources I know are the Vocabulary entries for Atop @ and At @: plus 
the Dictionary reference for Trains.  In particular the comment in the latter 
that the ranks of fork and hook are infinite.

Kip Murray

Sent from my iPad


On Nov 29, 2012, at 10:49 AM, Ian Clark  wrote:

> Department of Sudden Doubts...
> 
> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
> under all circumstances?
> 
> If so, where would I go to find this fact written up?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] @: and capped fork

[bob therriault]

Thinking it through, I guess that this example is really (v a) where v is 
+:@:+, and the a is /  , although it might look like u is +: and v is + to my 
(untrained) human eye.

Cheers, bob

On 2012-11-29, at 9:00 AM, bob therriault wrote:

> HI Ian,
> 
> If your v includes an adverb such as / the long left reach of conjunctions 
> could get you into trouble. That would be part of the parsing rules for verbs 
> vs conjunctions.
> 
> (+:@:+/) 3 4 5
> 42
>   ([:+:+/) 3 4 5
> 24
> 
> Cheers, bob
> 
> On 2012-11-29, at 8:49 AM, Ian Clark wrote:
> 
>> Department of Sudden Doubts...
>> 
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
>> 
>> If so, where would I go to find this fact written up?
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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

Re: [Jprogramming] @: and capped fork

[bob therriault]

HI Ian,

If your v includes an adverb such as / the long left reach of conjunctions 
could get you into trouble. That would be part of the parsing rules for verbs 
vs conjunctions.

(+:@:+/) 3 4 5
42
   ([:+:+/) 3 4 5
24

Cheers, bob

On 2012-11-29, at 8:49 AM, Ian Clark wrote:

> Department of Sudden Doubts...
> 
> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
> under all circumstances?
> 
> If so, where would I go to find this fact written up?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

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