I came from APL and found that then "one liners" while clever, do not
allow for easy interpretation . This is, while a neat one-liner is not
easy to interpret. even though you have given interpretation of steps.
I look at
*`<`>`<.`>.`<:`>:`#`=`+:`-:`|`|.`+`-.`*:`{`}:`{:`{.`}.`;`,`,.`,:`;:`C.`A.`q:`e.`/:`\:
4 : '(> y) =: (x `:6) : (x `:6@]) label_. y '"0 ;: 'sign box open floor
ceiling decr incr tally self double halve magnitude reverse conjugate
not square catalog curtail tail head behead raze ravel items itemize
words cycle anagramindex factors razein gradeup gradedown'
and wonder "what the hell !"
Is this a benefit?
Is there a need for a dyadic interpretation (and most, operators,
as far as I can see, do this) for all operators?.
some operations do not need this and doing this may be convenient but do
add overhead that may not be of actual use may be counterproductive
-definitely in terms of coding, at a more basic level than J. that may
result in bloated or slower internal algorithms
I suggest, as one who does not have your experience with J, that "KISS"
is a principle to follow.
Does your suggestion follow this?
With respect.
Don (old fart) Kelly
On 11/24/2015 7:03 PM, 'Pascal Jasmin' via Programming wrote:
Here's my suggested implementation. The only linebreaks are at empty lines.
*`<`>`<.`>.`<:`>:`#`=`+:`-:`|`|.`+`-.`*:`{`}:`{:`{.`}.`;`,`,.`,:`;:`C.`A.`q:`e.`/:`\: 4
: '(> y) =: (x `:6) : (x `:6@]) label_. y '"0 ;: 'sign box open floor ceiling decr incr tally
self double halve magnitude reverse conjugate not square catalog curtail tail head behead raze ravel
items itemize words cycle anagramindex factors razein gradeup gradedown'
i.`i: 4 : '(> y) =: (x `:6) : (+ x `:6) label_. y '"0 ;: 'iota steps'
?`?. 4 : '(> y) =: (x `:6) : (x `:6@#) label_. y '"0 ;: 'roll rollf'
+.`*. 4 : '(> y) =: (x `:6) : (({ x `:6)"0) label_. y '"0 ;: 'real length'
indices =: I. : ( I.@:=)
The only special monad not previously mentioned
3 indices 3 5 1 3 2 3
0 3 5
all names are lowercase, and match the dictionary except
sign incr decr iota rollf items factors
----- Original Message -----
From: 'Pascal Jasmin' via Programming <programm...@jsoftware.com>
To: "programm...@jsoftware.com" <programm...@jsoftware.com>
Sent: Tuesday, November 24, 2015 4:39 PM
Subject: Re: [Jprogramming] dyadic J
The audience would be people like me when I started. I came from VB and
dabbling in lisp python ruby. Not APL.
The best tip for reading tacit code that is not published very prominently is
that a fork is
A D A - (A)mbivalent (D)yad
which still leaves the interpretation step of is A actually M or D? Its
extremely rare for a train to be meaningful under both M and D.
The first objective is readability. Seeing a verbose built in name would clue
you in that this is primarily a monadic verb.
In terms of less error prone, when you write i. (or #) you mean either iota or
indexof. Not some flexible ambivalent version of i. So if you used iota as
one of the edges of your fork, you can still make the whole fork dyadic while
one tine is monadic. You can also use iota@[ to refer to x side.
While you can remember for any sentence that you intended i. to be iota for the
next 5 to 30 minutes, that memory fades. A month later you are in the same
position as if I were to try to guess what you intended. With a coding style
of word for monad, symbol for dyad, it seems to me to be an obvious significant
boost in clarity.
What originally gave me the idea is that if every verb in J had a dyad
implementation, then J can be implemented in every other language. For example
in python
add(y, x=0) is a function signature where x is an optional parameter. Removing
monad as a verb category makes it possible to handle missing parameters at the
function level in some languages, and with an adverb equivalent to @] in others.
Implementation in other languages is as far as I can tell good for J in that J
is likely to retain a performance advantage, and it can only risk infecting
others into J-ing. Both the implementation in other languages and newcommers
ability to understand is easier if there are fewer categories of functions to
understand and implement.
see also
https://www.reddit.com/r/dailyprogrammer_ideas/comments/3tz8ds/3_part_series_turn_your_favorite_language_into_an/see
When everything is a dyad with default : ($:@]) implementation (if not a "real"
dyad) then it also makes conjunctions easier to write/use.
a cute implementation of the proposal:
Monad =: : ($:@])
count =: # Monad
Consider:
hook_z_ =: 2 : '([: u v) : (u v) '
The core issue in this conjunction is that u can be monadic or dyadic, but for
some reason v must be monadic. There are plenty of more sophisticated
conjunctions that have to deal with this issue and make these tradeoffs, but
the actual best solution for a conjunction here would be to return:
([ u v)
if the user of the conjunction wants to use monadic v then he passes (v@]). if
he wants monadic u then passes u@]. And it call all be part of a larger dyadic
train. This is already possible of course, but the design temptation when
writting the conjunction is to guess whether u and v will be monadic most of
the time and so create restrictions around optimizing the most frequent use
case.
With this convention, you can now always use monads when dyads are expected,
and so can freely design modifiers as though dyads are the only relevant
consideration.
While I have what I think are useful enhancements for built-in monads, one good
case for making them all
: ($:@])
is that a useful alternative hook conjunction above is that
([ u v) has useful intuitive interpretations for M M, M D , D M , and D D.
Similar to the Monad definition above,
Dyad =: 2 : 'm&$: : v'
For all dyads, there exists a default x that is at least not inconvenient. In
the worst case that x is ERROR/null/i.0 0.5 _
----- Original Message -----
From: Dan Bron <j...@bron.us>
To: J Programming <programm...@jsoftware.com>
Sent: Tuesday, November 24, 2015 3:13 PM
Subject: Re: [Jprogramming] dyadic J
It would be interesting and helpful to see some motivating examples — code that
is shorter, clearer, less error-prone, whatever, using “dyadic J” than the
original “standard J”.
Would also be helpful to describe the intended audience. For example, are the
motivating examples shorter, clearer, less error-prone, whatever, for novices?
Calculus students? Immigrants from APL? J veterans?
-Dan
On Nov 24, 2015, at 3:02 PM, 'Pascal Jasmin' via Programming
<programm...@jsoftware.com> wrote:
A simple project whose benefits are described shortly:
replace (add shaddow names) most of the monadic built-in verbs with ambivalent
definitions that may add extra utility.
count =: # : #@]
all monads have an obviously intuitive dyad alternative of v@], but some monads
can be given additional utility in a way that is still providing the
fundamental function. For instance
iota =: i. : (+ i.)
1 iota 3
1 2 3
roll =: ? : ?@#
5 roll 6
1 1 5 4 2
benefits:
providing extra utility to verbs is nice, but not the main reason.
It would make J more approachable if every verb is a dyad whose monadic
interpretation can be understood as an ommitted default parameter.
Its easier to read tacit code, for instance if iota and i. look different, and
the verbose version is verbose for the specific reason that it is a monad.
Tacit forks would look more like (word symbol word) if they are intended as
monadic forks, but may have dyadic tweaks. examples:
(3 * iota) 3
0 3 6
1 (3 * iota) 3
3 6 9
The above tweak is a practical dyadic variation of essentially the same fork,
whereas with i. in the fork, the dyad use is likely a misapprehension of the
function.
this may be cool too,
1 (iota"0 iota) 4
0 0 0
1 0 0
1 2 0
1 2 3
The main benefit stated more succinctly is that real dyads would look different
than real monads, but overall fewer errors would occur as a result of valence
errors, and it also shortens some code.
details:
% - ^ ^. #. #: ] [ 0: ": j. p: r. p.. are examples of monads that would not get a shaddow
name, because their dyad is already a "default x" implementation.
* %. [: ". I. { ;: may have useful dyad tweaks I can't think of
Some verbs would have weird names
real_imag =: +. : ({ +.)
length_ang =: *. : ({ *.)
these may be bad ideas, but are interesting:
double =: +: : (+:@]^:[) NB. double x times. -:*:
curtail =: }: : (-@[ }. ]) NB. but }:@] would be more useful
do =: ". : (".@(, ' ' , ]))
Another approach is to avoid providing any improvements to the dyadic version
of monadic functions and instead make them all have dyad version of v@]
Assuming that improvements are useful, can you think of any alternate
implementations for ambivalent:
* %. [: ". I. { ;:
----------------------------------------------------------------------
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
