Raul Miller-4 wrote: > > On Tue, Dec 22, 2009 at 1:23 AM, Viktor Cerovski > <[email protected]> wrote: >> 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 > > As near as I can tell, every time you define TTT, you are defining > it as a verb. If this is the case, it does not matter when you define > v. > [...] >
You are right Raul. Let's consider a slightly more general example involving fork: U =: C * V V =: % There are three cases: 1) A noun is assigned to C before a verb U is defined: C =: 1 U =: C * V V =: % In this case C is a global constant. It can be changed later but U won't. 2) C is "lifted" to become a global parameter: C =: 1 fun U =: C * V V =: % In this case, as you point out and contrary to what I said in the post, it doesn't matter in which order C and U are defined. What is important here is that we do not fix U, in order to retain parametric nature of C. By fixing U we would get a precise definition (i.e a definition that won't change as we assign something to the name of some object (such as V) upon which the definition relies.) In other words, by fixing a verb a function is defined in the sense of functional programming, and that's exactly what we're trying to avoid here to be able to change C later on at will and execute U for each particular choice of C without need either to (re)define anything else or to pass explicitelly C around (among potentially many) verbs. This leads us to consider a generalization of the adverb f., namely a conjunction f: (fix-without) such that U f: 'C' would fix U except for C, giving: C * % Accordingly, f. === f:'' (fix-without exceptions.) Finally, 3) a noun is assigned to C after U is defined: U =: C * V V =: % C =: 1 In this case we get a run-time error when invoking U, well prescribed within J. The error is also a consequence of the decision not to do fixing, no more severe than any other run-time type mismatch. In Haskell, for instance, a similar situation is passing a number instead of a monad, for instance: 1 >>= ...some function... instead of (return 1) >>= ...some function... (where return would be the name of the lift operation analogous to fun). > That said, the name v can cause problems. Unless you like being > sneaky, you should avoid the names m n u v x y. > Name v was supposed to associate on word verb, but then, yes, it may indeed also be the name of an explicit parameter in scripts, thus creating some name-shadowing. At any rate, what kind of objects are v, V, U and C? Well, V is no doubt a verb, while all the others are verbs that we want either to change later (TTT, C) or will indirectly depend upon that change (v, U). They are thus strictly speaking neither pure functions, nor nouns, nor adverbs, nor monads in the Haskell sense of the word, nor any fixed verbs. Instead, they are proverbs, some kind of prototypes of verbs, so we are also talking about programing with tacit proverbs. -- View this message in context: http://old.nabble.com/Tacit-exercise-tp26860170s24193p26901743.html Sent from the J Programming mailing list archive at Nabble.com. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
