coffeescript programming with espruino

Is it possible to write scripts for espruino with compiling languages, coffeescript e.g., with compilation on the fly?

Not JIT but with XCompile - so: on the pseudo-fly.

As @Gordon pointed out in various posts, there is not enough memory to do JIT things of that magnitude - and speed would loose out for sure (that's why Espruino has its own unique engine, and not, for example Rhino, or V8,...). That approach also allows to just pick and choose what fits and makes sense, and grow over time gradually to full functionality - full meaning: everything that is very useful for the very platform at hand. It would though be possible to xcompile beforehand (in the Web IDE) and combine it with advanced minification. On the other hand, any of that kind technology makes it more difficult to exploit dedicatedly what a JS platform on a microchip has to offer. CoffeScript creates much more compact source code. In order to keep that going forward, the xcompiler needs to be aware of how the target JavaScript achieves similar effects, including minification. For simple constructs as found in CoffeScript's introduction, mapping looks trivial, and related overhead is predictable. What about nested closures? There is only that much of abstraction layering one can put on top of the core API before loosing touch with reality - that API. - 'It is just JavaScript' is easier understood than implemented.

If there was a coffeescript REPL (I guess there is?) you could probably modify it to send the code you write direct to Espruino - a bit like in the implementation of https://www.npmjs.org/package/espruino-c­li?

Espruino won't run CoffeeScript directly, but there's no reason that you can't compile Coffeescript instantly on your PC, and then send the JavaScript to be executed,

There is a coffeescript REPL: http://coffeescript.org/documentation/do­cs/repl.html

You would have to run it on the client and modify the included eval function so that it sends the compiled JS to the board instead of executing it.

Or make your own REPL. Compiling little bits of coffeescript code into javascript interactively is quite easy to do:

coffeeCode = '((s)->console.log s) "hello"'
jsCode = require('coffee-script').compile coffeeCode, {bare: true}

You would just have to read coffeeCode from stdIn and send jsCode to the board. The option bare=true is important because without it, the coffeescript compiler wraps everything in its own closure to keep the namespace clean. In that case, if you compile and run "a=5" and then compile and rund "console.log a", it would print "undefined", unless you specify bare=true

I will look into it once I get my Espruino board. Still waiting for it to ship...

@Dennis. you hit a crucial subject regarding the 'qualities' if Javascript: do yo want to use Javascript in a light weight and hybrid mode geared towards the (memory and execution speed constraint) Espruino / uController platform/implementation or for 'strong' desktops and even stronger backends. Being very familiar with the latter, I was glad @Gordon made me think about this and 'adjust my attitude'. No insult here for that a-word, but it matters. For sure I do not want to be stupid and forget what I 'learned' about software modularity, robustness, reuse, maintainability, etc., but it IS a different way of thinking and doing things.

In todays approaches, one tries to keep the namespace 'clean' by using the various require techniques. But even those have their differences. This though does not come for free, and is even more - up to prohibitive - 'costly' on execution time, especially in Espruino context, where interpretation happens from source code and not from an internal JIT compiled 'byte'/'token' code. Any extra 'layer' eats over-proportionally into the resource pie(s), even more so if these layers are not natively implemented. Javascript's core has come quite far from the way it has been incepted. - and I like it. On the other hand: It is not the language that makes the life, it is what we say with it.

Currently I'm working on things in the WebIDE... and that would be the perfect place to make such things happen as using just any source and make sure on upload to take care of what has to be taken care of. It works as long as all participating pieces (modules) follow the same structure... since globals are a crucial part of (plain) Javascript and execution context, it is easier said than actually followed. How would the 'system' know what it pulls in? There is just so much semantics you can put into the .js file extension: Javascript... and that means a lot of different things for different contexts.

Espruino's require('moduleName') has a very simple, straight forward implementation. Again, no offense taken for any of these characterizations. The function serves well balanced what it is intended for and has even neat features for in what sequence it looks where to find the module and what shape the module is in it. Personally, I would like a bit more details in the reference doc, especially about how it works, when it applies, what it does when... assuming that most Javascript users venturing into Espruino come from a Web usage and node.js context as best. Latter does not even apply to me, even though have a server-side oriented past but worked most on the client-side/browser in regard to Javascript.

Therefore, I'm still adjusting my thinking for and shaping of solutions to run in Espruino context without giving up pushing the envelope(s)...

Looking forward to hear about progress and experience over a coffee... ;-)

@allObjects: I didn't mean to express any preference with regards to namespaces. My point was just that in a REPL, it doesn't make much sense to execute every new line in its own closure. Because the typical use case of a REPL is to try things out and that most likely relies on executing things in the same namespace. Once you have a complete program, it's a very different story.

I like Gordon's approach to have a REPL at all for communicating with a board, and to interpret source code directly on a board instead of compiling it. I just never liked the syntax of JavaScript. CoffeeScript fixes all that, this is why I code in CoffeeScript. I have an idea how to make the Espruino console work with CoffeeScript, I'm just waiting for my board...

@Dennis, have you seen the espruino-tools repo?

It doesn't currently implement a REPL, but it could (and probably should) do (which would be really handy). If compiling CoffeeScript really is that easy, perhaps it would be possible to add a -coffeescript option that just shoved everything through the coffeescript compiler first? :)

It actually uses EspruinoTools, which @allObjects mentioned. You could potentially add a plugin for that so the Web IDE could take CoffeeScript too - but I wonder whether the CoffeeScript compiler would run under Chrome (not node.js).

There is always the option to send the stuff 'over' to a (node.js) 'server' for the compile send the returned compiled artifact the board.... or store it in the module folder... or...

It should be possible to accessing the desktop that runs the WebIDE with a http request safely/securely enough by setting some TBD config in, for example, the project. The WebIDE is doing similar things to get the (module) code through google's closure compile service when uploading code with required('moduleName) to he board... under certain configuration circumstances... does it still, @Gordon?

For other tool chains I'm thinking along the same lines... javascript or any to javascript or native compilation, shrinkwrapping, packaging, etc., , etc...Doing so has most likely to consider OS variations and versions across Win-LIN*-OSX. It is though not anymore as bad as it was even a few years ago.

Yes, doing it server-side would be very simple...

In fact as you suggest @allObjects it would be trivial to create a plugin that added an optional URL in the Web IDE settings. When set, the Web IDE could then POST the code to that URL, get the response and send that to the board.

People could then easily add their own processors without having to change the Web IDE.

I really like this suggestion! It would be nice then if we had somewhere to share these processors for others to try and use as well, maybe? Probably overkill with a sub forum, but maybe a sub-page on the site somewhere? Then just PR to the documentation github?

Yes, that sounds good... Maybe make it a semi-colon separated list so that more than one can be applied.

Later on the Web IDE could even contain a list of well-known ones that could be selected.

High on my list would be a preprocessor that added constants for all the STM32's peripheral registers (for peek and poke). There's already JS code for this in Espruino, but I can't actually add all of them as it'll fill up the available memory. Instead we'd want to just detect them and replace them with their numeric equivalents.