Language to replace C

[Michael Nahas]

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I am a long time C programmer (I read the old testament in 1987) and
I've tried to keep the spirit of C and make as few changes as possible.
I was mostly driven by the bloat of C++ and, now, C99. I was also
driven by the gcc extensions, which provide needed features that aren't
present in ANSI C.
(http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html)
The things people will most hate are:
1) new keywords (fun, var)
2) changed type declarations
3) changed variable and function declarations
3) @ as the array operator, instead of []

The things people will most love are
1) multiple return values made easy
2) function pointers easier to declare and read
3) exact specifications of types
4) no forward declarations
This language doesn't add any power over C because it is designed to be
able to link to C files. It is just trying to do what C does with a
better type system and a better syntax for some things.

I know I am going to get flamed for this. I'd appreciate it if replies
contained constructive comments ("I'd rather have seen ...") rather than
destructive comments ("What you have sucks!"). Second, make sure to
mention what you like about it (if there is anything) rather than only
things that you hate. Lastly, if you think it violates the spirit of C
(a valid complaint in my mind), then try to state as clearly as you can
the principle that C embodies and then an example of how my language
violates it. E.g., "C uses minimal keywords. Your language has two new
keywords, 'fun' and 'var', all over the place."

As a final note, I have not written a replacement for the C
pre-processor yet. It's affect on C is much stronger than many people
believe. I have a few ideas floating around, but nothing solid yet.
Some involve using the [] symbols, which I would like to use for
polymorphic types, similar to C++'s templates. (Which use < and >, the
ugliest thing in C++.)

Let the flames begin...
Mike


For Torben:
I agree with most of your suggestions, but I didn't think that this
was the language for all of them. I wanted a language that was
linkable with C and didn't require anything else. I basically
wanted C with a clearer type system and a nicer interface to a few
features. Thunks, overloading, and polymorphism didn't fit.
(Although, polymorphism may come through type macros.) After I
finish the design of this language and write a compiler, I'm going
to look at designing a higher-level language. I've come to like
OCaml, but dislike a few hickups (naming especially) and it's
syntax. I think there could be a market for a type-safe language
that could easily link to C and use a conservative garbage
collector.

Mike

Subject: Re: a language to write an OS with ???
From: to*****@diku.dk (Torben Ægidius Mogensen)
Newsgroups: comp.lang.misc

Antti Sykäri <js*****@gamma.hut.fi> writes:

Nowadays it's all too common for language designers to design high
level, garbage-collected, object-oriented, bigger-is-better like
languages (witness C++ since addition of multiple inheritance and
exception specifications, Java, C#, and now D). To strive for an
efficient, clean, and "light-weight" language -- a language that would
be just appropriate to create a modern operating system in -- doesn't
seem to be very fashionable.
I wouldn't say that there is less interest in designing such
languages, I would rater say that the "market" for such languages is
more entrenched than for higher-level languages, especially scripting
languages. One reason may be that an OS is a major undertaking and
likely to be in use for a long time. So OS writers want a language
that they know will be around for a long while and which will be
ported to a large range of platforms (allowing their OS to do the
same).
My own hobby language is about creating a better C/C++, with cleaner
syntax, more extensibility, more transparency, better metaprogramming
facilities and ultimately, the ability to go as close to the hardware
as possible when needed. (Yes, it's likely to be a long road.)

In essence, it's about taking C and evolving it in the same direction
as C++ did, emphasizing the "what you don't use, you don't pay for"
rule and paying less attention to backwards compatibility.

In designing a C replacement, I wouldn't start from C. Even without
the C++ additions etc., C is a horrible language, with highly
complicated and somewhat ambiguous syntax, underspecified semantics
and lacking in features necessary for OS writing (such as jumping
through a pointer).

What I would do was (among other things):

- Have well-defined syntax and semantics.

- Ensure that the sizes of all types are specified by the language,
so it would, e.g., be explicit if an integer or pointer is 32 or 64
bits long. Memory layout would also be explicit, so big-endian or
little-endian numbers and strings would have explicitly different
types (and both would be present).

- Make it explicit in the type of a pointer if it can be null.

- Make it explicit in the type of a value if it can be modified after
creation and initialization. Integrate creation and
initialization.

- Allow pointer-arithmetic only on pointers to arrays. Doing it on
other pointers should give type errors. You can have fields
offsets and such, and they can even be negative (a record/struct
pointer type can specify to which field the pointer points). Allow
all/several components of a record to be accessed at once, using a
kind of pattern-matching.

- Have no implicit casts, even between integer sizes.

- Have parametric polymorphism, implemented by
replication/specialization.

- Overloading via (Haskell-style) type classes, not by ad-hoc
overloading or OO-style virtual methods.

- Have type-safe closures/thunks.

- Allow programmer to specify pointer to address at which a record,
array or other structure is built. Issue compile-time warning if
the type of the pointer does not ensure sufficient space.

- Allow compile-time warnings to be supressed individually, but not
en-masse. I.e., when the programmer gets a warning, he can check
if there really is a problem, and if not insert an assertion at the
relevant place in the code to supress the warning.

- Drop macros and instead require the compiler to inline definitions
that are marked as such.

Torben

[E. Robert Tisdale]

Michael Nahas wrote:

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I am a long time C programmer (I read the old testament in 1987) and
I've tried to keep the spirit of C and make as few changes as possible.
I was mostly driven by the bloat of C++ and, now, C99.
I was also driven by the gcc extensions,
which provide needed features that aren't present in ANSI C.
(http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html)
The things people will most hate are:
1) new keywords (fun, var)
2) changed type declarations
3) changed variable and function declarations
3) @ as the array operator, instead of []

