Terminology: fixed-array => eager-array?
Bradley Lucier
(05 Aug 2015 00:55 UTC)
|
Re: Terminology: fixed-array => eager-array? Jamison Hope (05 Aug 2015 14:33 UTC)
|
Re: Terminology: fixed-array => eager-array?
John Cowan
(05 Aug 2015 17:46 UTC)
|
Re: Terminology: fixed-array => eager-array?
Bradley Lucier
(17 Aug 2015 19:25 UTC)
|
Re: Terminology: fixed-array => eager-array?
John Cowan
(25 Aug 2015 12:37 UTC)
|
Re: Terminology: fixed-array => eager-array?
Jamison Hope
(25 Aug 2015 15:29 UTC)
|
Re: Terminology: fixed-array => eager-array?
Bradley Lucier
(31 Aug 2015 00:26 UTC)
|
Laziness (was: Terminology)
John Cowan
(05 Aug 2015 16:55 UTC)
|
Re: Terminology: fixed-array => eager-array? Jamison Hope 05 Aug 2015 14:33 UTC
Hi, On Aug 4, 2015, at 8:54 PM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote: > I believe that racket uses strict-array for what this SRFI calls fixed-array. > > As a mathematician I’m always making up terms, usually just locally in a paper, and like many others I get lazy and say that some object is “admissible” if some condition holds, or use a similarly generic term. This type of terminology will never be picked up by other people. > > So I think that terminology should be more particular than strict-<whatever>. > > So how about “eager-array”? Eager’s the opposite of lazy (there are no lazy arrays in this proposal), and it could indicate that the values that the getter returns are pre-computed and accessed with a simple memory reference. I don't think "eager" is the right word, either. Retrieving a value via pointer arithmetic is certainly simple, but it is no more eager than retrieving a value via a hash table lookup or getting a value out of a sparse array stored as a linked list (put another way, hash tables and sparse arrays are not necessarily lazy). I would suggest "simple-array"; what you're describing is similar to how that term is used in Common Lisp (although it's not an exact match). Also, I think John already touched on this, but an array being fixed/eager/simple/whatever should have no bearing on its mutability. -- Jamison Hope xxxxxx@alum.mit.edu