Go Down

Topic: Designing a new programming language for Arduino (Read 14126 times) previous topic - next topic

YemSalat

#60
Nov 23, 2015, 02:34 pm Last Edit: Nov 23, 2015, 02:49 pm by YemSalat
I think requiring it provides consistency that is very valuable for beginners.
...
strcat() is the obvious solution whereas sprintf() is more powerful but uses more memory.  The standard Arduino implementation of sprintf() does not allow for the use of float variables although it can be added at the expense of more memory use.  snprintf() is safer to use than sprintf()
Thanks for the explanations, I guess its best to stick with snprintf() for concatenation, at least for the first version. I am planning to revisit this later though, for example could do char array manipulations behind the scenes, perhaps some optimizations could even be done during the code evaluation phase.


Another small question, regarding object creation on Arduino. Just let me know if I get this right:

Object foo; - this statement means that the object will be created on the stack and cleaned up automatically (e.g inside a function)
Object* foo = new Foo(); - vs this, creating an object on the heap and having to delete it manually.

Is the above correct?

SurfingDude

It's good that each generation strives to re-invent the tools of a previous generation. I grew up on FORTRAN vs ASM vs COBOL, so that's my generation. I moved into ALGOL, SIMSCRIPT, PASCAL, and ADA, and then into C and C++. I've seen lots of language wars and fought on several sides.

The question for this thread is whether we are re-arranging the frosting on the cake or are we making a new kind of cake?

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.

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.

Just my 2 cents.

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?
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Robin2

#63
Nov 23, 2015, 11:40 pm Last Edit: Nov 23, 2015, 11:41 pm by Robin2
If there is to be a new language I'd like it to focus on improving the cake.
I like your analogies (or are they metaphors).

I think that @YemSalat is making new tastier frosting to make the Arduino more accessible to beginners. And IMHO that is A GOOD THING and should not be sidetracked by a wish to change from a victoria sponge to a fruit cake.

I don't think there is any intention to displace the usual C/C++ Arduino programming system - apart from the possibility that the new system (if it works) is so attractive that everyone evolves towards it.

And there is an opportunity for another enthusiast to create a different cake.

However I can't help feeling that you are expecting a lot from a 2K Arduino. Personally I like the fact that it carries no baggage even though that means I have to create my own. That way I know exactly what is in my cake (sorry for the mixed metaphors)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

CrossRoads

Well, it can be geared toward the 1284 then - 16K SRAM, dual serial port, 32 IO, all the stuff that will let beginners avoid having to add more hardware right off the bat.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

SurfingDude

However I can't help feeling that you are expecting a lot from a 2K Arduino.
Hello Robin2,

There is nothing wrong with developing new languages. I went to school with a fellow who designed a new language for each problem, then implemented it as a set of functions.

We are in an industry where the rate of change is frightening. I am not expecting much at all from the 8-bit Arduinos. Today belongs to the 32-bit architectures with lots of flash and RAM.

Tomorrow belongs to multi-core processors, which are already available. But aside from Parallax Propeller nobody has figured out how to make a go with them in the enthusiast space. This is an open area for language designers, and within a few years there will be multicore ARM solutions in the Arduino price range.



YemSalat

#66
Nov 24, 2015, 02:53 am Last Edit: Nov 24, 2015, 03:39 am by YemSalat
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.

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 spinMotor () {
   setPin(9, HIGH)
   delay 5s // <- will only delay the code inside the 'spinMotor' function
   setPin(9, LOW) // and won't block other code execution
}



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.

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.

YemSalat

#67
Nov 27, 2015, 04:17 am Last Edit: Nov 27, 2015, 07:01 am by YemSalat
Yet another update.


Unfortunately I did not have time to work on the project in the beginning of the week.
So I was trying to cram everything into the past two days.. I really want to release the first version over this weekend, but as usual the most tricky bugs show up right before the demo :)

Initially the IDE was just a prototype which I was planning to rewrite from scratch at some point.
But things did not go exactly as planned, so instead I was adding more and more code to the prototype.
I just HAD to refactor all of this, so I spent a good chunk of yesterday evening on that. Now all the code is much more tidy.

I also had a few cache issues with the IDE (those are the worst, aren;t they?) but I figured it out.

There are a couple things that I was planning to include in the first release, but will most likely have to postpone until future versions:
- I had to remove the 'save' button from the IDE, instead everything is auto-saved. It is just quicker to implement it this way, because a 'save' button means that I would need to keep track of the file states (saved/unsaved)

- I initially added syntax to support classes, so the standard 'library' could use them. But having classes means adding another step to the compilation, because class names can be used before they are declared, so I would need to first go through the code and collect all the class declarations. This step is inevitable though and I will be adding it at a later stage.
For now all the standard built-in functions - are just 'functions', so you have print() and println() for output, pinRead(), pinWrite(), pinMode() for pins, etc. (I will post a full list upon release)

Overall I am doing final polishing before the release , just wanted to give a quick update.

[EDIT] added a couple things to the post, fixed some typos

Robin2

Quote
everything is auto-saved.
I don't like that idea.

I often find myself making a stupid mess and it is great just to NOT save the file and re-load the original version.

I think if you must use auto-save it should have to a different file each time - with serially-numbered names. But that is very difficult with the Arduino IDE because of its requirement for the file name and directory name to match. I sometimes save a version with a name myProgram.ino.BK1 and the IDE just ignores it when it comes to compile time. (This is on a Linux PC).

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

