Proposal: Functions accept sequences

[Symbolics]

Functions accept lists as arguments. In most cases they can be made to accept sequences, which include both lists and vectors. The advantage here is speed: large lists can be very inefficient where as vectors are relatively efficient when working with large data volumes. Also, many packages that generate data, deliver it in the form of a vector.

In most cases, making the functions accept sequences is relatively straightforward, since most built in lisp functions accept sequences (sequence is a super-class of list and vector).

[Symbolics]

When implementing this feature, the developer should take note of the fill-pointer available in common lisp. From the specification, fill-pointers: "make it easy to incrementally fill in the contents of a vector and, more generally, to allow efficient varying of the length of a vector." This will avoid the oft-time expensive list copying operations (and possibly eliminate the need for the increase-list-length function).

@RodrigoZepeda, if you'd like to discuss working together on some of these issues, please contact me so we can coordinate efforts.

[RodrigoZepeda]

@Symbolics I'll be more than happy to work together and improve this project. I'm writing you to your email.

[Symbolics]

Commit d0c31a2 updates to-javascript-array to accept sequences and should provide a partial example of how to work with sequences.

In looking through the remaining code, I do not think it worthwhile catering for both cases. Instead, the functions should accept and manipulate vectors, and then coerce lists to vectors if passed a list.

I'm not sure what the plan is for adding different plot types. If different plots require different JavaScript variables, we may want to consider making javascript-string more generic (in the programming sense, not the CLOS sense).

[Symbolics]

The postmodern project may have the right idea in these language transpilers: a def-op macro similar to the one they have in s-sql.lisp that translates lisp to SQL. With this, we could have something like:

(with-output-to-string (js-string)
   (js:defvar xdata #(1 2 3 4 5)
   (js:defvar ydata ...))

This might make the JavaScript easier to manage. If we did this, I'd suggest locating the JavaScript transpiler functions in a separate "JS" package. The Parenscript package might be useful here. Or, if too heavyweight, we should cherry pick what we need. In either case, Parenscript looks worthy of study.