Re: Installation issues
On 2015-02-15T02:56:38+1100, Alexander Burger said: AB Unfortunately, Thorsten (the original maintainer) is currently AB offline. AB I can't do anything in 'picolisp.el', as I'm ignorant of emacs, AB but I can gladly take changes (if they are thoughtfully reviewed AB and agreed upon by competent people) and put them into the AB PicoLisp release. Excellent. :-) Thanks! i'll try to find some time to: * examine the diffs between the distribution version and the GitHub version; * add to the former any fixes and/or extra functionality found in the latter; * add in my code to present documentation for the symbol at point; and * add in things like user configuration of the path to the `pil` executable. :-) Alexis. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A pragmatic solution to using arrays in picolisp
thanks for your ideas and elaborations! thank you for having created picolisp Personally, I must say that I am against using arrays in PicoLisp, and wrote it up a few years ago in: http://picolisp.com/wiki/?arrayAbstinence Yes, I have read it. I agree more or less with it. Can you give me an example where you need a list with 65536 elements, in a Lisp program? Normally you would use some kind of tree to maintain larger data structures, and you example of using helper list does exactly that. If I had a 65536 elements array at my disposal, the first thing I would do is to couple it to the cute 'hash picolisp function (whose output is 1..65536) in order to have very good hash tables. (I could use binary trees instead, hash tables are simpler and a little faster, binary trees are more powerful). If one is interested in building virtual machines in picolisp, I think that one needs arrays, to emulate flat memory above all, but as well to execute the machine instructions efficiently by table dispatching. Besides this, technically your implementation looks good. It breaks the Lisp programming style though. You can't use the rich set of list-manipulation functions on arrays. To do anything interesting, you have to either fetch the whole array (or parts of it) into a list, or operate one by one by accessing individual elements. Very tedious. I use lists for most tasks, as usual, it's only at very selected places that I would reach for an array for random access. You have to take care of garbage collecting these arrays by yourself, i.e. to know when a given array is no longer needed. and this inconvenience alone destroys the possible advantage of an array. Given a function markAll(CELL*) that marks all cons-cells reachable from a given cell, we can just insert the following code in the garbage collector marking phase, so that the contents of all arrays can be protected from being sweeped. for (int i=1; i=current; i++) # thru each array if (void **p=arrays[i]) # only if array hasn't been disposed of for (int j=1; j=size(p); j++) # thru each bucket markAll(p[j]); These 4 lines of code (plus the creation and disposing code) are the price to pay (I think) for having arrays in picolisp. Enrique. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A pragmatic solution to using arrays in picolisp
Hi Enrique, thanks for your ideas and elaborations! Personally, I must say that I am against using arrays in PicoLisp, and wrote it up a few years ago in: http://picolisp.com/wiki/?arrayAbstinence Can you give me an example where you need a list with 65536 elements, in a Lisp program? Normally you would use some kind of tree to maintain larger data structures, and you example of using helper list does exactly that. Besides this, technically your implementation looks good. It breaks the Lisp programming style though. You can't use the rich set of list-manipulation functions on arrays. To do anything interesting, you have to either fetch the whole array (or parts of it) into a list, or operate one by one by accessing individual elements. Very tedious. You have to take care of garbage collecting these arrays by yourself, i.e. to know when a given array is no longer needed. and this inconvenience alone destroys the possible advantage of an array. In addition: 2) I suppose that the garbage collector would have to keep track of all those CELL pointers in the array, that are outside of the reach of Correct. Without that, you can store only short numbers (up to 60 bits) in such an array. Data of any other type (bignums, symbols or lists) will be thrown away by the garbage collector and your program will crash horribly ;) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
