It seems to me that this change would move J in the direction of prefix 
notation, and away from infix notation. 

If we were to do that, I'd rather take it to its logical conclusion and 
simplify the syntax at the same time, and go for something like Lisp's 
S-expressions (while also making boxing, per se, transparent to the programmer).

Which is to say: I do not prefer we pursue this course. J's infix notation is a 
fundamental part of its character, and is one of the things that distinguishes 
it from other languages. Not to mention one of the sources from which it draws 
its brevity (which is *definitely* a core part of its character). 

Plus I believe infix acknowledges and honors the constraints of the medium of 
programming: a line of text (a line! meaning the ability to move in TWO 
directions).

That said, I was pleased and impressed by the use of x&p. in your description 
of the idea.

Thanks,

-Dan

Sent from my iPhone

> On Mar 30, 2014, at 3:24 PM, Raul Miller <[email protected]> wrote:
> 
> Let's imagine
> 
> Rank=:2 :0
>  NB. u: verb
>  NB. n: noun (list of numbers)
>  NB. y: boxed nown
> ...
> )
> 
> Here, #n must be at least 1 1.5 0.5&p.#y
> 
> u is applied at rank specified by n {~ (i. + _1 0.5 0.5 p. ])@# y to the
> contents of the boxes of y.
> 
> Would this be practical? Yes and no... for some small problems and for
> illustrative purposes a straightforward J implementation would work great.
> This could also serve, for some people, as an example of how rank "really
> works". But for larger problems it would be a pain to use, and something
> closer to more classical APL might be a better approach.
> 
> If we had good J compilers, that would open up some additional options and
> make some of those cases be significantly more efficient. And writing such
> a compiler might be a fun student project (for the right kind of class).
> But efficiency is often a misleading issue and reasoning about it is often
> contradicted by experience.
> 
> Let me know if you want me to draft up an implementation (of Rank, not of
> good J compilers - Rank is something that would take maybe an hour to
> implement, a good compiler takes longer). (And, I've got other things I'm
> working on today.)
> 
> Thanks,
> 
> -- 
> Raul
> 
> 
>> On Sun, Mar 30, 2014 at 2:34 PM, Dan Bron <[email protected]> wrote:
>> 
>> I recommend cultivating a skepticism of the thought "this is a bug in J".
>> It's a thought-stopping reaction, and almost always wrong.
>> 
>> That's not to say J has no bugs: no, I mean "almost always" in the
>> measure-theoretical sense; while I've found plenty of bugs in J, their
>> number is absolutely dominated by the number of bugs I've found in my
>> understanding of J. So now my first reaction is to debug my mental model
>> before I try to debug J.
>> 
>> Here's how I might approach that in your current case. First, I recognize
>> that the argument to }, here, is a 3-element gerund, and the derived verb
>> being invoked dyadically:
>> 
>>> 3 +`((0 0;1 1;2 2)"1)`]} i.3 3
>> 
>> 
>> So I look up that case in the definition of } :
>> 
>> x (v0`v1`v2)} y ↔️ (x v0 y) (x v1 y)} (x v2 y)
>> 
>> Next, I would test this assertion the DoJ is making, against my current
>> example:
>> 
>>   x =: 3
>>   y=:i.3 3
>> 
>>   v0=:+
>>   v1=:(0 0;1 1;2 2)"1
>>   v2=:]
>> 
>>   m=: v0`v1`v2
>> 
>>   benchmark=:x m} y
>>   test =:(x v0 y) (x v1 y)} (x v2 y)
>> 
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to