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: (e-mail address removed) (Torben Ægidius Mogensen)
Newsgroups: comp.lang.misc
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
