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
