> 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.) > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
