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
