Memoization can be introduced as an adverb, so that instead of the system guessing whether a verb can be memoized, you'd say:
v M. v M. would give exactly the same results as v but would be memoized. I don't see that comparison tolerance necessarily presents insurmountable difficulties. The global tolerance is problematic, but the v!.t version should be fine. What are the problems with ? for functional programming, other than the definitional one? Whatever functional programming is, it would be poorer if it can not accommodate ? (rule out Monte Carlo methods, etc.) ----- Original Message ----- From: John Randall <[EMAIL PROTECTED]> Date: Sunday, July 2, 2006 7:47 pm Subject: [Jgeneral] J as a functional programming language > It seems to me that many of J's primitive verbs are pure > functions, and > there is a fairly small amount of state in the exceptions. > > Obviously ? is a long way from being a mathematical function: it is > specifically designed to give a different result every time it is > called. > Input and output functions do not fit well into this scheme. Input > functions return a different value each time they are called, and so > cannot be memoized: output functions have side effects and so > cannot be > lazily evaluated. > > Most of the others are OK. The major drawback is comparison > tolerance. > Has there ever been consideration of moving J in a more functional > programming direction? In particular, memoization would be very > useful,and would seem to be compatible with J's execution model. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
