Cero

[suncore]

Hi all!
I've created a small flavour of C++ called Cero. I find it useful and would just like to share it, maybe you will too. Cero is basically C++ without semicolons and curly braces, plus some additional stuff.
See http://cero-lang.org

Thoughts?

-- Henrik

[manasij7479]

Why did you decide to modify C++ and not design a general purpose language from scratch?

[phantomotap]

No header files

O_o

+++ public
+decl
+++ private
#include <iostream>
#include <string>
+void myprint(std::string s)
    std::cout << s

If you are going to "bake" header files from `import' statements and the `ce' file, you should handle include files as `import'.

If you are correctly handling forward declarations on behalf of the client, you can use the same juice to eliminate the need for `+++ public' and `+++ private'.

+++ public
+decl
+++ private

In other words, you may assume the above unless otherwise stated.

No curly braces and semicolons - some exceptions

Why not "overload" "null assignment" for that context? The expression would be familiar to Python, Javascript, and several other programmers.

void fun() = null;

You'll also find relatively few contexts where brace initialization occurs in C++11, and if you don't consider "in-place" contexts you can easily parse comma-delimited lists allowing a client to forgo the braces if they put everything on a single line.

Breaking long lines

A line beginning with a unique operator may be parsed no differently from a line ending with a unique operator.

Why did you decide to modify C++ and not design a general purpose language from scratch?

Can't be done; programmers are doomed to repeat the mistakes of earlier languages.

People shape the world with tools, but the tools inevitably shape the wielder.

Soma

[suncore]

Why did you decide to modify C++ and not design a general purpose language from scratch?

C++ as a base is good enough for me, but I wanted a few minor changes to the syntax. Also, the effort involved in designing a new language is huge.

-- Henrik

[suncore]

<No header files>
If you are going to "bake" header files from `import' statements and the `ce' file, you should handle include files as `import'.

The idea is that 'import' imports Cero files and #include includes C++ files. I think it's good to keep them apart.

If you are correctly handling forward declarations on behalf of the client, you can use the same juice to eliminate the need for `+++ public' and `+++ private'.

+++ public
+decl
+++ private

In other words, you may assume the above unless otherwise stated.

The idea with "+++ public" is that you put everything to be exported in that section. That way you don't have to put "+" on every little thing to be exported. That method can be used for e.g. exported functions where the function definition header can be reused/copied to the +decl statement.

<No curly braces or semicolons - some exceptions>
Why not "overload" "null assignment" for that context? The expression would be familiar to Python, Javascript, and several other programmers.

void fun() = null;

You'll also find relatively few contexts where brace initialization occurs in C++11, and if you don't consider "in-place" contexts you can easily parse comma-delimited lists allowing a client to forgo the braces if they put everything on a single line.

Might be difficult for e.g intializers for multidimensional arrays where the braces correspond to the structure of the initialized data.

<Breaking long lines>
A line beginning with a unique operator may be parsed no differently from a line ending with a unique operator.

That's a good idea. I will have to think some more about it.

Thanks for your comments.

[Mario F.]

C++ as a base is good enough for me, but I wanted a few minor changes to the syntax.

Syntax... frankly, the least useful aspect of your proposed language. More interesting to know is what is the impact of your changes on the compiler speed and generated code.

[Yarin]

[snip] programmers are doomed to repeat the mistakes of earlier languages. [snip]

like OOP

^_^

[Elkvis]

I rather like curly brackets and semicolons. doing away with semicolons makes it more difficult to have multi-line statements, and curly brackets make scope more clear to the individual reading the code, even if they aren't entirely necessary for the compiler to understand it.