«

On Fri, 20 Jun 2003 19:01:45 +0000, Clint Olsen wrote:

Having said that, has anyone even tried to rethink
> 'portable assembly' and come up with another implementation? Does such
> an idea even have merit?

I think the idea has merit. However, I wouldn't focus so much on a clean
slate approach. I feel the answer may lie in updating the C standard with
well known beneficial functionality.

> Someone has already taken a stab at 'D', but I'm not sure that's the
> direction I would take with a systems programming language.

To me D is a completely different beast than "portable assembly". It's
very object oriented and the ABI is not fully compatible with C (ie. you
can link from D to libc, but not the other way around).

> I don't necessarily want to rehash wish lists again, but I would like to
> discuss design considerations that would contribute to a successor
> actually being successful like the ability to inter-operate with
> existing code (be able to exploit the existing libc) etc.

I think some of the functional languages can provide us with answers about
how to extend C in useful ways. For me, functional languages like Erlang,
SML, and Haskell tend to feel a lot like C. That is, "flat" in nature as
compared to an object-oriented language. This is not a bad thing in my
opinion and I've seen and written some very nice software in functional
languages. The reason I say they can be useful is because although they
are "flat" like C they also incorporate some newer ideas about program
design.

So what do I think a better C might have?

- It needs some type of namespace partitioning system. C++ style
namespaces would work, or even better would be something like Erlang's
module system with explicit function import/exports. C++'s symbol
mangling would not be needed and the namespace name could just be
pre-pended to any symbols (this is how Cyclone does namespaces). This way
the ABI is completely C compatible.

- It needs some type of powerful macro/template system. Something like
C++ templates would work, although C++ templates are geared a little far
out on the object-oriented side of things and I'd rather see something
easier to grasp for the average programmer. Lisp style macros might be
interesting if we could use a pseudo C-like language to describe the
macros. Basically just something to support generic programming better.
void* is not type-safe and adds unneeded overhead (ie. a vector
implemented as void* types will not be type-safe nor perform as well as
the C++ version). Keeping the ABI compatible becomes difficult here, but
I'm really just talking about a more powerful macro system where the
symbol names could be spliced together in a sensible manner.

Other stuff that I'm not so sure is needed but that most modern languages
support:

- By default all non-built-in types should be passed by const reference.
Pointers would still be available but would no longer be the standard type
for function arguments. Also, pointers should be const by default and
need special language to be mutable. That would be opposite the way it
works now; I hate having to manually specify const each time, it's more
often that you're using const than non-const for function arguments.

- A standard garbage collector should be available and part of the
language if desired. You should be allowed to use it when you want or not
use it when you don't. It should be seamless and clean either way.

- There should be built-in types for containers. vectors, maps, lists,
etc. could all be part of the language because they are used so often.
Although strictly speaking you wouldn't need this if you had the powerful
macro system I mentioned above, it would be nice to have them be part of
the language so that everything is more clear (eg. the compiler could do
all the hard work of managing the various types). Keeping ABI
compatibility would be very difficult at this point, so I don't know about
this. The standard could state explicitly how the symbols would be named
and the symbols should be simple to make them easy to use from straight
C-based languages.

Far out stuff:

- Type inferencing would be a great optional feature. I hate declaring
types. In my opinion O'Caml has the best model here. Th e types are
inferred but strong. So keep C's strict type checking, but infer all the
types rather than declaring them each time.

Cyclone has some of these features but it has a LOT of cruft along with
it. Cyclone's syntax gives me headaches (how many pointer types are
there?!). It seems to suffer from education/research syndrome and doesn't
feel very clean. Plus it's goals are different, it aims to be a "safe" C
rather than a better C.

With that said, take what I say with a grain of salt. My views are always
changing. I constantly flip between functional, object-oriented, and
straight-C programming and my view of perfection changes from day to day.

Sorry, this turned into somewhat of a wish list. I welcome comments.