How would you design C's replacement?

[jacob navia]

Le 30/04/12 10:01, Malcolm McLean a écrit :

We also need a bigger standard library.

Things like hash tables, regular expressions,

directory functions, port access for internet programming, SQL,

and the ability to open a graphics window shouldn't have to rely on 3rd
party libraries.

Well, I am developing just that. And this since almost two years.

The latest message is just a few hours ago. Please take a look.

Thanks

jacob
P.S.

http://code.google.com/p/ccl/

 

[James Kuyper]

On 04/30/2012 02:33 AM, Robert Wessel wrote:
....

And if you can't address C's ubiquity, you aren't going to have a
better language than C.

One of the key features of C that has lead to it's ubiquity is also one
that's been most strongly reviled: the freedom it gives implementors in
implementing the language. The standard deliberately leaves many
features implementation-defined or otherwise unspecified, and in many
cases says that the behavior is undefined. In many cases, it does so
because it was thought that there might be some platforms, now or in the
future, for which requiring a specific behavior would make it
excessively difficult to create a fully conforming implementation of C
with acceptable performance.

What the standard doesn't say about Quality of Implementation (QoI)
allows a low-quality but conforming implementation of C to become
available on virtually every possible platform not long after the
platform itself becomes available. What the standard doesn't say about
specific features allows a high-performance implementation that takes
advantages of specific features of a particular platform, while still
being fully-conforming, to eventually become available.

That is a key factor in C's ubiquity. It's not the only factor - if it
were, then the best C standard would be no C standard, giving
implementors complete freedom of implementation. I programmed in C
before the first standard, I have no desire to go back to that world.
The C standard does mandate support for enough useful features that
people can write useful programs without very frequently exceeding the
limits of what it does guarantee, and that is also important.

 

[jacob navia]

Le 30/04/12 13:26, James Kuyper a écrit :

On 04/30/2012 02:33 AM, Robert Wessel wrote:
...

One of the key features of C that has lead to it's ubiquity is also one
that's been most strongly reviled: the freedom it gives implementors in
implementing the language. The standard deliberately leaves many
features implementation-defined or otherwise unspecified, and in many
cases says that the behavior is undefined. In many cases, it does so
because it was thought that there might be some platforms, now or in the
future, for which requiring a specific behavior would make it
excessively difficult to create a fully conforming implementation of C
with acceptable performance.

[snip]

That doesn't justify taking 20+ years for getting rid of gets() however.

There are obvious WARTS and BUGS in the C standard. asctime() had a
built in buffer overflow in the sample code of the C99 standard.

We have discussed about the trigraphs for years and they are STILL THERE
in the 2011 standard that didn't dare to fix all bugs apparently, they
were busy introducing more problems with their thread specs.

