7 ms·

C2 Programming Language

44 points by luu 11y ago

Nadya 11y ago
I'm not a C programmer by any means - and the languages I've dealt with don't have signed/unsigned. So I don't fully understand the merits and drawbacks of them. However I know enough to question this: >The default int and float types have been removed, as have type modifier like short, long, signed, unsigned. If the goal is this: >C2 aims to be used for problems where currently C would be used. So low-level programs, like bootloaders, kernels, drivers and system-level tooling. It is my understanding that signed/unsigned is exactly the type of concern you have when dealing with low-level, embedded, or binary code. eg. Bit masking, bit shifting, raw memory So I'm a bit confused. The removal of them seems a bit contrary to the domain goal of the language.
- RogerL 11y ago
  They removed the default types. Meaning no int or unsigned int. They do have int8, int16, int32, uint8, uint16, and so on. You are forced to be explicit. http://c2lang.org/site/language/basic_types/ http://c2lang.org/site/language/basic_types/
  - Nadya 11y ago
    That's what I get for glancing (asking silly questions already answered in a relevant section)! :) Thanks. That makes a lot more sense.
- dragonwriter 11y ago
  They've removed the default "int" and "float" types and modifiers for size and signed/unsigned. Instead, they just have the specific types which have specified signed/unsigned and size characteristics. So, this because explicit over implicit. They have int8, int16, int32, int64 and uint8, uint16, uint32, uint64, and float32, float64. They don't have short, int, unsigned int, signed short int, long, unsigned long, long long, unsigned long long int, float, double, long double, etc.
nwmcsween 11y ago
> int32 instead of int. In C2 you always specify the size Have fun porting that, this language is already dead out the gate. It also seems to ignore low level details on how compilers optimize programs, Rust actually invested into this on the language side and wasn't just some syntastic difference from C.
- vvanders 11y ago
  How is this any different than rust(aside from [i|u]size type)?
- agumonkey 11y ago
  You mean that int32 is some sort of premature specialisation ? But if the machine you run that program has 15 bits int won't you have to rewrite part of the logic to deal with the new limit ?
