«

If you were given the task to design a replacement for the C programming
language intended to fix all its problems and shortcomings, what would you
propopose?


Rui Maciel

"Rui Maciel" <> wrote in message
news:jnjpil$ek2$...
> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?

Perhaps the problems and shortcomings should be summarised first. Then they
need to be agreed to be shortcomings; many of the experts here are quite
happy with the language as it is. Others will already be using alternatives.

--
Bartc

Rui Maciel <> writes:
> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?

Just about every post-1978 language that uses curly braces to delimit
code blocks, and many that don't, is *somebody's* answer to that
question.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2012-04-29, Rui Maciel <> wrote:
> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?

void. I would get rid of void. No "void func()", no (void) argument list, no
void * pointers. Functions with no return value could be declared/defined with
the "proc" keyword. Generic pointer would be "byte *", where byte would be a
type built in to the language, exactly like unsigned char, and explicit
conversion by cast would be required in both directions.

More consistent syntax. For instance function parameter decls separated
by semicolons, not commas, allowing:

proc foo(int a, b, c; double *p)

I would smear the distinction between statements and expressions. Statements
would be allowed to return values, so for instance, this would be valid:

int x = if (a > b) c; else d;

Conformance. I would distinguish warning and error diagnostics in the spec,
and forbid required diagnostics from being mere errors. Implementations which
translate a unit that requires a diagnostic, allowing it to be linked and
executed, would be considered nonconforming.

Introspection. The language would have an API for run time introspection.
I don't want to start writing details about this, but suffice it to say that
the introspection would be sufficient that it could allow a program in the
language to implement a precisely tracing garbage collector (even in the
presence of threads) without resorting to any platform-specific assembly
language or other hacks. Introspection would allow the GC to walk stacks and
know exactly where the live variable values are.

I would strengthen arrays without the disadvantages of making them more
encapsulated. There would a way to define an integral object which indicates
the size of an array referenced by a pointer:

struct vec {
double *dynamic : int size;
double *fixed : 1; /* pointer to just one double */
};

Such a definition introduces two objects, so that struct vec above has
a member called size of type int. The compiler understands that the
size of the array pointed at by v->dynamic is given by int size.

This would be in function parameters also:

double dotproduct(double *v1 : int size_v1, *v2 : int size_v2);

Now when we have a sized vector, we can do this:

dotproduct(v1->dynamic, v2->fixed);

The compiler knows that the size of v1->dynamic (where v1 points to a struct
vec) is given by v1->size. So, automatically, it passes v1->size as
the value for the size_v1 formal parameter. For size_v2, it passes 1.

If you pass an unsized pointer to a sized parameter, the size parameter is not
filled in. It must be specified explicitly:

dotprodut(some_pointer : 4, v2->fixed);

If a pointer is derived from an array, its size is inferred from the array.

All dataflows involving pointers would automatically carry the size
information, if any, propgating it between the size objects:

v1->dynamic = v2->dynamic; /* v1->size = v2->size is implicit! */

I would drop variable length arrays. They could be replaced by sized pointers
which are initialized using a notation:

int *p : int s = [42];

This [42] is an initializer which means dynamically allocate automatic
storage, returning null if it is not possible, and the size is 42 times the
size of the pointer being initialized. The variable s receives the value 42 if
the allocation succeeds, otherwise zero.

Of course, the s is optional:

{
int *p = [42]; // make auto array of 42 ints, or fail with null
}
// out of scope: array is now gone

The nice thing is that we can now pass p into functions, and using the
size-propagation logic, functions can know the size. This is even if we wrap p
inside a data structure:

struct obj {
int *ptr : int size;
};

proc foo(struct obj);
int bar(int *ptr : int size);

/* ... */

{
int *p = [42];
struct obj;
obj.ptr = p; // implicit: obj.size = 42;
foo(obj); // foo knows size
bar(p); // bar receives size
}

Pointer arithmetic would also propagate the size, if possible. (Which is part
of the point.)

If p is a size-attributed pointer of constant size s, then p + n is either
erroneous, if this is out of bounds, or it produces a new pointer displaced
by n, whose size attribute is the value s - n.

If p is a size-attributed pointer with a variable size stored in object s, then
p + n evaluates s to determine whether p + n is out of bounds.
If it is not out of bounds, then the displaced pointer p + n is produced,
and its size attribute is the rvalue s - n. (No provision for safety for
negative displacements would be provided.)

Example:

{
int *p : int size = [42];

p++; /* size is now 41 */

p -= 2; /* UB. */
}


