Thanks for your list of “Some more things I’d love to see in the next version”.
1. A way for programs to quickly test if a particular extension or feature is available by name
Great idea! The Common Lisp way of doing this is with the *features* variable. You would simply be able to do:
(member :floating-point *features*)
to find if your version of uLisp has a particular feature. Initially I suggest populating it with features from this table:
Lisp for microcontrollers - Versions
2. Ability to have an arbitrary number of extensions loaded
My first attempt at the Extensions feature did allow an arbitrary number of extensions files, but it made it a lot more complicated, and there was an impact on uLisp’s performance. I suppose if there’s enough interest in this I could revisit it.
3. Function overloading by extensions.
It’s a nice idea, but do you think it would really be useful, apart from the bigint example?
Also, can’t the equivalent be achieved by redefining the built-in functions? For example:
(defun * (a b) ($* a b))
4. Better streams
Yes, we’ve talked about this before. I had a look at it but it was non-trivial to use peek rather than the way I do it at the moment with LastChar. I can have another look at it.
5. Proper &key parameters
As you know, I’m keen to keep uLisp compact, rather then letting it gradually grow towards a full Common Lisp, and this seemed a good point at which to draw the line.
Because uLisp is an interpreter, supporting &key parameters would have a performance impact, even when they’re not used.
Also, once uLisp supports &key parameters there would be an case for many functions to be extended; for example, all the sequence functions could be expanded to support the full set of keyword parameters such as :start, :end, :test etc.
I feel that there are other ways of achieving what you’re suggesting without having to add full support for &key parameters; for example, like I’ve done with make-array.