Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bas

Pages: [1] 2 3 ... 6
1
Ideas / Struct Function declaration
« on: April 15, 2017, 09:22:04 PM »
With the current syntax, I think it's quite unclear when a function is a struct function. I would
like to try to make this more explicit. So hereby some ideas.

Code: [Select]
func void point_add(Point* p, int32 x) { .. }    // current syntax

func void Point_add(Point* p, int32 x) { .. }   // allow Upper-case as first char, so looks more like type Point

func void point_add[Point](Point* p, int32 x) { ..} /// hmm, 3 points in a row..no

func void point_add(Point* p, int32 x) @{structfunc} { ..} // via attribute
func void point_add(Point* p, int32 x) @{struct='Point'} { ..} // via attribute, nr 2

func void Point.add(Point* p, int32 x) { .. }   // most explicit, via member operator

..

I like the last option best. The two arguments against it are:
  • it's harder to see what the c- function name is (point_add in all cases). The is actually currently
        the same for module attributes as well (Foo.bar() -> foo_bar)
  • The syntax breaks more with the ansiC style

What do you think?

2
General Discussion / Re: VLA crash
« on: March 15, 2017, 08:37:44 AM »
The issue reproduces nicely indeed. There seem to be several issues here. The first one
is that array subscript expressions were not marked at compile-time-constant (if they were).
That is fixed on a branch now. Since C2 allows more then C sometimes, I'll look carefully
at the order of evaluation, since it's otherwise easy to get loops in constant declarations
that we have to detect/avoid..

3
General Discussion / Re: Typo in manual
« on: March 06, 2017, 09:36:44 PM »
fixed.
I hope you have a very pleasant flight eh experience from now on ;)

4
General Discussion / Re: Diffs to C99 and C11
« on: February 16, 2017, 04:50:44 PM »
There is a page called 'Changes from C' in the documentation that highlights some big changes. Otherwise
there are many smaller changes. Just look at some code fragments in the examples/ dir and the unit tests.

Macros in C/C++ work by including (copy-pasting) a header file into a .c/cpp file. The preprocessor then does
textual replacements. This is very flexible, but also prevents the compiler from many useful diagnostics
(or at least makes it very hard). There is a post about macros on the forum that explains the different use
cases for macros.

Variable length arrays are supported in function scope (just like newer C standards). At global scope, C2 allows
'adding' items from different parts of the code, but essentially at runtime these are fixed size. Multi-dimensional arrays
are supported just like C/C++.

OpenMP is not in the planning yet..


5
General Discussion / Re: clangd compilation server
« on: February 16, 2017, 04:45:06 PM »
Thanks for mentioning it here. I did catch something of it some time ago. This solution is nice for large C/C++ codebases
where compilation times are non-trivial. For C2 I haven't even found a good reason to multi-thread yet... (1.8 Mloc/sec parsing,
800Kloc/sec with analysis). Since the latest vim (7 if I remember correctly) they support pipes that can be used by plugins
to for example talk to a persistent server/daemon like this..

6
Implementation Details / Re: incremental arrays
« on: January 29, 2017, 11:16:30 AM »
The intention was indeed to remove a lot of macro magic by allowing incremental arrays. Currently all parts must be
in the same file I think, but I don't think there are problems when allowing multiple files in same module (since the order is
specified in the recipe).

7
Ideas / Re: Vectors in combination with semi-automatic memory management
« on: January 04, 2017, 08:04:00 AM »
C has a perfect mechanism to clean up what you allocate in a function: the stack.

When you need some piece of memory that has a bigger lifetime than the function, you use malloc.
So I'm a bit confused as well what you want. In C++ destructor functions are used to do the stuff you describe
(with smartpointer concepts).


8
Ideas / Re: Enum classes
« on: January 04, 2017, 07:45:40 AM »
Most modern C compilers will give a warning on this. In C2 this will just be an error and requires an
explicit cast to work..

9
Ideas / Re: Enum classes
« on: January 02, 2017, 08:30:36 PM »
The big advantage of explicit enum types would be to catch mistakes like:
Code: [Select]
type Temperature enum int8 {
  Low,
  High,
}

type State enum int8 {
  Begin,
  End,
}

State state = High;  // <- wrong enum constant

