Thanks for this list, Ric. Looks pretty thorough. It'll be a day or two before I can incorporate these changes, but they're on my list.
A few comments inline, where I'm inclined to argue. Ian On Thu, Nov 4, 2010 at 1:08 AM, Sherlock, Ric <[email protected]> wrote: > See previous threads for [["J In A Day" --crits please]] in the General & > Chat forums. > > Some more feedback on the article and the latest calc.ijs. > > ================================================================ > Article > ================================================================ > > == A simple, yet non-trivial, application == > * The paragraph starting "The calculator is so elementary ..." can probably > just be deleted now. > > * The calc_cancel_button is mentioned but is no longer in the calc.ijs script > (the button was redundant). I had misgivings deleting this. I wanted to keep it in to discuss how to link handlers, something which VB makes a dog's breakfast of, IMO. Mind you, I'm addressing APLers, not VBees. Maybe I shall move the whole discussion to the earlier "stub" calc.ijs, generated by Form Editor. Because that retains both calc_cancel_button and calc_close. > I'd be tempted to get the user to put the script in the ~temp folder rather > than the ~user folder. Why do you think that? There's no File menu item for loading from /temp. IMO there should be. I'm a bit sorry J makes this all slightly tedious on the Mac. Nothing that troubles an intermediate learner. Nothing that a folder alias can't solve. But most languages allow you to download source and then double-click it (on the desktop) to run it. Oleg (I think) had a fix to allow J-scripts to be double-clickable on the Mac. But I haven't been able to make this work. The neatest way to grab a script is to copy/paste from a code block into a new IJS. It overcomes variations in line-end conventions, and allows inspection of all the material and case-studies without having to run J. Some people aren't allowed to install interpreters on their machines. There are computers in the local library with a non-standard folder organisation, so it can be swept clean between sessions. The only things that work are the browser, plus a small collection of MS products. But inline code makes for a very long article. Maybe I could hive it off into subsidiary pages? The smart reader could have two browser windows open side-by-side. > == Handlers: closing the app's main form == > * calc_cancel_button is mentioned again but no longer in script. > > * do handlers "ignore their arguments"? Or is it that they are only given the > argument '' by the gui - which typically is not very useful to use in the > handler? Pedantic perhaps? I see I have indeed used the word "ignore" once. Elsewhere I say "disregard". Some might see that as a synonym but what I mean is that the arguments do not carry useful information and so you don't make use of them in the code. But I can't say they can be omitted from the code. Arguably 'setop' is a handler -- or rather an adverb for computing handlers. I find I cannot omit mention of its 'y', even if its value is discarded by 'empty', else 'setop' doesn't work. (I'd like to know why someday). > * definition of calc_close - I'd tend to add a space between :: and 0: just > to make it easier for readers to correctly identify the primitives. > > == A simple monadic verb: eval == > * The control-word return. is no longer used in the definition of decimal in > the script. > > == How to offer a parameter to a handler == > * If the above section about handlers ignoring their arguments gets changed > then this will need some changes too. > > * "we use a predefined verb: bind to ..." should perhaps become "we use a > predefined word: bind to ... " > > == Writing an ambivalent verb == > > Here are a couple of alternative examples where using dyadic rather than > monadic ". is desirable (not sure if they're preferable to your current one): > ". '123 -456' > _333 > ". '123 -456 4.4e-3' > |ill-formed number > | ".'123 -456 4.4e-3' > 0 ". '123 -456 4.4e-3' > 123 _456 0.0044 > Yes, the current example is a bit naff and could usefully be augmented. > == The locales: base, z, j == > Might be worthwhile mentioning how to check which locale is current (i.e. > coname '' ) > > Also might be worth adding a link to > http://www.jsoftware.com/jwiki/Studio/Locales > for those who want more info on locales/copaths etc. (and mention the Object > Oriented Programming lab for those that want more info on OO ?) > > ================================================================ > Script > ================================================================ > > * The labels for the divid and times controls. I'd suggest either using '/' > and '*' or ' ÷' and '×' rather than '/' and 'x' I thought small-x was more expressive that * -which tends to mean something else on phone-type keypads. And although I like the effect on my Mac of the APL chars ' ÷' and '×', last time I tried it in Win2000 the buttons didn't show Unicode properly. Maybe there's a way round that? I recall Bill has a demo where he puts Chinese chars on button-tops, so clearly there is! > * I think it is only negative exponent formats that cause problems? If so > then the following would still allow large numbers: > if. +./ 'e_' E. z do. z=. ,'0' end. NB. kill negative scientific format > > I don't think this problem is solved by (,8!:2) - you'll still get > "ill-formed number" error when you try to do something with a negative > exponent: > 0.000000001 + 0.000000001 = + > To solve this you need to change eval to use dyadic ". which correctly > interprets say '99e-4' My aim here wasn't primarily to deliver an optimal calc, but as a platform to exhibit familiar constructs in-use. This may be better served by a "buggy" calc coded in the most obvious way, to which refinements are made as the article progresses. That said, more effective solutions can be offered as commented-out statements. This is very much the case with 'eval', which really is superfluous, but affords the best example to discuss from a number of different angles. I discuss the use of dyadic (".) in 'eval' later in the article. Maybe a few commented-out statements in calc.ijs itself can be used to suggest the most effective solutions. I'll have to think some more about this. Maybe 'eval' is just too contrived, and doesn't bear the weight I'm putting on it to illustrate coding alternatives. But it carries the least baggage of any existing word in calc.ijs, and it's meaningful to run it standalone. Maybe I'll get more mileage from a number-formatting word for use in 'update'? -- and simply eliminate 'eval' and replace it with dyadic (".). Ian > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
