Messages

1

Ideas / Re: Array types

« on: February 14, 2015, 11:04:18 PM »

I found this proposal by John Nagel on Lambda The Ultimate : http://lambda-the-ultimate.org/node/4573

The idea is to tie together parameters in a function declaration so the compiler can see that one of the parameters is the length of the array in the other parameter. Look at the "n" in this example he gives:

    int read(int fd, char (&buf)[n], size_t n); 

Even if this proposal isn't appropriate, maybe the reaction and discussion is informative.

2

Ideas / Re: unifying '->' and '.' member accessors

« on: March 15, 2013, 05:33:30 AM »

I definitely would prefer this.

Looking around at other languages, I see that Modula-3 and Oberon both allow struct.field as shorthand for struct^.field (where ^ is the dereference operator in those languages), and Ada allows struct.field as shorthand for struct.all.field (where .all is the dereference operator in Ada, if I'm reading correctly).

3

Ideas / Re: C2 Package system

« on: February 17, 2013, 06:07:04 PM »

Here's a good case for (B) : We're already doing it!

In any sizeable C program, you tend to include the name of the module (package) in the function name. For example, look at mutex.c in the Linux kernel: functions there are named mutex_lock(), mutex_trylock(), etc. With full package naming, the functions would be renamed to lock() and trylock(), and users of these functions would refer to them through the package name as mutex.lock() and mutex.trylock(). Some functions in the kernel are named a little differently, with a verb in front of the package name like flush_workqueue(), which would be renamed to flush() and referred to as workqueue.flush(). See, its often the same amount of typing - so that concern goes away.

When you look at example code in a C language book, thinking about changing all the printf()s and getc()s to the longer stdio.printf() and stdio.getc() seems discomforting. However, in real production code the difference is negligible.

4

Ideas / Re: C2 Package system

« on: February 16, 2013, 07:49:17 AM »

Hi Bas,

I just saw the video of your FOSDEM 2013 lighning talk at http://video.fosdem.org/2013/lightningtalks/The_C2_programming_language.webm. Very interesting.

(A) I think the . works fine. When using Python, I've never suffered confusion with the . for packages.
(B) I prefer full specification of external symbols. You never have to guess which package something comes from. The breakage scenario you describe convinces me further.
(C) use <long> as <short> makes (B) much more manageable, and I can't think of a downside.
(D) Opaque types sound almost necessary to seriously build software with architecture in mind.