> 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
