Messages

181

Ideas / Re: Built-in recipe handler/make replacement

« on: July 23, 2014, 08:05:15 AM »

I must have missed these (the forum doesn't show new messages at top level somehow).

Yes writing takes a lot of time, but is also a lot of fun.
I will look into your SPECS and cbang posts, always nice to see similar thoughts!
When studying Apple's Swift recently, I was amazed how much similarity there is
between modern languages. Almost all use 'import' and 'module' for one thing.

Cheers,
Bas

182

Ideas / Re: Built-in recipe handler/make replacement

« on: June 30, 2014, 07:45:57 AM »

I'm not familiar with TypeScript, but am a fan of doing a larger project in C2 to see which
issues we run into. I currently write down all the (minor) issues I run into when programming
C and then try to think of a better solution. A lot of these solutions can already be found in the
D programming language. They have some really cool ideas, their macro-replacements for
example.

Because implementing the IR generator to interface with LLVM is taking so much time, I
have changed my focus on the C generation first. That is a lot easier and then the project
becomes usable for programmers who want to use/try the language. To still show some
powerful features, I'm also working on c2reto, the C2 REfactor TOol. 
This tool should be able to do global renames, drag'n drop reordering (even across files)
of functions,types and globals, etc.

183

Ideas / Re: Built-in recipe handler/make replacement

« on: June 24, 2014, 08:03:44 AM »

Good points!

For most C++ project I currently work on, we use either CMake or qmake (Qt).
These behave at a level of a C2 recipe. I think we can avoid most of the Java case,
since in C2 there will be certain hooks for (Yacc) generated files etc. I'm even
thinking of integrating lua here. So that way a developer can run scripts at
certain points. That should be enough for 99.9% of the cases. The weird 0.1% will
have to use make and Plain old C

But you make a good point. The best argument I have for integrating a build system
is that for C there are Soo many build systems, that something must be missing.
Additionally forcing developers into a common way (a bit like Python), is something
C developers are not used to, but does yield significant speedup is development time.

184

Ideas / Re: Weird ideas #3: resource control

« on: June 19, 2014, 08:18:32 AM »

Yes, I (and a lot of others) think this is the most powerful feature of C++, destructors.
I've seen constructions in C also. The source code of Systemd uses this, you use a
GCC specific attribute, to register a function that gets called when the block exists.
This is used to free stuff like your example. I think in the systemd case, they should
have used C++ instead, because you should use a language in a way the designers
intended. I would *love* adding some C++ features like functions on objects or
interfaces, and destructors, but not in the C++ way. That would be C2++ and is
currently planned for 2034 

185

Ideas / Re: Weird ideas #2: variable sized structures

« on: June 19, 2014, 08:11:40 AM »

Hmm interesting.

C2 currently has something called 'incremental arrays'. This means you can do:

int

• array;

array += { 1, 2 }
...(other code)..
array += { 4 }

elemsof(array) would return 3 here. Maybe we can re-use the same '+' symbol?

186

Ideas / Re: Weird ideas #1: primitive data type sizes

« on: June 19, 2014, 08:08:06 AM »

Hi Kyle,

You are already on the right track, since I can't agree more. C2 has this builtin:
int8, int32, int64, uint64 etc. Also bool.
keywords unsigned, long, short etc are removed. So a base type is always a single
word.
What is still unclear is how to handle uintptr_t etc. So an integer type to hold a
pointer value. I get a lot of these when building/patching code to work on both 32 and 64-bit
systems. Do you have any experience with this?

187

Ideas / Re: Apple's proposed addition of modules to C/C++

« on: June 19, 2014, 08:04:02 AM »

Hi,

I've mentioned this here: http://www.c2lang.org/forum/index.php?topic=15.0

In the Clang codebase there are Modules (from 3.4 I think), but still Beta. The problem
IMHO is that adding this is nice, but severely limits the options. In C2 we get a lot more
mileage from this concept (like global checking of unused etc)

188

Ideas / Big Renames

« on: June 03, 2014, 02:15:29 PM »

After a lot of thinking, I've decided to finally rename package -> module and use -> import.
A module is more a part of something bigger, while a package has something complete in
the name. Also it conforms to a lot of new generation languages.

189

Implementation Details / Update from LLVM 3.3 -> 3.4

« on: May 21, 2014, 08:32:00 PM »

Hi,

Upgrading from Clang/LLVM 3.3 to the latest 3.4 has been on the TODO list for a while, but has been
pushed minutes ago. The nasty part was that I had to manually compile GCC 4.8.2 on Ubuntu 12.04
32-bit (my laptop) to get to compile LLVM/Clang at all. On my desktop (Arch 64 bit, GCC 4.9.x), I
required some testing. The upgrade was a lot less work then the 3.2 -> 3.3 upgrade, so maybe the
Clang internal API seems to be stabilizing as well..

190

General Discussion / Results of language-enabled dependency generation

« on: May 12, 2014, 12:46:03 PM »

Today I've pushed the functionality to let the C2 compiler generate the full dependency graph for a project.
The output is in XML form and shows types, (global)variables and functions and their complete relationship.
Also the containing package is show and optionally the file they're in. (yes functions are in a single file! no
header/c-file issues here  )

