SurfingDude:
As to frosting, I think the conceptual bridge between the arduino world and the C/C++ world is something to keep. Many recipes exist to solve problems in in the semicolon-bounded world and I'd want to be able to copy and paste them into any new world, or take my arduino work and learning onto an industry platform.
At least syntax-wise the language is definitely going to resemble C/C++ as close as possible, exactly for the reasons you mentioned (compatibility with existing code and ability to transfer your projects 'back' to C if required)
I also want to keep the transpiled code close to the original (keep variable names, etc) and also format it in a nice and readable way.
What I am still 'on the fence' about though - are the C pointers, right now I have not implemented them in any way, and I am not a big fan of the original syntax (especially things like having the same '*' operator to declare and dereference a pointer) So if pointers will be kept in the language - they will almost certainly undergo some syntax changes. I know that pointers are super useful, especially on embedded systems, but I will need to think more about the best way to implement them before they appear in the language.
SurfingDude:
As to the cake part, the thing that we lack most are effective ways to deal with concurrency. This is holding back the use of multi-core hardware and leads step-by-step programs into problems of semaphores and deadlocks, especially now when we try to use interrupts to multitask.If there is to be a new language I'd like it to focus on improving the cake. Maybe with objects that communicate messages via queues, but do computation in the way that is already known and accepted. The standard frosting looks just fine.
This is exactly what I have been thinking about myself. Better support for concurrency even on the level of language constructs would be a big win (note, when I say concurrency I don't mean threads)
The best idea I had so far, which would not require a complex runtime, is implementing a kind of an 'event loop' where objects would emit events and react to them. This is similar to message passing and would not change the code structure much.
Another idea I had - is being able to write asynchronous code in a synchronous way. For example, the delay construct could be limited to the current code block, so it does not stop other things from executing at the same time:
void [b]spinMotor[/b] () {
setPin(9, HIGH)
[b]delay[/b] [i]5s[/i] [color=gray]// <- will only delay the code inside the 'spinMotor' function [/color]
setPin(9, LOW) [color=gray]// and won't block other code execution[/color]
}
But these are of course 'Big' ideas for the future. Right now I am focusing on making a good language for beginners that is easy to understand and building some helpful tools around it.
CrossRoads:
If you didn't have s setup() function, where would the stuff that only needs to occur once happen?I didn't see the unsigned long type in there. Will that be coming to support the time elements?
Will bit manipulation be supported?
I decided that I will use setup() for what it was intended.
Sorry, I forgot to mention the unsigned types in the previous update, but I added the unsigned long and unsigned int in the form of: uint, ulong
All the time literals are assigned a 'ulong' type by default at the moment (this can be optimised in the future)
Regarding bit manipulation - yep, all C/C++ bitwise operations are supported (actually they are just mapped directly because the syntax is the same)
I will definitely publish a list of all the language features and entities that are supported once the demo is released.
[EDIT]
Sorry, I started writing this reply before the last 3 messages were posted.
For now I would like to focus on getting the minimal functionality into the language and make it a 'friendlier' version of C/C++ which is more geared towards Arduino development. However, I would definitely like to improve on some bits in the future versions (which does not mean dismissing the original concept). For example by providing an easier way to express what you want to do then you would in C/C++ (I already talked about this in my reply to @SurferDude's comment)
The best approach would of course be to keep the existing 'cake' untouched, but also add some additional flavours to it (and I don't mean 'overload' with features, we already have C++ for that)
I would also like to keep the UNO chips as the primary target at least for the nearest future (this is still by far the most popular version of the Arduino)
The more modern chips do provide some really cool possibilities, I think we can discuss this as time goes.