The things people will most love are
1) multiple return values made easy
2) function pointers easier to declare and read
3) exact specifications of types
4) no forward declarations
This language doesn't add any power over C because it is designed to be
able to link to C files. It is just trying to do what C does with a
better type system and a better syntax for some things.

I know I am going to get flamed for this. I'd appreciate it if replies
contained constructive comments ("I'd rather have seen ...") rather than
destructive comments ("What you have sucks!"). Second, make sure to
mention what you like about it (if there is anything) rather than only
things that you hate. Lastly, if you think it violates the spirit of C
(a valid complaint in my mind), then try to state as clearly as you can
the principle that C embodies and then an example of how my language
violates it. E.g., "C uses minimal keywords. Your language has two new
keywords, 'fun' and 'var', all over the place."

As a final note, I have not written a replacement for the C
pre-processor yet. It's affect on C is much stronger than many people
believe. I have a few ideas floating around, but nothing solid yet.
Some involve using the [] symbols, which I would like to use for
polymorphic types, similar to C++'s templates.
(Which use < and >, the ugliest thing in C++.)

Great idea!

I think that you should start your own newsgroup

comp.lang.myc

right away. :-)

[those who know me have no need of my name]

[fu-t set -- cross-posted articles should have one of these, yours did not]

in comp.lang.c i read:

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf Let the flames begin...

okay. it's off-topic. please don't pollute.

--
a signature

[Antti Sykäri]

In article <dN*****************@twister.rdc-kc.rr.com>, Michael Nahas wrote:

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I'll give some general impressions first and then proceed to comment on
smaller details.

Firstly, I notice that you have abandoned a lot of C's syntax. May I ask
the reason for that? I've been pondering language design issues for some
time and currently my view is that syntax is as important, if not more
important, than other substance. Ideal syntax is just great for the
coder-in-the-trenches who faces it 8 hours a day, but it also attracts
new programmers that have never seen the language before. And when it
comes to attracting new programmers, nothing is as good a weapon as
familiarity. Syntax that most programmers are familiar resembles C.

Therefore, if I'd make a language, it would definitely have a syntax
that would be quite similar C.

When I first saw the "Hello World" in MyC, I was a bit startled since I
actually expected to see something like C. Instead, there was this:

[Page 2]

const main = fun(int)(argc: int, argv: @@char) {
printg("hello, world\n");
return 0;
}

1) function declaration syntax is different (it has the keyword "fun"
not familiar to a c programmer, and "const" looks odd in a function
declaration, actually reminding of C++'s const member functions)
2) argument list has a pascal-like syntax (argc: int instead of int
argc). Most C programmers hate pascal-like syntax.
3) instead of char* argv[], there's @@char. Probably pointer-to-pointer,
or perhaps array-of-arrays, all right, but this syntax just reminds
of objective-C or some other obscure language.

I strongly suggest taking a look at each of the differences above and
thinking hard whether the value brought by the syntactic outweighs its
cost in familiarity to C programmers.

In fact I was expecting something like:

int main(int argc, char[][] argv) {
print("hello, world\n");
return 0;
}

But well, I think you saw it coming:
The things people will most hate are:
1) new keywords (fun, var)
2) changed type declarations
3) changed variable and function declarations
3) @ as the array operator, instead of []
(and how well you said it yourself:)
E.g., "C uses minimal keywords. Your language has two new keywords,
'fun' and 'var', all over the place."
The thing is, people love to invent new syntax. But new syntax has the
downside of steeper learning curve, smaller target audience, and most
importantly the creeping feeling that something isn't just right with
this language. Best language designers take the syntax of a commonly
used language and slip their own language under it, making their target
audience feel as if they were right home.

Now that I finished the syntax rant, I have some actual things to say.

[Page 3]
const main = fun(int)(argc: int, argv: @@char) {
for var fahr = 0; (fahr <= 300) fahr += 20;
// ^--- A missing semicolon here?
printg(.%d\t%d\n., (&fahr, &(5*(fahr-32)/9)));
return 0;
}

Is this one a typo or are semicolons really not required inside for
loop? Also, I believe you use the banned ";" statement as the main
statement of the for loop instead of "{}".