To show how this works, I've analysed the puzzle.c2 example (c2lang.org/docs/puzzle.c2).
The resulting architecture is show in c2lang.org/docs/puzzle_arch1.png.
Then I refactored it, by extracting some functions/vars into a separate file (really easy, just move them to
a new file, add that to recipe and done). This results in c2lang.org/docs/puzzle_arch2.png.

While the example is very small, it already starts showing the potential of the language/tools.
The next step will be to integrate these into c2reto (C2 refactor tool), so that drag-n-drop refactoring
and continuous visualization is possible. I can't wait to see how that works out!

191

Implementation Details / update wk17

« on: April 23, 2014, 08:29:28 PM »

Hi,

Current progress on the C2 compiler has focused on the Analyser. Currently there are
over 250 unit tests to make sure it keeps working. Not an easy thing. Recently I've
added some checks for array initializations. While I've been programming C for a long
time, I've never realized just how many details there are to a compiler. Some situations:

    int[]   a;    // @error{definition of variable with array type needs an explicit size or an initializer}
    char[] b;   // @error{definition of variable with array type needs an explicit size or an initializer}

    int[]   c = 10;  // @error{array initializer must be an initializer list}
    char[]  d = 20;  // @error{array initializer must be an initializer list or string literal}
    uint8[] e = 20;  // @error{array initializer must be an initializer list or string literal}

    int[]   f = "foo"; // @error{array initializer must be an initializer list}
    char[]  g = "bar";
    uint8[] h = "faa";

    char[3] i = "bar";
    char[3] j = "hello"; // @error{initializer-string for char array is too long}

and that's just a tiny part.
But with a *Lot* of small steps, we're getting there. Slowly more and more situations
are being handled. While C2 is still a far way from being a full fledged C alternative,
the Analyser part is definitely showing it's advantages over gcc/clang. Getting warnings
about unused struct fields and unused types is very nice!

Hopefully the next update won't take as long as this one...

Bas

192

Ideas / Re: Switch statement

« on: April 14, 2014, 09:28:11 AM »

Nice one.
The choice would then be between more compact cases and more explicit code..

I also found another choice: In languages like Ada, there is a default break, but you
can specify more matches in single case. Something like:

switch (x) {
case 1|2: ..
case 3|4 ..
}

193

General Discussion / Interesting site (warning: radical ideas)

« on: April 08, 2014, 07:31:34 AM »

For those who want to 'think outside the box' about software development,
I've found a very nice ideas and set of tools, called Rebol.

http://www.rebol.com/

Gives some food for thought.

194

Ideas / Switch statement

« on: March 27, 2014, 09:11:44 AM »

Some new languages like C# changed the default behavior of a case statement so that it breaks by default.
I wonder if this would be an good for C2 as well. It would make writing case statements for concise, but we'd
need a keyword to specify fallthrough (fallthrough, next, ?). I currently lean to the default-break, unless there
are good arguments for default-fallthrough.

195

General Discussion / Re: Integer Literal checking

« on: March 27, 2014, 09:03:54 AM »

I currently implemented Option 2 and I think it works just fine.

constexpr is indeed a nice option. I wonder if LLVM's IR can optimize functions like factorial etc?
It would not a problem to add a constexpr concept later on. The flags are already present in the
AST for other const stuff like numbers and constants etc.