What would you like to see in uLisp in 2023?

#1

Happy New Year!

What new features would you like to see in uLisp this year? Or what additional documentation or tutorials do you think would be useful?

What would you like to see in uLisp in 2024?
#2

A working MQTT implementation. With uLisp running on microcontrollers, its the missing link between our projects and the rest of the world.

#3

The starting point would be to incorporate an Arduino-compatible MQTT library in uLisp, but there seem to be several to choose from. Do you have any recommendations?

#4

I have used the Knollary PubSubClient from Arduino successfully. I have used it via the Tasmota project with the Arduino IDE to control pumps with flow control (also using Node RED). The reason for a uLISP implementation is having a high level language like uLISP would let me write the application logic in a more reliable, consistent manner. C / C++ is not good for this especially if you are not looking at the same codebase regularly. Tasmota covers all the easystuff, but makes complex logic almost impossible. If someone has the skill to make a uLISP pubsub library, I and I suspect many others would be prepared to make a financial contribution towards it.

I am also learning Common LISP and have considered :

sourceforge.net/projects/arduinolisp/ & https://ecl.common-lisp.dev/main.html

I do love the cleanliness of the uLISP project, its community and attitude as well as its well written documentation, and as it works on all my preferred micros, I would prefer to use it rather than cross compile, upload and test, essentially breaking the lovely LISP workspace model.

Warm regards

Stephen Morgan

#5

Hello I’m very new here but I’ve had my hands in several Lisp dialects. :D Your uLisp dialect is MUCH more powerful than what ships with AutoCAD. You should be proud of that!

My wish would be for something rather controversial but I really feel that Common Lisp style macros would let me program the programming language a bit more than relying ONLY on combinators and closures. You can go a long ways with those but defining new syntax is a luxury. It’s really the only feature I’ve missed because you implemented quite a bit given space constraints.

In this way, we could grasp at a subset of Common Lisp on a per case basis without having to accrue the cost of having huge libraries. It would also take some of the burden away from the people maintaining the source code as users could define their “missing” forms. I realize macros are a bit controversial with the way people use Lisp today, but I think when carefully used they are one of the features that sets Lisp apart. I would prefer unhygienic macros … yes I realize they’re a bit more “dangerous” but they’re also a bit more powerful. I will say that I like how uLisp is sensible and traditional and regular in its syntax. I don’t think reader macros are super important. I’d love to have what we’ve got in Common Lisp as far as “normal” macros go. I’m not much of a C guy or I’d take a crack at implementing them myself. :D I don’t know what would be required beyond implementing backquote, list splicing, and defmacro which does not evaluate its arguments immediately.

Anyway, thank you for a wonderful product that provides a very flexible and dynamic way to program microcontrollers. It’s made for a handful of very entertaining weekends.

#6

EQUAL. :) Yes, I can define it, but it would be sweeter if I didn’t have to. :) So that I can compare lists…

#7

OK, I’ll put that on my to-do list!

#8

I’d love to have a tutorial on a simpler way to extend ulisp.

If this could be done somehow in the builder, where I could add the external library functions in one place, I’d be thrilled!

#9

@devcarbon I assume you’ve already seen this: Adding your own functions.

It’s pretty simple, but I agree that it could be simpler; for example, if all the extensions could be put in a separate source file, and automatically incorporated if that file is included in the build. I’ve thought about how to achieve that, but it’s a bit tricky…

I don’t think the builder is the answer; that’s something I created for my own use, and it’s not really user friendly.

#10

@Pixel_Outlaw Thank you for your comments about uLisp! I’ll think about whether it would be possible to implement macros, at least a subset.

#11

Hello,

I just wonder if it would be possible to run uLisp on top of the Nordic nRf9160. So you would be able to natively reach lte-m or nb-iot networks.

I was checking some forums and it looks like the only supported platform is the Zephyr Os. Would it be possible to add a feature or function or manual in order to run it there?

