Will Electric Imp's Squirrel evolve?

#1

Hi Imp people,

I’m wondering if Electric Imp are open to further development of this implementation of the Squirrel programming language? Or will the core language and standard library definitely stay as-is, and development just focus on expanding the Imp API?

In particular:

  1. If new standard library methods are added in upstream Squirrel, should I put in feature requests to add them to Imp’s version?
  2. Would you consider adding threads (coroutines) if a good case could be made?
#2

Generally we intend to track upstream where applicable, though there has been a small amount of divergence - we do have to ensure backwards compatibility for customer code. There are commercial products which have not had their app code updated in 5 years, though they’re running the latest OS.

Threads were actually on the wish list at the start; the issue was simply that originally, the weight of each one (in terms of RAM usage) was a bit prohibitive. These days it’s much less of an issue due to optimizations and more RAM on most imps so they probably should come back.

#3

Great, thanks for that @hugo. I would expect to keep backwards compatibility, but good to know you’re open to updates. I’ll try to get together a list of requests together soon (the first one that comes to mind from upstream is string.startsWith()).

There are some new features I’d like to see for Squirrel generators. I’m discussing these with the upstream creator/maintainer, where he has pointed out that most of these already exist upstream, but for threads instead of generators. My ideal outcome is probably for those thread features to be implemented for generators upstream, and then for those changes to be merged into Imp’s version (then I wouldn’t mind about not having threads). If anyone wants to have a say or see what that’s about, see the issue on Github.

#4

@hugo I’ve had a look and come up with a short list of updates from upstream that I’d like to see in Imp’s Squirrel:

There’s no big change to the language here, just some library additions for convenience. There’s a lot of other stuff in the change log too (bug fixes, performance enhancements, internal changes) that someone with a better understanding than me might appreciate.

As a much bigger request… the core regexp library is kind of broken. Is this something your team could look into? There’s at least one bug with greedy operators not matching in the way that one would expect (see this issue), and there’s no documentation for how they do match. It’s in need of a rewrite IMO (or replacement with some suitable existing library). Depending on how it was done, this change would mean either breaking backwards compatibility (in a small way though, might be worth it) or using more code space to include both versions, so there are downsides to consider. Reliable regexps would be super useful on the Imp though, and a great contribution to the Squirrel community on the whole.

#5

We can’t break backwards compatibility, which really limits what we can do with regexp. This is why we have re2 on the agent side, but this is far too big to fit on the device.

Sure there are things that could in theory be done (default mode, “fewer bugs” mode) but right now we have other things to work on besides regex. If there was an upstream fix then we’d look at integrating this.

Currently we have other squirrel changes scheduled to be merged in release 44 (40 is in test right now, 41 betas are with select customers) - so we’ll probably revisit the extra string things at that time.