I really like how MyC unifies structs, tuples, and function arguments.
I'm not sure if it works at all, but it feels somehow good. One thing
that left me wondering, by the way:

[Page 4]

About tuples - it seems that you can have lvalues in them. This means
that every other person tries to use it to swap values like this:

var x int = 1;
var y int = 2;

(x, y) = (y, x);

The question is, whether this will translate into

x = y; y = x;

or

temp_x = x; temp_y = y;
y = temp_x; x = temp_y;

It seems that it would be useful to sometimes leave a value in a tuple
unassigned. Underscore is used in languages with some kind of
unification:

(x, _) = swap(2, 3); // assign 3 to x, dump 2

[Page 4 again]
Note that the value 5 may have type union(char,int), but
that the value 'e' probably does not, because the lengths would be
different.

I don't understand this - isn't type of value 5 int? (Or int8, or
whatever) Doesn't it depend on the type of the variable it's assigned
to? Clarification please.

[Page 5]

Bool has values 0 (false) and 1 (true) and has a machine-dependent
size.

Wouldn't it be wise to nail down the size of bool, since the sizes of
other basic types have been specified as well? Size of one byte is not
probably a bad one...

switch is the same.

Did you consider fixing switch (that is, making it break by default and
falling through only if specified?)

[Page 6]

I like the integer naming and integer constant syntax. I doubt that
types of non-local endianness are used that often, though, but as they
are straightforward to implement, why not.

Char constants are the same as in C, with the exception \o### is an
octal char value (similar to the newer \x## used for hex). '\0' is
still the nul that terminates strings.

I suppose that binary char should also be \b####? Since you have
0xb#### as well.

Do you mention the type char in section "Types" somewhere? I suppose its
size is 1 and it's unsigned? (Though that doesn't matter, does it...)

Are integer promotions done automatically?

IMHO it would make sense, only conversions that destroy information
should be explicit.

Can you convert between bool and other basic types?

How do you declare an array of constant size?
Some involve using the [] symbols, which I would like to use for
polymorphic types, similar to C++'s templates. (Which use < and >, the
ugliest thing in C++.)

Do you consider them ugly because they complicate the parser, or because
of the First<Second<Third<int> > > syndrome? Or "just because"? (Which
would be the reason why I consider syntax "x: int" ugly...)

Java and C# have fixed this so you can now say First<Second<int>>. I
think.

IMHO <> make a nice syntax, [] is not bad either, () would be OK as
well; the only truly abominable template syntax would be {}.

-Antti

--
I will not be using Plan 9 in the creation of weapons of mass destruction
to be used by nations other than the US.

[Jack Klein]

On Thu, 10 Jun 2004 23:03:37 GMT, Michael Nahas
<mi***************@deletethis.com> wrote in comp.lang.c:

Antti & all interested,

The draft description of my language to replace C is available at:
As one other reply already mentions, completely off-topic in
comp.lang.c.

I am a long time C programmer (I read the old testament in 1987)

"long time C programmer" == "1987"???!!!

ROTFLMAO!

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Dan P.]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:5s********************************@4ax.com...

On Thu, 10 Jun 2004 23:03:37 GMT, Michael Nahas
<mi***************@deletethis.com> wrote in comp.lang.c:

Antti & all interested,

The draft description of my language to replace C is available at:

As one other reply already mentions, completely off-topic in
comp.lang.c.

I know C.L.C. is about the C language only, but I can't think of a more
appropriate group to discuss a modification of C than in this group. Who
else is going to give better feedback on such a language?

I am a long time C programmer (I read the old testament in 1987)

"long time C programmer" == "1987"???!!!

ROTFLMAO!

I would consider programming a certain language for 17 years pretty long.
Why is this so funny?
Dan

[CBFalconer]

those who know me have no need of my name wrote:

[fu-t set -- cross-posted articles should have one of these,
yours did not]

FYI there was no follow-up set on your article.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[those who know me have no need of my name]

[fu-t set]

in comp.lang.c i read:

those who know me have no need of my name wrote:

[fu-t set -- cross-posted articles should have one of these,
yours did not]

FYI there was no follow-up set on your article.

damn. fingers slipped. *sigh*

--
a signature

[those who know me have no need of my name]

[fu-t set]

in comp.lang.c i read:

I know C.L.C. is about the C language only, but I can't think of a more
appropriate group to discuss a modification of C than in this group.

if you were interested in modifying c then comp.std.c would be the
appropriate venue. but you aren't doing that, you are making an entirely
new and different language using c as some sort of seed, so neither
comp.lang.c or comp.std.c are appropriate. comp.lang.misc is fine, in fact
it's quite appropriate, but alas you haven't confined your discussions to
that group.

--
a signature

[Thomas Matthews]

Michael Nahas wrote:

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I am a long time C programmer (I read the old testament in 1987) and
I've tried to keep the spirit of C and make as few changes as possible.
I was mostly driven by the bloat of C++ and, now, C99. I was also
driven by the gcc extensions, which provide needed features that aren't
present in ANSI C.
(http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html) [snip] Torben

