Messages

196

Ideas / Re: D-language Modules/Imports

« on: March 27, 2014, 08:02:58 AM »

I did not have the intention to compare C2 to D here; just compare the import system, since that is very similar in
need/purpose. D can be seen as a 'replacement' for C++. C2 is covering the same domain is C. So whenever you
would use C for something, you could use C2. But for software that usually written in C++ now, maybe D can be
used. So the domains are different. C2 is a lower-level language than D, with all advantages/disadvantages.

197

General Discussion / Integer Literal checking

« on: March 12, 2014, 01:22:11 PM »

Integer Literals in code are constants like 10, 20, -100, etc
The analyser in c2c currently distinguishes between 3 types of expressions:
fully compile-time-constant:  basically any number
partial compile-time-contant: a + 10
not compile time constant: a, calc()

Full:
char a = 128;   -> error 128 not in range of char, range [0, 127]
char b = 800 - 700;    // ok, since 100 is in range
So the entire expression is evaluated and checked against the range.

None:
char a = b;    // error if type of b is larger than char.
So just the types are checked

Partial: (this is where it starts to get fuzzy)
char a = 128 + b;  // (b = char) so should this be allowed?
or the previous example:
char b = 800 - 700 + a;   // char a, should this be allowed?

Here there are some choices I think:
1 don't check any ranges of partial ctc expressions
2 only allow subexpressions to be of same < smaller type/value
3 check if range could be ok(Clang has a crude implementation of this)

I would prefer option 2, since it is the most safe option, but it would
restrict programmers too much perhaps. I think this would be ok,
but what do you guys think?

Bas

198

Ideas / D-language Modules/Imports

« on: March 05, 2014, 10:11:00 AM »

Hi,

I've studied the Module/Import system of the D language (dlang.org). D is a
language that tries to be a better C++. It's good to see that there are lots
of similarities between D and C2. This means that more people make the same
choices, which probably means that can't be that bad.

Similarities are:

• Concept of Package(C2)/Module(D)
• Package/Module have public/private symbols
• D static import are equal to C2 use
• D non-static import are equal to C2 use local (allows symbol use without prefix)
• Use(C) / Import(D) statement
• Import Aliases: use as (C2) / import io = c.stdio (D)

Differences are:

• D modules are single file, whereas C2 Packages can consist of multiple files
• D allowes Modules to be prefixed with a 'Pakage', c.stdio
• C2 has a build-system, D uses external one (like Make)
• D allows public import, C2 doesn't have this concept
• D allows multiple import in 1 line: import a,b, C2 doesn't
• D allows scoped import, C2 doesn't
• C2 doesn't need the module scope operator like D (.x)

I'm very interested in the public import feature. Does anyone have experience with this
(drawbacks, large-scale problems, advantages?)

Another think I'm still thinking about is the concept of something bigger than
C2 Packages. In D these are called Modules, but D also has a concept of Package.
The only use I discovered was that the compiler automatically looks for pkg.module
in pkg/module.d. But maybe in C2 we can use this for something else..

Finally, I think 'Module' reflects the meaning a bit better than 'Package', so
maybe C2 will also follow this. Package was currently chosen to create distinction
from clang's 'Modules' concept.

Anymore?

Bas

199

General Discussion / C improvements

« on: February 26, 2014, 03:43:47 PM »

There are initiatives that try to improve the current C language. Below is a list of
initiatives I know of, but I'm also interested if there are others I don't know of yet.

