Vocabulary/WorkingNotes
Working Notes on NuVoc review
/* Cool Links -- NuVocWorkList ; ControlNuVoc ; NuVoc ; Vocabulary/TestYourJ ; Vocabulary/Words ; Vocabulary/Nouns ; Vocabulary/Verbs ; Vocabulary/Modifiers ; Vocabulary/ErrorMessages ; Vocabulary/BackusNaurFormOfJterms ; Vocabulary/GuidelinesForEditingNuVoc ; Vocabulary/AncillaryPages ; Vocabulary/PrimitivePaste ; Glossary ; Vocabulary/Glossary ; Vocabulary/AbsolutelyEssentialTerms ; Vocabulary/SpecialCombinations ; Vocabulary/AboutNuVoc2 ;
- /
Carrying on drafting a new page on Verb Rank: User:Ian Clark/VerbRank - paraphrasing http://www.jsoftware.com/help/jforc/loopless_code_i_verbs_have_r.htm
- Will do another such page for Vocabulary/FramingFill
- Will have only limited time to spend on this during November. Backlog of maintenance of several websites to catch up on.
- But must keep my eye in. Once I've babytalked your existing material, I'll have a better handle on how NuVoc can best package verb rank for presentation.
-- Ian Clark <<DateTime(2014-11-05T00:40:03Z)>>
Sorry haven't made much progress with rewriting. Heavy publishing job to complete. Hope to get time to devote to this after end October. -- Ian Clark <<DateTime(2014-10-24T01:28:14Z)>>
PE67: the trick is to replace the bottom 2 rows with a single row that indicates, for each atom in the row, the maximum value that can be added by choosing that atom.
Thus, if the last 2 rows are
4 6 2 9 5 2 11 3 1
we would replace it with
9 17 13 12
because if we get to the first atom of the first row (4) we can amass a total of 9 by choosing the 5 from the next row; and if we get to the 6, we can amass 17 by choosing the 11, and so on.
The way to combine the two rows is
combinerows =: + 2&(>./\)
The 2&(>./\) chooses the larger of each consecutive pair:
2&(>./\) 5 2 11 3 1 5 11 11 3
so in our example rows we have
4 6 2 9 combinerows 5 2 11 3 1 9 17 13 12
Now to show how item thinking beats axis thinking: for an entire pyramid of values, all we have to do is repeatedly apply this trick to successive items. Start with the example pyramid from PE67, which in J will be a list of boxes, one box per row (because the rows have different lengths):
pyramid =: 3;7 4;2 4 6;8 5 9 3 ,. pyramid +-------+ |3 | +-------+ |7 4 | +-------+ |2 4 6 | +-------+ |8 5 9 3| +-------+
and
combinerows&.>/ pyramid +--+ |23| +--+
Voila!
-- Henry Rich <<DateTime(2014-10-19T17:23:15Z)>>
With several days away from any form of electronics, my mind has had a chance to defrost.
A solid concept of Verb Rank is at the heart of J competence, and a helpful presentation of the same is at the heart of the (revised) NuVoc. But I think it is less a question of epiphany than choosing an efficient presentation of key concepts.
I'm going to go back to the original plan: rephrase http://www.jsoftware.com/help/jforc/loopless_code_i_verbs_have_r.htm in my own words. Ditto Vocabulary/Agreement. Then it will become clearer to me exactly where the "difficulty" of this topic resides.
Just one thing. Vocabulary/Agreement rests heavily upon the notion of "macrocell". Apart from this WorkingNotes page, "macrocell" occurs nowhere else in jwiki and is used only in Vocabulary/Agreement, where it is introduced without definition. Is it a key concept, or an unnecessary mystification?
-- Ian Clark <<DateTime(2014-10-12T22:04:56Z)>>
Macrocell per se is not a key concept. But some such idea is needed to explain dyad matching.
I made up the term (which I didn't use in JfC) partially as a wake-up to the user that there is an additional level of matching going on for dyads above what you need for monads.
I have no attachment at all to the word, and if you want to change it do; or if you have a different way to approach the topic and want me to rewrite Agreement with that approach, say so.
A way to start might be to ask: why does
0 1 2 + i. 2 3 |length error | 0 1 2 +i.2 3
fail?
-- Henry Rich <<DateTime(2014-10-12T23:00:07Z)>>
I think J programmers can be classified into those that have overcome a serious misunderstanding about rank, and those who will do so in the future. If you have recently had an epiphany, that's good, maybe you can transmit the dazed understanding to the reader.
Total understanding of the rank system is shown when you start thinking that rank as it is is OK, but what I really want is a way to say which axes are taken as part of the cell, leaving the others to form the frame - sort of a combination of transpose and rank. I suspect it was just too hard to spec and implement that, considering how little it gains.
-- Henry Rich <<DateTime(2014-10-08T01:57:39Z)>>
Okay, I think I'm getting a feel for how the whole topic of verb rank should be handled in NuVoc. But I shall have to draft it out before I can decide whether it will work or not.
You asked a while back if I wanted a single JTalk page on verb rank. I think: no. I'd rather have a collection of pages which hangs together well, and can be invoked from the primitives-pages to address specific questions (which is, after all, the purpose of a JTalk page), but each of which can be read as a self-contained topic with a limited learning objective.
The big problem with that is how to split Verb Rank up into self-contained topics. Is it even possible to do so? I think it is, and I think I'm beginning to see how.
There's an analogy with trying to teach Gravity at K12 level. It wouldn't work to thrust Einstein's General Theory down the kids' throats up-front, when Newton's Laws will satisfy their needs and aspirations for a good long while, maybe forever for most people. On the other hand it would be nice to give pupils a firm grounding in Newton's Laws without the distraction of complications, yet not conceal the existence of a more general theory, or put obstacles in the way of a wider understanding. But it's good to recognize that a wider understanding is to be achieved when, and only when, the pupil can appreciate the need for it.
Of course, my own understanding of Verb Rank may be defective, which disqualifies me from even thinking about how to present the topic coherently yet simply. But I think I'm past that stage, and can at last appreciate the merits (and demerits) of others' prior attempts to document the topic. Including my own earlier efforts, e.g. Vocabulary/EZRank.
I must admit though that until fairly recently my grasp of verb rank was distinctly crippled, and I have yourself to thank for making me properly aware of it. In particular APL's axis notation, as in +/[1]y did indeed "put obstacles in the way of a wider understanding". So too did Excel, with its naive approach to summing rows and columns. The former may be an impediment restricted to myself and a mere handful of others who have come to J via APL. The latter though might be shared more widely. But I have to get myself back into thinking like a novice -- or more correctly several novices coming from different backgrounds -- in order to recognize and circumvent the more frequently encountered obstacles to understanding.
I have a family funeral to attend at the other end of the country, so it won't be till next weekend, now, that I'll get a chance to crystallize my insights (...if that's what they are). -- Ian Clark <<DateTime(2014-10-05T07:17:18Z)>>
I look forward to seeing what you have in mind.
When you are trying to explain why cells are better than axes, look at
https://projecteuler.net/problem=18
This is an short but impressive application for u/ where you replace the bottom two rows of the table with a single row that represents them both, and just munch your way back to the top of the table to get the single distance. The same program solves the similar PE problem 67.
I can't see how to view solutions. The site doesn't seem set-up to extend that courtesy, just to show-off, a-la Fermat. So I'm none the wiser. -- Ian Clark <<DateTime(2014-10-12T22:36:34Z)>>
-- Henry Rich <<DateTime(2014-10-05T14:10:41Z)>>
Further thoughts on item verbs:
Some of the J verbs are computational: they perform well-known mathematical operations. These verbs have the rank appropriate to their function, so that the extension mechanism can do its work. Thus, + - * %, which operate on numbers, have rank 0, while #. #: have rank 1 and the matrix operations %. and monad +/ . * have rank 2.
The other verbs perform an operation on an entire array. The operation may be informational, as in monad # $ L., structural as in the ,-family or monad #, or ordinal as in the i.-family and /: \:. Informational verbs barely look at the values in the arguments, but the structural and ordinal verbs really have to be item verbs.
Modifiers that subdivide the arguments have a similar taxonomy. When the rank of the cell to be operated on is known, you get u"n. When the shape of the subarray is known, you get u;.0 3. These are analogous to computational verbs. Partitioning and interval modifiers / \ /. \. ;.1 2 are like ordinal verbs and work on items or collections of items. L: S: don't quite fit. I. monad and dyad is anomalous in that it relies on a partial ordering of its argument and thus must have rank 1.
I think the root of your unease about +/ and +/"1 may be that +/ y is an illusion. It appears to be adding columns of y, but it's not. A J programmer quickly internalizes the 2 steps: + between items; extension to add corresponding atoms. It's a big step for a novice to catch both ideas at once.
--That's exactly my problem with +/. And, by extension, all item verbs. Summing rows and/or columns is a familiar task to just about everyone, if only from accountancy and spreadsheets... and J's treatment of the whole business is quirky, to put it kindly. It's as if, in offering an easy solution to a hard conceptual problem, well beyond what most people have even guessed the need for, the originators of J have tricked themselves into offering a conceptually hard solution to a very common and easy task. -- Ian Clark <<DateTime(2014-10-01T14:17:16Z)>>
Perhaps we should have a page "The Illusion of +/ y"? That would catch someone's attention and make them attentive to what's really going on.
--yes, something like that. It's not as if there's an intrinsic problem in trying to explain the mechanismS (plural) involved. It's a question of implied attitude, e.g. as conveyed in using a word like "illusion" in the first place. Here we are, trying to offer a rational, objective explanation of J's behavior: it's presumably not our intention to damn the language in the minds of 90% of our novice readership at the outset, for all time. Yet I can't see how to do it honestly without the implied message: "you won't understand this at first. And may never do so. Nor ever appreciate the reason for doing things this way. But here's how the originators of J, in their effable, ineffable, effanifeffable wisdom, saw fit to specify how to sum across and down a table, as part of a grand scheme of things that handles simply everything you'll ever imagine wanting to do with arrays - and a bit more besides." -- Ian Clark <<DateTime(2014-10-01T14:17:16Z)>>
Are you thinking APL, where (as I understand it) you could say +/[1] to say which axis to operate on? The point to make there is that it isn't meaningful to next axis operators - having +/[2][1] - is it? But it makes sense with rank.
Most of our users will be coming from scalar languages. They are used to
for(i=0;i<width;++i) { // for each column
for(j=0, total[i]=0;j<height;++j)total[i] += array[j][i]; // for each number in column
}
all we are asking is that they replace that with
for(i=0;i<width;++i)total[i] = 0;
for(j=0;j<height;++j) { // for each row
for(i=0;i<width;++i)total[i] += array[j][i]; // for each number in row
}
I think they can accept that if you give them a good reason. The reason comes when you are doing something more complicated than + . When the verb doesn't have rank 0 - say, each row is a permutation and you are trying to combine all the permutations (the verb would be {/) - the very notion of 'column operation' is meaningless. But applying u between items is still reasonable.
This is all saying what you said above, but without the apology. The line of argument is:
- +/ adds along columns of a table, or more generally along the first axis
- +/"n adds along axis r-n where r is the rank of y
- this simple interpretation works because the rank of + is 0, so that looping among atoms of a cell produces the desired result
- rank is better than axis:
- when u has rank other than 0, u/ is still meaningful, but it doesn't refer to columns any more
- nested rank makes sense where nested axis might not
-- Henry Rich <<DateTime(2014-10-01T18:12:28Z)>>
Another take:
When you add up the elements of an array, you have to loop along each axis so that you visit each atom. Some of these loops are for bookkeeping, some are for computation.
With the axis method ("add along columns"), only one axis is computational, the rest are bookkeeping.
With the cell method (+/"1), axes before the operand cell are bookkeeping, while axes in the cell are computational.
The cell method is more flexible, because in keeping more axes computational we make it possible to do things in a cell that require more than one axis.
The downside is that it is less intuitive in the simple examples using +. But really, that's a small price. -- Henry Rich <<DateTime(2014-10-01T18:19:15Z)>>
I'll wait to see your next thoughts. I have one last thing to add to dissect (boxing level) and then I can finish all the modifiers - and I now see how to do boxing level.
I don't share your concern about item verbs. Think about it this way: if you were going to implement, say, Sort (/:~) at infinite rank, what would it sort? Atoms?
Really, there is no choice but to have the verb work on items. And, once you see how to make item-verbs interact with rank, you come to realize that it's a fine choice. So I think the key is to make the user sees the reasonableness (nay, the necessity) of item verbs, and how the item-verb concept interacts with rank. Then you have explained the whole host of item verbs.
dyads , ,. ,: and monad ; are quasi-item-verbs. They are discussed as such (I think under dyad ,) but you might want to link that discussion into your new one.
The thread: "Predicting the shape of the result" was about dyad u/ which works on cells of x and is always going to confuse people because it's not an item verb. But that reader was stymied far before he got to that subtlety.
I guess you're thinking we'll link everything that has a whiff of rank to it to your new VerbRank page when it's done?
-- Henry Rich <<DateTime(2014-09-25T22:04:53Z)>>
Yes, all your tweaks are good ones.
- I've made the change(s) Rank --> Verb Rank. Need to do it pronto before I/we start linking this page from the primitives-pages.
- The page is now called Vocabulary/VerbRank
- Linked as such from NuVoc
- You missed a few "pidgeons" -- I've shot them for you. :-) -- Ian Clark <<DateTime(2014-09-25T08:23:22Z)>>
I forgot all about Vocabulary/Agreement !!!
- Yes it needs seamlessly reconciling (& x-reffing]] with Vocabulary/VerbRank. Maybe also with Vocabulary/Verbs#Verb_Rank. -- Ian Clark <<DateTime(2014-09-25T08:23:22Z)>>
I wavered momentarily on AtomsAreArrays -- and thought I'd seize the bull by the horns. But you've convinced me we must stand firm on this. Failure to do so will not help the beginner -- far from it.
Reading your comments has given me a few thoughts of my own, too woolly as yet even to write down. But vital to get right.
I must confess to consternation at the extent of the "Item Verbs" problem. I'm in a state of despair at ever presenting a clear consistent view of it to a beginner. I predicted below:
" I think a beginner could read and digest Vocabulary/Rank and still find the behavior of +/ and +/"1 puzzling."
and it's exactly what I see in the forum today. See the thread: "Predicting the shape of the result".
I need to get my own thoughts straight on this matter, let alone straight enough to be able to present it to a beginner. -- Ian Clark <<DateTime(2014-09-25T08:43:23Z)>>
Just looked at Vocabulary/Rank. Magnificent. I think that it will need a short-form, much as we ended up needing for : .
I made a few tweaks, and did not make the following changes which I want us to think over:
- The page is titled Rank. Either that should change to VerbRank, or you should discuss noun rank as well.
- You omit the replication of cells within macrocells as described in Vocabulary/Agreement. Either mention it or refer the whole discussion of dyads to Agreement.
- I think AtomAsArrays is not necessary even in this page and I would like to stand firm on that distinction in terminology. Use 'noun' when you need 'atom or array' - I think that will be surprisingly seldom.
Bravo!
-- Henry Rich <<DateTime(2014-09-23T16:59:03Z)>>
Many topics...
I like the idea of side-by-side loop/nonloop code. I don't like using J control words, though, because it means you're going to use J syntax for indexing, which will put users off. How about taking Java as a lingua franca and show Java vs J for the different kinds of loops?
<!> I take the point about how nasty the indexing apparatus looks in an explicit verb body.
- But I gag at Java as a "lingua franca". I don't even know Java myself. IMO there is no such lingua franca these days
- formerly you could get away with examples in Basic - or even Fortran!
- Knuth invented his own. (So did KEI--but that's a buried story.)
- Python is making a bid to be the lingua franca among UK schoolkids -- at least in the raspberry Pi world.)
- Giving loop-examples in J itself does at least avoid the lingua franca issue.
- Not to say furnishing examples that the reader can immediately execute, without going scratching for an alien compiler.
- And anyway, do we want to make explicit programming in J look attractive?
* --I dunno. I just can't see my way forward in all this.
-- Ian Clark <<DateTime(2014-09-25T09:05:05Z)>>
I think that has great potential, because the experienced scalar programmer will take in the loop at a glance and will then easily see the compression that the J primitives provide.
Item verbs are legion. The i. family is all item verbs. dyad , operates on items, as do /:, \:, dyad #, monad |., monad {. }. {: }:, and the simple form of dyad {. and }. .
It might well be worthwhile to introduce the item verb concept and link all those verbs to it. I will volunteer to do the linking and the Glossary if you decide to include the discussion.
<!> At this stage it looks unavoidable to me. But hold-off for now, until I can think the problem thru. -- Ian Clark <<DateTime(2014-09-25T08:53:03Z)>>
It is a key unstated requirement of the implementation of the interpreter that every verb have a defined nonnegative rank. This is needed so that the interpreter can do its integrated rank support efficiently. It leads to interesting specimens:
a =: undefname a b. 0 _ _ _ undefname =: + a b. 0 _ _ _ a f. b. 0 0 0 0
A side effect is that u"_1 is really equivalent to u"_1"_, as you discovered. I think I mention this in the details of ". -- Henry Rich <<DateTime(2014-09-23T14:46:57Z)>>
...uhhhh... (And I was just thinking of slipping in a para on the significance of negative rank!) -- Ian Clark <<DateTime(2014-09-25T08:53:03Z)>>
I've finished (a first draft of) Vocabulary/Rank.
IMO the treatment is self-contained and complete, basically following Chris's approach in Essays/Rank.
However, there's a problem. It omits an explanation of summing rows versus columns of a matrix.
I think a beginner could read and digest Vocabulary/Rank and still find the behavior of +/ and +/"1 puzzling.
My aim at present is to write another JTalk dealing just with this problem, referring back to Vocabulary/Rank.
It will be based on my discarded draft Trash/Vocabulary/Rank.
Chris in Essays/Rank introduces the novel (to me) concept of Item Verbs
i.e. verbs working basically on items, considered as _1-cells. Example: +/ Yet (+/) b.0 does not return (_1 _1 _1) -- it returns (_ _ _).
He says J defines many verbs, such as +/ , to apply to the items (or _1 cells) of an array, which are the subarrays consisting of all axes but the first, for example the rows of a matrix.
--> "many such verbs"??
- Offhand I can only think of +/ -- plus other verbs created by (/).
- Could you hazard a guess at all such item verbs -- at least, covering those derived from (modified) primitives?
- How do you recognize an item verb? Surely not from its verb rank?
- How would you go about writing an explicit item verb, which doesn't simply cover an item verb primitive?
I'd like to avoid the concept of "Item verbs" in NuVoc. But it does at least explain +/ . -- Ian Clark <<DateTime(2014-09-23T01:20:37Z)>>
I've not forgotten about your JfC chapter you pointed me at: [1]
I like it, for its taxonomy of looping constructs. This would definitely grace NuVoc. But I don't envision it belonging inside Vocabulary/Rank -- although there's an overlap of course.
I have a comparable "looping taxonomy" in mind, based on Control Words, especially for. while. whilst.
I'd like to see pairs of equivalent explicit and tacit verbs exhibited side-by-side (with comparative timings). So if you can see your way to writing a for.-loop, you can use the equivalence to migrate your loop to a rank-based construct. How does that approach strike you? -- Ian Clark <<DateTime(2014-09-23T01:39:56Z)>>
Another JTalk page: Tacit Programming For Beginners
- What are tacit programs?
- What programs should be made tacit?
- Are tacit programs faster?
- Using compounds to make baby steps toward tacit coding
- Tacit and functional programming compared
- Hybrid programming: good design + tasteful tacitry
-- Henry Rich <<DateTime(2014-09-19T01:24:32Z)>>
Sounds a good idea. -- Ian Clark <<DateTime(2014-09-21T20:22:11Z)>>
I think there's several separate JTalks in this. -- Ian Clark <<DateTime(2014-09-23T01:39:56Z)>>
With much trepidation, I'm making a bold start to a JTalk offering a "definitive" treatment of Rank. See Vocabulary/Rank.
My approach will be to put things in the simplest, most naive way I can think of. Show why, where and how this isn't good enough. Then progressively refine. It'll need several bites of the cherry. Otherwise I risk dumping on the reader a set of tablets of stone, without giving them any clear idea how to apply the concept of Rank to anything real. -- Ian Clark <<DateTime(2014-09-17T14:00:35Z)>>
I like the pace and the content. It feels like it will work. I would put the MATLAB/APL business in a sidebar or in smaller letters, as I think few of our target audience would know those.
Also: distinguish noun rank from verb rank. The two words mean quite different things. Noun rank is easy; verb rank is hard.
I will leave it to you whether introducing the term cell would help or hurt. -- Henry Rich <<DateTime(2014-09-17T22:27:49Z)>>
After studying Chris's treatment in Essays/Rank I'm going to trash my current draft of Vocabulary/Rank and start again. -- Ian Clark <<DateTime(2014-09-21T20:21:03Z)>>
Also look at Vocabulary/Agreement and Vocabulary/FramingFill, which cover the back part of the process, and agreement for dyads. The new discussion should at least be compatible with using those pages for reference. There is a variance of terminology between Chris's assembly and my collection which can be resolved either way for all I care, but I used the word "collection" everywhere else in NuVoc. I think what is needed in Vocabulary/Rank is motivation for why verb rank? and examples of how to think in terms of rank rather than loops, with pointers to the other pages that show the details. -- Henry Rich <<DateTime(2014-09-21T20:55:02Z)>>
Something else for you to think about: the perennial question of how do you write a tacit verb that refers to the current value of a noun, or of the result of some system function.
I would say that was impossible, or maybe meaningless the way you've expressed it... A noun is always a value, so its "current value" is itself, for all time. I guess you mean "pronoun" or "name". Then the only way to refer to its value within a tacit verb is to write a string (=a noun) into the verb expression which spells out the pronoun, then use some verb that returns the value of a pronoun given as a string, like (".) or ((5!:5)@<)
mynoun=: 8 foo=: ". bind 'mynoun' fo=: ((5!:5)@<) bind 'mynoun'
...which I'd call "binding by name" as opposed to "binding by value". -- Ian Clark <<DateTime(2014-09-12T15:35:50Z)>>
And as for the system function...
tt=: (6!:0) bind 'hh:mm:ss' tt'' 16:42:57 tt'' 16:43:04
-- Ian Clark <<DateTime(2014-09-12T15:45:53Z)>>
Yes, that's how you do it, what I meant was how do we document this for newbies. The question comes up when users start writing tacit code, and I think we need a place where we can anticipate such questions. -- Henry Rich <<DateTime(2014-09-12T17:36:02Z)>>
<!> It's a puzzle. It would be so easy to bury this away in a JTalk such as Vocabulary/Nouns, the placement being perfectly obvious to an expert but not at all clear to a beginner. How about a new JTalk: Vocabulary/Variables which, although an "alien" topic in J thinking, explains how J supports (or doesn't support) the notion of a "variable" in C, Fortran, Basic, etc.? There'd be two prongs to the treatment:
- How to carry over an unregenerate notion of Variable into J, especially tacit J
- How J's functional programming does away with the need for variables in most situations, leaving only a residue of "control flags" and "parameters", mostly relevant to released utilities, with names like TRACE, DEBUG or TIMEFORMAT.
Looking at other Wikis, which use the form in the way it's intended, I see a lot more pages that are more like paragraphs on narrow topics, rather than the monographs that we tend to go for. As a result the links are easier to deploy, more wiki-like and less cumbersome. E.g.
- see EmptyArrays
-rather than
...We deprecate newcomers' attempts to misuse J like C, yet it seems to me we misuse the wiki form as if it's a vehicle for a traditional textbook.
- Part of the problem is that Chris has made it clear he doesn't like a flat wiki because he deems it hard to maintain, and much prefers walled-gardens, each in its own folder.
-- Ian Clark <<DateTime(2014-09-15T11:23:28Z)>>
I like the idea of Vocabulary/Variables. It's a page a user might reasonably guess is worth reading.
I think variables still have their place. Explicit programming is still almost functional. The rank concept is what does away with temporary variables; if you design your functions well, the fact that the implementation of each one uses named variables is a very smal point compared with the ease of connecting the functions together.
And then there's OOP in J, which uses class and instance variables in much the same way as any other language.
-- Henry Rich <<DateTime(2014-09-15T23:36:33Z)>>
<!> My first attempt at Vocabulary/Variables is hopeless. I'll have to think some more about it. The approach looks theological, not practical. Probably best to get straight to the point, with some examples. Thanks for reminding me about OOP. "Variables" in the form of "state variables" needs to be supported in J just for OOP compliance. Even if you call them "attributes". Yes, Vocabulary/Variables will be the best place for a treatment of OOP "attributes". Good idea perhaps to write our J-and-OOP jTalk first? -- Ian Clark <<DateTime(2014-09-17T12:55:01Z)>>
Example:
v =: mynoun + ]
uses the value of 'mynoun' at definition time, not execution time. You need
v =: 3 : 'mynoun + y' NB. best
or
v =: (+ ".)&'mynoun' NB. If you have fallen in love with tacit code
I think this is a chapter in the discussion of Parsing In J. Other topics would include right-to-left execution; long left reach of modifiers; passing verbs by name, other things by value; the parsing table; unusual situations requiring parentheses; user-written modifiers; f. tricks.
-- Henry Rich <<DateTime(2014-09-01T01:47:28Z)>>
Frightfully snowed-under and not able to attend to much. That was before I put my bzck out.
Writing this lying on my back, on an unfriendly laptop. Will think about a "proper" JTalk on verb rank. Nothing is going to happen for a week or so, I'm afraid. -- Ian Clark <<DateTime(2014-08-29T23:20:27Z)>>
Even if you were upright, a good long think would be the thing to do. What seems to be difficult about verb rank is convincing a novice that it is worth taking the time to understand.
So much is new in J, and so much seems to be done automatically (like 2 + 3 4 5 or 1 2 3 + 4 5 6), that the beginner is oblivious to what is actually happening. Then they seem to get by with a skeletal understanding, until +/@* comes along and they're buffaloed. In the meantime they have developed a flawed model of rank and it has to be torn down and replaced with the right one. The sorry mess results from Ken's "learn by trial and error" methods. I have seen it happen many times.
I guess that sums up my personal experience of learning J...! I wonder if, even now, I'm mentally equipped to write an exposition of rank that puts it at the center of a mature understanding of J. The trouble is -- for me and I suspect for others -- a lack of ambition in the sorts of programs I have wanted to write. I've used APL a lot in my working career, but never felt much need for either function composition or for arrays of rank larger than 2. The programs I still write in J are scarcely more advanced than those I used to write in APL, which I felt was ample for my needs. It's like owning an aeroplane and only ever having had the ambition to taxi round the airfield. -- Ian Clark <<DateTime(2014-09-12T14:35:11Z)>>
How to motivate the beginner to learn rank, and then to teach the topic interestingly so as to keep the motivation up, is the challenge.
We wish you a speedy recovery! -- Henry Rich <<DateTime(2014-08-30T14:48:23Z)>>
Thanks. Much better now, and up-and-about. But I still can't sit for long at the computer -- a severe curb on my creative endeavors, and thus my capacity to contribute sognificantly to NuVoc. -- Ian Clark <<DateTime(2014-09-12T14:38:53Z)>>
I should add: walking around class I see lots of students referring to NuVoc pages. They never did that with the Dictionary. -- Henry Rich <<DateTime(2014-08-30T15:14:05Z)>>
That's very encouraging! -- Ian Clark <<DateTime(2014-09-12T14:35:11Z)>>
I went ahead and moved my summary to the top of the Locales page. Please feel free to revert, move, or edit as you think right. -- Henry Rich <<DateTime(2014-08-28T00:40:13Z)>>
I have added some talk about many of the items discussed below. I have marked as (Done) below what I have added. -- Henry Rich <<DateTime(2014-08-27T16:53:26Z)>>
The JTalk page on agreement discusses the parts of dyadic rank that differ from monadic. What we need now is a good introduction to the whole rank concept.
-- Henry Rich <<DateTime(2014-08-27T01:54:26Z)>>
I have gone through Locales checking accuracy, and added a table of co*** verbs.
-- Henry Rich <<DateTime(2014-08-26T18:19:04Z)>>
I am at the point in class where I assign the kids to read about verb rank. In the past, I have had them read the chapter from JfC, to wit http://www.jsoftware.com/help/jforc/loopless_code_i_verbs_have_r.htm#_Toc191734331 . I think we never created a tutorial with that information! When I look at NuVoc, I see a good bit of documentation about verb rank, but it all seems to point somewhere else for the full explanation, ending up at my page above, which I think is still the best exposition (and the part of JfC that I'm proudest of). So I had to assign that again.
I think for completeness we ought to get this into NuVoc, minus the C orientation. I also think the organization of the JfC page is sound even for NuVoc, because here we're not trying to reach the hurried coder - we're teaching a difficult new concept. Whoever hopes to use this has to mark, learn, and inwardly digest. We can take a slower pace in our discussion, guiding them through the necessary experiments.
May I ask that you take this on? Treat my JfC chapter as the raw version.
I am putting all my free time into Dissect, which I think is the best thing I can do to advance the usability of J. It has proven its worth in class already, as I can put up graphical examples of what the primitives are doing, and the kids can experiment on their own.
-- Henry Rich <<DateTime(2014-08-25T23:34:51Z)>>
Right, I've finished my rewrite of Vocabulary/Locales. Phew! That was difficult!
I've tried to replace explanations which initially baffled me with actual worked examples. -- Ian Clark <<DateTime(2014-08-22T20:05:17Z)>>
Bravo! That's so much better. I will read it again at leisure looking for wording tweaks. At the top level,
- I think the page needs to be split. Perhaps cleave off the parts that describe instances and object programming?
- We need to discuss object creation and destruction, and the mysterious create_parent_ f. trick.
- (Done) We need to show how to use class-wide nouns (as in name_classname_ in instance code)
- (Done) We need to mention COCREATOR
- (Done) We should note that the search paths allow for complex inheritance (a feature I am getting a lot of mileage out of in Dissect).
- (Done) We should walk the user through just what entrypoint_z_ =: entrypoint_classname_ is doing and why it works.
Well done! -- Henry Rich <<DateTime(2014-08-22T21:42:01Z)>>
Henry -- that's exactly what's on my mind. We need a separate JTalk for the OO mechanism and classes.
- It can't just be treated as a sideshow to an introductory page on locales.
- It needs a very simple worked example, like I've done for addons
- In fact "How to write an addon" would be a big asset. It might even nudge a few longtime J-ers into taking the plunge. I know Chris has documented it, but (as ever) Chris is a programmer not a documenter and doesn't pretend to be. His big plus is that he keeps it terse. I'm thinking of a "monkey-see-monkey-do" (as we used to call it in IBM). OUAT all articles entitled "Getting Started With..." used to be of this nature, but i see that convention has slipped in recent years.
I'd also ask you please to check what I've written about Class Instances.
- When rewriting it, I was conscious I might have been changing the meaning of what you wrote because I was only guessing at what you meant, and don't fully understand what conew does. Thus - does it only create new numbered locales?
- I didn't explore any actual code (except a lookaside at how j602 does IJX/IJS windows.
- What a pity j802 no longer uses a numbered locale for each edit windows. It was a beautiful reference app and helped me to understand J classes. So now any article will have to construct its own KISS reference app.
IMO Vocabulary/Locales still needs
- (nothing to do) a description of the search path structure of J on startup (without a config/startup.ijs), explaining how this gives the z-locale its magical properties.
- (Done) a table of the co*** verbs, the Foreigns they cover, and what to use them for.
-- Ian Clark <<DateTime(2014-08-23T19:23:21Z)>>
I will check everything carefully for accuracy (it may be a day or two).
Yes, conew creates only numbered locales.
There is nothing magical about z locale. By convention it is the last locale in every search path, and when you start, it is the only thing in the search path for base. It is possible to create a locale with an empty search path; execution in that locale will have no global names defined (I use such a locale in Dissect).
I will do the table for the co*** verbs.
I am thinking also to start the locales page with a short summary of what follows, since the discussion has become rather long. What I have in mind is something like
Summary of the Locale Mechanism
- A locale is a public namespace. A locale is created whenever you create or refer to a name in the space.
- At all times there is an implied locale that gives the namespace to use by default.
- A locative is a name that specifies the namespace to use instead of the implied locale.
- name_locale_ means "name in the namespace locale".
- name__instance means "name in the namespace given by the value of instance".
- Each locale has an associated search path, a modifiable list of locales. By convention every search path ends with the locale z.
- References to names begin the search in a starting locale which is the implied locale unless a locative overrides it. If the name is not found in the starting locale, lookup continues with the locales in its search path until the name is found.
- Public assignments are always made in the starting locale.
- When a locative is executed (example: names_z_ ''), the implied locale is changed to the locale given in the locative, and changed back after execution.
- An instance of a class named newclass is created by a line like
instancename =: (creation_parameters) conew 'newclass'
which creates an instance locale, executes the create verb in the instance, and returns the locale name of the instance.
I am looking for something to help the user who has seen this before, or perhaps is trying to understand some existing code without having to learn everything. Think about where this summary should go.
-- Henry Rich <<DateTime(2014-08-23T21:54:31Z)>>
I have put deprecations into Vocabulary/curlyrtu, and pointed to them in Details of Vocabulary/curlyrt, referring to them as obsolete forms. I think no more is needed. -- Henry Rich <<DateTime(2014-08-18T14:52:08Z)>>
Fine. (I've made slight adjustments and added a link the other way.) -- Ian Clark <<DateTime(2014-08-21T22:53:54Z)>>
I don't understand this assertion in Vocabulary/Locales
- simplename__objname[s] - the name contains two underscores in a row, creating an object locative: the double-underscore is followed by one or more names of nouns whose values give the starting locale. Each value must be a boxed string.
What does a locative look like which is followed by more than one names of nouns (whose values give the starting locale) ??
- How are the names separated?
- I think an example would be good here,
-- Ian Clark <<DateTime(2014-08-10T18:19:19Z)>>
I've taken a start at this. I seem to have forgotten how to write. You'll have to touch it up. -- Henry Rich <<DateTime(2014-08-11T17:36:59Z)>>
I think I've "touched it up" good and proper now. Manhandled it maybe. -- Ian Clark <<DateTime(2014-08-23T19:17:33Z)>>
Here's a copy of my private To-Do list.
It's undigested -- I'm not sure what some of them mean. Or if they're still relevant. -- Ian Clark <<DateTime(2014-08-09T03:25:11Z)>>
Our own JTalk page for Control Words?? with sample loops plus exact tacit (^:) equivalents. -- Ian Clark <<DateTime(2014-08-10T18:03:20Z)>>
Vocabulary/JayTaster --is mentioned upfront in HowNuVoc. so it's a priority to complete. Else remove reference from HowNuVoc
Single reference-app to supply code samples?
Check all Ancillary Pages are (tagged and) referenced in NuVoc where appropriate. Check like-pages for orphans
The 6 parts of speech:
Noun, Verb, Modifier, Copula, Punctuation, Control Word. ensure this list is the same thoughout.
I seem to have obliterated all definition hiliting. ...we agreed to it. Put it back??
Also need rationalizing: semidot* suite
TOC --needed now, for many pages especially some modifiers with extensive "More Information". Try various ways of making a custom TOC
hook fork @: -- need rewriting for greater clarity @: needs simpler example up-front of u and v candidates: - |. |."1 >:
Vocabulary/grave -- needs rewriting. Wrong use of "Common uses".
Rewrite rdot to use a less boring plot, e.g. for 30-degree angle? provided the plot will behave.
Example 4 in fdot is too heavy.
/Nouns A noun is either an atom or an array. ---QUALIFY may need a new JTalk on zero rank arrays Suggest: Are scalars really different from vectors?
>>> Work on Glossary !!! See: >NuVoc-- Glossary revamp
HowNuVoc needs notes on how to use Glossary, AET
More task-based, e.g.
- I have an unexpected error message
- What does this primitive mean/do?
- I'm having difficulty getting this technique to work
- Is there a better way to do this?...
Inconsistent terminology in:
http://www.jsoftware.com/jwiki/Vocabulary/Nouns#Type
Rewrite Box and Open <<<<<< (the dyadic cases have been done.)
Revise /eq --explanation too bulky & forbidding.
Extend NuVoc portal /* rank */ Comments to point into RankInfo
I've created a new stub page: Vocabulary/curlyrtu (u}).
You may need to rename the primitive (i.e. this u} usage). Also it'll need a link, maybe in a wiki note, to get the reader curlyrt <--> curlyrtu if she lands on the wrong page.
I was going to say: like Vocabulary/tilde and Vocabulary/tildem -- but I see they don't actually link to each other (IMO they should).
We've done this sort of crosslinking elsewhere (I can't for the moment remember where) and we ought to be consistent.
-- Ian Clark <<DateTime(2014-08-09T03:21:37Z)>>
I reckon I am ready to announce.
- Which is a good thing, because essential family business calls me away tomorrow at short notice. So I've either met my Wednesday deadline, or I can't.
- I shall be back on Wednesday, and I shall announce it all then.
I still have a long list of improvements and things I'd like to change, but no glaring omissions (I trust). A "customer" would have to browse NuVoc in-depth to discover items on my list. But in doing so would of course come up with a long list of her own. So although I don't start with an empty bug-list, it will only get longer anyway.
You made the following suggestion: "I think the minimum needed for an announcement is: 1. hyperlinks 2. friendlier arrangement of JTalk in NuVoc portal 3. roadmap for reading JTalk and using NuVoc"
1. Most pages are hyperlinked to Glossary and AET. I would have said all pages, but I see some have slipped the net -- or perhaps it's just that more words could usefully be linked. Mostly these are @: @ & &: --which I left till last. Plus some ancillary pages. These I can backfill at odd moments.
2. By "JTalk" I guess you mean what I'm calling Ancillary Pages. These are now in better muster, accessible via NuVoc#bottomrefs.
3. New page Vocabulary/HowNuVoc gives an overview on how to make best use of NuVoc, aimed separately at "novices", "beginners" and "journeymen".
-- Ian Clark <<DateTime(2014-06-22T15:00:54Z)>>
I've made a new diagram to serve all 4 of At (@:), Atop (@), Compose (&) and Appose (&:).
This shows a side-by-side comparison, as you suggested. Most revealing, I think.
I can't see how to include hook and fork in this diagram. In fact I can't see how to replace your character-graphics figures in hook and fork just yet, so I'll let them stand.
-- Ian Clark <<DateTime(2014-06-22T08:47:55Z)>>
New essay Vocabulary/NumericPrecisions. Something like this almost wants me to agree with you the J is implementation-defined, but I prefer to see it as following some commonsense rules, implied (but of course not made explicit) by Ye Dic, and with a number of bugs mixed in.
-- That looks a significant masterclass. I anticipate learning a lot from it myself. Maybe these ancillary pages need a graphic to grade them: Beginner, Intermediate, Advanced? -- Ian Clark <<DateTime(2014-05-29T04:35:40Z)>>
lint next, methinks, and that may be all I have time for. -- Henry Rich <<DateTime(2014-05-29T01:01:32Z)>>
My focus now will be on hyperlinking all the CategoryNuVoc pages (underway) and finish hyperlinking the primitives pages. I'll probably not look much at this page much, so if you want me to read anything on it please send me an email. Ditto if you want me to start reading it again.
Do you intend to do anything substantially more at NuVoc before I see Gloria and yourself in July?
When shall we announce it?
-- Ian Clark <<DateTime(2014-05-29T04:23:03Z)>>
I reckon we're on the home stretch now.
- I've deferred spending time on hyperlinking, since IMO this is something I can get on with during June when you're not available for advice.
- I've had a stab at some graphic art in Vocabulary/at. Shall I do the same for other pages?
-- I think so. Your drawings have the slim aspect ratio I couldn't get with ASCII, so you could line @ @: & &: side-by-side for comparison. There are also drawings in Hook and Fork that could be prettied up. -- Henry Rich <<DateTime(2014-05-27T21:19:51Z)>>
- Shall I replace AbsolutelyEssentialTerms with AET now, and redirect the former to the latter?
-- Yes. -- Henry Rich <<DateTime(2014-05-27T21:19:51Z)>>
If you're looking for things to do (though not for long now, I guess), I have a little list of CategoryNuVoc pages we might still do. Any comments?
- file I/O
- probing expressions for intermediate results & symbolic execution
- debugging tools
- IDE's
- date & time
- selected Foreigns (those that aren't obvious from JDic:xmain)
-- I was just thinking that a page on the debugger would be the main thing we need. Unfortunately I don't use the debugger (or any other IDE), because during my formative J years it didn't work on my big programs. Maybe you could get someone who uses it to chip in a page. If not, I'll do it, because I really should be teaching it to my students.
As far as probing expressions: that's actually what I'm going to be working on in silence. I have a tool to give a graphic display of execution of a sentence, allowing the user to see what feeds into what, select cells, etc. I think it's the greatest thing in the world, a feeling shared by no one else, alas. It supports verb executions, hook, fork, @ @: & &. &: &.:, and " right now, and my mission is to add support for all the other modifiers. If I get that working it should, I think, revolutionize learning J.
That leaves Foreigns. A quick guide to foreigns would be useful; I could putter on that.
I might also write a page on lint, my static analyzer, which is really pretty useful (essential in a classroom, because it catches 95% of the silly mistakes novices make, giving me time to do something besides correct syntax errors). -- Henry Rich <<DateTime(2014-05-27T21:19:51Z)>>
-- Ian Clark <<DateTime(2014-05-27T19:27:52Z)>>
FWIW, my bright students who program (there aren't many of them) use Python, so you might be right about that as the competition.
I have made a pass over AET. Somehow it's not the dramatic improvement I was hoping for. It's not... welcoming enough. It doesn't sympathize with the novice and say, "I know this seems weird, but it'll make sense and will be worth the trouble". Over to you.
-- Henry Rich <<DateTime(2014-05-26T10:31:34Z)>>
-- I guess I've not been seeing it as "welcoming" but as "stop-gap". This is remedial stuff, not showcase material.
It's not part of the royal road into J. I wouldn't want to commend it as essential reading for a beginner.
You only enter it if you're ignorant enough to click on a linked word, e.g. "verb", in one of the primitives pages.
To me that means you're really, really lost and floundering around.
Most likely the whole sentence puzzles you and you ask: what precisely does this guy mean by "verb"?
So I reason the most reassuring response would be to explain "verb" with brutal clarity and minimal ambiguity.
No "welcome". No "sympathy". The message is "get with it, man!" Though patiently, not patronizingly.
The result may look "anal" but the only criterion I'd want it judged by is: does it help?
Frankly it's not my style of learning. I'd prefer to induce the meaning of "verb" by seeing how it's used.
Not by intensive study of something so microscopic as a mini-glossary of "essential" terms.
From my pov if you find yourself browsing this material with any degree of interest, you're a J basket-case.
I'm adopting an extreme pov here, but to me it's not front line material, and anyone ending up here is a mark of our failure.
If I were developing this stuff with the resources of a big firm, I'd run experiments to see what sort of a safety-net subjects actually need.
-- Ian Clark <<DateTime(2014-05-26T23:13:42Z)>>
-- Mostly agreed, but: if the clueless user gets to AET, and it's a mark of our failure, we should at least do what we can to get him back on the right course. Maybe if he clicks on 'verb' we should be saying, + and +/ are verbs, as as user-written programs. I don't know.
I'm pretty handicapped about this because my learning style is microscopic (I guess you can tell this from some of the details I have offered). When I was using PL/I back in the day I read the Error Messages manual front to back - more than once - and I think I learned a lot from the experience. This shows me that I should leave coddling the user to your final judgement. -- Henry Rich <<DateTime(2014-05-27T00:38:52Z)>>
IBM San Jose Human Factors was once asked a simple question: when a user is faced with a down-arrow button, does she expect the window to move down (and the text to move up) or the text to move down relative to the window? They answered wrong -- and had to undertake a long and costly study to find out the real situation, which is hilariously bizarre. Working as a HF engineer has taught me there's no substitute for actual experiment. Yes, I see the same old blunders, so I know what to do. But sometimes I don't know the answer any better than anyone else. That's true here. -- Ian Clark <<DateTime(2014-05-27T00:48:40Z)>>
--Yes, I too wrote reams of PL/I in a former life. It was a helluva kludge - a smash-together of COBOL and FORTRAN. The Error Message documentation was your best friend 'cos you only got one shot at the compiler each day. IBM Hursley Product Test had a tool called the Syntax Machine: you fed in the BNF and it generated random code. By this they showed that the language was hopelessly inconsistent. In practice you only got it to work by not trying anything too clever in it.
Heresy to say it, I know -- but that's still largely how I feel about J. There are rules a human can memorize of course: you simply have to think like the interpreter. -- Ian Clark <<DateTime(2014-05-27T01:05:28Z)>>
I want to quibble with one thing: the concept of the valence of a verb (I am looking at "argument" in AET).
A verb may have a monadic definition, or a dyadic, or both, but it is incorrect to say that a verb is a dyad. Verb invocations are monadic or dyadic, and nothing can stop a user from trying to execute your supposed dyad as a monad.
-- This was my attitude originally, when I came to J from APL. Yet I see the terms "monad" and "dyad" being used all over the place. I succumbed to using them, all the while telling myself that "monad" isn't an invariant attribute of a verb, like gender of an animal or plant. A verb is a "monad" if J is going to treat it as a monad in a given context.
AFAIK there is no case where a sentence will behave differently (without signalling an error) if a given verb is defined with monad define or dyad define. (Do you know of one?) So valence (at call time) is decided entirely by sentence syntax -- and monad define and dyad define only serve to determine whether J will honor the invocation or signal an error.
To talk of a "verb" is anyway hopelessly ambiguous unless you make it clear whether you are defining the verb or executing it.
So should we expunge all uses of "monad" and "dyad" in favor of "called monadically / dyadically"?
Throughout I've been talking about "the monad <" and "the dyad <" as two entirely different verbs.
Not the same verb called with or without an x-argument.
All this of course serves to erect a huge entry barrier to novices.
They will quickly get the idea that J is "implementation-defined" - and conforms to no useful user model. -- Ian Clark <<DateTime(2014-05-26T23:59:40Z)>>
-- I think we agree here. You shouldn't say, "x is a monad", which suggests that x is somehow going to ensure that it is called only monadically. Rather, you say "x has only a monadic valence", or "only the monadic form of x is defined". Invocations of verbs are monadic or dyadic, and succeed if the verb is defined for the corresponding valence.
In the primitive pages we hardly use the words "monad" and "dyad". We say x % y or % y. I think that's good.
Modern Java/C++ use overloaded operators extensively. The user will understand that *y and x*y are completely different. Monad * and Dyad * are different verbs, as you say. -- Henry Rich <<DateTime(2014-05-27T00:38:52Z)>>
-- Henry Rich <<DateTime(2014-05-26T01:59:46Z)>>
"Dekko"? I'm going to speak Brit slang like a native if we keep this up long enough.
-- Hindi word, I think, I'm old enough to be using slang from the days Britain had an empire. -- Ian Clark <<DateTime(2014-05-25T22:45:18Z)>>
I like your ArrayProcessing page. It explains (or will, when it's finished) why an OPL programmer needs to learn new ways. At some point they're going to need a manual for how to translate their ideas, which is when they'll use Loopless. I think the two could work together. Based on your comments I will tweak wording and otherwise leave Loopless as is. We can always add to it. If you think of ways to improve it I know you'll hop in.
I think of Idioms as 'things you would never even dream of asking about' - brilliant code sequences, clever inverses. The other pages are answers to questions you know how to ask, collected for easy access. Idioms will always be a grab-bag; it should stay small, though. Perhaps the name should change.
-- Yes I agree there's a place for such a page. Speaking for myself (and other former APLers) "idioms" has the thrust of recommended ways of achieving common tasks. Much more like your Vocabulary/SpecialCombinations. So maybe it does need another name? There used to be a page: Essays/Jems -- Ian Clark <<DateTime(2014-05-27T17:29:25Z)>>
I think the new AET is much improved but still has a ways to go. I think it doesn't do enough to relate the J terms to a novice's context. I also think it spends too much effort being precise (I can hardly believe it's me saying that!), and may need some examples. I will make some of the changes I have in mind to show you what I mean (perhaps not till Tuesday, though).
-- Great. I was hoping you'd have some ideas about it.
- It's mission-critical for novices, so it needs a lot of effort, perhaps tweaking for months in the light of feedback.
- I was only trying to get the format right. It serves us well for ErrorMessages so I reckoned it would work here too. It gives us much more space to explain things properly.
- I didn't change the original wording much. Just shortened the table and moved the original content into its expanded section. I only added to this when it was clear something more was needed. No attempt to make the wording novice-friendly.
- Examples: Yes! OPL-friendly wording: Yes! Such precision unnecessary: Yes! (It uses the Glossary as fallback and all the precision can reside there. More reference needed to the ancillary pages. -- Ian Clark <<DateTime(2014-05-25T22:45:18Z)>>
This brings up a question we should have asked long ago: what programming background do we think our novice has? I reckon we can't assume C/C++, but can we assume Java? Javascript? In other words, some general understanding of the ALGOL family? This would affect the language we use for explanation.
-- I wonder if we aren't of most interest to the scientific fraternity? That would be Pascal (electronics), and Fortran even!
- VB is Microsoft's workhorse language, but who programs Windows computers except business corporations?
- I think of Javascript as mostly of interest to people writing html for web apps, maybe Java too. I don't believe J competes (though with JHS it does mesh)
- The C/C++ fraternity, if memory serves, mostly built clever screen UIs. But Objective C (delivered via Xcode) is Apple's pro language, when it's not building plastic knives & forks for the punters. Again I don't think J competes.
- I think we mostly compete with Python. That's being used as the reference language in education in UK these days (supplanting BBC BASIC), besides being beloved of Google.
- Raspberry Pi Foundation also touts Python as the odd-job language to use. It's certainly the community into which I'd like to introduce J. I'm only an entry-level "pythoneer" myself. Been coding in J to drive a raspi-controlled tank, but the project's had low priority. Need to make it sexier before I can crow about it in MagPi. -- Ian Clark <<DateTime(2014-05-25T22:43:08Z)>>
-- Henry Rich <<DateTime(2014-05-25T21:57:46Z)>>
Just been contemplating your Vocabulary/Loopless. There's much there to ruminate on. So what follows are initial thoughts only.
Firstly you must be one of the few people (a class of one, I suspect) who's seriously attempted this sort of intellectual bridge-building with J.
An essay likes this really graces NuVoc, because it picks up the "Accessible" ball (as in "Accessible Voc/Dic") and runs with it.
- "Accessible" not just by the computer novice, but the mentally crippled old hack who's in thrall to the old "scalar" ways.
- That's a tall order.
- So "fit-for-purpose" is a demanding requirement. Almost anything will be a great advance on what I've seen from anyone else.
I like your tabulated-recipe format, which you seem to have evolved by now to the masterclass level. This alone could make this particular node of the internet the cyber-equivalent of "well-thumbed".
I instantly grasp what you're aiming at, what it needs and how you've approached it. It's how I'd do it, if I'd only just become aware of the issues. Which makes your treatment crystal-clear to my eyes.
- Whether it would be crystal-clear to our putative "old hack" is a different matter. The problem is largely one of attitude (and motivation). You can take a horse to water, but how do you make it drink?
- You may not have the answer here (just yet) but it certainly delineates the questions to ask.
- Now I see how you've approached it, and truly savored the issues involved, I can be the sparrow on the eagle's back.
Without wishing to be patronizing, I'd typify this approach as:
1. Grab horse's bridle. 2. Drag his nose underwater.
I'd like to toy with ideas along different lines at Vocabulary/ArrayProcessing:
1. Make horse painfully aware he's in an arid desert. 2. Show horse the J Oasis on the blue horizon.
I doubt my trial page will go critical any time soon, so I recommend you remove passives and give your approach a final coat of paint prior to shipment.
-- Ian Clark <<DateTime(2014-05-25T18:47:14Z)>>
Take a dekko at what I've done at Vocabulary/AET.
Maybe I'll keep that name AET. So much handier in use. but not retrofit the old one - just redirect.
-- Ian Clark <<DateTime(2014-05-25T16:58:54Z)>>
ASCII art added to & &: . All I have left on my list is a page on Extended Integers/Rationals.
New page Vocabulary/StructuralOperations. An "essay" without text - just a bunch of examples. I wrote down what came to mind. Have a look, and add what you like. If you don't have a good way to do something, just write the English description and I'll have a go at the J version.
-- Nice. I was just going to suggest we needed a CategoryNuVoc page like this.
- Doesn't need any narrative. It links to whatever's needed.
- Yes, I might take up that offer. I'll look thru some of my old code for bozo constructs.
- There's an overlap with Vocabulary/Idioms - but I'm not saying (and don't believe) Vocabulary/StructuralOperations should be merged with it, because the latter has a nice integrity all its own. I'm wondering if "Idioms" isn't one of those born-again pages that litter jwiki, with a too-general provenance. It's not going to be an easy page to ever finish - just a bucket to sling odd thoughts into. But there might be value in a roadmap with that name. -- Ian Clark <<DateTime(2014-05-25T17:14:38Z)>>
Just found: JDic:errors. With friends like this...
-- ha-ha. (That would have got us on a bit...!) -- Ian Clark <<DateTime(2014-05-25T17:00:34Z)>>
1!:40-42 were old foreigns that were replaced by 1!:43-44. 1!:44 should be blocked during security level but isn't. I suspect no one has ever set security level to 1.
You were right about 15!:n . I tried all the foreigns to see which ones were blocked. #security is OK now.
-- Henry Rich <<DateTime(2014-05-24T17:19:14Z)>>
-- I think you might just have denazified security. There may even be a beneficial role for it now in our brave new world. -- Ian Clark <<DateTime(2014-05-25T17:56:01Z)>>
Oh, I didn't realize #security was in my court; I will get on it.
Will also do the ASCII picture of & &:
Yes, AET is hard to pin down. Now that I read your comments, I realize that cell requires verb rank... and I think that is beyond the Absolutely Essential. Noun rank is essential, but not verb rank, and verb rank should be removed from AET. I think. I'll leave it to your ruminations. I think the first step might be to expand the definitions of AET to where they really work for a novice, and then see what more/less is needed. I envision a paragraph for each term, with a snappy opening sentence, like "A sentence corresponds to a statement or line of code in other languages."
-- I agree, and I've "elided" Verb Rank.
- It'll be easy enough to add new terms later. But once they arrive, they'll come to stay.
BTW, EmptyArguments is taken almost verbatim from JfC, but written in IAC style. Aren't you proud of me? It reads so much easier now.
-- Yes, I am impressed! (The para starting "Consider" might benefit for clarity with a simple code example.) -- Ian Clark <<DateTime(2014-05-25T16:58:54Z)>>
There is no question in my mind about the distinction between Dic and Voc. It is visible in the right-hand column of JDic:contents. Voc is the primitive-by-primitive description; Dic is that plus the description of Words and Grammar, which we supply with all the JTalk pages. Thus, Voc=primitive pages, Dic=Voc+JTalk. Perhaps NuDic would be a better name for the whole project, but that ship sailed long ago.
... anyway I think NuDic has the wrong sound to it. ;-) -- Ian Clark <<DateTime(2014-05-25T16:58:54Z)>>
-- Henry Rich <<DateTime(2014-05-24T01:51:45Z)>>
Sorry, been busy today and haven't had time to do much. Will get down to it over the weekend. -- Ian Clark <<DateTime(2014-05-23T23:30:14Z)>>
BTW #security (below) needs attention -- you may have overlooked it. Only small changes needed, but I don't know how to fix it. -- Ian Clark <<DateTime(2014-05-24T00:56:15Z)>>
Look at Vocabulary/at and see if the ASCII art serves, & whether I should make one for & &: .
-- Henry Rich <<DateTime(2014-05-22T22:44:45Z)>>
-- I remember looking at it before and thinking it was fine and clear, although ASCII art might be thought clunky. You asked me this 12 days ago and I can find no evidence I replied. Apologies for that. I shall have a go at some jaypeggy art, but not as a priority. So if it's not too much trouble as a temporary measure, please replicate for other primitives that need it. -- Ian Clark <<DateTime(2014-05-23T23:30:14Z)>>
Essay on Empty Arguments is finished at Vocabulary/EmptyArguments.
-- Henry Rich <<DateTime(2014-05-22T18:50:55Z)>>
Essay on Loopless Code is at Vocabulary/Loopless. I can't really tell whether it's fit for purpose. I would appreciate your judgement.
-- Henry Rich <<DateTime(2014-05-22T01:33:07Z)>>
Consider whether "cell" should be an AET. I'm not saying I think it should, just that it comes up a lot in this Looping page I'm writing.
-- Henry Rich <<DateTime(2014-05-21T22:25:50Z)>>
-- If we don't have "cell" in AET, then we effectively relegate everything to do with Rank to an advanced topic. Which is not good. But if we do have it in AET, we're presenting the novice with a very big pill to swallow before they're even allowed to start browsing NuVoc. I wrote Vocabulary/EZRank precisely to address this issue. It may not do the job (I suspect it doesn't) but the issue remains.
...My opinion is changing like a Necker Cube. When I start on AET, maybe it'll stabilize. -- Ian Clark <<DateTime(2014-05-24T00:19:00Z)>>
Look at the rewritten AboutNuVoc. The credits at the end are guesswork to me. Getting this project off the ground at all was a major accomplishment, and a monument to your tenacity, but I wasn't around to see that happen. If quorum pars magna fui was good enough for Aeneas, it is good enough for me; you can best give credit where it is due.
-- Henry Rich <<DateTime(2014-05-21T20:36:50Z)>>
-- Thanks, Henry. It's just the sort of thing I was hoping for. Even if we tweak it continually until D-day (D=Dictionary). I've corrected my role: I "created" none of it and all the major design decisions were taken before I clambered aboard. Then I was left holding the wheelbarrow, but 'nuff said about that. -- Ian Clark <<DateTime(2014-05-24T00:52:43Z)>>
I changed "Accessible Vocabulary" to "Accessible Dictionary" which is now more appropriate.
-- Henry Rich <<DateTime(2014-05-22T00:53:24Z)>>
-- That's still something to be sorted out: the exact semantics of "Dictionary" and "Vocabulary". As it stands, it reads like we use the terms interchangeably. But since JHelp shows both "Dic" and "Voc" along the top, do we have the luxury of being able to do that? Perhaps we ought to make it clear precisely what stands in relation to what, as it could be a real source of confusion to our "novice", bless her. (I get confused myself!) -- Ian Clark <<DateTime(2014-05-24T00:52:43Z)>>
Took a look st Vocabulary/TBlock ...
- Looks good. You've provided some really in-depth examples! "The Mills of God grind slow, but exceeding small..."
- I learned something from your new section: the Result of a Verb
- But I touched-up the sample code for verb b until I myself was able to understand it.
- AND I was careful to test it.
- But I gagged at this para at the end of the first section ...
((snipped))