:-(

jacob

 

[James Kuyper]

if you want a proper reply make it clearer what you are asking.

You're talking to io_x; clarity is not an available option.

 

[Leo Havmøller]

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?

http://xkcd.com/927/

Leo Havmøller.

 

[BartC]

On 4/29/2012 4:37 PM, BartC wrote:

except #import is already used by C++, and is technically different from
include.

Sorry, I didn't realise this replacement language had to retain
compatibility with C++!

I'm not even sure if it's supposed to be a drop-in replacement for C itself.
(And if not, there was the D language, or the first version of it; recently
it seems to have become nearly as complex as C++).

<--
#pragma precompiled_header //compiler hint to use PCH
#pragma once //compiler hint to only include once

#ifndef MYLIB_H //good old header guard (for everyone else)
#define MYLIB_H
...
#endif
-->

But this is exactly the sort of stuff we're trying to tidy up. Just write
#import and let the compiler worry about these things. The efficiency of
reading large numbers of headers is also a compiler issue, and it should
solve that problem, if in fact it is a problem (caching the results of
previous imports of the same module for example; but it should be behind the
scenes).

yeah, my language uses this syntax.

(I use "_", "'" and "`" as separators which can also be mixed. I also allow
numeric literals to be split over several lines (as I have to accommodate
big integers too). Also "million", "billion" etc as multipliers.)

it would be nice in C for making things like 64-bit constants easier to
read.

Especially when they get around to allowing binary literals.

however, with multi-line string literals, I would no longer need a
separate tool for this, and could just be like:
char *mylib_bigGlobOfASM=
"""
...
lots of code...
...
lots more code...
...
""";

OK (just making a mental note to add the same feature..). Actually, a
version of #include which reads in the entire file as a string literal could
be useful here (taking care of embedded quotes etc which would anyway no
longer be an issue). That could also allow the compiler to keep the actual
string data on disk until it's necessary to do something with it.

 

[BartC]

I would strengthen arrays without the disadvantages of making them more
encapsulated.

What are the disadvantages of an encapsulated array (assuming there are
still regular arrays too)?

There would a way to define an integral object which indicates
the size of an array referenced by a pointer:

double *dynamic : int size;

I recently created a similar feature, I just called it a 'slice', but it is
simply an encapsulated (pointer, length) object. This is handy for passing
to functions (passing a regular array as a slice parameter, the length is
automatically filled in and the caller knows then the size of the array).
But is not suitable for proper dynamic arrays where the language looks after
the memory side.

This opens the way to slicing operations in the language, and works with
char arrays too! (Ie. you get counted strings for free.)

 

[Malcolm McLean]

בת×ריך ×™×•× ×©× ×™,30 ב×פריל 2012 09:08:29 UTC+1, מ×ת jacob navia:

Le 30/04/12 10:01, Malcolm McLean a écrit :


Things like hash tables, regular expressions,

directory functions, port access for internet programming, SQL,

and the ability to open a graphics window shouldn't have to rely on 3rd
party libraries.

Well, I am developing just that. And this since almost two years.

The latest message is just a few hours ago. Please take a look.

The issue is that it needs to be accepted as a standard by someone with theweight to make everyone use it.

Anyone can write typedef float[3] vect3; The hard part is getting everyone to use the same typedef for their 3d libraries. You'll always get some pedant who insists on point3 for points and vect3 for directions. And you'll always get someone who legitimately needs double precision, or 16 bit fixed point. But the worst problem is that someone else will write typedef struct {float x; float y; flaot z} vector3; simply because it was never arranged that you would be the person to define the 3 dimensional point type for the entire world.

 

[BGB]

Sorry, I didn't realise this replacement language had to retain
compatibility with C++!

I'm not even sure if it's supposed to be a drop-in replacement for C
itself. (And if not, there was the D language, or the first version of
it; recently it seems to have become nearly as complex as C++).

it depends.

for example, my own language is an entirely different language, but most
of my own "C variants" were more-or-less bidirectionally compatible with
existing C compilers, differing mostly in terms of details and
standards-conformance issues.

for example, a person can use alternate declaration parsing without
necessarily breaking compatibility, but with the cost that there may be
constructions which are no longer valid or held in common.

a person can also largely define syntax extensions in ways which can be
faked via macros as-needed.

....

But this is exactly the sort of stuff we're trying to tidy up. Just
write #import and let the compiler worry about these things. The
efficiency of reading large numbers of headers is also a compiler issue,
and it should solve that problem, if in fact it is a problem (caching
the results of previous imports of the same module for example; but it
should be behind the scenes).

I disagree in the sense that I wasn't writing about "tidying up" C, but
rather:
changes to increase flexibility and allow higher-performance compilers.


as-is, the design of the language often makes it necessary to spend
anywhere from 100ms to several seconds compiling each module (and C++ is
IME much worse in these regards), whereas at least allowing for the
possibility of a C compiler that requires, say, under 10ms per module,
would be desirable.

as-is, the bulk of time when compiling C tends to go mostly into:
A, parsing header contents;
B, dealing with parsed header contents.

besides this, declarations are both common and presently fairly
expensive to parse (needing to endlessly look up identifiers to
determine whether or not they are a typedef is both not free regarding
time, and also limits some possibilities regarding the implementation).


admittedly, I am partly also thinking of ideas to revive my "C-based
scripting" effort (eventually), partly by in this case likely compiling
C into a form usable by my BGBScript VM. it should work as nearly every
major C feature is supported by the script VM (yes, including pointers).

a downside would be that performance would be worse, since (among other
things), the script VM currently lacks a functional JIT. however, a
number of recent changes should make it possible to implement a much
simpler JIT, say, by reducing the need for complex type analysis in the
back-end, ...

(I use "_", "'" and "`" as separators which can also be mixed. I also
allow numeric literals to be split over several lines (as I have to
accommodate big integers too). Also "million", "billion" etc as
multipliers.)

I considered these, but opted for only allowing '_' on the basis that
the others would have potentially created syntax issues.

Especially when they get around to allowing binary literals.

yep.




OK (just making a mental note to add the same feature..). Actually, a
version of #include which reads in the entire file as a string literal
could be useful here (taking care of embedded quotes etc which would
anyway no longer be an issue). That could also allow the compiler to
keep the actual string data on disk until it's necessary to do something
with it.

yes, potentially.

 

[James Kuyper]

On 04/30/2012 11:22 AM, Malcolm McLean wrote:
....

The issue is that it needs to be accepted as a standard by someone with the weight to make everyone use it.

No one has that "weight". If it needs to be forced on people - if it
can't gain acceptance except by reason of being mandated by a
sufficiently powerful authority - it can't be good enough to justify
mandating it.

 

[BartC]

בת×ריך ×™×•× ×©× ×™, 30 ב×פריל 2012 09:08:29 UTC+1, מ×ת jacob navia:

The issue is that it needs to be accepted as a standard by someone with
the weight to make everyone use it.

Anyone can write typedef float[3] vect3; The hard part is getting everyone
to use the same typedef for their 3d libraries.

Does it happen often that you want to make the same application work with
several different libraries? Even if exactly the same typedef was used,
there would be entirely different sets of functions, macros, defines. For
example to get your GDI32 application to work with OpenGL instead, might
involve more than a compatible set of typedefs.

I don't see the problem. And if there is, the usual solution is to write
wrappers around the libraries to make their interface more acceptable.

You'll always get some pedant who insists on point3 for points and vect3
for directions. And you'll always get someone who legitimately needs double
precision, or 16 bit fixed point. But the worst problem is that someone
else will write typedef struct {float x; float y; flaot z} vector3; simply
because it was never arranged that you would be the person to define the 3
dimensional point type for the entire world.

So, what *should* be the common 3D point representation? What about a 3D
vector? See, it's not so easy...

Although the comment was more to do with basic screen graphics.

 

[James Kuyper]

Anyone can write typedef float[3] vect3; The hard part is getting everyone
to use the same typedef for their 3d libraries.

Does it happen often that you want to make the same application work with
several different libraries?

I'm required by our contract with our client to make my application work
simultaneously with four different libraries. Two of them have a number
of typedefs that they use for similar purposes; the other two rely upon
standard C types for those same purposes. My code necessarily reads data
as float64 from the input file, converts to PGSt_double for using
certain utilities, converts to double for using certain C standard
library functions, and then converts back to float64 to write to the
output file. Those are quite likely all the same type - but the library
makers reserve the right to make them different types, depending upon
the platform where my program is compiled, or depending upon the version
of the library. As a result, I can't meet my portability requirements
unless I write my code so it works properly even if float64, PGSt_double
and double turn out to be three different types.

If I had permission to assume C2011, I could use the _Generic feature to
write more complicated code that handles things more efficiently
whenever any two of those types are compatible. I don't even have
permission to use C99 yet.

It would simplify my code if they could all have reached agreement on
the name and meaning of similar typedefs. However, it's only an
inconvenience. Typedefs for vectors and points would be more of a
problem, if I had needed to use them.

 

[lawrence.jones]

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?

That the person assigning the task get their head examined.

 

[Michael Angelo Ravera]

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?

What are C's design goals? I would say that they allow low-level manipulation and production of efficient code while opting for a terse syntax and portability.

If we are interested in allowing better documentation, we should have a "Long Comment Begins" and "Long Comment Ends" in addtion to "short comment begins" and "short comment ends" "/*" and "*/" are fine for the latter.

If we are interested in low-level manipulation, how about a "Fake Assembly Language" syntax as an option.

I have yet to find a language that nominates functions and arguments without describing the function (extdefs, ect) in a way that I would like.

I have yet to find a language that allows for variable, optional, or sparse arguments to functions in a way that I would like.

Some sort of syntactic difference between language provided features such as "sizeof", "offsetof", "argumentpassed", "numberofarguments" and things that could be user or implementation provided.

 

[jacob navia]

Le 30/04/12 20:25, (e-mail address removed) a écrit :

That the person assigning the task get their head examined.

C is perfect?

Trigraphs included?

Now, come on...

 

[Rui Maciel]

Serialisation needs to be an inherent part of the language, with the
ability to serialise to backing store, memory, or a port, in a
cross-platform and interoperable way.

Why should serialization be an inherent part of the language?

Libraries need to be a lot easier to install and use.

Technically, they are already extremely easy to install and use. You store
the header files anywhere in your file system, as you do with the library's
object files, then you add those paths to your compiler's library and
include path. Good to go.

1) We need an end to the type problem. For instance every library that
does 3d graphics will define some version of Point, point3, vector3, or so
on. None of these work together.

