The only disadvantage I recognize is the point about special code.
floor
<. :(<.@])
10 timespacex 'floor@%: i.10000'
0.00426304 264832
10 timespacex '<.@%: i.10000'
0.00220912 264448
workarounds would include using the symbol to trigger special code. f. could
also be improved such that:
u@]@[ f. is u@[
u : v @ w f. is u @ w
As to your other points, because the primitives are tacit, I believe there is
integrated rank support.
floor b. 0
0 _ _
I guess though 0 _ 0 might be better (and something I can automate in
definitions), but I don't know of a case that it makes a difference.
English is needed to read dictionary, and all of the primitives are the monad
dictionary entries, so everything is autodocumented. Points 3 and 8 are fair
though I think minor.
The advantage bigger than the one you mentioned is better seeing the intent of
code. Only the monads that are not a simple ommitted parameter version of
their dyads are given primitive names. Code will still use plenty of symbols.
In a "@train", there is no need to use the primitive shaddow names for non
right-most elements.
I agree that knowing the primitive mappings is just a tiny portion of the
difficulty of J. What is difficult for even those past beginner status is
determining whether i. is iota or indexof in code they read.
----- Original Message -----
From: Henry Rich <henryhr...@gmail.com>
To: programm...@jsoftware.com
Sent: Thursday, November 26, 2015 3:06 PM
Subject: Re: [Jprogramming] dyadic J
Replacing J primitives with names has big disadvantages:
1. A user learning J by these names will not be able to read code
written using primitives or other names.
2. The names are English.
3. A 'line of code' - what fits comfortably on a screen - will contain
much less code.
4. The special combinations
(http://code.jsoftware.com/wiki/Vocabulary/SpecialCombinations) will not
be used, making code slower, sometimes much slower.
5. Integrated Rank Support is not available for the names.
6. The names will not have full documentation. To see what a name does,
a user must go to a page for the primitive.
7. Names will not automatically link to help pages.
8. The chosen names may conflict with other uses of the same names in
existing code.
The advantages are:
1. The J primitives will be easier to remember.
I think that remembering the J primitives is a small part - 10% perhaps
- of the trouble of learning J. Restructuring one's thinking is the
hard thing. If I know a primitive exists, looking it up on NuVoc is easy.
I think a user learning J by names would soon want to shed the names.
Therefore, I think that the names should be as useful as possible to a
raw beginner. A very common beginner error is getting the valence
wrong; names such as Bill suggested, where each name has only one
valence, would prevent that: probably the best thing to come from the
project.
Henry Rich
On 11/26/2015 2:45 PM, 'Pascal Jasmin' via Programming wrote:
> You intended it to be dyadic, but no error occurs if you use it monadically.
> The dyadic result is a "bonus" (your term) feature (not a bug).
>
>
>
>
> ----- Original Message -----
> From: Linda A Alvord <lindaalv...@verizon.net>
> To: programm...@jsoftware.com
> Sent: Thursday, November 26, 2015 2:06 PM
> Subject: Re: [Jprogramming] dyadic J
>
> C2 as I wrote it is dyadic. What else it does is not necessarily important
> or useful. So I should only use it as a dyadic function without considering
> what the result means if it is used dyadically.
>
> Linda
>
> -----Original Message-----
> From: programming-boun...@forums.jsoftware.com
> [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of 'Pascal
> Jasmin' via Programming
> Sent: Thursday, November 26, 2015 1:27 PM
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] dyadic J
>
> Nothing wrong with c2. Its what you wrote. In explicit code, x u v y is x u
> (v y). v is monad. u is dyad.
>
> in tacit code, ([ u v)
> u is still dyad, but v (and even [) is ambivalent: different verbs based on
> dyad or monad call.
>
>
>
>
> ----- Original Message -----
> From: Linda A Alvord <lindaalv...@verizon.net>
> To: programm...@jsoftware.com
> Sent: Thursday, November 26, 2015 1:04 PM
> Subject: Re: [Jprogramming] dyadic J
>
> f is a new verb which seems to be the same as c2:
>
> conjugate =: +@]
> f=: 13 :'x+ conjugate y'
> c2=: 13 :'x++y'
>
> f 2j3
> 4
> c2 2j3
> 4
>
> 2j3 4j5 f 6j7 8j_9
> 8j_4 12j14
> 2j3 4j5 c2 6j7 8j_9
> 8j_4 12j14
>
> f
> [ + [: conjugate ]
> conjugate
> +@]
>
> c2
> [ + [: + ]
>
> What os wrong with c2?
>
> Linda
>
> -----Original Message-----
> From: programming-boun...@forums.jsoftware.com
> [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of 'Pascal
> Jasmin' via Programming
> Sent: Thursday, November 26, 2015 12:13 PM
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] dyadic J
>
> Some things you may ( or not) already know,
>
> monadic + and dyadic + are different functions.
>
> tacit verbs (including the result of 13 : ) are ambivalent: Both monadic and
> dyadic.
>
> What prompted this post was making tacit expressions more clearly intentional.
>
> Bill's suggestion would give only a monad or dyad interpretation to a tacit
> verb, and give an error if called wrong. My proposal would, in general,
> ignore the left argument for the parts of a tacit expression that is intended
> to be monadic, still allowing the whole expression a valid dyadic
> interpretation as well.
>
>
>
> ----- Original Message -----
> From: Linda A Alvord <lindaalv...@verizon.net>
> To: programm...@jsoftware.com
> Sent: Thursday, November 26, 2015 11:54 AM
> Subject: Re: [Jprogramming] dyadic J
>
> Am I missing something?
>
> f=: 13 :'+y'
> f
> +
> f 2j3
> 2j_3
>
> 2j3 f 4j5
> 6j8
>
> Linda
>
> -----Original Message-----
> From: programming-boun...@forums.jsoftware.com
> [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of 'Pascal
> Jasmin' via Programming
> Sent: Thursday, November 26, 2015 10:58 AM
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] dyadic J
>
> Let me make up a term and call it "ambivalent coherence". Referring to a
> function that behaves coherently under both monad and dyad use. Where
> coherent is defined as the only mental effort required to know the monad form
> is substitution of a default parameter for x.
>
> - % ^ ^. all have ambivalently coherent implementations (default x of 0 1 e
> e). Addition and multiplication do too, but they are too boring and
> duplicate (Same ]). In J's design it was thought to be a waste to not reuse
> the symbols + * for something useful monadically too.
>
> although ambivalent coherence is a binary - pregnancy like- condition,
>
>
> * # $ have relatively low "ambivalent incoherence" The monads are incoherent
> to their dyads, but there is a functional relationship. There is also some
> coherence with how the 3 verbs differ monad from dyad. The conjunction 2 :
> 'u@] u v' could likely be meaningful where u can be any of the 3.
>
> dyadic J is the simple naming of ambivalently incoherent monads. To tweak
> your definitions slightly,
>
>
> m1=: ] + +@]
> d1=: ] + +
>
> Both of those verbs are "ambivalently valid" (return without error, and have
> practical "meaningful intentionality" under both monad and dyad). They are
> (as whole verbs) also ambivalently coherent as long as the domain is not
> imaginary numbers. They both produce the same answer if called monadically,
> for any domain.
>
> So the "m and d" hints are not actually appropriate for what are ambivalently
> valid verbs. To make them appropriate we would need to unnecessarily force a
> domain error.
>
> dyadic J makes it easier to compose ambivalently coherent expressions, and
> easier to read the ambivalent intent.
>
> conjugate =: +@]
> m1=: ] + conjugate
>
> (d1 * m1) can also be "intentionally ambivalently valid" and coherent with
> dyad x of 0 and y not imaginary.
>
>
>
>
>
> ----- Original Message -----
> From: bill lam <bbill....@gmail.com>
> To: 'Pascal Jasmin' via Programming <programm...@jsoftware.com>
> Sent: Thursday, November 26, 2015 12:12 AM
> Subject: Re: [Jprogramming] dyadic J
>
> A long tacit train of symbols can be difficult to parse especially when we
> don't know whether its usage is monad or dyad.
>
> examples in J Phrases give hints like this,
> m1=: [ + +
> d1=: [ + +
>
> Ср, 25 ноя 2015, jprogramming написал(а):
>>> Also the primitives addon can not translate from symbols to
>>> namedverbs automatically because valency is unknown until actual
>> execution.
>>
>> That's what I remember, and the primitives addons workaround is to give 2
>> names to each builtin verb, and IndexOf 5 is valid even if nonsensical.
>>
>> Your proposal is a completely reasonable alternative, but its less
>> convenient and requires more typing effort.
>>
>> Consider Conjugate
>>
>> 3 ([ + +) 3j4
>> 9j4
>> 3 ([ + +@]) 3j4
>> 6j_4
>> ([ + +) 3j4
>> 6
>>
>> all are valid ambivalently, but if you intended the 2nd and 3rd vs 1st and
>> 3rd then:
>>
>>
>> ([ + conjugate) captures that intent. (includes option of no
>> whitespace)
>>
>>
>> with your proposal you would have to write either
>>
>> ([ + Conjugate@])
>>
>> or
>>
>> (Right Plus Plus) NB. if 2nd meaning intended
>>
>>
>> but that 2nd one is only valid if you call it dyadically and it doesn't have
>> any of the 3 mentioned meanings:
>>
>> 0 ([ + +) 3j4
>> 3j4
>> 0 (] + +) 3j4 NB. required call to match original monad.
>>
>> so that is another advantage to leaving the dyad primitives alone. You can
>> still make ambivalent verbs, and the dyad case may be the main ambivalent
>> intent.
>>
>>
>> ----- Original Message -----
>> From: bill lam <bbill....@gmail.com>
>> To: 'Pascal Jasmin' via Programming <programm...@jsoftware.com>
>> Sent: Wednesday, November 25, 2015 11:40 AM
>> Subject: Re: [Jprogramming] dyadic J
>>
>> I think ambivalent is difficult and not that intuitive for uninitiated
>> users. Perhaps J (and APL) needed ambivalent partly because there were
>> not enough symbols. Making named verbs either monad or dyad but not
>> both, might make life of new users easier. eg.
>>
>> til =: i. : [:
>> til 5
>> 0 1 2 3 4
>> 1 til 5
>> |domain error: til
>> | 1 til 5
>> indexOf =: [: : i.
>> 1 2 3 indexOf 2
>> 1
>> indexOf 2
>> |domain error: indexOf
>> | indexOf 2
>>
>> Also the primitives addon can not translate from symbols to named
>> verbs automatically because valency is unknown until actual execution.
>>
>>
>> --
>> regards,
>> ====================================================
>> GPG key 1024D/4434BAB3 2008-08-24
>> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver
>> subkeys.pgp.net --armor --export 4434BAB3
>>
>>
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>> ----------------------------------------------------------------------
>> 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 gpg --keyserver
> subkeys.pgp.net --armor --export 4434BAB3
> ----------------------------------------------------------------------
> 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
> ----------------------------------------------------------------------
> 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
