Correction: (2 3$'abcdef') plus/ . (times"0) 3 4$'ABCDEFGHIJKL' should be (2 3$'abcdef') plus/ . times 3 4$'ABCDEFGHIJKL'
Gives the same result but eschews the circumlocution. ----- Original Message ----- From: Roger Hui <[email protected]> Date: Thursday, July 23, 2009 16:02 Subject: Re: [Jprogramming] Reimplementing J To: Programming forum <[email protected]> > > One thing I'd experiment with, if it became a reality, is a > "symbolic"> numeric datatype. Basically it would be a string. If > the variable a > > contained the value 'a' and b the value 'b' then a+b would > return the > > value 'a+b'. Long ago I used this approach to debug numerical > > algorithms, especially fancy array operations, and found it very > > powerful and useful. Come to think of it, I was using FORTH... > > plus =: ('(' , [ , '+' , ] , ')'"_) &.> > minus=: ('(' , [ , '-' , ] , ')'"_) &.> > times=: ('(' , [ , '*' , ] , ')'"_) &.> > 'a' plus 'b' > +-----+ > |(a+b)| > +-----+ > 'a' plus 'b' plus 'c' > +---------+ > |(a+(b+c))| > +---------+ > plus / 'abcde' > +-----------------+ > |(a+(b+(c+(d+e))))| > +-----------------+ > plus /\ <"0 'abcde' > +-+-----+---------+-------------+-----------------+ > |a|(a+b)|(a+(b+c))|(a+(b+(c+d)))|(a+(b+(c+(d+e))))| > +-+-----+---------+-------------+-----------------+ > plus /\. <"0 'abcde' > +-----------------+-------------+---------+-----+-+ > |(a+(b+(c+(d+e))))|(b+(c+(d+e)))|(c+(d+e))|(d+e)|e| > +-----------------+-------------+---------+-----+-+ > 'abc' plus/ . times 'def' > +---------------------+ > |((a*d)+((b*e)+(c*f)))| > +---------------------+ > (2 3$'abcdef') plus/ . (times"0) 3 4$'ABCDEFGHIJKL' > +---------------------+---------------------+-------------------- > -+---------------------+ > |((a*A)+((b*E)+(c*I)))|((a*B)+((b*F)+(c*J)))|((a*C)+((b*G)+(c*K)))|((a*D)+((b*H)+(c*L)))| > +---------------------+---------------------+-------------------- > -+---------------------+ > |((d*A)+((e*E)+(f*I)))|((d*B)+((e*F)+(f*J)))|((d*C)+((e*G)+(f*K)))|((d*D)+((e*H)+(f*L)))| > +---------------------+---------------------+-------------------- > -+---------------------+ > minus/ . times 3 3$'abcdefghi' NB. determinant > +---------------------------------------------------------+ > |((a*((e*i)-(h*f)))-((d*((b*i)-(h*c)))-(g*((b*f)-(e*c)))))| > +---------------------------------------------------------+ > > > ASIDE: My claim to being a mathematician is that I have a PhD > in the > > subject. Gene in his book APWJ claims he _isn't_ a > mathematician. I > > must say he's a better one than I am! (There's something > Wizard- > > of-Oz about that.) > > http://keiapl.org/anec/#Dickey > > > > ----- Original Message ----- > From: Ian Clark <[email protected]> > Date: Thursday, July 23, 2009 15:15 > Subject: Re: [Jprogramming] Reimplementing J > To: Programming forum <[email protected]> > > > > At some point you will have to issue machine instructions of some > > > sort. Otherwise, you will still be using the machine > > instructions> generated in the current C implementation of J. > > > > Correction: your new interpreter will need to execute machine code > > somewhere, even if it's inherited from the previous version. > The power > > of the approach is to go with what works, and only override > what needs > > improving. A bit like OO. > > > > It's no new idea to "model" or "emulate" proposed new language > > features in the language itself. The number of APL editors > > written in > > APL I've seen! (Also c/f APWJ chapter 2) But to replace a language > > primitive with its "emulation" is to re-implement, not > "model". Basing > > the release of a whole language processor version on this philosophy > > is frankly something I haven't fully thought through. It's expecting > > something for nothing. A monkey on my back is whispering it would > > merely export the cogs of J from C (++) -- or whatever -- into > > profile.ijs. That this could take place without severe performance > > degradation totally offends my prejudices. Nevertheless there are > > precedents. Namely Burroughs Algol. > > > > But think of the power of the approach! Any of us could > > prototype a > > language extension, then release our own version of J with this > > feature built-in. Or maybe we'd only need to release our > > profile.ijs...? > > > > One thing I'd experiment with, if it became a reality, is a > "symbolic"> numeric datatype. Basically it would be a string. If > the variable a > > contained the value 'a' and b the value 'b' then a+b would > return the > > value 'a+b'. Long ago I used this approach to debug numerical > > algorithms, especially fancy array operations, and found it very > > powerful and useful. Come to think of it, I was using FORTH... > > > > In old "computer science" textbooks this trick was called "symbolic > > execution". It appealed to mathematicians of my generation > because we > > had no real feel for numbers per-se, only algebraic expressions. > > Algebraists were two-a-penny, but nobody admitted to being an > > arithmeticist. > > > > ASIDE: My claim to being a mathematician is that I have a PhD > in the > > subject. Gene in his book APWJ claims he _isn't_ a > > mathematician. I > > must say he's a better one than I am! (There's something > Wizard- > > of-Oz > > about that.) > > > > Ian > > > > > > On Thu, Jul 23, 2009 at 11:23 AM, Raul > > Miller<[email protected]> wrote: > > > On Wed, Jul 22, 2009 at 10:01 PM, Ian > > Clark<[email protected]> wrote: > > >> This stands the FORTH approach on its head, and I was wrong > > to dismiss > > >> it althogether. So what you're saying is I need to revisit > > the idea of > > >> reimplementing J at boot-up time from a tiny kernel of > > primitives...>> not naive ones as in FORTH but very > > sophisticated ones like ;: and > > >> ^_1. > > > > > > At some point you will have to issue machine instructions of some > > > sort. Otherwise, you will still be using the machine > > instructions> generated in the current C implementation of J. > > > > > > That said, I imagine the ;: dyad would be an important part of > > > any J implementation. (They monad is being a fixed left > > argument> to the dyad.) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
