How would you design C's replacement?

[Rui Maciel]

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

[BartC]

"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:jnjpil$ek2$1...@speranza.aioe.org...

> 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

[Keith Thompson]

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) ks...@mib.org <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"

[Kaz Kylheku]

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]

"Rui Maciel" <rui.m...@gmail.com> ha scritto nel messaggio
news:jnjpil$ek2$1...@speranza.aioe.org...

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

[io_x]

"io_x" <a...@b.c.invalid> ha scritto nel messaggio
news:4f9d9e5f$0$1384$4faf...@reader2.news.tin.it...

here i not find the google sys for NG
so google not support NG?

[io_x]

"io_x" <a...@b.c.invalid> ha scritto nel messaggio
news:4f9d9e5f$0$1384$4faf...@reader2.news.tin.it...

and some instruction on 8 bit unsigned char too

[Rui Maciel]

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

[FireXware]

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.

[BartC]

"BartC" <b...@freeuk.com> wrote in message news:jnjun6$g0s$1...@dont-email.me...

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

[Mark Storkamp]

In article <jnjpil$ek2$1...@speranza.aioe.org>,

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

[BGB]

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.

[Kaz Kylheku]

On 2012-04-29, Stefan Ram <r...@zedat.fu-berlin.de> wrote:

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

I'd propose to hang C on the shelf and keep evolving C++.

[BartC]

"BGB" <cr8...@hotmail.com> wrote in message
news:jnkfle$2bh$1...@news.albasani.net...

> On 4/29/2012 10:44 AM, BartC wrote:

>> "Rui Maciel" <rui.m...@gmail.com> wrote in message
>> news:jnjpil$ek2$1...@speranza.aioe.org...
>>> If you were given the task to design a replacement for the C programming
>>> language intended to fix all its problems and shortcomings

>> Perhaps the problems and shortcomings should be summarised first.

> "#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).

The #include mechanism can be left alone. But for using library functions,
there would just be something like:

#import bar

As I've implemented this elsewhere, this defines the imported names from bar
in a protective scope, forming a namespace that ought not to clash with
anything that happens in foo. This does require that the compilation of
bar/foo produces a special file containing all the exported names, and that
that compilation has already been done. (That makes mutual imports/exports
between two modules tricky. That's why you leave the old #include in
place...)

> other things which could be nice:
>
> ability to put "_" in numbers as a separator, as in
> "0x0123_4567_89AB_CDEF"

At least two or three major versions of C over twenty years, and no-one
bothers to add in trivial stuff like this which takes five minutes..

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

Doesn't C already have that? You do need to have the portion on each line
fully quoted.

> 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...

Same here...

--
Bartc

[BGB]

this is more of an OS or tools issue than a language issue though.

although, C extensions to indicate library dependencies could be nice,
such that a directive in the headers can indicate to the compiler to
link against certain libraries.

#pragma usinglib("somelibrary")

could give a hint to the linker to try linking against
"libsomelibrary.so" or "somelibrary.dll" or similar.



but, on this note, some sort of cross-platform VM architecture which can
capably run C code would also be nice, as in:
can run unmodified C code (as well as other languages);
performs comparably to natively compiled code;
can utilize natively compiled libraries (and can be readily linked with
native code in both directions);
...

although technically .NET can run C and C++ code (via C++/CLI), it can't
really do so in a portable manner, and implementations like Mono don't
support it.

granted, this is likely itself technically non-trivial in some ways
(would be difficult to pull off in terms of keeping it portable and
non-intrusive), and apart from using native binary formats (such as
PE/COFF and ELF), it would almost invariably require some level of
auto-generated glue-code (such as linking against a "managed" library
requires either linking against a special static library or stub-library
which in-turn "trampolines" into the VM).

calling out of a VM is at least a little easier, but still not perfect.

a more subtle but nasty issue is that the contents of system headers
will tend to vary from one target to another:
the values of various defines;
the contents of various structures;
the types of various typedefs;
...

this in-turn likely requiring some "nasty trickery" to make work (this
is a problem which AFAICT C++/CLI did not address).


the other option would be to run the VM with "sandboxed" system
libraries (say, the C runtime runs within the VM and is independent of
the "native" C runtime). although simpler, this doesn't really fix the
problem (and potentially introduces a "seam" between the the world
inside the VM and the natively compiled parts of the app, say when
sharing data with the potentially that the internal and external types
and values differ).


although, to some extent, this latter strategy could be "glossed" via
trickery, such as:
typedef __native_type__(size_t) size_t;
typedef __native_type__(FILE) FILE;
which could basically indicate that the type is declared external to the
VM sandbox (the full type will not be known until later, but this allows
the compiler to have a set of "placeholder" types to work with).

as well as possibly with hackery like:
__native__ void *malloc(size_t size);
...

in this case, the version of the C library within the VM is mostly a set
of stubs to the native C library.


or such...

[BGB]

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

a hack involving precompiled headers and a #pragma could allow C to use
a more efficient mechanism which remaining backwards compatible and
still conform to the C standard.


example(mylib.h):
<--
#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
-->

(bar.c)
<--
#include <mylib.h> //doesn't look any different than before
...
-->

so, what happens in this case is that the preprocessor starts going,
sees the header, and sees the #pragma, and is all like "my work is done
here" and inserts a command into the preprocessor output telling the
compiler to load the precompiled header instead (or however exactly it
ends up being implemented).

in the likely worst case, #include is no slower than before.

>> other things which could be nice:
>>
>> ability to put "_" in numbers as a separator, as in
>> "0x0123_4567_89AB_CDEF"
>
> At least two or three major versions of C over twenty years, and no-one
> bothers to add in trivial stuff like this which takes five minutes..
>

yeah, my language uses this syntax.
it would be nice in C for making things like 64-bit constants easier to
read.

>> multi-line strings (like in Lua, Python, and my own language).
>
> Doesn't C already have that? You do need to have the portion on each
> line fully quoted.
>

the problem in C is that it is ugly-looking, and makes it awkward to
type large multi-line string constants.

it also doesn't help that compilers like MSVC will barf if a string
constant is larger than about 4096 characters or so (so, then one has
the fun of not only having nasty multi-line strings, but such strings in
an array).

