I'm not sure if this is what you're referring to, but Jeffrey Shallit and Eugene McDonnell published a paper on extending APL to support infinite-length arrays. I don't have these proceedings in my library, and can't remember details of their talk, so can't say much about it. This from Shallit's web site:
(with Eugene McDonnell) ``Extending APL to infinity", Proc. APL 80 Int'l Conf. North-Holland, Amsterdam, 1980, pp. 123-132. The issue of implementation of infinite-length arrays is not out of the question in J or other languages: http://hopl.murdoch.edu.au/showlanguage2.prx?exp=1223 As an example of a possible approach to implementing infinite-length arrays in an array language interpreter or compiler, consider the use of Arithmetic Progression Vectors (APV) of the form: "First + Step * i. Length" as an internal data structure: rather than naively interpreting each verb in turn, the system could keep a list or descriptor of (First; Step; Length) for these expressions, and then perform arithmetic on the descriptor. E.g., "2 + APV" creates (First+2; Step; Length). If Length can take on the infinity value _, then infinite arrays are easy to work with and take up almost no space. In the interest of time, naive display of such an array is discouraged, of course. Structure and selection operations (e.g., take, drop, reshape, reverse) on APVs are fairly straightforward to implement, for common cases. Things start to get a bit messy when you run into a Taylor Series and have to do: x ^ APV I am not sure how much of APL or J could be extended to infinite arrays, in the sense of avoiding the need for array expansion often enough to be useful. That is, do the benefits warrant the effort required to implement it? Or do we end up with a toy with just enough power to be irritating? APVs (on non-infinite arrays only) were introduced at least as early as 1972 or so, into the Siemens APL/4004 system, by Eric Iverson (and others?): @INPROCEEDINGS{EBIverson:apl4004, AUTHOR="Eric B. Iverson", TITLE="{APL}/4004 Implementation", BOOKTITLE="{APL} Congress 73", PUBLISHER="North-Holland Publishing Company", KEYWORDS="APL, implementations, interpreters, j-vectors, arithmetic progression vectors, APL PLUS, APL\360, APL/4004, efficiency, file, IBM 2741, loop, Siemens 4004, Siemens T.200, Siemens 8150, Textronix 4013, text editor, virtual memory", PAGES="231--236", YEAR="1973"} The downsides of APVs in an interpreter are twofold: They complicate the interpreter structure and invite unpleasant bugs, because of frequent requirements to expand an APV into its array form, perhaps because some APV special case code has not been written, or because the APV has to passed to an external agent, such as a native file system. The APV code was, I recall, removed from the Siemens interpreter because APV-related code faults pervaded the system, and the actual performance benefit obtained by the use of APVs was minimal or negative: APVs, for the same reason, slow down an interpreter, because every single operation has to check for the "Is This An APV" case. A compiler has considerably more latitude here, because it can perform such analysis once, rather than over and over again, and generate appropriate code. A compiler also can spend a fair bit of time performing optimizations, such as constant folding, that are generally impractical in a interpreted environment. A Just-In-Time interpreter that compiles code into a more pleasant form for execution is not an extremely difficult task; that may be a good approach to handling APVs, and for improving the performance of various derived functions, trains, highly iterative code, and the like: It offers the possibility of performing a reasonable amount of analysis and optimization, without materially lengthening the main code path through the interpreter. Bob On Wed, 2008-05-28 at 12:14 -0700, Tracy Harms wrote: > John Randall wrote, in the Programming forum: > > > I think the author of the Wikipedia article is trying to get at this, > > so you would accept 1+1=2 (mod 12) but not 9+4=1 (mod 12). In my > > opinion, this fixates on the distinguished representatives rather > > than the equivalence classes, and if you do that, you will go wrong > > somewhere else. > > Thank you for this assessment of that flawed Wikipedia paragraph. > > Because equivalence classes are infinite sets, my curiosity is piqued: > How should Iverson notation be applied when dealing with infinite sets? > > It seems that for this use we must move to statements that would not be > valid under the requirements of executability that J and APL entail. > Yet, it would be nice to be able to refer to things like these > equivalence classes, integers, rational numbers, real numbers, and the > complex plane within a near-J notational structure. > > I've put this to the Chat forum because it departs from J proper, but if > the moderators think it is a better fit for the Programming forum we can > move it back there. > > Another area where I'm not entirely sure how to apply J are statements > of formal logic such as "for all" and "there exists" (inverted capitals > A and E, respectively.) > > In general, I wish to explore a return to the roots of J. The > abstraction of tacit notation is itself a triumph along those lines; the > way it removes specification of particulars allows us to refer strictly > to the functions. The arguments could in many cases be infinite sets, > setting aside the needs of implementation. The limit power (^:_) also > provides something along these lines. > > As an example of where my curiosity has wandered, I've not been able to > decide whether (i: _j_) naturally denotes the Rationals, or only a > subset of them. (If "_" were taken as a value, which it must not be, it > would denote the Integers.) > > -- > Tracy Harms > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