Arrays would be first class citizens: passed into functions, returned from
functions. Array syntax in a function argument list would not denote a
pointer. Size mismatches would diagnose. An explicit cast would override the
size mismatch, resulting in truncating or zero-padding semantics.

/* funct takes one int, returns array of 3 int. */

int (func[3])(int a)
{
int x[2] = { 1, 2 };

return x; /* error, size mismatch */

return (int[3]) x; /* return value is padded with zero */
}

I would provide a simple namespacing scheme based on textual gluing of prefixes
onto identifiers.

On the definition side:

prefix mylib_ {
int open(char *);
int close(int);
};

The above is precisely equivalent to:

int mylib_open(char *);
int mylib_close(int);

On the use side:

prefix mylib_ open, close;

This means that if the names mylib_open and mylib_close are visible in this
scope, the short names open and close now stand for mylib_open and mylib_close.
If no such names are visible, it is erroneous.

Something similar would be provided for preprocessor symbols (if I actually
kept the preprocessor as such).

Control flow. I would provide a non-local dynamic return mechanism with
cleanup (unwind protect). Any function or block would be able to execute
cleanup code if it is terminated by a nonlocal transfer.
Some kind of exception handling would be provided.
Named blocks for breaking out of nested constructs.

io_x wrote:

> i propose assembly: 8 32 bits registers and 20 - 30 instruction on them
> ...

Why? What's wrong with writing routines in assembly and then calling those
routines from C?


Rui Maciel

On 04/29/2012 10:17 AM, Rui Maciel wrote:
> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?
>

I would keep C the same but enforce a universal 'package manager' type
of thing for installing and building with libraries. So that I don't
have to spend more time figuring out how to get the damn library to
compile with my code than it would take me to write the library myself.

Rui Maciel <> writes:
>If you were given the task to design a replacement for the C programming
>language intended to fix all its problems and shortcomings, what would you
>propopose?

I'd decline this task. I am not capable to design something
better. I'd propose to keep evolving C.

(However, I would suggest some small changes to the specification.
For example, footnote 197, seems to use the term »variable«,
but this term does not seem to be defined in N1570. So I'd
either change the wording of this footnote or define »variable«.
I would try to change implicit definitions of terms to a more
explicit wording of the form »An x is a y, so that ...«, where
»y« is a superordinate concept of x that is already known.)

"BartC" <> wrote in message news:jnjun6$g0s$...
>
>
> "Rui Maciel" <> wrote in message
> news:jnjpil$ek2$...
>> If you were given the task to design a replacement for the C programming
>> language intended to fix all its problems and shortcomings, what would
>> you
>> propopose?
>
> Perhaps the problems and shortcomings should be summarised first. Then
> they need to be agreed to be shortcomings; many of the experts here are
> quite happy with the language as it is. Others will already be using
> alternatives.

This has all been discussed before, for example "Has thought been given
given to a cleaned up C? Possibly called C+" from March 5 2010 in clc.

Actually I've already designed a language, which does the same sorts of
things as C, and quite a bit more, but with hardly any of its
idiosyncrasies. But it's not a replacement for C, and is based on a
different syntax. I'm trying to implement it at the moment.

But I can tell you that, even if I created a curly-braced front-end for it,
it wouldn't be popular in this newsgroup. It's a struggle even to get people
here to accept binary literals in the language!

Another problem with C is that it isn't one language, it's several: (1) The
main C syntax; (2) type declaration syntax, which is in a class of its own;
(3) its macro language (a code-obfuscation tool) (4) compiler-switch options
(5) make-file syntax. This is apart from various proprietary extensions.

If you download any open source C project, you need to become an expert in
all these, otherwise the project probably won't build.

I don't think giving the main language a make-over would make that much
difference to it. Any replacement would need to consider the whole
tool-chain, but still be targeted at the same application fields (mainly,
implementing everything else that other languages are not capable of).

--
Bartc

In article <jnjpil$ek2$>,
Rui Maciel <> wrote:

> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?
>
>
> Rui Maciel

A Heuristic Algorithmic Language. Seems we're about 11 years behind
schedule on that as it is.

On 4/29/2012 10:44 AM, BartC wrote:
>
>
> "Rui Maciel" <> wrote in message
> news:jnjpil$ek2$...
>> If you were given the task to design a replacement for the C programming
>> language intended to fix all its problems and shortcomings, what would
>> you
>> propopose?
>
> Perhaps the problems and shortcomings should be summarised first. Then
> they need to be agreed to be shortcomings; many of the experts here are
> quite happy with the language as it is. Others will already be using
> alternatives.
>


a few thoughts:

