# RE: A pragmatic solution to using arrays in picolisp

If I may provide an advice, in "Purely Functional Data Structures" from Chris
Okasaki (Cambridge University Press, 1998), you will find various data
structures based on lists which come close to regular arrays in term of access
performance. This might be what you are looking for.
A simplified ML syntax is used in this book (because ML uses static types),
some parts are dedicated to performance analysis and there are some interesting
suggestions hidden in some of the exercices, if I remember well.
Regards,
Denis

> From: petenr...@gmail.com
> To: picolisp@software-lab.de
> Subject: Re: A pragmatic solution to using arrays in picolisp
> Date: Mon, 16 Feb 2015 20:19:40 +0100
>
> I've changed my mind.
>
> If we have a linear list for which we need fast access, we can do
> another thing:  Instead of substituting the list with an array
> structure, we can keep the list and use an array as a helper of the
> original list.
>
> That means that instead of storing the elements of a linear list in
> the buckets of the array and getting rid of the list, we can store
> the cdr's of the list and keep the list.
>
> So we can get rid of the 'get: and 'set: functions, that are very
> rigid, and break the Lisp programming style, as you said, and have only
> a 'nth: accessor.
>
>
> 1. First (the big advantage) is that we retain all the usual list
> functions at our disposal, restoring Lisp programming style.
>
> 2. The patch to the garbage collector gets simpler:
>
>     for (int i=1; i<=current; i++) # loop thru each array
>        if (void **p=arrays[i]) # only if array hasn't been disposed of
>            markAll(p[1]); # we only need to traverse the first bucket
>
> ------------------------------------------------------------------
> So, recapitulating we would have only 3 functions:
>
> (setq *Ram (array (need 131072 0)))
> (nth: *Ram 50000)
> (dispose *Ram)
>
> This use of arrays as helpers associated with some lists, instead of
> substitutes of lists, makes arrays even more segregated from the core
> of the language. I think that makes them more acceptable.
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe