Re: A pragmatic solution to using arrays in picolisp
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. This has two advantages: 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 5) (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
Re: A pragmatic solution to using arrays in picolisp
On 2015-02-15 02:29, Alex Gilding wrote: One cheap workaround for this would simply be to have a nogc function that temporarily disables the GC around a piece of code. If you're crunching data in arrays, you probably want to isolate that operation in its own little high-performance block anyway. I would add some code to the garbage collector, in order to keep the array items protected. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
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. This has two advantages: 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 5) (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
Re: Installation issues
Hi list, as I mentioned in my previous mail, is Thorsten currently offline. He asked me to post this for him: - Hi Alexis, this is Thorsten, the current maintainer (but ot original author) of the Emacs stuff. i'll try to find some time to: * examine the diffs between the distribution version and the GitHub version; Why? Just use the newer version, i.e. the Github version. Nobody else but me did change anything recently. * add to the former any fixes and/or extra functionality found in the latter; Again - why? Just replace the older version with the newer version ... * add in my code to present documentation for the symbol at point; and you mean an eldoc implementation for picolisp? patches are welcome, just fork me on github. * add in things like user configuration of the path to the `pil` executable. :-) AFAIK the path is remembered, to avoid typing, but can be changed - just try using a prefix before the command, that should give you the opportunity to type in your own path (but I'm not sure right now). Try C-h f on the core functions, there is quite a lot of info in the docstrings. Sorry for being late to the discussion, but I'm not really online at the moment. Cheers Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A pragmatic solution to using arrays in picolisp
Hi Enrique, 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. Do you think this is a good idea? OK, you have a list then, where you can access the elements by index. But if you have such a redundant structure, where the array elements point into the list, you have a large overhead to build both the array and the list. You can't do any changes (cons, insert, delete, reverse) without rebuilding the array. And - as before - you have to keep track of your arrays to know when to dispose them. I'm still not convinced at all that accessing list elements by a numeric index is really needed, or at least justifies the effort. The mentioned 'hash' mechanism is alread there, in constructs like the built-in 'cache' function (see also the answer by Denis Fourt). ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
