I, just as you, wrote [: and ]: instead of [. and ]. in my response). I never use them much, nor missed them after decommission, and they have been long forgotten. Further, as you might have realized, I would not miss [: either (in any of its forms).
You interpretation about my, J being Turing complete, phrase is right. I am saying that in principle any computation can be expressed as a J verb and any J verb can be expressed tacitly (in practice, some J idiosyncrasies are virtually impossible (e.g., mapped files manipulation) because the related facilities were designed to be used explicitly). In a few words, one can show that any computing task can be written tacitly because, if worst come to worst, one can write tacitly a Turing machine emulator ( as I did in ttp://www.jsoftware.com/pipermail/general/1999-December/002736.html ) or any other emulator (as you reportedly did; http://www.jsoftware.com/pipermail/programming/2007-February/005340.html ) that can emulate any other computer (I am assuming that the von Neumann IAS simulator that you implemented is Turing complete). However, worst does not have to come: one can write any verb (as programmers can write directly any program without GOTOs) tacitly in a structural programming fashion since local nouns and while statements can be emulated directly (see the last sentence in my abovementioned email). From this perspective (my perspective if you will), adverbs and conjunctions usefulness is ultimately measured by their ability to facilitate the generation of tacit verbs. I did not miss much [. and ]. because the tacit facilities to generate verbs directly (adverbs and conjunctions) were not, and are not, complete anyway (as you well know). The approach that I follow, outlined in the tailing email, can be illustrated with one of your examples in your email cited above, stk=. 1 : '] ,: u.' sumstk=. +/ stk sumstk i.3 0 1 2 3 3 3 Can you do that tacitly? stk0=. &(('] ,:('"_ , ] , ')'"_)@[ (apply f.) ]) stk0 &(('] ,:('"_ , ] , ')'"_)@[ 128!:2 ]) sumstk0=. '+/' stk0 sumstk0 i.3 0 1 2 3 3 3 The disadvantages are that arguments are strings representations (e.g. '+/') and dyadic verbs require a little more effort; also, the method is an overkill for your simple example but I hope the point is made. The advantages are that arguments can be string representations of verbs, adverbs, conjunctions or even any code fragment) and code can be generated, stored and/or executed easily in real time. You, as I understand, would like to write, stk1=.] ,: [. sumstk1=. +/ stk1 sumstk1 i.3 0 1 2 3 3 3 So, what I was suggesting to you is to write a verb <compile> that, in this particular case, would convert the above 3-line script into the equivalent script, sumstk1=. ] ,: (+/) sumstk1 i.3 0 1 2 3 3 3 Further, you could modify jijs.ijs and facilitate the process (for example, add a <Compile> entry to the <tool/selection> menu that compiles and executes a code selection). I hope this helps. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of neville holmes > Sent: Wednesday, December 26, 2007 5:17 AM > To: [email protected] > Subject: [Jprogramming] Lev and dex (was Multicore Arithmetic) > > > I wrote (Dec 21): > > > Please excuse me if this contribution duplicates > > comments already made in the multicore thread. > > I have dropped working in J pending the restoring > > of [: and ]: as functions like [. and ]., and unlike the > dropped lev > > and dex conjunctions, to allow me to avoid explicit coding, > so I have > > just been skimming this forum's discussions. (Not that I really > > expect this change to take place, but hope springs eternal.) > > > > Jose Mario Quintano wrote (Dec 24): > > > "If Mohammed will not go to the mountain; the mountain must come to > > Mohammed." > > > Could you not move the mountain towards you? Perhaps is not that > difficult: > > conceivably you could write a verb to compile code written using [: > and ]:, > > as you have proposed before, generating equivalent code in current > standard > > J; ';:' might facilitate the process. You could even write the > compiling > > verb using your syntax and primitives, compile it by hand > and use the > source > > as a test case for the compiled version of itself. > Further, jijs.ijs > is > > open, allowing for interesting possibilities. > > Unfortunately, I write as a teacher, not a programmer. Until > a few years ago when I was retired, I taught a variety of > students for some years about tacit J under the heading of > Functional Programming. I was enthusiastic about tacit J and > when I stopped teaching after the official onset of senility, > I started to write a popular book to > recruit anyone interested in numbers to tacit J. Finding it > impossible > to keep entirely tacit, I gave up when I realised the > repeated use of footnotes to excuse reversion to explicit > coding would make my introduction of tacit J very > unconvincing. Therefore I dropped that writing and my only > contact with J since has been skimming items in this forum. > That's why I put [: and ]: in my message above when I should > have put [. and ]. and it's why the journey to the mountain > suggested above is inappropriate (a) because I don't > understand it and (b) because there's no point in my > struggling to understand it because it could have no place in > the book I was wanting to write. > > > Unlike others, I have never missed much the old [: and ]: > (As I have > > mentioned before, Tacit J is Turing complete regarding verbs; verbs > (and > > nouns, adverbs, conjunctions, etc.) can be represented by strings > that can > > be manipulated by verbs; and resulting strings representing > verbs can > be > > executed, even in real time if necessary, via apply (128!:2)). > However, I > > would be interested to see your suggestions in action. > > So [: still exists as Cap and ]: didn't ever exist as far as > I can remember. What did exist was [. and ]. but > unfortunately they were conjunctions. I don't understand > quite what you are trying to tell me in respect of tacit J > being Turing complete, but I suspect it is that anything > computational can be expressed. Sadly, when you teach > students, may of whom are arithmetically naive, about coding > algorithms, you need to be more concerned about how things > are coded than about whether particular things can be coded > or not. Simple things need to be able to be done simply, and > when I was teaching tacit J I kept having to tell students > that what they wanted to do couldn't be done simply. > > The problem seemed always to be something that could have > been done simply if only [. and ]., or something like them, > could have been used as verbs. Using [ and ] was > delightfully simple in allowing arguments to be placed within > tacit definitions. > > In effect, [ and ] are formal names for the arguments of > a tacitly defined function (verb), so, in one sense are a > departure from pure functional programming, albeit a very > useful one. When teaching tacit J I came to realise that the > problem was that tacit J could not be used to define > operations (adverbs or > conjunctions) as freely as [ and ] allowed functions to be > defined. Then I noticed that all the problems of defining > operations tacitly would disappear if only primitive > functions could be used to bring operands into the tacit > definition of an operation in the same way that [ and ] are > used to bring arguments in. > > I remembered having tried to use [. and ]. some time > before I started teaching Functional Programming, but > found them difficult to use. Looking at old documentation > it seemed that this was because they were conjunctions > and so could not act simply as operands or functions > within a tacit definition. All the examples I then > experimented with became easy of solution (mentally) if I > used [. and ]. syntactically as functions. > > I hope this explains my point of view and the reasons why > the kind of methods I think you are recommending would > not be appropriate for me as an author of a text intended > to suck numerically minded lay people into using tacit J. > > > I am curious, in which language (if any) are working now instead of > J? > > English (see eprints.utas.edu.au/view/authors/Holmes,_Neville.html). > In the '70s and '80s I used APL (and RPG, COBOL, FORTRAN, > PL/I and others even earlier), but when I retired and took up > teaching I gave up coding. Now that I've been retired again > I mostly code in HTML and Unix scripts. So I am way behind > the times, and my teaching of J over the last twenty years > has always been to beginners. > ... ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