In languages where an enum is just an integer, the above would be perfectly fine. Currently the C2 compiler
catches these issues (but ATM doesn't give a nice diagnostic msg yet). So internally, enum constants have
the type of the enum (and not just int8). Maybe that's enough for now, since the only other advantage is being
able to have different enum types in the same module, with same enum constants (eg. both have a 'Middle')...

10
Ideas / Re: Struct Functions - part 2
« on: January 02, 2017, 08:19:35 PM »
In C2 'this' is not a keyword. It's just the name of the first argument used in struct functions. You are allowed
to use any name you want. The question was whether to let developers skip the 'this.member' and just type 'member'
inside struct functions. The compiler would then convert 'member' to '<name_of_arg0>.member'.
This way struct functions are a lot more similar to C++ class functions (where you are also allowed to use 'this->member'),
but can also just use 'member'.

11
General Discussion / Re: Pthreads
« on: January 02, 2017, 08:15:04 PM »
I think that in general most modern solutions tend to trade complexity for disk-space. Disk space is cheap, while
complexity is growing. So, for example, instead of having a complex package system with a lot of dependency-tracking,
a (big) application would just provide all the libs it needs itself. This is also basically the idea of Docker and such.

While I agree that it is often a good trade, it also feels a bit like admitting to a loss.

Building software can be quite straightforward, as shown by many (non-mainline) languages such as Ada etc. Remember
that the C2 compiler knows everything it needs to build the C2 code in the project. The only other things it needs to understand
are libraries (basically collections of symbols with some plumbing) and linking (format depends on platform). For stuff like
opening a file, C2 re-uses llvm libraries.

While it would be very nice to solve all the libc legacy, that is simply not a realistic way forward for C2 at the moment. So there
will be different versions of C2 libc for different platforms. Since C2 does *not* target Windows, most *nix systems don't differ
too much to cause real problems..  :)



12
General Discussion / Re: Question: how are growable arrays implemented?
« on: January 02, 2017, 03:44:32 PM »
C2 doesn't have growable arrays in the sense that they can grow during runtime. They can 'grow' during compilation. The C2 compiler just
merges all the 'array += value' declarations and creates a single (static) array. The may goal was to avoid having to use complicated macros when
you want to extend both an enum and a  data structure that uses the enum constants as index.

13
General Discussion / Re: C-domain useful features
« on: December 10, 2016, 09:26:03 AM »
Exactly, It's also a explicit non-goal to make the language help developers. What!?!?

With C2 my ideas is to restrict to language a bit more. This is similar to Python with the
one-way to do things. So if something is allowing in C, but in any of my project we would
disallow a certain construction (by agreement), in C2 this would simply be forbidden in the
language. This will make C2 programs more consistent and easier to read.

14
Ideas / Re: Struct Functions - part 2
« on: December 09, 2016, 08:47:07 AM »
One of the basic design choices in C2 is not to do symbol mangling. So for a function, it should be quite
clear what the exact symbol will look like. In C2 this is currently 'module_symbol', which is not real mangling,
but just concat-ing module name and symbol name.

I agree that the syntax of struct functions is probably not the best it can be, but I'm still puzzling to find
a better one.

One idea that came up during usage is to add the struct members to the 'namespace' of the function. So
you don't have to do 'this.member' but can simply do 'member'. This leads to the question whether a user
should have to type the first argument and whether it's always 'this'. I always prefer simplicity when in doubt
and I don't think that saving some keystrokes should be a goal. A simple language with a well readable syntax
is a higher goal imho.

Another idea would be to make the fact that a function is a struct function more explicit. In that sense your
syntax proposal could be used...




15
General Discussion / Re: C-domain useful features
« on: December 09, 2016, 08:40:37 AM »

The 'examples' directory from the c2compiler git archive is indeed a more practical example. For more
extensive code fragments showing of specific features, you can look at the 'test' directory. That contains
the automated tests that test individual features.

The goal of C2 is to be a better C. For some problem domains, C++ would be a better choice than C. Let's
call this domain the systems-programming domain. Most big new languages like Go, Swift, D, Rust target
that domain. C2 explicitly does not, since you need a lot more higher-level features there, like some form
of object-orientation, some form of memory-management (even like C++'s destructor).

Even the C2 compiler is written in C++, which is a better choice than C for those type of applications.
I used to love C++, but the direction it's going is simply that of one big mess. And looking on the Internet,
I'm not alone in that opinion. I would love to see a combination of C++ and C2, say C2++ :)
But for C2, there simply cannot be a viable, runtime, etc.

Which features of C++ don't you like?







Pages: [1] 2 3 ... 6