-
Sat 2021.10.16
reply to post #6
'no case to be made that it is a semantic restriction of Espruino or its debugging mechanism'
No, not semantic restriction, I don't believe it is possible to insert the debugger statement within a list/container as, (previously discovered years ago) must be on it's own line. Haven't tested recently.
ref: 'then what's the point of Espruino at all?'
A month ago I put together some links on the history and comparison to the evolution of Arduino:
'I came here in the expectation that things would “just work” without too much hassle'
Arduino had an army of devlopers over a twenty year period while Espruino is one/couple/community in just over a five year period. IMO Espruino is light years ahead with it's ease of setup (just plug it in) and near instant ability to start writing code and interactive debugging. Major bonus for the young mind and those just exploring the world of code.
As this thread has now uncovered, agrees with my assessment that Espruino is starting down the path of bloatware trying to do too many things with too little resources. Microsoft tried that and look what happened to their marketshare.
'if you really hate the comma operator so passionately, why allow it in if and switch?'
That question should be directed at the originators of the project. I'm an end user like yourself with a need to support 10-16 year olds with just the basics along with the Blockly graphical editor. Espruino ver 1V95 was perfect as ES5 features are all I require.
Point of note: With the close of the Bangle V2 KickStarter campaign, It is likely that shipping will be under way with their limited time to respond timely.
You are reading a single comment by @Robin and its replies.
Click here to read the full conversation.
Robin
I don't quite understand the question. The comma operator is a normal operator valid in any full Expression (13.16 ). It is historically descended from Algol68's semicolon operator, and (despite the different precedence) semantically related to JS's
&&operator. Like&&it processes the left argument and returns the right; unlike&&it voids the left argument and proceeds unconditionally. In fact, I suspecta, bcould be defined (semantically) as!a < 2 && bor some such stupidity.Syntactically it has only one oddity, which is that it, like the bare assignment operator, is also used for other things, such as forming VariableDeclarationLists (14.3.2) and ArgumentLists (13.3), which means that there are places where the semantic expectation is an expression but the syntax restricts you to an AssignmentExpression to resolve the ambiguity of which kind of comma is expected.
In any case, none of this has anything to do with the conditions in control constructs, which are uniformly and uncomplicatedly Expressions (14.6, 14.7.2.1, 14.7.3.1, 14.7.4, 14.7.5, 14.12).
There's also no case to be made that it is a semantic restriction of Espruino or its debugging mechanism, since the semantically identical
while ((0, 0));parses and executes flawlessly. This is nothing but an issue with Espruino's internal grammar, as far as I can see, either a typo (I hope) or an utterly capricious decision to alter the syntax ofwhile ()while not even making the same change forif ().To the argument that this feature of the language is not pretty and adds confusion, all I can say is that today it was recommended to me that I replace
search: while (…) while (…) if (…) break search;(which Espruino does not implement) with(() => {while (…) while (…) if (…) return;})();. It does not appear that prettiness and lack of visual confusion is the driving force behind this project(!). And, for goodness' sake, if you really hate the comma operator so passionately, why allow it inifandswitch?Orthogonality and lack of bugs are generally considered virtues in the programming language community; I'm honestly not sure what's going on here. If it's that efficiency trumps usability, then what's the point of Espruino at all? C, or indeed assembly, is easy enough to write; I came here in the expectation that things would “just work” without too much hassle :-}.