as-is, mostly these are used for inlining globs of ASM and BGBScript
code into C (sometimes tool-aided, mostly so that I can type the code
into stand-alone text files without needing all those nasty quotes and
"\n" escapes).


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...
...
""";


although, the compiler for my language currently has a limit of 64k
characters for a multi-line string literal, but I could potentially
change this later (such as maybe allowing several MB or more in a large
string literal), but at this point it would almost make sense to devise
some sort of data-compression feature (such as an LZ77 variant) for
large string literals.

however, even 64k is "pretty damn large" WRT a string literal (a person
is hard-pressed to exceed this by writing code by hand, whereas 4k is a
much easier limit to run into), but this could happen if folding
data-files into source-code or similar.


my language allows both triple-quotes and a custom "<[[ ... ]]>" syntax,
which mostly has the merit of being nestable provided it is evenly
matched. although slightly uglier IMO than the "[[ ... ]]" syntax used
in Lua, the merit is that it doesn't clash with the syntax for nested
arrays (since arrays use the syntax "[ ... ]" in my language, mostly due
to its ECMAScript heritage).

the reasoning also being that "<[[" and "]]>" were otherwise very
unlikely to show up normally, and even then, they are not real tokens by
themselves, and so will only be recognized in certain contexts (such as
when parsing a literal).

>> 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...
>
> Same here...
>

yep.

[Ian Collins]

On 04/30/12 01:30 PM, BGB wrote:
> On 4/29/2012 4:37 PM, BartC wrote:
>>
>> The #include mechanism can be left alone. But for using library
>> functions, there would just be something like:
>>
>> #import bar
>>
>> As I've implemented this elsewhere, this defines the imported names from
>> bar in a protective scope, forming a namespace that ought not to clash
>> with anything that happens in foo. This does require that the
>> compilation of bar/foo produces a special file containing all the
>> exported names, and that that compilation has already been done. (That
>> makes mutual imports/exports between two modules tricky. That's why you
>> leave the old #include in place...)
>>
>
> except #import is already used by C++, and is technically different from
> include.

Is it?

--
Ian Collins

[James Kuyper]

On 04/29/2012 09:30 PM, BGB wrote:
> On 4/29/2012 4:37 PM, BartC wrote:

...

>> The #include mechanism can be left alone. But for using library
>> functions, there would just be something like:
>>
>> #import bar

...

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

When did they add that, and what does it mean? I haven't kept up with
C++, my latest draft standard version is n3035, dated 2010-02-16; it
makes no mention of #import.
--
James Kuyper

[jacob navia]

Le 29/04/12 22:56, Stefan Ram a écrit :

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

I am doing exactly that. See

http://www.cs.virginia.edu/~lcc-win32

[BGB]

ok, it is not standard, but both MSVC and GCC seem to have support for
it, so either way...


both make mention of it:

http://msdn.microsoft.com/en-us/library/8etzzkb6%28v=vs.71%29.aspx

http://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Obsolete-once-only-headers.html


it does basically the same thing as #include but only includes the file
once.


however, I would be less fond of using the directive, as either way:
it doesn't have exactly the intended semantics, so a secondary mechanism
would still be needed;
it isn't compatible with compilers which don't support it, and something
like:

#ifdef _SOMECC
#import <foo.h>
#else
#include <foo.h>
#endif

isn't really a desirable solution.
it seems better IMO if a single solution could be used, with the option
of optionally improving performance on certain implementations.

[Robert Wessel]

On Sun, 29 Apr 2012 17:17:29 +0100, Rui Maciel <rui.m...@gmail.com>
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?

There have been dozens, if not hundreds attempts to create a "better"
language than C. Heck, I've speculated how such a thing might look,
and have a laundry list of things I'd like changed.

The problem is that all this entirely misses the point. C is an OK
low-ish level language, with no horrible flaws that prevent its use in
many places. There *are* dozens of better languages, even for C's
primary system level purpose. C's value has almost nothing to do with
its quality as a language (other than the avoidance of terrible
flaws), and everything to do with its ubiquity.

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

[io_x]

"Rui Maciel" <rui.m...@gmail.com> ha scritto nel messaggio

news:jnk87q$pu4$1...@speranza.aioe.org...

my macro assembly is easier than C because not has undefinite behaviour
and it is as it has to be... the loop-if build with gotos

> Rui Maciel

[nick_keigh...@hotmail.com]

On Sunday, April 29, 2012 9:07:39 PM UTC+1, io_x wrote:

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

I don't think you understand what assembler is

[nick_keigh...@hotmail.com]

On Sunday, April 29, 2012 9:23:08 PM UTC+1, io_x wrote:

> here i not find the google sys for NG
> so google not support NG?

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

this was posted from Google Groups. Does that answer your question?

[Malcolm McLean]

בתאריך יום ראשון, 29 באפריל 2012 17:17:29 UTC+1, מאת Rui Maciel:

> 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?
>

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.

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

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.

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

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.

[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.
--
James Kuyper

[jacob navia]

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

> 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.
>

[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]

On 04/30/2012 03:41 AM, nick_keigh...@hotmail.com wrote:
> On Sunday, April 29, 2012 9:23:08 PM UTC+1, io_x wrote:
>
>> here i not find the google sys for NG
>> so google not support NG?
>
> 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.
--
James Kuyper

[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]

"BGB" <cr8...@hotmail.com> wrote in message

news:jnkq43$f66$1...@news.albasani.net...

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

>> The #include mechanism can be left alone. But for using library
>> functions, there would just be something like:
>>
>> #import bar

> 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).

>>> ability to put "_" in numbers as a separator, as in
>>> "0x0123_4567_89AB_CDEF"
>>
>> At least two or three major versions of C over twenty years, and no-one
>> bothers to add in trivial stuff like this which takes five minutes..
>>
>
> 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.

>>> multi-line strings (like in Lua, Python, and my own language).
>>
>> Doesn't C already have that? You do need to have the portion on each
>> line fully quoted.

> 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

[BartC]

"Kaz Kylheku" <k...@kylheku.com> wrote in message
news:20120429...@kylheku.com...

> On 2012-04-29, Rui Maciel <rui.m...@gmail.com> 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 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.)

--
Bartc

[io_x]

"James Kuyper" <james...@verizon.net> ha scritto nel messaggio
news:jnlt4j$4vp$2...@dont-email.me...

yes, i find the link in the II page of www.google.it ...

[BGB]

On 4/30/2012 5:06 AM, BartC wrote:
> "BGB" <cr8...@hotmail.com> wrote in message
> news:jnkq43$f66$1...@news.albasani.net...
>> On 4/29/2012 4:37 PM, BartC wrote:
>
>>> The #include mechanism can be left alone. But for using library
>>> functions, there would just be something like:
>>>
>>> #import bar
>
>> 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++).
>

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.

...

>> <--
>> #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).
>

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, ...

>
>>>> ability to put "_" in numbers as a separator, as in
>>>> "0x0123_4567_89AB_CDEF"
>>>
>>> At least two or three major versions of C over twenty years, and no-one
>>> bothers to add in trivial stuff like this which takes five minutes..
>>>
>>
>> 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.)
>

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

>> 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.
>

yep.

>>>> multi-line strings (like in Lua, Python, and my own language).
>>>
>>> Doesn't C already have that? You do need to have the portion on each
>>> line fully quoted.
>
>> 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.
>

yes, potentially.

[Malcolm McLean]

בתאריך יום שני, 30 באפריל 2012 09:08:29 UTC+1, מאת 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.
>

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. 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.

[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]

"Malcolm McLean" <malcolm...@btinternet.com> wrote in message
news:25101282.569.1335799356436.JavaMail.geo-discussion-forums@vbez20...

> בתאריך יום שני, 30 באפריל 2012 09:08:29 UTC+1, מאת jacob navia:
>> Le 30/04/12 10:01, Malcolm McLean a écrit :
>>
>> > We also need a bigger standard library.

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

> 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.

--
Bartc

[James Kuyper]

On 04/30/2012 12:17 PM, BartC wrote:
>
>
> "Malcolm McLean" <malcolm...@btinternet.com> wrote in message
> news:25101282.569.1335799356436.JavaMail.geo-discussion-forums@vbez20...

...

>> 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.

[io_x]

<nick_keigh...@hotmail.com> ha scritto nel messaggio
news:16038993.1390.1335771751469.JavaMail.geo-discussion-forums@vbai3...

> On Sunday, April 29, 2012 9:07:39 PM UTC+1, io_x wrote:
>
>> i propose assembly: 8 32 bits registers and 20 - 30 instruction on them ...
>
> I don't think you understand what assembler is

an assembler is one text converter from text we write in
the paper, or in one .txt format file, to cpu instructions...
to a file of cpu instructions
right? or something about it

i don't like theory [expecially when it seems theory is wrong]
so i like more pratice: programming using goto
[i express by '#'] for example this is
the last function i wrote-debug today...

align 4
InsBuf4CR:
<b,i,j,k
s-=32
a>=16#.e |a==0#.e|#.1
.e: a=16|stc |#.z
.1: i= c|^0=a|^4=c|i&=0Fh|^8=i ; i==0Fh [tutti bianchi] oppure
; caso nero 0<=i<=0Eh la posizione del primo nero
a&8!#.4
i==0Fh!#.2 ; tutti bianchi
a=0|FindPosBuf4CR() |jc .e ; nessuna posizione libera
k=a|a=^0|a&=7|PushkaBuf4CR()|jc .e|k&=0Fh|c&=0FFFFFFF0h|c|=k|#.f
.2: b=0Eh|FindPosOrdBuf4CR() |jc .e
.3: k=a|a=^0|a&=7|PushkaBuf4CR()|jc .e|#.f
; caso bianco
.4: i==0Fh!#.5 ; tutti bianchi
i=0|b=0Eh|FindPosOrdBuf4CR()|jc .e |#.3 ; CF== nessuna posizione libera
.5: i==0#.7|b=&*i-1|i=0|FindPosOrdBuf4CR() |jnc .6
a=&*b+1|a>=0Fh#.e ; caso non trovato in range
dato=> in b+1
.6: j=^8|j>=0Eh#.e|c&=0FFFFFFF0h|++j|c|=j|#.3
.7: ; caso inserisci un bianco in un vettore di neri...
; oppure inserisci il primo bianco
c==0!#.8|r==0!#.8|c|=0Fh|a=0|#.3
.8: a=0 |#.6
.f: a=k|clc
.z:
s=&*s+32
>b,i,j,k
ret

for doing the equivalent of what that function does, in some other language
in what i think...it is 4 time more long and 100 time more complex and
not readable...
and error check going to null...

Buon Giorno

[Michael Angelo Ravera]

On Sunday, April 29, 2012 9:17:29 AM UTC-7, 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?

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.

[lawrenc...@siemens.com]

Rui Maciel <rui.m...@gmail.com> 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?

That the person assigning the task get their head examined. :-)
--
Larry Jones

When you're SERIOUS about having fun, it's not much fun at all! -- Calvin

[jacob navia]

Le 30/04/12 20:25, lawrenc...@siemens.com a écrit :

> Rui Maciel<rui.m...@gmail.com> 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?
>
> That the person assigning the task get their head examined. :-)

C is perfect?

Trigraphs included?

Now, come on...

[Rui Maciel]

Malcolm McLean wrote:

> 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]

Michael Angelo Ravera wrote:

> 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]

BartC wrote:

> 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]

On 4/30/2012 9:17 AM, BartC wrote:
>
>
> "Malcolm McLean" <malcolm...@btinternet.com> wrote in message
> news:25101282.569.1335799356436.JavaMail.geo-discussion-forums@vbez20...
>> בתאריך יום שני, 30 באפריל 2012 09:08:29 UTC+1, מאת jacob navia:
>>> Le 30/04/12 10:01, Malcolm McLean a écrit :
>>>
>>> > We also need a bigger standard library.
>
>>> and the ability to open a graphics window shouldn't have to rely on 3rd
>>> party libraries.
>
>> 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.

>> 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.
>

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]

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

[jacob navia]

Le 30/04/12 23:04, Ben Pfaff a écrit :

I mentioned specific problems that you snipped.

The fact that perfection is not possible should not be an excuse for
leaving bugs in the language or not trying to improve it.

[Joe keane]

In article <jnjpil$ek2$1...@speranza.aioe.org>,

Rui Maciel <rui.m...@gmail.com> 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 propose?

I would make a language where the bitwise operators have higher
precedence than the comparison operators.

[Ben Pfaff]

Jacob, I'm criticizing the hypothetical assignment given by Rui,
not anything you wrote.

[BartC]

"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:jnmt3p$jro$1...@speranza.aioe.org...

OK, let's start with something obvious: C's type-declaration syntax. I find
its inside-out convoluted form completely impossible.

I've often had to resort to CDECL to sort out complex declarations. There
must be something seriously wrong in a language if I have to use external
tools to help understand it! And every time I've discussed this in this
group, I get step-by-step lessons on how to decode, or construct, such a
declaration! Nothing about fixing the language.

Outside of C, I use a type-declaration syntax that reads pretty much like
the English output of CDECL. And I once proposed, in clc, such a
left-to-right syntax for C that could just about co-exist with the old-style
type syntax.

And while we're dealing with the type-system, let's standardise on an
unsigned char type, and have separate signed/unsigned int types of the same
width as char (ie. bytes). There's loads more tidying of the type system
that can be done, but just one more thing for now: I'd also get rid of
struct name-spaces; they're just a source of confusion.

--
Bartc

[Keith Thompson]

James Kuyper <james...@verizon.net> writes:
[...]

> 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.

[...]

Out of curiosity, how to you verify that your code would still work if
these were different types? Do you have a test configuration with
modified versions of the libraries?

--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"

[Keith Thompson]

But not persuasively, IMHO.

C is at a lower semantic level than a lot of other languages.
But the major difference between C and assembly language is that
an assembly program specifies CPU instructions, while a C program
specifies run-time behavior.

That's a *huge* distinction, with assembly languages on one side,
and C, C++, Ada, Python, APL, and Intercal firmly on the other.

[Ian Collins]

On 04/30/12 06:33 PM, Robert Wessel wrote:
> On Sun, 29 Apr 2012 17:17:29 +0100, Rui Maciel<rui.m...@gmail.com>

> 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?
>
>

> There have been dozens, if not hundreds attempts to create a "better"
> language than C. Heck, I've speculated how such a thing might look,
> and have a laundry list of things I'd like changed.
>
> The problem is that all this entirely misses the point. C is an OK
> low-ish level language, with no horrible flaws that prevent its use in
> many places. There *are* dozens of better languages, even for C's
> primary system level purpose. C's value has almost nothing to do with
> its quality as a language (other than the avoidance of terrible
> flaws), and everything to do with its ubiquity.
>
> And if you can't address C's ubiquity, you aren't going to have a
> better language than C.

C's ubiquity comes in various forms, not only as run anywhere but also
find a programmer anywhere.

Most of the embedded projects I have been involved with recently use gcc
and a decent subset of those used gcc and a Linux kernel. One of my
first questions I asked on joining those projects was "why don't you use
C++?" and the answer invariably boils down to "we use what we are
familiar with".

So if it's hard to find experienced developers for the most popular C
derived language, I'd hate to be the one promoting a new one!

--
Ian Collins

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
[...]

> OK, let's start with something obvious: C's type-declaration syntax. I find
> its inside-out convoluted form completely impossible.
>
> I've often had to resort to CDECL to sort out complex declarations. There
> must be something seriously wrong in a language if I have to use external
> tools to help understand it! And every time I've discussed this in this
> group, I get step-by-step lessons on how to decode, or construct, such a
> declaration! Nothing about fixing the language.

Probably because this newsgroup isn't really about "fixing the
language".

> Outside of C, I use a type-declaration syntax that reads pretty much like
> the English output of CDECL. And I once proposed, in clc, such a
> left-to-right syntax for C that could just about co-exist with the old-style
> type syntax.

If you wanted to add a new declaration syntax to C, it would have to
*completely* coexist with the existing syntax. Breaking existing code
is not an option. (Yes, each new C standard has broken *some* existing
code, at least theoretically, but breaking every declaration more
complex than "int i;" would not be acceptable.)

And while I agree that a better syntax for a hypothetical new language
(the "C's replacement" we're discussing in this thread) would be great,
I'm not sure that a C-like language supporting both the existing syntax
and a new syntax would be better than one that just supports the
existing syntax.

But something that might be interesting, not as a language change but as
a development tool, would be integrating something like cdecl into the
build process. You could write code in a C-like dialect, with
declarations written in your new syntax, and your build tool would
automatically generate syntactically correct C. Another tool could
translate C declarations into your syntax. It would let you use your
preferred syntax while still being able to share C code with others who
don't have your tools.

> And while we're dealing with the type-system, let's standardise on an
> unsigned char type, and have separate signed/unsigned int types of the same
> width as char (ie. bytes). There's loads more tidying of the type system
> that can be done, but just one more thing for now: I'd also get rid of
> struct name-spaces; they're just a source of confusion.

I presume you mean requiring plain "char" to be unsigned (we already
have "unsigned char"). I tend to agree; permitting plain char to be
signed causes a lot of conceptual problems. I wonder what kind of
performance problems it might introduce, though; char expressions are
frequently promoted to int, and that promotion might be more expensive
on some systems if plain char is signed. (I presume that's why so many
compilers make plain char signed, when making it unsigned would be
perfectly legal.)

[BGB]

On 4/30/2012 5:08 PM, Keith Thompson wrote:
> "BartC"<b...@freeuk.com> writes:
> [...]
>> OK, let's start with something obvious: C's type-declaration syntax. I find
>> its inside-out convoluted form completely impossible.
>>
>> I've often had to resort to CDECL to sort out complex declarations. There
>> must be something seriously wrong in a language if I have to use external
>> tools to help understand it! And every time I've discussed this in this
>> group, I get step-by-step lessons on how to decode, or construct, such a
>> declaration! Nothing about fixing the language.
>
> Probably because this newsgroup isn't really about "fixing the
> language".
>

agreed.

I personally see little problem with the syntax in-general, except in a
few cases.

>> Outside of C, I use a type-declaration syntax that reads pretty much like
>> the English output of CDECL. And I once proposed, in clc, such a
>> left-to-right syntax for C that could just about co-exist with the old-style
>> type syntax.
>
> If you wanted to add a new declaration syntax to C, it would have to
> *completely* coexist with the existing syntax. Breaking existing code
> is not an option. (Yes, each new C standard has broken *some* existing
> code, at least theoretically, but breaking every declaration more
> complex than "int i;" would not be acceptable.)
>
> And while I agree that a better syntax for a hypothetical new language
> (the "C's replacement" we're discussing in this thread) would be great,
> I'm not sure that a C-like language supporting both the existing syntax
> and a new syntax would be better than one that just supports the
> existing syntax.
>

my own language (BGBScript) has an issue similar to this.


given its ECMAScript heritage, it has ECMAScript-style declarations.
given other reasons (mostly related to inter-language copy/paste), it
also has a more Java/C# style declaration syntax.

it is kind of annoying, as there is an issue as to which syntax is more
canonical.

I am mostly leaning more towards the ES-style being more canonical, more
because the language is technically an ES variant (it is largely
ECMA-262 conformant), and so it makes more sense if the language uses as
its canonical syntax, the one defined in the standard on which it is based.


example:
var x;
var i:int;
var a:int[];
var pv:*void;
vs:
variant x; //(1)
int i;
int[] a;
*void pv; //(2)

1: this syntax is longer and not strictly equivalent to "var x;",
however "var x;" is technically the other syntax given that var is a
declaration keyword. "variant x" is technically equivalent to "var
x:variant;". there is currently little functional difference though.

note that, given how the declaration parser works, it is also
technically possible to create double-typed variables, as in:
"int x:long, y:double;"

however, these currently have little practical use, and should be
considered an error (as-is, the later types will override the base type).

function declaration syntax is also partly redundant:
function foo(x:int):void { ... }
vs:
void foo(int x) { ... }


as-is, closures can only be declared with an ES-like form (sort of),
given that there are syntax problems otherwise.

function(x) { ... }
function(i:int):void { ... }

however:
function(int i) { ... }
function(int i):void { ... }
will probably work...

things like getters/setters, ... also have redundant syntax.

function get x():int { ... }
vs:
int get x() { ... }

...


2: "*type" was used instead of "type*" in my language due to there being
several cases in which the later would be syntactically ambiguous.
although declaring pointers this way may look strange, as-is it is a
fairly trivial change, and doesn't particularly hinder converting C code
to BGBScript, or at least not nearly as much as the differences in the
cast syntax.


a recent set of (fairly fundamental) changes in my interpreter has made
many of these types more canonical, as now declaring a variable as "int"
will actually store the variable as a 32-bit integer internally, rather
than, say, as a fixnum.

these changes have introduced a lot of bugs, so it is still an ongoing
transition.


I was also recently thinking and considering if my interpreter would be
fast enough to allow porting Quake to my Script VM. if some recent
benchmarks are representative, my interpreter is performing comparably
to the sorts of hardware Quake 1 and 2 were developed for, and so should
be sufficiently fast to run these games (even without a JIT).

granted, I would likely need a C front-end for this VM (sadly, doesn't
currently exist, 3), as it would probably be too much effort to port the
entire Quake 1 or Quake 2 engine to BGBScript.

not sure yet if I will actually attempt a thing, since as-is, this would
still be a fairly big project given the present state of the VM.


3: my existing C compiler targeted a different back-end, which is no
longer in operation. I would either need to modify this front-end to
target the current Script VM, or very possibly create a new C front-end,
or possibly a combination (keeping the existing parser, but write a new
AST->bytecode stage).

> But something that might be interesting, not as a language change but as
> a development tool, would be integrating something like cdecl into the
> build process. You could write code in a C-like dialect, with
> declarations written in your new syntax, and your build tool would
> automatically generate syntactically correct C. Another tool could
> translate C declarations into your syntax. It would let you use your
> preferred syntax while still being able to share C code with others who
> don't have your tools.
>

it is possible...

>> And while we're dealing with the type-system, let's standardise on an
>> unsigned char type, and have separate signed/unsigned int types of the same
>> width as char (ie. bytes). There's loads more tidying of the type system
>> that can be done, but just one more thing for now: I'd also get rid of
>> struct name-spaces; they're just a source of confusion.
>
> I presume you mean requiring plain "char" to be unsigned (we already
> have "unsigned char"). I tend to agree; permitting plain char to be
> signed causes a lot of conceptual problems. I wonder what kind of
> performance problems it might introduce, though; char expressions are
> frequently promoted to int, and that promotion might be more expensive
> on some systems if plain char is signed. (I presume that's why so many
> compilers make plain char signed, when making it unsigned would be
> perfectly legal.)
>

in my language, I split them up, so these types are more like:
byte: 8-bit unsigned byte;
sbyte: 8-bit signed byte;
short: 16-bit signed short;
ushort: 16-bit unsigned short;
char8: 8-bit unsigned char;
char/char16: 16-bit unsigned char.

char is not strictly equivalent to ushort, as they will have slightly
different semantics.

[Kaz Kylheku]

On 2012-04-30, BartC <b...@freeuk.com> wrote:
> "Rui Maciel" <rui.m...@gmail.com> wrote in message
> news:jnmt3p$jro$1...@speranza.aioe.org...
>> BartC wrote:
>>
>>> 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.
>
> OK, let's start with something obvious: C's type-declaration syntax. I find
> its inside-out convoluted form completely impossible.

The problem with any major changes to C's type declaration syntax is that
they break "declaration follows use".

A declarator like (*p[3])(double) gives us a p which can actually be used by
means of the syntax (*p[0])(3.0).

If you change how it is declared, but don't make a parallel change to the
expression syntax then you still have (*p[0])(3.0) /and/ the new syntax which
is inconsistent with this.

[James Kuyper]

On 04/30/2012 07:28 PM, Keith Thompson wrote:
> James Kuyper <james...@verizon.net> writes:
> [...]
>> 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.
> [...]
>
> Out of curiosity, how to you verify that your code would still work if
> these were different types? Do you have a test configuration with
> modified versions of the libraries?

I can't easily test conformance of my code to it's portability
requirements. We used to have several different platforms I could test
on, now all of our machines are made by the same manufacturer and run
the exact same version of the same operating system. The only variation
is that some of them are 32-bit and some are 64-bit, so I can at least
test that aspect of portability. Having a only a small number of
different machine set-ups simplifies system administration - an
important issue when a couple of system administrators are taking care
of nearly a thousand computers, but it makes portability testing harder.
I rely upon my own knowledge of what needs to be done to ensure
portability, and hope that I've done it right. The only place our code
really needs to run is on those thousand or so computers; that it must
be available to the general scientific community, and therefore highly
portable, is a requirement of our contract, but is substantially less
important.

In principle, if anyone has trouble installing or running my software on
a system different from the ones I've tested the code on, they should
complain to me. If they do, I'd be happy to investigate and try to solve
the problem, but if the issue ever comes up, I'll have to ask them to
give me access to their system to do my debugging.

We're allowed to assume POSIX conformance, and so far the only such
complaint I've received was from someone trying to port our code to a
non-POSIX environment. I was rather annoyed that I couldn't help him;
the linker he was using was failing to link in the right libraries, and
I didn't know enough about that platform to help him figure out why. He
knew more about how his linker worked than I did, and he couldn't figure
it out. I might have been able to figure it out with direct access to
his system, but his IT security people wouldn't allow it.
--
James Kuyper

[BGB]

to be fair though, something like:
void (*fooptr)(double x);

is usually called using something like:
fooptr(3.0);


and so some change to the function pointer syntax could still be
justifiable, say if people would instead have to write:
typedef void fooptr_t(double x);
fooptr_t *fooptr;

or, OTOH, use some sort of funky QuakeC-style syntax:
void(double x) *fooptr;


this later option would change a declaration from something like:
void (*foo())(int x)
{ ... }
into something like:
void(int x) *foo()
{ ... }


or such...

[BGB]

a person could write a spec for a "new language" nearly identical to C,
but absent things like trigraphs and K&R style declarations.


oddly, my C parser already does this.
it supports "most of the language" but omits "parts I don't actually
tend to see used".


granted, I got into arguments with people before as to what dropping K&R
syntax would mean for functions like:
void foo();
which in my case I had simply treated as equivalent to:
void foo(void);

where a person is far more likely to see a "()" function not expecting
any arguments, than they are to see something like:

foo(x, y) int x, y;
{ ... }

which will not actually parse in my case.


but, this was a long and pointless argument...


hmm, partial C subset, could be called "C-Axe", because it "cuts off
some rarely-used features".

[Ian Collins]

On 05/ 1/12 11:24 AM, BartC wrote:
>
>
> "Rui Maciel"<rui.m...@gmail.com> wrote in message
> news:jnmt3p$jro$1...@speranza.aioe.org...
>> BartC wrote:
>>
>>> 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.
>
> OK, let's start with something obvious: C's type-declaration syntax. I find
> its inside-out convoluted form completely impossible.
>
> I've often had to resort to CDECL to sort out complex declarations. There
> must be something seriously wrong in a language if I have to use external
> tools to help understand it! And every time I've discussed this in this
> group, I get step-by-step lessons on how to decode, or construct, such a
> declaration! Nothing about fixing the language.

More often than not there's something wrong with the programmer who
conjurers up such a convoluted declaration! Seriously, 99.9% of the
time complex type declarations are unnecessary.

One simplification that would help not break (much!) code would be to
adopt C++'s reuse of "auto". It would be very handy for those cases
where the compiler knows the type an expression and the programmer
doesn't really care. I have my own C++ Auto object type I use with my
JSON library and I've found it extremely useful in such cases.

--
Ian Collins

[BGB]

yeah, auto would be nice...


placing restrictions on declaration keyword orderings is also possible
and not likely to break all that much code (probably 95% would still
work), and could allow faster parsers (as well as allow eliminating
context dependency), such as by allowing switching to a C#-style parsing
strategy.

there are drawbacks though, namely that not all code or headers would
parse correctly, meaning it would likely involve a compiler option or
similar to enable it.

[Ian Collins]

Unlike incorporating C++'s "auto" which could be seamless.

--
Ian Collins

[BGB]

I also use mostly C, rather than C++, albeit I have my own reasons.
earlier on, I think it was because G++ was often either broken or buggy
(or, sometimes, missing altogether), so I didn't really trust it.


the most notable issue at present being that writing a C++ parser for my
tools to use looks like a huge PITA, so thus far I haven't really seen
it as a justified effort (more so for sake of features which are,
technically, mostly just syntax sugar anyways).

if I can write "slightly less clean" and do similar in C, it isn't
really a worthwhile tradeoff to use C++.


but, in any case, my language efforts aren't really intended to
"replace" C, as personally I see it as a fairly solid language for what
it does.


so, alas...

[Ian Collins]

On 04/30/12 04: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?

In addition to my other post concerning C++'s auto, there are a number
of other additions to C++11 that would benefit in C without breaking
existing code, some examples

Scoped and strongly typed enums[1], embedded compilers often enable the
type of an enum to be selected, so may as well standardise.

Constant expressions[2] would extend the usefulness of const.

Alignment[3] another extension that may well be of more use in C (giving
its dominance in drivers and embedded).

Narrowing prevention[4]

[1] http://www2.research.att.com/~bs/C++0xFAQ.html#enum
[2] http://www2.research.att.com/~bs/C++0xFAQ.html#constexpr
[3] http://www2.research.att.com/~bs/C++0xFAQ.html#align
[4] http://www2.research.att.com/~bs/C++0xFAQ.html#narrowing
--
Ian Collins

[BGB]

pretty much, but they do different things.


auto allows simpler-looking declarations.

alternate declaration parsing allows for a potentially somewhat faster
parser and compiler (combined with other tricks). I am not promoting
here making "obvious syntax changes", rather using a different parsing
strategy (with the restrictions being mostly a side cost).

like, wouldn't it be nice if, say, a person could compile about 100 kloc
of code in, say, 250ms or 500ms or so?... (vs maybe 10-20 seconds, most
due to endlessly re-parsing things like "windows.h" and similar...).

granted, it may be all a bit domain-specific, hence probably why it
would be a command-line option to enable it.


so, either way...

[Ian Collins]

On 05/ 1/12 05:25 PM, BGB wrote:
>
> I also use mostly C, rather than C++, albeit I have my own reasons.
> earlier on, I think it was because G++ was often either broken or buggy
> (or, sometimes, missing altogether), so I didn't really trust it.
>
>
> the most notable issue at present being that writing a C++ parser for my
> tools to use looks like a huge PITA, so thus far I haven't really seen
> it as a justified effort (more so for sake of features which are,
> technically, mostly just syntax sugar anyways).

Full C++ is extremely complex to parse, but the C with classes subset
shouldn't present too many problems (see cfront) and provides a
worthwhile superset of C.

--
Ian Collins

[Keith Thompson]

BGB <cr8...@hotmail.com> writes:
[...]

>> "Rui Maciel" <rui.m...@gmail.com> wrote in message

>> news:jnjpil$ek2$1...@speranza.aioe.org...

>>> 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?

[...]
> 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
[...]

If we're trying to come up with something better than #include, I'd
rather create a new mechanism that isn't part of the preprocess, and
doesn't look like it is (#pragma).

For example, this:

#include <stdio.h>

could be replaced by:

import stdio;

This would make all the declarations in the stdio "module" visible; it
would be up to the implementation to determine how to do that. There's
no implication that "import" performs a textual replacement.

There's plenty of precedent for this kind of thing in other languages.

I don't expect (or, probably, even advocate) that a future C standard
will have such a feature, but it's probably part of my own hypothetical
never-to-be-fully-defined C-like language.

[gwowen]

On Apr 30, 9:19 pm, jacob navia <ja...@spamsink.net> wrote:
> Le 30/04/12 20:25, lawrence.jo...@siemens.com a écrit :
>
> > Rui Maciel<rui.mac...@gmail.com>  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?
>

> > That the person assigning the task get their head examined.  :-)
>
> C is perfect?

Wow. That's quite the non-sequitur.

[Malcolm McLean]

בתאריך יום שני, 30 באפריל 2012 17:09:07 UTC+1, מאת 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.
>
It doesn't really matter what you call a 3d point. Even a novice programmer, provided he was sane, could come up with a perfectly good typedef or convention, which could be used worldwide with no harm.
In this case, it is a problem of designated authority.

[Jens Gustedt]

Am 05/01/2012 07:43 AM, schrieb Ian Collins:
> In addition to my other post concerning C++'s auto,

a nice feature, but reusing an existing keyword is a no-go, it is
simple as this

> there are a number
> of other additions to C++11 that would benefit in C without breaking
> existing code, some examples
>
> Scoped and strongly typed enums[1], embedded compilers often enable the
> type of an enum to be selected, so may as well standardise.

yes!

> Constant expressions[2] would extend the usefulness of const.

there would be a less intrusive modification to C that could achieve
similar goal: register const declarations. Just

- make it constraint violations not to initialize them
- allow them at places where compile time constant expressions are
allowed
- allow them in global scope

> Alignment[3] another extension that may well be of more use in C (giving
> its dominance in drivers and embedded).

this one already made it into C11

Jens

[BGB]

it depends some.

in this case, probably the #include would look at it and be all like
"hey, that is a precompiled header" and just spit out an "import" to be
passed handled by a later stage, and would otherwise just do as before,
and inline all the text.

> For example, this:
>
> #include<stdio.h>
>
> could be replaced by:
>
> import stdio;
>
> This would make all the declarations in the stdio "module" visible; it
> would be up to the implementation to determine how to do that. There's
> no implication that "import" performs a textual replacement.
>
> There's plenty of precedent for this kind of thing in other languages.
>
> I don't expect (or, probably, even advocate) that a future C standard
> will have such a feature, but it's probably part of my own hypothetical
> never-to-be-fully-defined C-like language.
>

as mentioned elsewhere, the main advantage of hacking #include is that
it remains compatible with compilers which don't support the feature
(which will instead just include all its contents as before), whereas
something entirely new will not be compatible with preexisting compilers.


so, it is more like:
feature with other compilers works as before;
feature with compilers which support it may result in a significant speedup.

this is a policy I follow with many of my language extensions, which
despite being extensions remain more-or-less compatible or no-op
features for compilers which don't support them.

granted, this is also partly because I compile most of my native code
with MSVC (or GCC on Linux), and so prefer to generally avoid
incompatibility.

to some extent my tools work as "co-compilers", generally processing
code and compiling/generating things alongside the main compiler (rather
than taking over its role).

[Ian Collins]

On 05/ 1/12 07:39 PM, Jens Gustedt wrote:
> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>> In addition to my other post concerning C++'s auto,
>
> a nice feature, but reusing an existing keyword is a no-go, it is
> simple as this

See the last couple of paragraphs of this section:

http://www2.research.att.com/~bs/C++0xFAQ.html#auto

>> Constant expressions[2] would extend the usefulness of const.
>
> there would be a less intrusive modification to C that could achieve
> similar goal: register const declarations. Just
>
> - make it constraint violations not to initialize them
> - allow them at places where compile time constant expressions are
> allowed
> - allow them in global scope

That's pretty much the "old" C++ usage of const, still a big improvement
over C.

>> Alignment[3] another extension that may well be of more use in C (giving
>> its dominance in drivers and embedded).
>
> this one already made it into C11

Ah good, I missed that!

--
Ian Collins

[Jens Gustedt]

Am 05/01/2012 10:21 AM, schrieb Ian Collins:
> On 05/ 1/12 07:39 PM, Jens Gustedt wrote:
>> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>>> In addition to my other post concerning C++'s auto,
>>
>> a nice feature, but reusing an existing keyword is a no-go, it is
>> simple as this
>
> See the last couple of paragraphs of this section:
>
> http://www2.research.att.com/~bs/C++0xFAQ.html#auto

yes, I know all of that

first, I think that this will not easily convince the C committee

second, this is all useless complication, why the hell they didn't
invent another keyword, something like C usually does "_Auto" if it
must or even more descriptive "_Autotype"?

third, I am probably a rare animal, but I occasionally use that in
macros for which I want to be sure that they end up in function scope

>>> Constant expressions[2] would extend the usefulness of const.
>>
>> there would be a less intrusive modification to C that could achieve
>> similar goal: register const declarations. Just
>>
>> - make it constraint violations not to initialize them
>> - allow them at places where compile time constant expressions are
>> allowed
>> - allow them in global scope
>
> That's pretty much the "old" C++ usage of const,

not quite, such an "rvalue" wouldn't have an address

I am also not sure if it would be the same for composite types. C++'s
rules for initializing global const qualified variables always scared
me. Wasn't it that you only could initialize integer constants at the
point of declaration, and other types (even floating point) hat to be
initialized/constructed at the point of definition/instantiation.

> still a big improvement
> over C.

Jens

[Ian Collins]

On 05/ 1/12 08:39 PM, Jens Gustedt wrote:
> Am 05/01/2012 10:21 AM, schrieb Ian Collins:
>> On 05/ 1/12 07:39 PM, Jens Gustedt wrote:
>>> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>>>> In addition to my other post concerning C++'s auto,
>>>
>>> a nice feature, but reusing an existing keyword is a no-go, it is
>>> simple as this
>>
>> See the last couple of paragraphs of this section:
>>
>> http://www2.research.att.com/~bs/C++0xFAQ.html#auto
>
> yes, I know all of that
>
> first, I think that this will not easily convince the C committee
>
> second, this is all useless complication, why the hell they didn't
> invent another keyword, something like C usually does "_Auto" if it
> must or even more descriptive "_Autotype"?

Maybe the C++ committee has a more echo-friendly recycling policy! They
definitely have better aesthetic sense.

> third, I am probably a rare animal, but I occasionally use that in
> macros for which I want to be sure that they end up in function scope

I've never come across that use auto before. Care to enlighten me?

>>>> Constant expressions[2] would extend the usefulness of const.
>>>
>>> there would be a less intrusive modification to C that could achieve
>>> similar goal: register const declarations. Just
>>>
>>> - make it constraint violations not to initialize them
>>> - allow them at places where compile time constant expressions are
>>> allowed
>>> - allow them in global scope
>>
>> That's pretty much the "old" C++ usage of const,
>
> not quite, such an "rvalue" wouldn't have an address

Hence "pretty much"!

> I am also not sure if it would be the same for composite types. C++'s
> rules for initializing global const qualified variables always scared
> me. Wasn't it that you only could initialize integer constants at the
> point of declaration, and other types (even floating point) hat to be
> initialized/constructed at the point of definition/instantiation.

I think you are confusing regular constants with const static members of
classes.

--
Ian Collins

[Rui Maciel]

Ben Pfaff wrote:

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

That didn't dissuade sompe people from investing their time designing what
they defined as "a better C", and a number of them managed quite well to
succeed in developing good programming languages.


Rui Maciel

[Rui Maciel]

Ben Pfaff wrote:

> Jacob, I'm criticizing the hypothetical assignment given by Rui,
> not anything you wrote.

It was intended to get opinions from C programmers on how the C programming
language could be improved. Why should that be a target for criticism?


Rui Maciel

[Rui Maciel]

Keith Thompson wrote:

> But not persuasively, IMHO.
>
> C is at a lower semantic level than a lot of other languages.
> But the major difference between C and assembly language is that
> an assembly program specifies CPU instructions, while a C program
> specifies run-time behavior.
>

> That's a huge distinction, with assembly languages on one side,

> and C, C++, Ada, Python, APL, and Intercal firmly on the other.

That's true. Nonetheless, there are languages out there who are referred to
as high level assembly languages which also employ some abstractions that,
at least in some aspects, don't make their abstraction level much lower than
C's.

Another issue we might consider is that if we were given the task of
designing an assembly language which should be able to generate code for
multiple architectures, I suspect we would end up with a language which, in
terms of features, wouldn't be much different than C's core language.


Rui Maciel

[Rui Maciel]

lawrenc...@siemens.com wrote:

> Rui Maciel <rui.m...@gmail.com> 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?
>

> That the person assigning the task get their head examined. :-)

Why? Do you believe that the C programming language can't be improved,
particularly when there isn't a need to preserve backward compatibility?


Rui Maciel

[Rui Maciel]

BGB wrote:

>> 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.
>
> this is more of an OS or tools issue than a language issue though.

Quite true.

I suspect that the way the C programming language handles "packages" can't
be made any simpler than it already is. The library headers are stored
somewhere (anywhere) in the file system, and so are the object files, if
there are any. Then, to be able to build our software with them, we only
need to configure the compiler to search for those header and object files
where we left them.

I suspect that this is only an issue when automatic build systems make this
to be harder than it is, and needs to be.


Rui Maciel

[Keith Thompson]

Rui Maciel <rui.m...@gmail.com> writes:
[...]

> Another issue we might consider is that if we were given the task of
> designing an assembly language which should be able to generate code for
> multiple architectures, I suspect we would end up with a language which, in
> terms of features, wouldn't be much different than C's core language.

And it wouldn't be an assembly language.

[Rui Maciel]

Leo Havmøller wrote:

> http://xkcd.com/927/
>
> Leo Havmøller.

If that was true, and it wasn't in fact possible to get any improvement in
any project intended to fix the shortcomings of a previous one, then
nowadays no programming language would be better than the very first
incantation of Fortran.


Rui Maciel

[BartC]

"Kaz Kylheku" <k...@kylheku.com> wrote in message
news:201204301...@kylheku.com...

> On 2012-04-30, BartC <b...@freeuk.com> wrote:
>> "Rui Maciel" <rui.m...@gmail.com> wrote in message
>> news:jnmt3p$jro$1...@speranza.aioe.org...
>>> BartC wrote:
>>>
>>>> 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.
>>
>> OK, let's start with something obvious: C's type-declaration syntax. I
>> find
>> its inside-out convoluted form completely impossible.
>

> The problem with any major changes to C's type declaration syntax is that
> they break "declaration follows use".

So what? That was a crazy idea that never really worked.

A lot of people *do* have trouble with C's type-declarations; they *do* need
to employ an algorithm to understand a complex one; many have to resort to
layers of typedefs to make them simpler to read and write; and some decided
to write the Cdecl utility to help read and write them! To me, that
suggests that there is an issue.

And declaration-follows-use breaks down in many cases; inside casts for
example, where the absence of a name from the type-spec makes it even harder
to know where to start; you just end up with a mess of parentheses and
asterisks.

How does it work here:

int a; a

It seems that any type-spec is broken down into two parts: the resultant
type (eg. 'int') and anything else (ie. mix of pointer, array, function
signtature). It is this 'anything else' that needs to be literally wrapped
around individual names, resulting in this confusing syntax:

int* a, b, c;

Where you do want all names with the same type, you have to duplicate the
type-spec:

int *a[10], *b[10], *c[10];

or start creating typedefs. (BTW declaration-follows-use also breaks down
when you try and write *a[10]...)

> A declarator like (*p[3])(double) gives us a p which can actually be used
> by
> means of the syntax (*p[0])(3.0).

(Your example gives an error in Cdecl unless something like 'int' is added
in front. See, I didn't even know that from looking!)

> If you change how it is declared, but don't make a parallel change to the
> expression syntax then you still have (*p[0])(3.0) /and/ the new syntax
> which
> is inconsistent with this.

Part of the problem is that C's dereference syntax is also back-to-front:
*p[0] instead of p[0]*.

But, if you have to design a new language that was fully-typed like C, would
you still use this type syntax or not?

(I would write your example, in another language, as follows (where 'real'
means double, and ^ means dereference):

[3]ref function(real)int p

p[1]^(3.0)

This was written directly using Cdecl's output as a guide: "declare p as
array 3 of pointer to function (double) returning int". The only difference
is I put "p" at the end rather than at the start.)

--
Bartc

[BartC]

"Ian Collins" <ian-...@hotmail.com> wrote in message
news:a098ic...@mid.individual.net...

> On 05/ 1/12 11:24 AM, BartC wrote:

>> I've often had to resort to CDECL to sort out complex declarations.

> More often than not there's something wrong with the programmer who
> conjurers up such a convoluted declaration! Seriously, 99.9% of the time
> complex type declarations are unnecessary.

But when it is, it tends to be crucial.

> One simplification that would help not break (much!) code would be to
> adopt C++'s reuse of "auto".

C++ is so complicated, that it's probably necessary. (In fact, when you
spend even a short time looking at C++ and at *its* quirks, you start to
think that perhaps there's nothing much wrong with C after all!)

--
Bartc

[Rui Maciel]

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?

Here are a couple of suggestions:

- namespaces
They aren't necessarily required to write software, but they are handy and,
depending on how they are implemented, they may be able to solve a
considerable number of problems. Let's consider a namespace implementation
which provides a way for a programmer to specify a prefix to be used
implicitly in declarations and definitions, and that lets programmers
specify a set of identifier prefixes that are taken into accoun when parsing
identifiers. For example, consider the following declaration:

<code>
namespace foo
{
int bar(void);
}
</code>

That would be equivalent to the following declaration:
<code>
int foo_bar(void);
</code>


then, with this declaration, the following code would be valid:
<code>
int main(void)
{
using namespace foo;
bar(void);

return 0;
}
</code>

...which would be equivalent to:
<code>
int main(void)
{
foo_bar(void);

return 0;
}
</code>

Any ambiguity regarding the use of specific namespace prefixes would be
signaled as a compiler error. So, for example, the following code would
fail to compile:
<code>
namespace foo
{
int bar(void)
{
return some_constant;
}
}

namespace baz
{
int bar(void)
{
return some_other_constant;
}
}

int main(void)
{
using namespace foo, baz;
foo_bar(void); // good
baz_bar(void); // also good
bar(void); // compiler error: ambiguous identifier

return 0;
}
</code>

This, inadvertently, would provide a way to add polymorphism to C, in a way
which I believe is better than C11's generic. For example:

<code>
namespace foo
{
namespace int
{
bar(int); // this would define foo_int_bar(int)
}
namespace float
{
bar(float); // this would define foo_float_bar(float)
}

// The following would automatically include nested namespaces
using namespace int, float;
}

int main(void)
{
using namespace foo; // this includes foo_int and foo_float
bar(1); // calls foo_int_bar(int)
bar(1.0f); // calls foo_float_bar(float)
return 0;
}
</code>

Although the keyword "namespace" has been used in this example, any other
keyword would do. Maybe it would be better to use some other keyword such
as "prefix", to avoid any compatibility problem with C++'s namespaces.


- include the standard library in a dedicated namespace.
There are some issues affecting C's standard library, and yet there is no
way to fix them without breaking backward compatibility. One way to avoid
that mistake would be to include each version of the standard library in a
dedicated namespace that would explicitly reflect the standard version. For
example:

<code>
#include <stdio.h>
/* with C11, this could include c89/stdio.h, c99/stdio.h and c11/stdio.h,
each one reflecting the standard library as defined by each standard. Each
header would, in turn, enclose every definition in a dedicated namespace,
similar to:

namespace std
{
namespace c89
{
// ...
}
namespace c99
{
// ...
}
namespace c11
{
// ...
}
}
*/

int main(void)
{
using namespace std; // in a C11 implementation this would
actually include namespace std and std_c11

char *buffer;
// some stuff happens
gets(buffer); // oops, compiler error. There is no such
thing as a gets() in C11's standard library.
std_c99_gets(buffer); // but this function would be defined
c99_gets(buffer); // this would also be ok

return 0;
}
</code>



Rui Maciel

[Rui Maciel]

Keith Thompson wrote:

> And it wouldn't be an assembly language.

Discussing whether such a language could be considered an high level
assembly language or not would essentially be the same as discussing whether
a particular shade of grey could be considered light or dark grey.


Rui Maciel

[James Kuyper]

On 05/01/2012 03:17 AM, Keith Thompson wrote:
...
> If we're trying to come up with something better than #include, I'd
> rather create a new mechanism that isn't part of the preprocess, and
> doesn't look like it is (#pragma).
>
> For example, this:
>
> #include <stdio.h>
>
> could be replaced by:
>
> import stdio;
>
> This would make all the declarations in the stdio "module" visible; it
> would be up to the implementation to determine how to do that. There's
> no implication that "import" performs a textual replacement.

That makes sense in a new language where preprocessing doesn't exist, or
at least is not needed to implement the standard library modules.
Otherwise, it's rather problematic.
--
James Kuyper

[James Kuyper]

On 05/01/2012 03:39 AM, Jens Gustedt wrote:
> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>> In addition to my other post concerning C++'s auto,
>
> a nice feature, but reusing an existing keyword is a no-go, it is
> simple as this

No, it is not that simple. Backwards compatibility is an important goal,
but it's only one of the goals the committee needs to take into
consideration. While auto technically is a C keyword, it is never
needed, and therefore is almost never used; as a practical matter the
only sense in which it is a keyword is that it's not available for use
as a user-defined identifier. As a result, there's essentially no
backwards compatibility issue. What little code there is that currently
does use 'auto' would mostly become easily identified syntax errors
under the proposed new meaning.
--
James Kuyper

[James Kuyper]

On 05/01/2012 04:47 AM, Ian Collins wrote:
> On 05/ 1/12 08:39 PM, Jens Gustedt wrote:
>> Am 05/01/2012 10:21 AM, schrieb Ian Collins:
>>> On 05/ 1/12 07:39 PM, Jens Gustedt wrote:
>>>> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>>>>> In addition to my other post concerning C++'s auto,

...

>> third, I am probably a rare animal, but I occasionally use that in
>> macros for which I want to be sure that they end up in function scope
>
> I've never come across that use auto before. Care to enlighten me?

"function scope" is the wrong phrase; statement labels are the only kind
of identifier which can have function scope (6.2.1p3). What he means is
called "block scope" (6.2.1p4).

What he's referring to is the fact that the auto keyword is not
meaningful, and is therefore disallowed, in external declarations (6.9p2).
--
James Kuyper

[James Kuyper]

On 05/01/2012 04:39 AM, Jens Gustedt wrote:
> Am 05/01/2012 10:21 AM, schrieb Ian Collins:
>> On 05/ 1/12 07:39 PM, Jens Gustedt wrote:
>>> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>>>> In addition to my other post concerning C++'s auto,
>>>
>>> a nice feature, but reusing an existing keyword is a no-go, it is
>>> simple as this
>>
>> See the last couple of paragraphs of this section:
>>
>> http://www2.research.att.com/~bs/C++0xFAQ.html#auto
>
> yes, I know all of that
>
> first, I think that this will not easily convince the C committee
>
> second, this is all useless complication, why the hell they didn't
> invent another keyword, something like C usually does "_Auto" if it
> must or even more descriptive "_Autotype"?

The purpose of using such reserved names is to avoid breaking existing
code. Since auto is already a keyword, it's not in use as a user-defined
identifier. Since it's current meaning is pointless, it's also almost
completely unused as a keyword, too. Therefore, auto and _Auto would
both be just about equally effective in avoiding breaking existing code.
It changes something that's currently an embarrassment for C, into a
useful keyword. Also, there's a policy governing both the C and C++
committees, to avoid gratuitous differences between the languages;
adopting the same new meaning for auto that C++ has adopted would remove
such a difference.

> third, I am probably a rare animal, but I occasionally use that in
> macros for which I want to be sure that they end up in function scope

I agree - that's a rare usage. It's not a sufficiently compelling use
case to justify resisting such a change.
--
James Kuyper

[Jens Gustedt]

Am 05/01/2012 10:47 AM, schrieb Ian Collins:
> On 05/ 1/12 08:39 PM, Jens Gustedt wrote:
>> Am 05/01/2012 10:21 AM, schrieb Ian Collins:
>>> On 05/ 1/12 07:39 PM, Jens Gustedt wrote:
>>>> Am 05/01/2012 07:43 AM, schrieb Ian Collins:
>>>>> In addition to my other post concerning C++'s auto,
>>>>
>>>> a nice feature, but reusing an existing keyword is a no-go, it is
>>>> simple as this
>>>
>>> See the last couple of paragraphs of this section:
>>>
>>> http://www2.research.att.com/~bs/C++0xFAQ.html#auto
>>
>> yes, I know all of that
>>
>> first, I think that this will not easily convince the C committee
>>
>> second, this is all useless complication, why the hell they didn't
>> invent another keyword, something like C usually does "_Auto" if it
>> must or even more descriptive "_Autotype"?
>
> Maybe the C++ committee has a more echo-friendly recycling policy! They
> definitely have better aesthetic sense.

Admittedly the _Bool things etc are ugly. But there is a good reason
for it and usually they come with a #define in a standard header file
(such as "bool") that makes it easy to hide them behind something that
is more eye-friendly.

>> third, I am probably a rare animal, but I occasionally use that in
>> macros for which I want to be sure that they end up in function scope
>
> I've never come across that use auto before. Care to enlighten me?

there are cases where I declare variables inside a macro and where it
must be guaranteed that such a macro doesn't end up being used in
file scope. I then just make the fact that it is an automatic
variable explicit by prefixing it with 'auto'.

>> I am also not sure if it would be the same for composite types. C++'s
>> rules for initializing global const qualified variables always scared
>> me. Wasn't it that you only could initialize integer constants at the
>> point of declaration, and other types (even floating point) hat to be
>> initialized/constructed at the point of definition/instantiation.
>
> I think you are confusing regular constants with const static members of
> classes.

perhaps, these complicated rules for C++ always confused me.

Suppose I'd have the following in a header file

struct toto { unsigned a; };
struct toto const totoZero = { 0 };

Would this result in multiple symbol errors when included in C++ or
not? In C it definitively would.

The way around in C is with defines

#define totoZeroInit { 0 }
#define totoZero (struct toto const)totoZeroInit

or even

#define totoZero (struct toto const)((struct toto const)totoZeroInit)

to have an rvalue. Still you'd have to be sure where to use
totoZeroInit and totoZero.

In what I proposed this would be

register struct toto const totoZero = { 0 };

and this then could be allowed in any context where a "value" of type
struct toto is required.

Jens

[Rui Maciel]

Keith Thompson wrote:

> If we're trying to come up with something better than #include, I'd
> rather create a new mechanism that isn't part of the preprocess, and
> doesn't look like it is (#pragma).
>
> For example, this:
>
> #include <stdio.h>
>
> could be replaced by:
>
> import stdio;
>
> This would make all the declarations in the stdio "module" visible; it
> would be up to the implementation to determine how to do that. There's
> no implication that "import" performs a textual replacement.
>
> There's plenty of precedent for this kind of thing in other languages.
>
> I don't expect (or, probably, even advocate) that a future C standard
> will have such a feature, but it's probably part of my own hypothetical
> never-to-be-fully-defined C-like language.

That would be nice. Other programming languages, such as Google's Go,
appear to support a package system which looks a bit like that.

http://golang.org/ref/spec#Package_clause


Rui Maciel

[Rui Maciel]

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.
>

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

Why is it necessary to force everyone to use a specific data structure in
their 3D libraries? It might be convenient in some cases, but convenience
isn't the same as a necessity.


Rui Maciel

[tom st denis]

I dunno, there are expressions and statements in C that are not
handled by any opcode from any CPU I know of.

Tom

[Rui Maciel]

tom st denis wrote:

> I dunno, there are expressions and statements in C that are not
> handled by any opcode from any CPU I know of.

The same applies to high level assembly, or assembly code which also
includes macros.


Rui Maciel

[tom st denis]

The joke [in this context] is a lot of people have claimed to
"improve" C but yet C persists despite them. Sure it's evolved in its
own right over the years but for the most part a program written 30
years ago in portable C is likely to both compile and function
correctly today.

The XKCD joke overall though is that often you'd have many competing
semi-compatible standards for the same thing. Shawn Hargreaves
(author of the Allegro game lib) apparently said this about the VESA/
VBE standards of the 90s. Many vendors implemented "VESA BIOS" but
they weren't necessarily all compatible. Nowadays you see this
manifest in how HTML is pushed. Each vendor has their own inventions
they bring up, some end up in W3 others are just added despite the
process.

[BGB]

On 4/30/2012 11:23 PM, Ian Collins wrote:
> On 05/ 1/12 05:25 PM, BGB wrote:
>>
>> I also use mostly C, rather than C++, albeit I have my own reasons.
>> earlier on, I think it was because G++ was often either broken or buggy
>> (or, sometimes, missing altogether), so I didn't really trust it.
>>
>>
>> the most notable issue at present being that writing a C++ parser for my
>> tools to use looks like a huge PITA, so thus far I haven't really seen
>> it as a justified effort (more so for sake of features which are,
>> technically, mostly just syntax sugar anyways).
>
> Full C++ is extremely complex to parse, but the C with classes subset
> shouldn't present too many problems (see cfront) and provides a
> worthwhile superset of C.
>

yes, but there is the issue that if "__cplusplus" is defined, a bunch of
C++ related stuff starts piling in from system headers.

this could still be looked into though.

[tom st denis]

Which high level assembler are you using? Things like NASM/YASM/GAS/
etc may have macros but the underlining statements are still opcode
mnemonics.

C can do things like

foo[somefunc(value1,value2)].something[blah?4:1] ^= 19;

Try writing that as a single statement in your "high level assembler."

Tom

[BGB]

the problem is that "level of abstraction" is a fairly subjective
measure in general.

a better way of classifying it is not whether it is higher or lower
level, but whether it maps directly to CPU instructions (ASM), or
whether it maps to operations on typed values (languages like C, Java, ...).

at which point there is no longer a fairly direct mapping between
source-code and CPU instructions (either directly via opcodes, or
indirectly via macros or similar), it is no longer ASM.

granted, ASM can also be considered relative to the target, for example,
ASM for JVM bytecode is still an assembler, despite not being for the
underlying HW but rather for a VM running on said HW.


there is also a considerable level of complexity involved in the
conversion between C and ASM (type handling, register allocation, ...),
that typically doesn't exist in a macro-assembler.

...