Why do we need a language to replace C?

C is a fine language, so are C++, Lisp, Java, Fortran,
Basic, Snobol, Pascal, Modula2, Ada, Smalltalk, Logo,
PL/1 (and PL/M), Basic, Ruby, Python, ....

None of these languages is replacing the other. Languages
come about because somebody believes that a new language
is better suited for a set of problems (situations), since
no language is perfect for all applications.

Since your name is not Microsoft, what rights do you have
in inventing a new language to replace another? :-)
{As you can see C# has not replaced C, C++, or Java.}

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Malcolm]

"Michael Nahas" <mi***************@deletethis.com> wrote

The draft description of my language to replace C is available at:
....
Let the flames begin...

This deserves to be discussed, but isn't really topical on comp.lang.c (if
you have issues with specific parts of the C langauge, eg handling multiple
returns from functions, then comp.std.c is the place for this, but not a
proposal for a new language).

[Michael Nahas]

those who know me have no need of my name <no****************@usa.net>
wrote in news:m1*************@usa.net:

[fu-t set -- cross-posted articles should have one of these, yours did
not]

in comp.lang.c i read:

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf

Let the flames begin...

okay. it's off-topic. please don't pollute.

Sorry, you're right. It was off topic. I wanted input from y'all; I
should have posted the main message only to comp.lang.misc and posted a
pointer to it in comp.lang.c. Sorry for the inconvenience.
Mike

[Dan P.]

"those who know me have no need of my name" <no****************@usa.net>
wrote in message news:m1*************@usa.net...

[fu-t set]

in comp.lang.c i read:

I know C.L.C. is about the C language only, but I can't think of a more
appropriate group to discuss a modification of C than in this group.
if you were interested in modifying c then comp.std.c would be the
appropriate venue. but you aren't doing that, you are making an entirely
new and different language using c as some sort of seed, so neither
comp.lang.c or comp.std.c are appropriate. comp.lang.misc is fine, in

fact it's quite appropriate, but alas you haven't confined your discussions to
that group.

Why do you keep saying "you". I'm not the original poster.

Dan

[those who know me have no need of my name]

[fu-t set]

in comp.lang.misc i read:

"those who know me have no need of my name" <no****************@usa.net>
wrote in message news:m1*************@usa.net...

[fu-t set]

[but was, alas, ignored]
Why do you keep saying "you". I'm not the original poster.

as i don't typically see the poster's name i made a mistake in seeing your
defense of it being posted to clc as-if you may have been the original
poster or a supporter. i should have checked more closely -- usually i do
when making responses that aren't mostly issue oriented -- i'm sorry i
missed doing that this time.

