Picolisp
A college pointed out Picolisp because of my work on Picobit.
The paper mentions Picobit and discounts it because a foreign function interface would be difficult to implement.
This isn't exactly true: I've been linking Picobit programs into ARM executables, and that certainly means I could link actual function addresses should I want to: I could generate C code containing a vector of the foreign function references, and link this into the resulting program. Once I have done this, I can define a foreign function primitive that uses the vector to call them. This will certainly be some work, but not as much work as writing Picolisp!
That isn't what I'm currently planning to do, however. I plan to copy Unix and define a limited set of operations for IO, define device numbers and route these calls to an appropriate driver according to the device number. One of the calls will be ioctl, which will allow arbitrary scheme data structures. I could use python's approach of providing a library to generate vectors that correspond to C structures.
Unix has rather outgrown this model, but micro controllers haven't: they still have a small set of physical devices, and memory limits the number of virtual devices like sockets or pipes, so a numbering scheme will work.
I also know, because of the Raspberry Pi, that this abstraction works for most of the peripherals I'll want to provide - since the Pi has GPIO, I2C, SPI on board. I can copy that.
This doesn't require me to create a new mechanism: The few functions I'll need I can add Picobit primitives for.
I may still want a foreign function interface at some point, but I reckon I can get a long way without one.
Picolisp might well be useful though: I should look at it's database and networking code - it's likely to fit fairly well.
The paper mentions Picobit and discounts it because a foreign function interface would be difficult to implement.
This isn't exactly true: I've been linking Picobit programs into ARM executables, and that certainly means I could link actual function addresses should I want to: I could generate C code containing a vector of the foreign function references, and link this into the resulting program. Once I have done this, I can define a foreign function primitive that uses the vector to call them. This will certainly be some work, but not as much work as writing Picolisp!
That isn't what I'm currently planning to do, however. I plan to copy Unix and define a limited set of operations for IO, define device numbers and route these calls to an appropriate driver according to the device number. One of the calls will be ioctl, which will allow arbitrary scheme data structures. I could use python's approach of providing a library to generate vectors that correspond to C structures.
Unix has rather outgrown this model, but micro controllers haven't: they still have a small set of physical devices, and memory limits the number of virtual devices like sockets or pipes, so a numbering scheme will work.
I also know, because of the Raspberry Pi, that this abstraction works for most of the peripherals I'll want to provide - since the Pi has GPIO, I2C, SPI on board. I can copy that.
This doesn't require me to create a new mechanism: The few functions I'll need I can add Picobit primitives for.
I may still want a foreign function interface at some point, but I reckon I can get a long way without one.
Picolisp might well be useful though: I should look at it's database and networking code - it's likely to fit fairly well.
