What would you like to see in uLisp in 2024?


#3

Picolisp [https://picolisp.com/wiki/?home] excels at this for android, there is an application called Pilbox [https://picolisp.com/wiki/?pilbox] that will run your Picolisp programs on the device, which can load them from an url.


#5

I’d like to suggest a feature for the self-contained Lisp computers: A REPL history feature, i.e. the possibility to call up at least just the last line typed into the local REPL with a single keystroke, say “cursor key up” or whatever. I’d consider this incredibly helpful for beginners like me because it’s tedious to retype a line that included a mistake and thus threw an error.
I tried to figure out how to implement this myself but haven’t yet understood the REPL internals enough to see the right entry point.


#6

Replying to @Ginkgo
I’ve wanted that too and have put some effort into making it happen, here’s what I learned: The first thing is that if you’re using a serial terminal like the Arduino IDE or termite it has history and editing etc, so the ulisp repl just taking in strings is perfectly fine. Those features are only important if you’re using ulisp on a self contained device like the t-deck.

The second thing I learned is that adding features like line editing and history require close to the effort of writing a text editor program. IMO in that sense one is better off writing a standalone program in ulisp that does what you want than modifying ulisps internal repl to add those features. This is something I’ve attempted but haven’t gotten too far in.


#7

I had the same idea as Ginkgo , some special key in ulisp to recall the last line typed.
Or even better a small editor perhaps …


#8

Gave it another try today but again without success. While I managed to save the last line successfully typed into the REPL within a new global variable, I sadly found no way to “inject” it into the reading process due to the character based workflow (?). Maybe there is a way, though? A hint would be very welcome. (I know the remote serial terminal provides a history, but to me the whole point of a self-contained Lisp machine is, well, to use it self-contained…)


#9

If you are using uLisp on a platform with a display you could implement this uLisp editor:

A Lisp Editor for T-Deck

See also:

Extensible T-Deck Lisp Editor


#10

I assuming you’re using uLisp with a terminal? Don’t you have the history visible on previous lines of the terminal window, so you could just copy the last line typed from the terminal history, and paste it at the uLisp prompt?

One option is the program editor, included with all versions of uLisp:

Using the program editor


#11

Hi David
I’m using gtkterm in linux , but as far as I know this hasn’t a history of typed commands. I didn’t know about the editor , I will take a look at it.

Regards,
Ronny


#12

That’s correct, I can always use uLisp with an external terminal (like the one in the Arduino IDE that offers a history). My suggestion refers to self-contained uLisp computers unplugged from a bigger PC, like the T-Deck or the Keyboard FeatherWing, then using the built-in keyboard and the built-in screen only, on the go, so to speak. The basics are working absolutely fine, of course, but when one types a mistake on the tiny Keyboard and hits Enter, causing an error, one has to retype the whole thing again, because the faulty lines do not lead to an accepted Lisp object that could be edited.
I’m definitely not complaining, though, since uLisp offers so much already. This was just a suggestion!


#13

Hello David,

I hope your are doing well.

From a technical standpoint, integrating ulisp with the Zephyr RTOS would be a valuable addition. This would enable the execution of ulisp programs on Nordic’s nRF9160, opening up new possibilities for low-power cellular IoT applications.

From a community perspective, establishing a dedicated GitHub repository for collecting “external contributor examples” alongside the existing “Simple, Larger, and Game” examples would pave the way for creative and experimental collaborative usage.

Best Regards


#14

This is an excellent idea. I assume it should be public so everyone can contribute to it without someone needing to maintain it.

One idea is that it could be a thread on this forum.

Alternatively it could be a GitHub repository, something like this:

Awesome Common Lisp

It should probably cover:

  • Programs written in uLisp.
  • Extensions written as an Extensions File, as in Adding your own functions.
  • Extended versions of uLisp, written as a fork of the original source file.

Further suggestions?


#15

I’ve had a quick look at the Zephyr RTOS documentation, and integrating uLisp with it looks like a pretty major project. If someone else is interested in taking this on I’d be happy to provide help.


#16

Hi,

Thanks a lot for the feedback.

Ohh the Awesome Common Lisp is quite extensive! However, I was thinking of something a bit more simple.

In fact it is quite positive and useful for a beginner / amateur like me that the ulisp examples just work when followed step by step. However, creating such content requires expertise in both programming and electronics / embedded systems while keeping the tutorial easy to follow.

For example consider creating a “larger” example for simulating a digital chess clock using ulisp (or any other open idea). You’ll likely need:

Two I2C displays
Four or five buttons
ulisp code 
Additional materials

With a collaborative approach, even a beginner could start the tutorial. Several authors could contribute / correct / guide it until it’s completed and tested. At that point, you could add a link to the tutorial within the ulisp forum’s external examples section. Of course the idea is always to keep the same ulisp / technoblogy tutorial format of providing pictures of the hardware + code + bill of materials.

Best Regards


#17

Hi,

The only similar approach for integrating a lisp implementation within Zephyr OS that I could find was here: https://svenssonjoel.github.io/pages/lispbm_zephyros_repl/index.html.

However, it seems that a full port would need to be done since ulisp is based on the Arduino implementation.

Thank you for checking!

Best regards,


#18

A chess clock is a great idea for such a project, because it’s something you might want to customise; eg for lightning chess, or special rules.

There are quite a few examples on the uLisp Sensor Library site that could form the basis for hardware projects; for example:

HT16K33 Seven-Segment Display


#19

Hi,

Appreciate your feedback. I’ll verify the compatibility Raspberry Pi Pico W

Best Regards


#20

1+ on this, uLisp is a delightfully useful and powerful subset of CL! It works shockingly well with few disappointments. I’d love to use it for scripting particularly given the tiny size and instant startup.


#21

See: Calling up the last line typed with a single keystroke.


#22

Things I’d like to see in uLisp for 2024 (and beyond) include:

Interrupt handling - being able to fire off a function when an interrupt is triggered, or store the fact that an interrupt was triggered in a queue or register would be nice.

Macros - I know these are dangerous, but it feels necessary for being a lisp to at least have them for more performant chips (teensy 4.0 and esp32). Not to mention it makes the language much more flexible.

Compile to assembly - this is a pie in the sky wish, but I’d love to be able to compile to one/all of the assembly languages. Not sure if this could be accomplished on the microcontroller, but even compiled on a computer and then passed back over the repl would be useful.


#23

Partial solutions to your three wishes:

Interrupt handling

The current options are:

  • Use the register command to set the appropriate bit in the pin change mask register, so a transition on a pin is latched in the pin change interrupt flag register. Then periodically poll the pin change interrupt flag register to detect when the pin change has occurred.

or:

  • Write a uLisp Extension file that implements interrupts, with an interrupt service that detects the interrupts and writes them to a location that can be queried from the Lisp program.

The terminology I’ve used is for AVR processors, but I assume something equivalent could be done on the other processors.

For information about the register function see: Programming AVR registers or Programming ARM registers .

For information about writing an Extension File see: Adding your own functions.

Macros

dragoncoder047 has implemented a pretty full implementation of macros in uLisp:

uLisp Extensions Requiring Major Edits

I would disagree that macros are dangerous; just difficult to understand, though I am not convinced that they are needed for most applications of uLisp.

Compile to assembly

The first step in doing this, namely compiling of assembler to machine code, is already available on ARM, AVR, and ESP; for example:

ARM assembler overview

The next step would be to write a compiler in uLisp to compile a subset of Lisp into assembler, or an intermediate bytecode. To be done!