YemSalat

#69
Nov 28, 2015, 07:29 am Last Edit: Nov 28, 2015, 07:42 am by YemSalat
I think if you must use auto-save it should have to a different file each time - with serially-numbered names. But that is very difficult with the Arduino IDE because of its requirement for the file name and directory name to match. I sometimes save a version with a name myProgram.ino.BK1 and the IDE just ignores it when it comes to compile time. (This is on a Linux PC).
You will still be able to 'download' a latest copy of any file at any time.
What I mean by auto-saving is that there is no way to loose whatever changes you make to the currently open files.

Its a bit hard to explain, in the IDE you can create new 'files' in the sidebar. You can download a copy of any of those files at any time, both source and transpiled C++ code (this code is to be pasted into Arduino IDE). But the files within the IDE itself are always saved, you can still Ctrl+Z to undo last changes, but it does not ask you to save it when you close the file. Does this make sense? (sorry, I am not great at explaining things)



Also, another quick question.

Do you think I should name the pin control functions the same way as they are on Arduino?

Right now they are pinWrite, pinRead, PinMode, which are shorter to type and all start with 'pin', which sort of 'namespaces' them in a way.
On the other hand they could be named digitalWrite/Read - that way the code can be transferred between languages easier.

PS sorry about the delay so far, just can't get enough time to work on this, and don't want to showcase an incomplete project

Robin2

But the files within the IDE itself are always saved,
That is the bit I don't like. Personally I only want it to save the changes when I say so. I am happy to take responsibility for my own failures. But I don't want my perfectly good working code automatically overwritten by some garbage that I typed and then thought better of. I do realize, of course, that the code needs to be saved before it can be compiled. Maybe I am misunderstanding when your program saves the code?

Quote
Right now they are pinWrite, pinRead, PinMode, which are shorter to type and all start with 'pin', which sort of 'namespaces' them in a way.
I rather like this style. It would be easy to have a few macros in regular Arduino code to make the same commands be converted to digitalWrite() etc.

It is probably a typo - but you have an uppercase P for your PinMode - be consistent (I prefer to start with lowercase).

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

YemSalat

#71
Nov 30, 2015, 06:30 am Last Edit: Nov 30, 2015, 08:56 am by YemSalat
That is the bit I don't like. Personally I only want it to save the changes when I say so. I am happy to take responsibility for my own failures. But I don't want my perfectly good working code automatically overwritten by some garbage that I typed and then thought better of. I do realize, of course, that the code needs to be saved before it can be compiled. Maybe I am misunderstanding when your program saves the code?
I think you got it right, and yes, as I have already discovered myself during testing that this can be a bit of a pain. (you can use Ctrl+Z to get the changes back, but if you reload the IDE - it won't help)
I wanted to auto-save everything just because it is quicker to implement it that way, but since I did not release the demo yet, I will probably just take a bit more time and do it properly.


I rather like this style. It would be easy to have a few macros in regular Arduino code to make the same commands be converted to digitalWrite() etc.
It is probably a typo - but you have an uppercase P for your PinMode - be consistent (I prefer to start with lowercase).
Oops, yep, that is definitely a lowercase. I was actually thinking of making it mandatory that all functions start with a lowercase ( and all class names start with uppercase ) and constants are all caps. I have not implemented this yet though, but I think it could improve the code style.


PS also, sorry again about missing the weekend release mark. This project obviously turned out longer then I initially planned (although I was not planning to make the IDE back then)

The compiler itself is complete (I blinked an LED for the first time with it yesterday :)
Right now I am just polishing all the stuff around it, so it does not feel too 'raw' when showcased.
I also want to make the project open source so the code needs to be cleaned up a bit (that's what I spent most of my time on in the last few days)


Robin2

you can use Ctrl+Z to get the changes back,
Sorry if I am labouring this point too much ... but just to clarify further ... (and this may be just my own foolishness)

Sometimes I get an idea for a substantial reorganization of a piece of code and rush in to make changes. After 30 minutes or so I have got completely confused. At that stage Ctrl+Z isn't really any help - partly because it is a sequential process and I can no longer remember all the changes I have made, never mind the order in which I made them. In that situation starting over is often easiest -  so dump all the changes and go back to the original version.

Don't worry about a few days delay. Although we might lose patience after 3 months  :)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

UKHeliBob

Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

YemSalat

Quote
That sounds very familiar.
Sometimes I get an idea for a substantial reorganization of a piece of code and rush in to make changes. After 30 minutes or so I have got completely confused. At that stage Ctrl+Z isn't really any help - partly because it is a sequential process and I can no longer remember all the changes I have made, never mind the order in which I made them. In that situation starting over is often easiest -  so dump all the changes and go back to the original version.
I don't think there is anything wrong with you, all developers I know are like that, that's why we use source control :)
This actually makes me think if it would be a good idea to add some sort of "Versioning" to the files, something that allows you to save the current version of the file - and then get back to it at any time. There can be multiple versions to one file. (This definitely won't be in the first release, but something to think about for the future)

Quote
Don't worry about a few days delay. Although we might lose patience after 3 months  :)
We are at 3 weeks and one day mark right now. (initially I was planing to be done in one week, hehe)
The first version of compiler is already done, now its all about making the IDE usable.

Go Up