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. Mark D. Niemiec wrote (Dec 24 also in response to the above); > Could you please elaborate on what you mean by this? > Just which functions of [: and ]: would you want "restored", > and in which J version did they exist? . . . My apologies for misleading you. I hope the explanation above straightens my viewpoint out for you. Ambrus Zsban wrote (Dec25, also re above): > I thought those were uncommitted because they only made sense as > helpers for operator trains, just like how [ and ] are mostly useful > for helpers in trains and composes. It sounds as though you understood them better than I did. Indeed, I'll have to think about operator trains if I ever do get back to writing about J. > Meanwhile, if you think they are useful, you could define something like > lev =: 2 :'u' > dex =: 2 :'v' > pass =: 1 :'u' > > as a substitute to the old [. ]. ]: primitives. These could be very useful if they worked as lev =: 3 : 'u' dex =: 4 : 'v' Certainly they encourage me to get back to J when I can get some free time (very hard when you're retired). Thanks very much. Raul Miller wrote (Dec 25 also re above): > He does not think they were useful > http://www.jsoftware.com/pipermail/programming/2007-September/008157.html See comment above. > More generally, his requirements [as I understand them] seem > to have internal conflicts which make them impossible for anyone > to implement. I would be very interested to know what those internal conflicts were. I think you, Raul, tried to explain them to me in this forum once before, but I seem to remember merely being bewildered. By the way, I greatly admired the ^:0 1 solution you gave for one of the examples I put here more recently. The problem is, though, that even if brilliant solutions like that were available for all the instances where I would otherwise have to revert to explicit coding, they could not be used in introductory teaching or an introductory text because they would require deeper aspects of J to be explained first. They wouldn't evidence a consistent pattern for clearly related requirements. My conviction is that [. and ]. as primitive verbs would be easy for beginners to understand and use, and they could later appreciate that many of their uses could be coded in several interestingly different ways, which is one of the splendours of a coding scheme like J that make it so much more interesting than all the more commonly used coding schemes. Neville Holmes, P.O.Box 404, Mowbray 7248, Tasmania Normal e-mail: [EMAIL PROTECTED] Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
