Re: A pragmatic solution to using arrays in picolisp
I support the last idea about that isn't necessary to touch core language, and if someone needs array support, it could be implemented the same way as e.g. ext and ht libraries. Best regards, Mansur --- skipped --- I don't think it's necessary to add arrays to the core language however, given a sufficiently featured array library, picolisp's FFI interface can be used to provide a nice abstraction above it. This is similar to how numeric arrays are used in Python with the numpy package. Functions are provided to copy data into and out of arrays from lists, dictionaries, or files, and the actual operations on the arrays are carried out by a native C library (and often third party libraries like blas/lapack). The arrays themselves are just opaque pointers to corrected sized and memory ordered malloc'ed regions. --- skipped --- -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A pragmatic solution to using arrays in picolisp
Arrays are very useful for numeric computing over linked lists. Contiguous blocks of linear memory are much more efficient, improving on numeric density, cache occupancy, and being able to take advantage of specific CPU vector instructions. For GPU based computing, contiguous arrays are essential and linked lists are useless, they must be scanned in linear time and no warp-level parallelization is possible. I don't think it's necessary to add arrays to the core language however, given a sufficiently featured array library, picolisp's FFI interface can be used to provide a nice abstraction above it. This is similar to how numeric arrays are used in Python with the numpy package. Functions are provided to copy data into and out of arrays from lists, dictionaries, or files, and the actual operations on the arrays are carried out by a native C library (and often third party libraries like blas/lapack). The arrays themselves are just opaque pointers to corrected sized and memory ordered malloc'ed regions. Googling 'C array library' returns many interesting hits. Judy arrays also look very interesting: http://judy.sourceforge.net/ -Michel On Tue, Feb 17, 2015 at 9:04 AM, Enrique Sánchez petenr...@gmail.com wrote: 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. I think that building trees take more overhead than executing a malloc and building a linear list. (And probably more cons cells). 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. There's no point in creating array helpers for small lists elements. These helpers are only useful for large lists. Most of us always use these big arrays as global, static (in the C sense), created at the beginning of a program, living during the whole lifetime of a program, and being disposed of manually at the end of the program, or automatically by the system at program end. During their life, these arrays don't grow, the structure remains the same, because they have the nature of an array. Of course I could use the allocation and disposing of small arrays at many points in the source code with this system, as you fear, like C and C++ programmers do. But that is hell, I would not do that. They do that because they don't have other means. So the allocation and disposing using malloc() and free(), are only made typically for a pair of big arrays at two well known points in the source code, and that's it. The following is a typical program showing the use of array helpers: (setq *Ram (array (readFile 65536 ram.bin)) # memory array *PC0 # Program pointer *SP16384 # Stack pointer *Reg1 0 *Reg2 0 *Reg3 0 # general registers *Run T ) (while *Run (setq *P (nth: *Ram *PC)) # random access (execute *P) ) [... here would be all the main code ...] (dispose *Ram) # optional (bye) For this kind of program, using trees to emulate raw memory array functionality seems convoluted, and I guess at least 10 times slower. Convoluted because of the emulation of a more primitive structure by means of a more complex one. The most important data structure in Picolisp, the cons cell, is nothing more than a array element, addressable by a pointer, that is just an array index. If I want to use Picolisp to do exploratory programming of computer interpreters, then having arrays seems natural. 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). If you consider that for building interpreters, emulating raw memory indexes with trees is appropiate, then I don't think so. I see it half way as convoluted as clogging the symbol table with symbols like 'M1, 'M2 ... for doing that. Or may be you consider that trees are not appropiate for that kind of application, as is my opinion, and your solution is to resort to another computer language, as C, for doing that kind of programming. In this case I would understand your choice. I would like to be able to do that kind of low level programming in picolisp. The implementation effort would be about 20 lines of code. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Installation issues
To complicate things I've attached my two local versions of picolisp.el and
inferior-picolisp.el
When I diff them I see quite substantial differences.
Unfortunately I have no idea why I made those changes as I didn't take any
notes and it was several years ago.
On Tue, Feb 17, 2015 at 7:12 AM, Alexander Burger a...@software-lab.de
wrote:
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
;; picolisp-mode: Major mode to edit picoLisp.
;; Version: 1.1
;;; Copyright (c) 2009, Guillermo R. Palavecino
;; This file is NOT part of GNU emacs.
Credits:
;; It's based on GNU emacs' lisp-mode and scheme-mode.
;; Some bits were taken from paredit.el
;;
Contact:
;; For comments, bug reports, questions, etc, you can contact me via IRC
;; to the user named grpala (or armadillo) on irc.freenode.net in the
;; #picolisp channel or via email to the author's nickname at gmail.com
;;
License:
;; This work is released under the GPL 2 or (at your option) any later
;; version.
(require 'lisp-mode)
(defcustom picolisp-parsep t
This is to toggle picolisp-mode's multi-line s-exps closing parens separation capability.
:type 'boolean
:group 'picolisp )
;; I know... this shouldn't be here, but you see, people may want to keep
;; their body-indent value unaltered and have a different one for picolisp
;; sources, so...
(defcustom picolisp-body-indent 3
Number of columns to indent the second line of a `(de ...)' form.
:group 'picolisp
:type 'integer )
(defvar picolisp-mode-syntax-table
(let ((st (make-syntax-table))
(i 0) )
;; Default is atom-constituent.
(while ( i 256)
(modify-syntax-entry i _st)
(setq i (1+ i)) )
;; Word components.
(setq i ?0)
(while (= i ?9)
(modify-syntax-entry i wst)
(setq i (1+ i)) )
(setq i ?A)
(while (= i ?Z)
(modify-syntax-entry i wst)
(setq i (1+ i)) )
(setq i ?a)
(while (= i ?z)
(modify-syntax-entry i wst)
(setq i (1+ i)) )
;; Whitespace
(modify-syntax-entry ?\t st)
(modify-syntax-entry ?\n st)
(modify-syntax-entry ?\f st)
(modify-syntax-entry ?\r st)
(modify-syntax-entry ?\s st)
;; These characters are delimiters but otherwise undefined.
;; Brackets and braces balance for editing convenience.
(modify-syntax-entry ?\[ (] st)
(modify-syntax-entry ?\] )[ st)
(modify-syntax-entry ?{ (} st)
(modify-syntax-entry ?} ){ st)
;; Other atom delimiters
(modify-syntax-entry ?\( () st)
(modify-syntax-entry ?\) )( st)
;; It's used for single-line comments.
(modify-syntax-entry ?# st)
(modify-syntax-entry ?\ \st)
(modify-syntax-entry ?' 'st)
(modify-syntax-entry ?` 'st)
(modify-syntax-entry ?~ 'st)
;; Special characters
(modify-syntax-entry ?, 'st)
(modify-syntax-entry ?\\ \\st)
st ) )
(defvar picolisp-mode-abbrev-table nil)
(define-abbrev-table 'picolisp-mode-abbrev-table ())
(defun picolisp-mode-variables ()
(set-syntax-table picolisp-mode-syntax-table)
;;(setq local-abbrev-table picolisp-mode-abbrev-table)
(make-local-variable 'paragraph-start)
(setq paragraph-start (concat $\\| page-delimiter))
;;(setq comint-input-ring-file-name ~/.pil_history)
(make-local-variable 'paragraph-separate)
(setq paragraph-separate paragraph-start)
(make-local-variable 'paragraph-ignore-fill-prefix)
(setq paragraph-ignore-fill-prefix t)
(make-local-variable 'fill-paragraph-function)
(setq fill-paragraph-function 'lisp-fill-paragraph)
;; Adaptive fill mode gets in the way of auto-fill,
;; and should make
Re: Installation issues
On 2015-02-17T17:12:54+1100, Alexander Burger said: AB as I mentioned in my previous mail, is Thorsten currently AB offline. He asked me to post this for him A i'll try to find some time to: A * examine the diffs between the distribution version and the A GitHub version; TJ Why? Just use the newer version, i.e. the Github TJ version. Nobody else but me did change anything recently. Then why isn't the GitHub version the one currently distributed with PicoLisp? The fact that it's not suggested to me there might be some issues around doing so. And why does the distribution version contain picolisp-wiki-mode.el, whereas the GitHub version doesn't? (A separate issue is, why do users have to manually patch paredit.el? Has there been some issue with upstream not being willing or able to modify paredit.el so that it can better support PicoLisp?) A * add to the former any fixes and/or extra functionality A found in the latter; TJ Again - why? Just replace the older version with the TJ newer version ... See above. A * add in my code to present documentation for the symbol at A point; TJ and you mean an eldoc implementation for picolisp? No, although that's certainly a good idea. What my code does is (for Emacs 24.3) to open the full reference documentation for a particular function in a new buffer via `shr`, or (for Emacs 24.4) in a Web browser. TJ patches are welcome, just fork me on github. ... except you're currently offline, for a period of time not specified. As i've mentioned elsewhere in this thread, given my experiences of spending time coding and submitting PRs/issues, only to have the latter ignored even by people who are demonstrably still actively coding, i'm not much inclined to get involved with code whose maintainer is very explicitly offline. A * add in things like user configuration of the path to the A `pil` executable. :-) TJ AFAIK the path is remembered, to avoid typing, but can be TJ changed - just try using a prefix before the command, that TJ should give you the opportunity to type in your own path TJ (but I'm not sure right now). TJ Try C-h f on the core functions, there is quite a lot of TJ info in the docstrings. Here's the doc for `run-picolisp` (which, i note, isn't mentioned in the README; nor does it begin with the `picolisp-` prefix to assist its discoverability and limit namespacing issues) from the GitHub version: run-picolisp is an interactive autoloaded Lisp function in `inferior-picolisp.el'. It is bound to run-picolisp. (run-picolisp CMD) Run an inferior Picolisp process, input and output via buffer `*picolisp*'. If there is a process already running in `*picolisp*', switch to that buffer. With argument, allows you to edit the command line (default is value of `picolisp-program-name'). Runs the hook `inferior-picolisp-mode-hook' (after the `comint-mode-hook' is run). (Type C-h m in the process buffer for a list of commands.) The fact that one can add a prefix arg to it to specify the full path to the `pil` executable, and that such a specification will be automatically remembered, isn't mentioned. TJ Sorry for being late to the discussion, but I'm TJ not really online at the moment. Fair enough; life happens! i myself have a lot happening, so it's important to me that my FOSS contributions aren't to no effect, or become more complex to manage than i've got the time and energy for. Consequently, given that the more i look at the situation around the above implementations, the more contextual complexity[1] i find, i feel it's best for someone else to take on the work of sorting things out. [1] As distinct from any complexity in the code itself. At any rate, i've started the process of renaming my own `picolisp-mode` to `a-picolisp-mode`, so that it doesn't get confused with these other existing codebases; and in the README for my package, i'll be emphasising that my code is in no way connected with the PicoLisp support included in the PicoLisp distribution, or the modified version thereof available on GitHub. Alexis. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A pragmatic solution to using arrays in picolisp
On Tue, Feb 17, 2015 at 2:30 AM, Denis Fourt denis.p...@hotmail.com wrote: 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. And if you do now want to start from the book, you may start with Okasaki's PhD Thesis: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf -- If technology is your thing plan to die reading manuals --Gene Woolsey -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