however in some ways i believe my use of `you' to be appropriate, e.g.,
you, personally, know that clc is the wrong venue yet can't seem to find
any other comp.lang groups, nor accept that clc doesn't magically become
appropriate just because there is nowhere else in all of the internet in
which the discussion is appropriate. in other cases `the op' or `one' or
`this whole thread, including the meta issues' may have been better terms
-- my intent being to point out the issue not necessarily to point at any
one person -- feel free to substitute whichever makes it more useful to you.

--
a signature

[Eric]

Michael Nahas wrote:

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I am a long time C programmer (I read the old testament in 1987) and
I've tried to keep the spirit of C and make as few changes as possible.
I was mostly driven by the bloat of C++ and, now, C99. I was also
driven by the gcc extensions, which provide needed features that aren't
present in ANSI C.
(http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html)
The things people will most hate are:
1) new keywords (fun, var)
2) changed type declarations
3) changed variable and function declarations
3) @ as the array operator, instead of []

The things people will most love are
1) multiple return values made easy
2) function pointers easier to declare and read
3) exact specifications of types
4) no forward declarations
This language doesn't add any power over C because it is designed to be
able to link to C files. It is just trying to do what C does with a
better type system and a better syntax for some things.

I know I am going to get flamed for this. I'd appreciate it if replies
contained constructive comments ("I'd rather have seen ...") rather than
destructive comments ("What you have sucks!"). Second, make sure to
mention what you like about it (if there is anything) rather than only
things that you hate. Lastly, if you think it violates the spirit of C
(a valid complaint in my mind), then try to state as clearly as you can
the principle that C embodies and then an example of how my language
violates it. E.g., "C uses minimal keywords. Your language has two new
keywords, 'fun' and 'var', all over the place."

As a final note, I have not written a replacement for the C
pre-processor yet. It's affect on C is much stronger than many people
believe. I have a few ideas floating around, but nothing solid yet.
Some involve using the [] symbols, which I would like to use for
polymorphic types, similar to C++'s templates. (Which use < and >, the
ugliest thing in C++.)

Let the flames begin...
Mike


For Torben:
I agree with most of your suggestions, but I didn't think that this
was the language for all of them. I wanted a language that was
linkable with C and didn't require anything else. I basically
wanted C with a clearer type system and a nicer interface to a few
features. Thunks, overloading, and polymorphism didn't fit.
(Although, polymorphism may come through type macros.) After I
finish the design of this language and write a compiler, I'm going
to look at designing a higher-level language. I've come to like
OCaml, but dislike a few hickups (naming especially) and it's
syntax. I think there could be a market for a type-safe language
that could easily link to C and use a conservative garbage
collector.

Mike

Subject: Re: a language to write an OS with ???
From: to*****@diku.dk (Torben Ægidius Mogensen)
Newsgroups: comp.lang.misc

Antti Sykäri <js*****@gamma.hut.fi> writes:

Nowadays it's all too common for language designers to design high
level, garbage-collected, object-oriented, bigger-is-better like
languages (witness C++ since addition of multiple inheritance and
exception specifications, Java, C#, and now D). To strive for an
efficient, clean, and "light-weight" language -- a language that would
be just appropriate to create a modern operating system in -- doesn't
seem to be very fashionable.

I wouldn't say that there is less interest in designing such
languages, I would rater say that the "market" for such languages is
more entrenched than for higher-level languages, especially scripting
languages. One reason may be that an OS is a major undertaking and
likely to be in use for a long time. So OS writers want a language
that they know will be around for a long while and which will be
ported to a large range of platforms (allowing their OS to do the
same).

My own hobby language is about creating a better C/C++, with cleaner
syntax, more extensibility, more transparency, better metaprogramming
facilities and ultimately, the ability to go as close to the hardware
as possible when needed. (Yes, it's likely to be a long road.)

In essence, it's about taking C and evolving it in the same direction
as C++ did, emphasizing the "what you don't use, you don't pay for"
rule and paying less attention to backwards compatibility.

In designing a C replacement, I wouldn't start from C. Even without
the C++ additions etc., C is a horrible language, with highly
complicated and somewhat ambiguous syntax, underspecified semantics
and lacking in features necessary for OS writing (such as jumping
through a pointer).

What I would do was (among other things):

- Have well-defined syntax and semantics.

- Ensure that the sizes of all types are specified by the language,
so it would, e.g., be explicit if an integer or pointer is 32 or 64
bits long. Memory layout would also be explicit, so big-endian or
little-endian numbers and strings would have explicitly different
types (and both would be present).

- Make it explicit in the type of a pointer if it can be null.

- Make it explicit in the type of a value if it can be modified after
creation and initialization. Integrate creation and
initialization.

- Allow pointer-arithmetic only on pointers to arrays. Doing it on
other pointers should give type errors. You can have fields
offsets and such, and they can even be negative (a record/struct
pointer type can specify to which field the pointer points). Allow
all/several components of a record to be accessed at once, using a
kind of pattern-matching.

- Have no implicit casts, even between integer sizes.

- Have parametric polymorphism, implemented by
replication/specialization.

- Overloading via (Haskell-style) type classes, not by ad-hoc
overloading or OO-style virtual methods.

- Have type-safe closures/thunks.

- Allow programmer to specify pointer to address at which a record,
array or other structure is built. Issue compile-time warning if
the type of the pointer does not ensure sufficient space.

- Allow compile-time warnings to be supressed individually, but not
en-masse. I.e., when the programmer gets a warning, he can check
if there really is a problem, and if not insert an assertion at the
relevant place in the code to supress the warning.

- Drop macros and instead require the compiler to inline definitions
that are marked as such.

Torben

I'm perfectly happy with C as it is.
Thanks You Very Much!
Eric

[Eric]

Michael Nahas wrote:

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I am a long time C programmer (I read the old testament in 1987) and
I've tried to keep the spirit of C and make as few changes as possible.
I was mostly driven by the bloat of C++ and, now, C99. I was also
driven by the gcc extensions, which provide needed features that aren't
present in ANSI C.
(http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html)
The things people will most hate are:
1) new keywords (fun, var)
2) changed type declarations
3) changed variable and function declarations
3) @ as the array operator, instead of []

The things people will most love are
1) multiple return values made easy
2) function pointers easier to declare and read
3) exact specifications of types
4) no forward declarations
This language doesn't add any power over C because it is designed to be
able to link to C files. It is just trying to do what C does with a
better type system and a better syntax for some things.

I know I am going to get flamed for this. I'd appreciate it if replies
contained constructive comments ("I'd rather have seen ...") rather than
destructive comments ("What you have sucks!"). Second, make sure to
mention what you like about it (if there is anything) rather than only
things that you hate. Lastly, if you think it violates the spirit of C
(a valid complaint in my mind), then try to state as clearly as you can
the principle that C embodies and then an example of how my language
violates it. E.g., "C uses minimal keywords. Your language has two new
keywords, 'fun' and 'var', all over the place."

As a final note, I have not written a replacement for the C
pre-processor yet. It's affect on C is much stronger than many people
believe. I have a few ideas floating around, but nothing solid yet.
Some involve using the [] symbols, which I would like to use for
polymorphic types, similar to C++'s templates. (Which use < and >, the
ugliest thing in C++.)

Let the flames begin...
Mike


For Torben:
I agree with most of your suggestions, but I didn't think that this
was the language for all of them. I wanted a language that was
linkable with C and didn't require anything else. I basically
wanted C with a clearer type system and a nicer interface to a few
features. Thunks, overloading, and polymorphism didn't fit.
(Although, polymorphism may come through type macros.) After I
finish the design of this language and write a compiler, I'm going
to look at designing a higher-level language. I've come to like
OCaml, but dislike a few hickups (naming especially) and it's
syntax. I think there could be a market for a type-safe language
that could easily link to C and use a conservative garbage
collector.

Mike

Subject: Re: a language to write an OS with ???
From: to*****@diku.dk (Torben Ægidius Mogensen)
Newsgroups: comp.lang.misc

Antti Sykäri <js*****@gamma.hut.fi> writes:

Nowadays it's all too common for language designers to design high
level, garbage-collected, object-oriented, bigger-is-better like
languages (witness C++ since addition of multiple inheritance and
exception specifications, Java, C#, and now D). To strive for an
efficient, clean, and "light-weight" language -- a language that would
be just appropriate to create a modern operating system in -- doesn't
seem to be very fashionable.

I wouldn't say that there is less interest in designing such
languages, I would rater say that the "market" for such languages is
more entrenched than for higher-level languages, especially scripting
languages. One reason may be that an OS is a major undertaking and
likely to be in use for a long time. So OS writers want a language
that they know will be around for a long while and which will be
ported to a large range of platforms (allowing their OS to do the
same).

My own hobby language is about creating a better C/C++, with cleaner
syntax, more extensibility, more transparency, better metaprogramming
facilities and ultimately, the ability to go as close to the hardware
as possible when needed. (Yes, it's likely to be a long road.)

In essence, it's about taking C and evolving it in the same direction
as C++ did, emphasizing the "what you don't use, you don't pay for"
rule and paying less attention to backwards compatibility.

In designing a C replacement, I wouldn't start from C. Even without
the C++ additions etc., C is a horrible language, with highly
complicated and somewhat ambiguous syntax, underspecified semantics
and lacking in features necessary for OS writing (such as jumping
through a pointer).

What I would do was (among other things):

- Have well-defined syntax and semantics.

- Ensure that the sizes of all types are specified by the language,
so it would, e.g., be explicit if an integer or pointer is 32 or 64
bits long. Memory layout would also be explicit, so big-endian or
little-endian numbers and strings would have explicitly different
types (and both would be present).

- Make it explicit in the type of a pointer if it can be null.

- Make it explicit in the type of a value if it can be modified after
creation and initialization. Integrate creation and
initialization.

- Allow pointer-arithmetic only on pointers to arrays. Doing it on
other pointers should give type errors. You can have fields
offsets and such, and they can even be negative (a record/struct
pointer type can specify to which field the pointer points). Allow
all/several components of a record to be accessed at once, using a
kind of pattern-matching.

- Have no implicit casts, even between integer sizes.

- Have parametric polymorphism, implemented by
replication/specialization.

- Overloading via (Haskell-style) type classes, not by ad-hoc
overloading or OO-style virtual methods.

- Have type-safe closures/thunks.

- Allow programmer to specify pointer to address at which a record,
array or other structure is built. Issue compile-time warning if
the type of the pointer does not ensure sufficient space.

- Allow compile-time warnings to be supressed individually, but not
en-masse. I.e., when the programmer gets a warning, he can check
if there really is a problem, and if not insert an assertion at the
relevant place in the code to supress the warning.

- Drop macros and instead require the compiler to inline definitions
that are marked as such.

Torben

If you really want to do something along this line of thought, turn your
efforts towards creating a really nice add-on function library that
would be freely distributed with source. There's a bazillion drudge tasks
that a library could do for people - everyone has their own set of useful
routines they use in project after project. collect em...
Eric

[Dr Justice]

"Michael Nahas" <mi***************@deletethis.com> wrote in message
news:dN*****************@twister.rdc-kc.rr.com...

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf

[crosspost to comp.lang misc removed]

I'll let this haiku speak:

C the guiding light
and the physical constant
blissful coders know

:-)

DJ

P.S. There's nothing wrong in having a go, of course!
--

[Gustavo Cipriano Mota Sousa]

Other day a friend told me about a new language that some guys
created, it's called D, it seemed to me to be a good sucessor for the
C language, it follows the same sintaxe, but if i remember well, the
project aims at creating a OOP language with garbage collector, and
that allows backward compability with C, allowing you to link programs
with C libs. It would also be compilable, generating native code
instead of running at the top of a VM. The URL of the project is
http://www.digitalmars.com/d/. They already have a frontend compiler
for gcc (although i haven't put it to work yet, because i am a bit
lazy)

[Malcolm]

"Gustavo Cipriano Mota Sousa" <gu*********@inf.ufg.br> wrote

Other day a friend told me about a new language that some guys
created, it's called D, it seemed to me to be a good sucessor for > the C language, it follows the same sintaxe, but if i remember well, the project aims at creating a OOP language with garbage
collector, and that allows backward compability with C, allowing
you to link programs with C libs.

Quite a lot of languages have been named "D", but as far as I know none has
caught on to any extent.
C++ already provides OO and, with the standard template library, garbage
collection, and has facilities to link C functions, and it is a
well-established language. "D" doubtless implements things much better, but
the advantage would have to absolutely overwhelming (or you would have to
have the marketing muscle of a big company behind you) to have any hope of
dislpacing C++ as language of choice.

[Richard Bos]

"Dan P." <dp***************@ec.rr.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:5s********************************@4ax.com...

On Thu, 10 Jun 2004 23:03:37 GMT, Michael Nahas
<mi***************@deletethis.com> wrote in comp.lang.c:

The draft description of my language to replace C is available at:

As one other reply already mentions, completely off-topic in
comp.lang.c.

I know C.L.C. is about the C language only, but I can't think of a more
appropriate group to discuss a modification of C than in this group.

Myeah, well. I don't think the OP was talking about modification of C as
much as about replacement of it. The language he designed is different
enough not to count as a mere modification of C.

Richard

[Antti Sykäri]

In article <ca**********@newsg1.svr.pol.co.uk>, Malcolm wrote:

"Gustavo Cipriano Mota Sousa" <gu*********@inf.ufg.br> wrote

Quite a lot of languages have been named "D", but as far as I know none has
caught on to any extent.
C++ already provides OO and, with the standard template library, garbage
collection, and has facilities to link C functions, and it is a
well-established language. "D" doubtless implements things much better, but
the advantage would have to absolutely overwhelming (or you would have to
have the marketing muscle of a big company behind you) to have any hope of
dislpacing C++ as language of choice.

D has the advantage of the having most of the advantages of C++ but not
too many of its weaknesses. In addition, it has features that make
programming just so comfortable that having to switch back to C++ makes
me cringe.

This has made D *my* language of choice when picking a language for my
hobby projects, and I don't find it at all unlikely if other people
eventually arrive at the same decision.

While D is not perfect (it's still in development and is still missing a
good part of its standard library) it's one of the best there is.

In summary, there is a gap between "good old" languages (C and C++) and
"fancy new" languages (Java and C#). The former are simple, fast, and,
to a certain degree, crude; are compiled to machine code; and have C
linkage. The latter are designed by large corporations, for large
corporations; have nice features that boost productivity; are run on a
virtual machine; and, therefore, can be perceived as having a certain
overhead.

D aims to fill that gap, and I hope it succeeds.

-Antti

--
I will not be using Plan 9 in the creation of weapons of mass destruction
to be used by nations other than the US.

[James Harris]

"Michael Nahas" <mi***************@deletethis.com> wrote in message
news:dN*****************@twister.rdc-kc.rr.com...

Antti & all interested,

The draft description of my language to replace C is available at:

http://nahas.is-a-geek.com/~mike/MyC.pdf
I am a long time C programmer (I read the old testament in 1987) and
I've tried to keep the spirit of C and make as few changes as possible.
I was mostly driven by the bloat of C++ and, now, C99. I was also
driven by the gcc extensions, which provide needed features that aren't
present in ANSI C.
(http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html)
The things people will most hate are:
1) new keywords (fun, var)
2) changed type declarations
3) changed variable and function declarations
3) @ as the array operator, instead of []

The things people will most love are
1) multiple return values made easy
2) function pointers easier to declare and read
3) exact specifications of types
4) no forward declarations
This language doesn't add any power over C because it is designed to be
able to link to C files. It is just trying to do what C does with a
better type system and a better syntax for some things.

I know I am going to get flamed for this. I'd appreciate it if replies
contained constructive comments ("I'd rather have seen ...") rather than
destructive comments ("What you have sucks!"). Second, make sure to
mention what you like about it (if there is anything) rather than only
things that you hate. Lastly, if you think it violates the spirit of C
(a valid complaint in my mind), then try to state as clearly as you can
the principle that C embodies and then an example of how my language
violates it. E.g., "C uses minimal keywords. Your language has two new
keywords, 'fun' and 'var', all over the place."

As a final note, I have not written a replacement for the C
pre-processor yet. It's affect on C is much stronger than many people
believe. I have a few ideas floating around, but nothing solid yet.
Some involve using the [] symbols, which I would like to use for
polymorphic types, similar to C++'s templates. (Which use < and >, the
ugliest thing in C++.)

Let the flames begin...
Mike


For Torben:
I agree with most of your suggestions, but I didn't think that this
was the language for all of them. I wanted a language that was
linkable with C and didn't require anything else. I basically
wanted C with a clearer type system and a nicer interface to a few
features. Thunks, overloading, and polymorphism didn't fit.
(Although, polymorphism may come through type macros.) After I
finish the design of this language and write a compiler, I'm going
to look at designing a higher-level language. I've come to like
OCaml, but dislike a few hickups (naming especially) and it's
syntax. I think there could be a market for a type-safe language
that could easily link to C and use a conservative garbage
collector.

Mike

Subject: Re: a language to write an OS with ???
From: to*****@diku.dk (Torben Ægidius Mogensen)
Newsgroups: comp.lang.misc

Antti Sykäri <js*****@gamma.hut.fi> writes:

Nowadays it's all too common for language designers to design high
level, garbage-collected, object-oriented, bigger-is-better like
languages (witness C++ since addition of multiple inheritance and
exception specifications, Java, C#, and now D). To strive for an
efficient, clean, and "light-weight" language -- a language that would
be just appropriate to create a modern operating system in -- doesn't
seem to be very fashionable.

I wouldn't say that there is less interest in designing such
languages, I would rater say that the "market" for such languages is
more entrenched than for higher-level languages, especially scripting
languages. One reason may be that an OS is a major undertaking and
likely to be in use for a long time. So OS writers want a language
that they know will be around for a long while and which will be
ported to a large range of platforms (allowing their OS to do the
same).

My own hobby language is about creating a better C/C++, with cleaner
syntax, more extensibility, more transparency, better metaprogramming
facilities and ultimately, the ability to go as close to the hardware
as possible when needed. (Yes, it's likely to be a long road.)

In essence, it's about taking C and evolving it in the same direction
as C++ did, emphasizing the "what you don't use, you don't pay for"
rule and paying less attention to backwards compatibility.

In designing a C replacement, I wouldn't start from C. Even without
the C++ additions etc., C is a horrible language, with highly
complicated and somewhat ambiguous syntax, underspecified semantics
and lacking in features necessary for OS writing (such as jumping
through a pointer).

What I would do was (among other things):

- Have well-defined syntax and semantics.

- Ensure that the sizes of all types are specified by the language,
so it would, e.g., be explicit if an integer or pointer is 32 or 64
bits long. Memory layout would also be explicit, so big-endian or
little-endian numbers and strings would have explicitly different
types (and both would be present).

- Make it explicit in the type of a pointer if it can be null.

- Make it explicit in the type of a value if it can be modified after
creation and initialization. Integrate creation and
initialization.

- Allow pointer-arithmetic only on pointers to arrays. Doing it on
other pointers should give type errors. You can have fields
offsets and such, and they can even be negative (a record/struct
pointer type can specify to which field the pointer points). Allow
all/several components of a record to be accessed at once, using a
kind of pattern-matching.

- Have no implicit casts, even between integer sizes.

- Have parametric polymorphism, implemented by
replication/specialization.

- Overloading via (Haskell-style) type classes, not by ad-hoc
overloading or OO-style virtual methods.

- Have type-safe closures/thunks.

- Allow programmer to specify pointer to address at which a record,
array or other structure is built. Issue compile-time warning if
the type of the pointer does not ensure sufficient space.

- Allow compile-time warnings to be supressed individually, but not
en-masse. I.e., when the programmer gets a warning, he can check
if there really is a problem, and if not insert an assertion at the
relevant place in the code to supress the warning.

- Drop macros and instead require the compiler to inline definitions
that are marked as such.

Torben

[James Harris]

"Michael Nahas" <mi***************@deletethis.com> wrote in message news:dN5yc.10866

What I would do was (among other things):

- Have well-defined syntax and semantics.

- Ensure that the sizes of all types are specified by the language,
so it would, e.g., be explicit if an integer or pointer is 32 or 64
bits long. Memory layout would also be explicit, so big-endian or
little-endian numbers and strings would have explicitly different
types (and both would be present).

I'm curious as to how you would handle these explicitly defined integers on a 36-bit
machine with 9-bit bytes as I'm having to deal with these questions myself. Explicit is
good in being repeatable but it is not necessarily fast. ANSI C defines arithmetic and
logical operations on integers and explicitly allows some operations to be implementation
defined. In other words all C integer operations are fast, most are the same on all
architectures (eg shifting a small positive integer), and some are to be avoided on
transportable code - at least within defined parameters.

What would you do on machines using 1's complement representation? You could put tests
around the code manipulating these but that would result in a performance hit. C avoids
this by calling shifts and suchlike on negative integers implementation defined. Have you
a fast way to avoid all such uncertainties? (To quote K&R C 2nd Ed sec 2.9, "Right
shifting a signed quantity will fill with sign bits ... on some machines and with 0-bits
.... on others.")

Also, would not explicitly stating whether an integer is to be stored as little-endian or
big-endian cause a massive performance hit on a machine for which that was not the native
format, eg. PowerPC supports both, IIRC, but Intel doesn't support big-endian. I think the
PDP architecture uses a mixed-endian representation of 4-byte ints.

--
Cheers,
James