2) We need an end to the stickiness problem. I recently asked for a
"convolve" function in C which did fast convolution with Fourier
transforms. I was directed to a massive library, OpenCV. My code is meant
to run as a Matlab mex fuunction (a matlab-callable function written in
C). In the event I got a KISS fft from the net and wrote my own.

I don't see how that would be a problem with the C programming language.

3) We need a simple, consistent method for specifying libraries,
installing them, and linking them.

I believe things don't get any simpler than copying them wherever you feel
like it and then configure your compiler to search for them. If you take
advantage of your system's standard paths, such as /usr/include and
/usr/lib, then you don't even need to tweak the compiler.

We also need a bigger standard library. Things like hash tables, regular
expressions, directory functions, port access for internet programming,
SQL, and the ability to open a graphics window shouldn't have to rely on
3rd party libraries.

I can understand the need for standard data structures. Yet, we already
have a standard library for "internet programming", and I really don't
understand why it would be in anyone's best interests to include stuff such
as SQL and GUI libraries into C's standard library. That's looks like a
problem masquerading as a solution for a problem that doesn't exist.


Rui Maciel

 

[Rui Maciel]

If we are interested in low-level manipulation, how about a "Fake Assembly
Language" syntax as an option.

I believe it can be argued that the C programming language is already a
"fake assembly language" as it is.