• Clang modules
• Link-time optimization
• Clang Virtual FS (http://www.phoronix.com/scan.php?page=news_item&px=MTYwOTM)
• #pragma once
• pre-compiled headers
• Amalgation (merging c/h files together into 1 big file)

While these initiatives are nice, I feel they fall short of really improving the language. This is
understandable, because they try to remain compatible with C on a language level. I feel that
keeping this compatibitily at a lower (link/library?) level, allows for far greater improvements.
Hopefully we'll be able to demonstrate some in C2.

Edit: interesting LTO link: http://hubicka.blogspot.co.uk/2014/04/linktime-optimization-in-gcc-1-brief.html

Bas

200

Ideas / Re: Recipe File Format

« on: February 25, 2014, 08:03:06 AM »

Hi,

The format of the recipe file is work in progress. Because the exact requirements are unknown,
we'll just let it grow. Changing it, will currently have no big impact. 2 file formats that are
roughly similar are qmake files and cmake files.
Maybe we can extract the best of them and remove the nasty bits?

201

Implementation Details / update wk41

« on: October 13, 2013, 04:11:11 PM »

A short update. The cpp/h files have been move to component subdirs. This makes it easier to show the
depenencies. Changing a components now requires less knowledge about the whole system.

Secondly the builtin types have been renamed.
i8 -> int16
i16 -> int32
..
u8 -> uint8
u32 -> uint32
..
f32 -> float32
f64 -> float64
This improves code readability.

202

Implementation Details / update wk37-wk40

« on: October 08, 2013, 09:03:58 PM »

Since it's sometimes hard to see what's happening by looking at the codebase; I though it'd be nice to
just start a regular 2-4 week update post series. This will be the first one.

The past 4 weeks saw quite some work on the analyser:

• symbol lookup and error-messages have been improved with the help of unit tests.
• better analysis of -> and . operators
• better analysis of type conversions, also in function arguments/return types
• bugfixes

I've added a feature to generate a dot file with the package dependencies (with the --deps argument). This file
can be converted into an image using:
dot -T png deps.dot > image.png

A LHS/RHS-argument (left/right-hand side) has been added to  analyseExpr(), so it can now check unused variables
and un-initialized use in the near-future.

And last but not least, c2c has been updated to LLVM/Clang 3.3 (from 3.2). This was not a big issue, since
the changes needed to clang are quite small. So pulling this update will require you to update as well (c2c
will not remain backwards compatible with 3.2).

The coming period will hopefully result in:

• file-dependency generation (the idea is to generate a Design Structured Matrix file)
• finally fixing the type of numeric constants (not so easy)
• start of implicit casts (needed for IR-code generation)

Bas

203

Ideas / Re: Make increment operators statements, not expressions

« on: August 27, 2013, 07:45:33 PM »

Well one of the starting reasons I started with C2 was the realization that:

• I was still programming C after 10 years
• There were many new language, but none that's in the domain of C
• I would probably be programming C for 10 more years

Now I like C, but some of it's quicks do feel a bit 20th century.

I don't mind making the language a bit more restricting, as it actually speeds up
development (by reducing debug time). As a rule of thumb, if the C compiler would
let you do something that all C programmers consider bad form, the C2 compiler
would just give an error.

There are a lot more ideas that can go into the language, but the idea is also not
to step outside the C domain (eg threading, garbage-collection, etc).

204

Ideas / Re: Make increment operators statements, not expressions

« on: August 27, 2013, 12:45:58 PM »

Yes, I think that option c would produce the clearest code. But I don't think forcing this will
help in getting C2 accepted, since it also make the code a lot bigger. There are a lot of cases
where correct usage will increase readability, because less lines of code are needed.

The balance I'm trying to find is on one side restricting the language to remove things that
are error-prone (like i = v[i++]). On the other side, not trying to restrict too much, since that
won't help convincing current C programmers to change to C2 in the future.

As a first step, maybe we could extend the FunctionAnalyser to check that no variables is changed
more then once in a single sequence?

205

Ideas / Re: Make increment operators statements, not expressions

« on: August 27, 2013, 08:22:35 AM »

Nice article!
I've been programming C for around 8 years professionally, but must say I've never run into
problems like that.

What I would prefer is getting the analyser to a point where it might check for behaviour like that.
I don't think it's impossible, since it comes down to checking a variable is modified > 1 times within
a single sequence. (Standard §5/4).

So when analyser a Full expression, reset the list of modified variables. For all sub-expressions, check
whether they modify a variable that's already on the list. This would filter out all the examples given.

206

General Discussion / clang article on Modules

« on: August 26, 2013, 09:44:06 AM »

Clang seems to be roughly going in the same direction as C2 by using a 'Modules' strategy:

http://clang.llvm.org/docs/Modules.html

Interesting read. It basically tries to solve some of the same problems as C2. In my opinion
this is very nice, but ultimately will fail to solve the problems completely since staying compatible
has some very severe restrictions. Nonetheless, very interesting.

207

Implementation Details / Re: C2 Grammar?

« on: August 26, 2013, 09:31:27 AM »

When experimenting the C2, I first started out with some basic tests with a hand-written parser.
After that, I started with a version that used lemon and re2c tools. These are Flex/Yacc-type tools.
For lemon, I had to describe the syntax in a formal way, but this proved to be a lot of trouble (dangling
else etc). Just using a parser seemed a lot easier. But I agree that having a formal specification would
help.

I had to disable the Wiki, since it was hacked by bots and consequently filled with ads.

208

Ideas / Re: Syntax of const pointers

« on: July 26, 2013, 01:06:06 PM »

I like option 4 as well. The only minor thing is that 'const int' changes to 'int const', so that'll take
a bit getting used to.

It also works well during parsing, since the const qualifier is added to the type (that was parsed left
of it). So we have the type already by then.

To be consistent, the same will apply to other qualifiers (volatile and restrict) as well,
so in case 4, those will be like:
int volatile reg1;
int volatile * const;  // const pointer to volatile int (the most common case in low-level programming).

I'll be away for the next 2 weeks, but i'll keep grinding my head about this.

209

Ideas / Re: Preprocessor and Macros

« on: July 24, 2013, 10:47:10 PM »

Sometimes macro's just save you from typing. But like many other basic tools, their heavily abused.

I through about removing the macro-preprocessor from C2, but still haven't found a good solution
as alternative. One idea are semantic macros. You can define these like functions, but the main
difference with normal macro's is that they are expanded inside the AST (Abstract Syntax Tree)
and not in the source code. This way, everything can be checked. For example:
old and very bad way
#define MAX(a,b) (a>b? a : b)

With semantic macros, this would be:
public macro MAX(a, b) {
   a>b? a : b;
}

The nice thing is that the compiler understands it a lot better and that
it can actually warn if used with the wrong a and b for example.

Recursive macros are still evil, semantic or not.

210

Ideas / Syntax of const pointers

« on: July 17, 2013, 07:39:26 PM »

I'm currently working on the Type system of C2 and ran into a syntax issue that
I would like to think about more and get more input about.

I'll start by briefly describing the syntax of (ansi-)C in this regard:

Code: [Select]

const intmeans an integer that cannot be changed.

Code: [Select]

int*a pointer to an integer. So far so good. Now for the tricky part:

Code: [Select]

const int*
int const*Both are equal and describe a pointer to an integer that cannot be changed. The pointer itself can be changed to point
at something else. Syntax here is already becoming more vague.

Code: [Select]

int* constOkaaaay So this is a constant pointer to an int. The int can be changed (through the pointer), but the pointer itself
will always point to the same int.

Code: [Select]

const int* constThe final version, both the pointer and the value it points to cannot be changed.

Since C2 tries to improve C, this piece of trickery begs to be upgraded.
I currently see 3 options:
1. Add some parentheses

ansi-C	->	C2
const int		const int
const int*		(const int)*
int* const		const (int*)
const int* const		const (const int*)

This does make it a bit more clear, but the syntax suffers also.

2. Require 2 steps for certain types:

ansi-C	->	C2
const int		const int
const int*		(const int)*
int* const		type IPtr int*; const IPtr
const int* const		type CIPtr const int*; const CIPtr

3. <Your idea here>

So please feel free to post.