and ... thank you, Dan ... now I've taken the trouble to read your post carefully at: http://www.jsoftware.com/pipermail/programming/2009-August/016123.html ... I believe I've just said what you did, only another way.
Ian On Tue, Dec 22, 2009 at 3:22 AM, Ian Clark <[email protected]> wrote: > That's a good word, Dan... "mutable". > > I'm enjoying this thread, although I can't keep up with the J > theosophy. But I have a thuggishly simple problem. With some equally > thuggish solutions. I'm porting an old but successful engine written > in APL to J. This engine (a Newton-Raphson expression-inverter, let's > call it CAL) works upon a piece of complex data named TT. It isn't the > only engine to do so, and it doesn't know about the other ones. And > it's supposed to be memoryless. But it's also supposed to be fast, > which has hitherto been achieved by use of cached data... (think about > it...) > > So TT is not under CAL's control. Whenever CAL gets a message it > straightaway goes to work on whatever happens to be present in the > base locale under the name "TT" and the first thing it needs to know > is the number of rows. > > Now in APL, the expression {first}{rho}TT did this totally reliably, > because a reference to "TT" inside a function is always bound at > call-time. (This isn't the beginning and end of the story, it's just a > taster.) Being a J rabbit, I assumed at the outset that #TT used > inside a verb had the same semantics. > > It doesn't. > > Not if I hope to benefit from the tacit "beauty" of functional > programming. I'd love to call it functional analysis, or functional > engineering but it's neither. > > Now I was trained as a mathematician and a physicist > (...separately...) and I've trained engineers and I know how they > think. And it's not how programmers think. There were two job titles > in IBM Hursley: "programmer" and "engineer" (I was one of the latter) > and they didn't even p*** in the same johns. Engineers don't believe > programmers know the first thing about engineering: they see them as > having more in common with theologians. Mullahs. > > Now I don't want to be the subject of a Fatwa, or excommunicated for > preaching the Explicit Heresy. I strayed into this discussion lured by > the enticing if formally undecidable proposition: "what's ugly must be > bad." My ideas of code "beauty" have been conditioned by long hard > years at the APL coalface. My ugliness-antennae have evolved to detect > ambiguities, elephant-traps ...and the Weinberg Bug. > > J is opening to me new worlds of beauty -- and ugliness. > > That entails the dawning awareness that tacit programming binds data > not at call-time, like an APL del-function, but at code-writing time. > That has implications. Specifically for porting what I'm thinking of > as an "engine" from APL to J, and hoping it will remain so. Plus the > underlying assumptions of my entire enterprise. > > Ian > > > On Mon, Dec 21, 2009 at 11:28 PM, Dan Bron <[email protected]> wrote: >> Ian Clark wrote: >>> Right, so you either write 'TT' into the string of an explicit >>> definition (when it gets bound to the current TT at call-time) or you >>> write something like ".@('TT'"_) . >> >> Right; tacit code is functional. Functional code, given the same inputs, >> always produces the same outputs. By definition, it can neither rely on nor >> produce side effects. Which means tacit verbs cannot refer to mutable nouns >> (or, alternatively, the only mutable nouns which can change the output of a >> tacit verb are its arguments -- which it does not refer to :). >> >> Lest anyone be led astray, ". is a J interpreter. So ".'something' is >> liking typing something into the IJX window (in the current context, >> equivalently to in debug mode). So ".'something' is only tacit if >> something is tacit. But since ". is a verb, it can only return nouns, >> and so something must be either be a noun phrase (which isn't tacit >> because arguments are mentioned, though parts of it can be tacit) or a side >> effect (such as an assignment or host interaction) which isn't functional, >> and hence isn't tacit. >> >> Embedding ". bind 'something' into your tacit code renders it non-tacit >> (or non-completely tacit, which may be the same thing, depending on your >> orthodoxy -- I mean perspective). >> >> I elaborated a bit on this in [1]; but it's spread throughout the thread a >> bit. The moral of that story was if you want to refer to mutable data, be >> up front about it (i.e. explicit). >> >> -Dan >> >> [1] http://www.jsoftware.com/pipermail/programming/2009-August/016123.html >> >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