- norswap 11y ago
  Java (the most popular programming language in the world by many metrics, if you didn't know) works exactly like this. I understand that C and Java have (sometimes) different use cases, still I feel reasonably confident that 32-bit arithmetic is going to be efficient enough on most platforms of interest (some embedded platforms might be a problem). It's true that something like the Posix int_fast_16_t (etc) types might be useful though.
- SomeCallMeTim 11y ago
  I've encountered this prejudice against specific-width types before. It confused me then as now. It seems to me that porting apps that rely on default types like int, where the int size/behavior changes between platforms, have about 1000x more chance of compatibility issues when trying to get the same code to run on new platforms. Sure there could be a performance hit on, e.g., a system that is optimized for 32 bit and you specify 16 bits. That's what types like fast_int16_t are for in C/C++. But porting the code is just easier when the types can't change out from under you. Early versions of C couldn't even decide whether char was signed or unsigned; how is specifying uint8 or sint8 not strictly better than a char that you couldn't be sure whether it was signed or not? How is specifying uint16/32/64 or sint16/32/64 not strictly better than saying "[unsigned] int"?
PythonicAlpha 11y ago
I am not sure, if it is really worthwhile to produce a C equivalent language in the year 2013 for more productivity. I think, that C has still some usages, but for bigger projects, it is IMHO not feasible to use C or an equivalent for the whole project. Most usage I see in generated code or small code samples that have to run rather fast. My questions: * for a faster C, is there really a new language needed? (can't we go with better compilers) * C2 should provide better tooling, but at first it is a drawback, since old tools are not working or are limited. How does that fit together? Would it not better, to use just C for generated code (where the usability aspects are also neglect-able). Of course, every programmer wants to create a new language, but most of them are not lasting long ... and C2 did not convince me from the front-page.
- SomeCallMeTim 11y ago
  There is value in a C replacement, but it would need mindshare even more than features. I think Go has a good combination of mindshare and features for system software development. Rust may as well, though I know less about it.
  - vvanders 11y ago
    I'd think that having a GC and runtime associated with it would prevent Go from even being considered for a Systems language.
  - aidenn0 11y ago
    I see Go as more of a java replacement than as a C replacement (inasmuch as there are lots of tools that can be written in both C and java, it is a C replacement though). Rust is obviously going after C++.
bitshiffed 11y ago
As a C-enthusiast, I came in assuming that I wouldn't like this. It actually looks very interesting though. Modules and imports look to make things much smoother, function pointers and structs are friendlier, and more explicit data types are something many C projects already adhere to. I'm curious to see how/if the compiler handles blocks and C11 threading/atomics, with the proper libraries (blocksruntime/musl).
- noobermin 11y ago
  Have to echo the sentiment (if at least to give the authors some encouragement if they are reading this). I saw the title and thought, "not another attempt to supercede C..." but it sounds rather interesting so far. I love high-level hacking as much as the next guy, but I can see how this can be easier for C-lovers to not hate since it explicitly doesn't try to be more high level.
nadams 11y ago
> For array types, C2 introduces a new operator, namely elemsof(). This returns the number of elements in an array sigh PHP - count Python - len C++ - .size (vector) C - macro or stored C# - .Length
- PythonicAlpha 11y ago
  Yes, "elemsof" is not only another new name, but in my opinion, it is also a name that does not disclose itself easily. Good naming in programming is an art.
  - kmill 11y ago
    It seems to have been chosen so there is some parallelism between sizeof and elemsof.
    - bitshiffed 11y ago
      It also makes the fact that you are referring to a size/length/count of elements, and possibly not bytes, very explicit.
      - PythonicAlpha 11y ago
        To me it does not disclose that easily. The parallelism between "sizeof" and "elemsof" seems to me very constructed. "size" and "elements" are not similar words. To be logical at all, the name should be "numelemsof" or "countelemsof" ... but I guess, those names are already to long for C purists ...
        Serow225 11y ago
        MATLAB uses numel()
        andresmanz 11y ago
        That's true all too often. Meanwhile, though, I prefer long and expressive names. You can easily find functions like getNumberOfEnemiesOnSamePlatform() in my C and C++ code. I don't think it's very hard to understand what that function does. With a few special exceptions, I haven't written any comments for almost two years and nobody ever complained.
ori_b 11y ago
I should ask the same question that people asked me when I introduce my language: Do you have interesting code written in it?
blt 11y ago
I'd love to see an evolved C that targets the most performance-obsessed programmers. Features like: * fine-grained control over alignment * automatic generation of SoA code from AoS code * first-class SIMD types * pragmas to switch the compiler into branch-avoiding codegen * cache line size as a built-in constant, with ability to compile a binary that contains several versions of the complete program optimized for different cache line sizes * user-defined calling conventions * vectors, matrices, and quaternions (taking care of 90% of the cases where you really want operator overloading in C++) * ability to treat an integer as an array of bits, bytes, or smaller integers, a la Terry Davis's "Holy C" And the standard library could contain some nice performance-oriented stuff like: * portable memory allocator that exposes pages, virtual memory indirection, reserve vs. commit, etc. * fixed-point math * approximate transcendental functions * bitwise stuff a la the "Stanford Bit Twiddling Hacks" while also adding modules and cleaning up declarations like C2 does. I think a lot of programmers would like it.
- theseoafs 11y ago
  The main issue would be fixing the problem of pointers; high-performance code is hard to write in C because of pointer aliasing. Rust has an interesting approach in its ownership model but I think a performance-oriented C evolution would require another more general solution.
  - ori_b 11y ago
    In Myrddin[1], the code is amenable to loop versioning -- All references are bounded, one way or the other. Either you have a raw pointer, which is bounded by the size of the type, or you have a slice, which carries with it a length. This allows you (or the compiler) to trivially write an 'aliases(a, b)' predicate, which allows the compiler to write something like: if aliases(a, b) slowpath else fastpath ;; Considering that this language seems to also keep track of bounds on the pointers, you could probably do something similar. [1]http://eigenstate.org/myrddin/ http://eigenstate.org/myrddin/
  - aidenn0 11y ago
    ANSI rules for aliasing, plus the restrict keyword go a long way to address this.
flyinglizard 11y ago
From someone who mostly deals with embedded systems, I like that. All of the modern system languages essentially rely on having a virtual memory model and force you to use GC. Both these prerequisites essentially rule out something like Go for a microcontroller (it can work, just not be useful beyond a novelty). There are a few things I'd personally want to see, like lambdas and nested functions, some more intelligent error handling, fixed point math, etc. But its a good step forward.
Sprocklem 11y ago
I see a few questionable decisions in the type system: * Why is char equivalent to int8? If C2 is keeping 8-bit chars, why not use uint8? * Why isn't there a primitive size type a la size_t or rust (i|u)size to increase portability? Beyond this, when I first saw this link, I expected to be disappointed with what they'd done. I was pleasantly surprised to find I liked it.
tagrun 11y ago
A few features from Go that can make things better and help preventing certain class of bugs: * no parentheses for if/switch/for, and mandatory {}, no semicolons * fallthrough in switch Also some sweet features like * replace while with a generalized for * struct methods * multiple return values (this might be a stretch) * if with variable definition (if x := y; x<z { ... } ) * not sure if it already has but type inference

44 points by luu 11y ago

Nadya 11y ago

I'm not a C programmer by any means - and the languages I've dealt with don't have signed/unsigned. So I don't fully understand the merits and drawbacks of them. However I know enough to question this: >The default int and float types have been removed, as have type modifier like short, long, signed, unsigned. If the goal is this: >C2 aims to be used for problems where currently C would be used. So low-level programs, like bootloaders, kernels, drivers and system-level tooling. It is my understanding that signed/unsigned is exactly the type of concern you have when dealing with low-level, embedded, or binary code. eg. Bit masking, bit shifting, raw memory So I'm a bit confused. The removal of them seems a bit contrary to the domain goal of the language.

RogerL 11y ago
They removed the default types. Meaning no int or unsigned int. They do have int8, int16, int32, uint8, uint16, and so on. You are forced to be explicit. http://c2lang.org/site/language/basic_types/ http://c2lang.org/site/language/basic_types/
- Nadya 11y ago
  That's what I get for glancing (asking silly questions already answered in a relevant section)! :) Thanks. That makes a lot more sense.
dragonwriter 11y ago
They've removed the default "int" and "float" types and modifiers for size and signed/unsigned. Instead, they just have the specific types which have specified signed/unsigned and size characteristics. So, this because explicit over implicit. They have int8, int16, int32, int64 and uint8, uint16, uint32, uint64, and float32, float64. They don't have short, int, unsigned int, signed short int, long, unsigned long, long long, unsigned long long int, float, double, long double, etc.

nwmcsween 11y ago

> int32 instead of int. In C2 you always specify the size Have fun porting that, this language is already dead out the gate. It also seems to ignore low level details on how compilers optimize programs, Rust actually invested into this on the language side and wasn't just some syntastic difference from C.

vvanders 11y ago
How is this any different than rust(aside from [i|u]size type)?
agumonkey 11y ago
You mean that int32 is some sort of premature specialisation ? But if the machine you run that program has 15 bits int won't you have to rewrite part of the logic to deal with the new limit ?
norswap 11y ago
Java (the most popular programming language in the world by many metrics, if you didn't know) works exactly like this. I understand that C and Java have (sometimes) different use cases, still I feel reasonably confident that 32-bit arithmetic is going to be efficient enough on most platforms of interest (some embedded platforms might be a problem). It's true that something like the Posix int_fast_16_t (etc) types might be useful though.
SomeCallMeTim 11y ago
I've encountered this prejudice against specific-width types before. It confused me then as now. It seems to me that porting apps that rely on default types like int, where the int size/behavior changes between platforms, have about 1000x more chance of compatibility issues when trying to get the same code to run on new platforms. Sure there could be a performance hit on, e.g., a system that is optimized for 32 bit and you specify 16 bits. That's what types like fast_int16_t are for in C/C++. But porting the code is just easier when the types can't change out from under you. Early versions of C couldn't even decide whether char was signed or unsigned; how is specifying uint8 or sint8 not strictly better than a char that you couldn't be sure whether it was signed or not? How is specifying uint16/32/64 or sint16/32/64 not strictly better than saying "[unsigned] int"?

PythonicAlpha 11y ago

I am not sure, if it is really worthwhile to produce a C equivalent language in the year 2013 for more productivity. I think, that C has still some usages, but for bigger projects, it is IMHO not feasible to use C or an equivalent for the whole project. Most usage I see in generated code or small code samples that have to run rather fast. My questions: * for a faster C, is there really a new language needed? (can't we go with better compilers) * C2 should provide better tooling, but at first it is a drawback, since old tools are not working or are limited. How does that fit together? Would it not better, to use just C for generated code (where the usability aspects are also neglect-able). Of course, every programmer wants to create a new language, but most of them are not lasting long ... and C2 did not convince me from the front-page.

SomeCallMeTim 11y ago
There is value in a C replacement, but it would need mindshare even more than features. I think Go has a good combination of mindshare and features for system software development. Rust may as well, though I know less about it.
- vvanders 11y ago
  I'd think that having a GC and runtime associated with it would prevent Go from even being considered for a Systems language.
- aidenn0 11y ago
  I see Go as more of a java replacement than as a C replacement (inasmuch as there are lots of tools that can be written in both C and java, it is a C replacement though). Rust is obviously going after C++.

bitshiffed 11y ago

As a C-enthusiast, I came in assuming that I wouldn't like this. It actually looks very interesting though. Modules and imports look to make things much smoother, function pointers and structs are friendlier, and more explicit data types are something many C projects already adhere to. I'm curious to see how/if the compiler handles blocks and C11 threading/atomics, with the proper libraries (blocksruntime/musl).

noobermin 11y ago
Have to echo the sentiment (if at least to give the authors some encouragement if they are reading this). I saw the title and thought, "not another attempt to supercede C..." but it sounds rather interesting so far. I love high-level hacking as much as the next guy, but I can see how this can be easier for C-lovers to not hate since it explicitly doesn't try to be more high level.

nadams 11y ago

> For array types, C2 introduces a new operator, namely elemsof(). This returns the number of elements in an array sigh PHP - count Python - len C++ - .size (vector) C - macro or stored C# - .Length

PythonicAlpha 11y ago
Yes, "elemsof" is not only another new name, but in my opinion, it is also a name that does not disclose itself easily. Good naming in programming is an art.
- kmill 11y ago
  It seems to have been chosen so there is some parallelism between sizeof and elemsof.
  - bitshiffed 11y ago
    It also makes the fact that you are referring to a size/length/count of elements, and possibly not bytes, very explicit.
    - PythonicAlpha 11y ago
      To me it does not disclose that easily. The parallelism between "sizeof" and "elemsof" seems to me very constructed. "size" and "elements" are not similar words. To be logical at all, the name should be "numelemsof" or "countelemsof" ... but I guess, those names are already to long for C purists ...
      - Serow225 11y ago
        MATLAB uses numel()
      - andresmanz 11y ago
        That's true all too often. Meanwhile, though, I prefer long and expressive names. You can easily find functions like getNumberOfEnemiesOnSamePlatform() in my C and C++ code. I don't think it's very hard to understand what that function does. With a few special exceptions, I haven't written any comments for almost two years and nobody ever complained.

ori_b 11y ago

I should ask the same question that people asked me when I introduce my language: Do you have interesting code written in it?

blt 11y ago

I'd love to see an evolved C that targets the most performance-obsessed programmers. Features like: * fine-grained control over alignment * automatic generation of SoA code from AoS code * first-class SIMD types * pragmas to switch the compiler into branch-avoiding codegen * cache line size as a built-in constant, with ability to compile a binary that contains several versions of the complete program optimized for different cache line sizes * user-defined calling conventions * vectors, matrices, and quaternions (taking care of 90% of the cases where you really want operator overloading in C++) * ability to treat an integer as an array of bits, bytes, or smaller integers, a la Terry Davis's "Holy C" And the standard library could contain some nice performance-oriented stuff like: * portable memory allocator that exposes pages, virtual memory indirection, reserve vs. commit, etc. * fixed-point math * approximate transcendental functions * bitwise stuff a la the "Stanford Bit Twiddling Hacks" while also adding modules and cleaning up declarations like C2 does. I think a lot of programmers would like it.

theseoafs 11y ago
The main issue would be fixing the problem of pointers; high-performance code is hard to write in C because of pointer aliasing. Rust has an interesting approach in its ownership model but I think a performance-oriented C evolution would require another more general solution.
- ori_b 11y ago
  In Myrddin[1], the code is amenable to loop versioning -- All references are bounded, one way or the other. Either you have a raw pointer, which is bounded by the size of the type, or you have a slice, which carries with it a length. This allows you (or the compiler) to trivially write an 'aliases(a, b)' predicate, which allows the compiler to write something like: if aliases(a, b) slowpath else fastpath ;; Considering that this language seems to also keep track of bounds on the pointers, you could probably do something similar. [1]http://eigenstate.org/myrddin/ http://eigenstate.org/myrddin/
- aidenn0 11y ago
  ANSI rules for aliasing, plus the restrict keyword go a long way to address this.

flyinglizard 11y ago

From someone who mostly deals with embedded systems, I like that. All of the modern system languages essentially rely on having a virtual memory model and force you to use GC. Both these prerequisites essentially rule out something like Go for a microcontroller (it can work, just not be useful beyond a novelty). There are a few things I'd personally want to see, like lambdas and nested functions, some more intelligent error handling, fixed point math, etc. But its a good step forward.

Sprocklem 11y ago

I see a few questionable decisions in the type system: * Why is char equivalent to int8? If C2 is keeping 8-bit chars, why not use uint8? * Why isn't there a primitive size type a la size_t or rust (i|u)size to increase portability? Beyond this, when I first saw this link, I expected to be disappointed with what they'd done. I was pleasantly surprised to find I liked it.

tagrun 11y ago

A few features from Go that can make things better and help preventing certain class of bugs: * no parentheses for if/switch/for, and mandatory {}, no semicolons * fallthrough in switch Also some sweet features like * replace while with a generalized for * struct methods * multiple return values (this might be a stretch) * if with variable definition (if x := y; x<z { ... } ) * not sure if it already has but type inference