"#include", maybe some sort of alternative mechanism could be devised,
like a standardized precompiled header mechanism.

a major issue is mostly that as-is, if you do:
#include <foo.h>
#include <bar.h>

then by definition declarations within "foo.h" may alter the behavior of
declarations within "bar.h", regardless of whether or not such behavior
is desired or relevant.

a better mechanism could be one which is "similar" to include, except it
leaves the matter undefined as to whether actual textual inclusion is
used, or if the headers are compiled independently (and their contents
imported later).

one idea here:
#pragma pch_standalone
or:
#pragma precompiled_header


(decided to mostly leave out analysis of mechanisms in several other
languages, namely Java and C#).

my own language uses a variant of "import" here, which mostly just
imports "modules" (more or less just "source files"), with a tree-based
organization scheme vaguely similar to the JVM package system, but sadly
also with a lot of special-case modifiers.


another issue:
the current declaration syntax (and also the cast syntax) is ambiguous
apart from knowing in advance what the types are. this makes parsing
both more problematic, and potentially slower.

one option is placing some restrictions on allowed constructions (such
as those similar to C#), which could allow for the parser to skip
looking up typedefs.

the concern here is that such a feature would not be strictly backwards
compatible, as there may be some code which could run into problems.

a specific problem with the strategy as used in C# is that it would
limit some constructions involving calling the result of a prior
expression, forcing the use of temporary variables for function pointers
in some cases.

in my own language, I had switched to an alternate cast syntax: "x as
type" and "x as! type", personally rather having the ability to curry
functions without a temporary at the cost of losing the traditional cast
syntax.


next issue:
the preprocessor allows some constructions which are only possible if
textual substitution is used, which hinders alternate strategies (such
as AST-based macro expansion).

the main imposition here (of changing this) would be being unable to
express macros with unmatched parenthesis or braces.

also, block-macros would be nice.

so, rather than having to type:
#define FOO(x, y, z) \
first_line(x); \
second_line(y); \
third_line(z)

a declaration like:
#macro FOO(x, y, z)
first_line(x);
second_line(y);
third_line(z);
#endmacro

could be used.


yet another issue:
current handling in C for variable argument lists sucks.

nicer would be some alternative mechanism for these, which could
potentially allow:
not needing an argument before '...', or va_list / va_start() / va_end().

maybe some ability to determine the argument types (would be problematic
for current ABIs though).


other things which could be nice:

ability to put "_" in numbers as a separator, as in "0x0123_4567_89AB_CDEF"

multi-line strings (like in Lua, Python, and my own language).

example:
"""
this is a string
which spans lines...
"""
or (a syntax my language uses):
<[[this is a string
which spans lines...]]>
rather than:
"this is a string\n"
"which spans lines..."



far less certain features (wouldn't work well with current compilers or
ABIs):

maybe references and operator overloading could be nice.
maybe support for variant types.

maybe also an object system, or features to aide in implementing an
object system (such as via operator overloading), but this would be
getting a bit far outside of C domain (as would be features like eval, ...).

admittedly, I am not fond of the C++ OO facilities, but would like it if
it were more possible for people to "role their own", such as by
overloading "->" or similar.

for example, if this could work:
variant operator->(MyType obj, char *name)
{ ... }

or, further (syntax for defining a custom method handler):
variant operator->(MyType obj, char *name)
{ return function(variant[] args...) { ... }}

(where "function" would be a "true" closure, as in, one which retains
the parent scope following the parent function returning).

what this would look like in my own language's syntax:
function operator.(obj:MyType, name:string):variant
function(args...) { ... }

(although doing something like this isn't really needed in my case, as
there are more specialized features, like "function get*()" and similar).


likewise, it would also be nice if C could (optionally) support things
like late-binding and link-time type specialization (these would likely
be mostly transparent at the language level, but could have a more
significant impact on the compiler).


but, it is all not as big of a deal for me, since I can roll my own
language and have whatever features I want in it...

a downside is that my own language can't currently really compete with
C, especially at present WRT things like performance (or, sadly, being
entirely free bugs in the implementation).

the performance issue is partly due the problem of my own difficulties
creating or maintaining a reliable native code generator, leaving me
mostly stuck with much slower options: namely the use of interpreters
and threaded-code, and even then still trying to nail down all the bugs
(and having an annoyingly large bytecode ISA, roughly about 600 opcodes
at present).

even then, it is still likely that my language would require a fair
amount of run-time support, and so would be ill-suited to non-hosted
environments (unless restricted to a more strict C-like subset).

so, C remains as my primary development language.