Viktor and Dan -- thanks a bunch. That's tempted me with hosts of forbidden ideas.
But I fear in the end that any process creating/updating TT in my base locale will have to be asked to do the ethical thing and lay some tracks for my engine after it has done it. Or else CAL tries to be as APL-like as possible so it can depend unquestioningly on call-time binding. Or... (and I've done this before and earned Purgatory), CAL starts an asynchronous timer to fire off some holy inquisition to check (inter alia) that TT hasn't changed. Which would be a pity. Because much of the attraction of porting CAL to J (apart from the little matter of saving me buying a licence for APL+ on my iMac) is to free me to address the problem from first principles. I too am a convert to the benefits of functional programming, having suffered exceedingly in the past from the error of proliferating semiglobals. And who knows -- I might even come to abjure Newton, not to say Raphson, for the virtue of writing foo^:_1 to back-calculate foo's input vector. Ian On Tue, Dec 22, 2009 at 11:56 AM, Dan Bron <[email protected]> wrote: > Viktor Cerovski wrote: >> I should tell you that there is a tacit solution to your >> problem > > Viktor, that was a neat post, and it gives me some insight to "monads" (in > the Haskell sense), which I've been struggling with. Thank you. > > But just so no one is led astray by your terrible heresies, let me denounce > them a bit. At the end I'll make it up by presenting an even more insidious > perversion from the vaults. > > First, you're right that v isn't tacit (functional) in the J sense. Or, it > is, at any given moment of time, but not in motion as you've shown it. What > is "a moment in time" and "in motion"? A "moment" is a given, specific > definition, and "in motion" means "throughout the course of multiple > definitions". Because, of course, v is defined in terms of TTT, which you > keep redefining. The fact that v can give outputs for the same inputs > every time you redefine it should be no more surprising than this: > > f =: +: > f 12 > 24 > > f =: *: > f 12 NB. Oh noes! Same line, different result!!11one > 144 > > > Put another way, Ian indicated his CAL has no control over TT (which your TTT > mimics). He doesn't define (or re-define) it; CAL just receives a signal and > begins calculating on the current value stored there. So how do you arrange > for your tacit verb to keep up with this externally-changing value? Your > method won't work. > > But here is a perversion which will: > > load'jmf' > createjmf_jmf_ 4000;~jpath'~temp\TT.jmf' > map_jmf_ 'TT';jpath'~temp\TT.jmf' > > TT =: i. 4 4 > TTT =: TT #@:[ ] NB. Length of TT, as a orthodox, mundane NVV > tacit verb > > TTT '' > 4 > > TT =: i. 12 4 NB. TT can change behind the scenes... > TTT '' NB. and TTT will keep up > 12 > > > TT =: i. 125 4 NB. Fun! > TTT '' > 124 > > > TT =: i. 126 4 NB. Awww :( > |allocation error > | TT =:i.126 4 > > > Just don't let your children see it. > > -Dan > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
