Thanks for your reply.  Strict mode makes life a bit easier because I have a lot of scripts which get loaded and unloaded and I want to be careful about namespaces.  In strict mode, eval is not allowed to introduce new variables into the surrounding namespace.  'Arguments' are also simpler and cleaner.  More importantly, I _think_ it makes javascript slightly less insecure: see

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/Strict_mode#.22Securing.22_JavaScript

Maybe it's like bolting your front door even though all your windows are still open, but presumably better than nothing.  It is also claimed that using strict mode enables the engine to make a number of optimizations, which certainly won't hurt if it's true.  (To sum up, I think it's a better language in strict mode.)

I have read through your discussion with Vladimir from last year, and I can see that my offhand suggestion was terribly naive.  <cringe>.  Multiple value return in js is obviously an "interesting" problem.  Certainly, none of the ideas I have considered myself can solve all the problems.  Doing a _completely_ CL-alike multiple value return scheme would seem bound to make the compiler a great deal more complex for quite small returns (no pun intended).  I'm not too keen on the global variable,but that's my problem.  Of course, it would have to be declared if it should work in strict mode.

At the risk of embarrassing myself again: what about having a values macro return a closure which holds the multiple-value array and which pops a value off it every time it gets called? If you only want to return 1 value from values, or null, the macro could deal with that, and if you want to return a single function, ie (values (lambda () ...), the macro could wrap it in a lambda, to allow the pop() to return the desired anonymous function. The multiple-value-bind receiving macro could bind the functions appropriately.  Something like vlet* could nest calls to multiple-value-bind if you want to mix local assignment of strings and numbers and calls to multiple-value-returning functions but only use the first value.  It will still break if you bind a var to the return value of a non-values-lambda-returning-function, since vlet* assumes that function values must be popped (ie, funcalled). Just in case this idea is worth something, I am attaching these three macros ('fvals, 'fmvb and 'vlet*) which seem to do at least some of what is wanted, with some test cases.

And yes, it would be great to have compilation to Lua! Lua is very nice.

Regards,

Peter