Ian,
Before you plunge into mysticism, depression, theosophy(?)
or whatnot, I should tell you that there is a tacit solution to your
problem, using a technique that is closely related to the functional
programming finest: monads. Let's first have some fun:
fun =: "_
Now we want to calculate:
v =: #...@ttt
For this technique to work it is necessary that v is defined *before*
TTT. Since TTT has no definition when v is defined, it is treated
*as if* it is a verb (I think it's called proverb).
Now all we do is apply fun to TTT (which "lifts" the noun into the
world of verbs):
TTT =: 1 2 3 4 fun
Let's check that v is unaffected by TTT getting value:
v
#...@ttt
So how do we make v to calculate? Simply by giving it any argument
whatsoever (every monad has to be triggered to perform computation):
v a:
4
TTT=:(i.100)fun
v a:
100
But wait a minute---if the same expression, v a:, gives two/many different
values, then it cannot possibly be a function in the mathematical/functional
programming sense of the word. Well, that's true in J but it is not true
in Haskell, where monads are indeed functions! In J, for instance,
we can easily see that v, when TTT is not defined, is a verb that cannot
be fixed by f.
How do we do computations with the noun that is lifted into the verb?
1+TTT
1+TTT
Nothing happens, until we trigger the process (the monad in the sense
of pure functional programming):
(1+TTT)a:
1 2 3 4 5 6 ...
So I'd surmise that tacit programing *without nouns* should be
an instance of monadic computations.
Ian Clark-6 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
>
>
--
View this message in context:
http://old.nabble.com/Tacit-exercise-tp26860170s24193p26884460.html
Sent from the J Programming mailing list archive at Nabble.com.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