Thanks a lot!

#12

Is there an Arduino core for the Nordic nRf9160?

#13

I don’t think there is. I think @chamobit was trying to asking if there is ulisp support for other frameworks, or rather the Zephyr framework in particular. Maybe ulisp zero would? I can’t remember if it requires an adruino core or not.

I am a little curious how much would need to change to not be dependent on the arduino core.

#15

So here’s a thought, granted it is probably far-fetched, but I think it would be really cool for ulisp to also optionally compile down to c/cpp in a way similar to microscheme. https://ryansuchocki.github.io/microscheme/

So you could interactively develop in interpreter mode, and once you’re done, compile to c/cpp with whole-program optimization.

#16

Currently uLisp depends on the Arduino core for all the hardware interface support, such as digitalwrite, pinmode, with-spi, with-i2c etc. To not be dependent on the Arduino core one would effectively have to write an Arduino core within uLisp.

You can comment out all these functions, in which case uLisp will not be Arduino dependent. For example uLisp Zero is Arduino agnostic.

uLisp as a Library + Outside of the Arduino IDE (PlatformIO, etc)
#17

Hello,

It looks like there is not support for nRF9160 :( at least not officially as per this.

" Zephyr has some documentation on how to include third-party libraries here and here.

But I would assume it depends on how “arduino-y” the library is. Zephyr doesn’t provide the Arduino runtime libraries etc.

We don’t support nRF9160 development without Zephyr RTOS so if you go this route, there is a lot of Nordic provided support that won’t be available to you"

Best Regards

#18

Excellent, thank you very much!
Here is some nice documentation on them. (Though you are probably familiar)
https://cl-cookbook.sourceforge.net/macros.html

Backquote from there might be a good low hanging fruit initially.

#19

Thanks for the link. That’s interesting but seems quite esoteric - can you suggest a macro that an Arduino user might want to write, for something that couldn’t be done any other way?

#20

To get the ball rolling here’s an example I’ve thought of:

A C programmer would like to extend Lisp with a for-loop construct so they could write something like:

(defun test ()
  (for ((i 0) (< i 10) (incf i))
    (format t "~a ~a~%" i (* i i))))

Here’s the Lisp macro that would achieve this:

(defmacro for ((init condition increment) &body body)
  `(let (,init)
     (loop
      (unless ,condition (return))
      ,@body
      ,increment)))

It could also be written slightly less elegantly without backquote like this:

(defmacro for ((init condition increment) &body body)
  (list 'let (list init)
        (append
         (list 'loop (list 'unless condition '(return)))
         body
         (list increment))))

Just to clarify: the above code doesn’t currently work in uLisp.

#21

Yep that’s the case for a macro!

Here is an actual one I would have liked when I was playing with the minesweeper clone on my Raspberry Pi Pico.

Macros are special because they delay evaluation, so in the body there (&body is the same as &rest) you can see I delay evaluation until I’ve wrapped and bound the required dotimes around it. This new form with-iterators is something you would have to implement in C. However with a macro I’d be able to have my cake and eat it too without burdening you. :) There are some gotchas for the programmer on the user side like unintentional capture and multiple evaluation. But to me this is a very powerful feature with countless uses beyond my loop below. :)

The nice thing about this new form is that it grows in a linear way avoiding manual nesting. The programmer (me) doesn’t really care that it generates nested dotimes I really only want to specify iterators - so a macro is born.

I’m not much of a C guy but I do know that nearly all Common Lisp dialects are implemented in it.
There might be some source code in ECL, Clisp, GNU Common Lisp or SBCL.
But the SBCL guys are doing some heavy voodoo for speed. I think some of the heavy hitters in the CL might be willing to help out if need be, your dialect is pretty close to Common Lisp already.

You might even get some helping hands from the IRC channel #lisp on the server irc.libera.chat !

macro-expand
macro-expand.png611x863 47 KB

Anyway, yeah I think you’ve grokked the idea.