Rui Maciel

 

[Rui Maciel]

Perhaps the problems and shortcomings should be summarised first. Then
they need to be agreed to be shortcomings;

These tend to be more subjective than objective. I believe it's more
interesting if we get people to point out what they perceive to be a
problem, why it's a problem and how they would fix it.



Rui Maciel

 

[BGB]

בת×ריך ×™×•× ×©× ×™, 30 ב×פריל 2012 09:08:29 UTC+1, מ×ת jacob navia:

The issue is that it needs to be accepted as a standard by someone with
the weight to make everyone use it.

Anyone can write typedef float[3] vect3; The hard part is getting
everyone
to use the same typedef for their 3d libraries.

Does it happen often that you want to make the same application work with
several different libraries? Even if exactly the same typedef was used,
there would be entirely different sets of functions, macros, defines. For
example to get your GDI32 application to work with OpenGL instead, might
involve more than a compatible set of typedefs.

I don't see the problem. And if there is, the usual solution is to write
wrappers around the libraries to make their interface more acceptable.

yes.

the usual split IME is to split the "inside" and "outside" worlds of the
codebase, with the inside using its own conventions, and most external
interfacing being done by wrappers.

generally, this is much cleaner IME than letting the outside types and
APIs and similar be directly exposed to internal code.

So, what *should* be the common 3D point representation? What about a 3D
vector? See, it's not so easy...

Although the comment was more to do with basic screen graphics.

in my case, to a large degree I have roughly adopted a variant inspired
by GLSL:
'vec3': contains 3 floats;
'vec3d': contains 3 doubles;
'vec4' and 'vec4d', likewise.
....

as-is they are represented as one of:
a structure containing 4 floats ('w' is ignored for vec3);
a structure containing an "__xmm128" (SIMD intrinsics are used depending
on the compiler and compiler options in use);
another version specialized for my own C compiler and tools (these are
mapped to built-in vector-math types and intrinsics).

sadly, the above difference does create a worry that there "could" be
potential compatibility issues between libraries compiled with different
compiler options (say, due to differences in representation and alignment).

most basic operations are handled by either wrapper macros or
static-inline functions, with some more complex ones (for example,
"slerp", ...) redirecting to library functions.

for example: "v3dot(a, b)" calculates the dot-product of two 'vec3'
vectors, "v3add(a, b)" adds two vectors, "v3cross(a, b)" does
cross-product, "v3x(a)" gets the x component, "v3xz(a)" gets an XZ
vector (vec2), ...


my script language also supports them as a built-in feature (and using
binary operators instead), internally representing them as "boxed
value-types" (heap-allocated objects using value-type semantics).


a lot of my older C code makes use of raw float pointers and arrays, but
this is being gradually replaced. due to being both more generally
awkward and, actually, apparently slightly slower on-average.

although for in certain cases arrays of floats are faster, in many other
cases they seem to work out marginally slower "for some reason" than the
use of passing structs around by-value (I actually find this a bit
counter-intuitive).

but, performance is like this sometimes.

nevermind, there are a few regions of code which use arrays of doubles
as the default vector type, ...

but, float is generally sufficient for "most things" in a 3D engine (and
double is often overkill).

 

[Ben Pfaff]

Le 30/04/12 20:25, (e-mail address removed) a écrit :

C is perfect?

No language is perfect and so anyone assigning the tasks of
fixing "all [C's] problems and shortcomings" is setting an
impossible goal.