Re: Designing a successor to C

Discussion in 'C Programming' started by Chris, Jun 24, 2003.

  1. Chris

    Chris Guest

    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

    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

    - 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.
    Chris, Jun 24, 2003
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George W. Cherry

    Successor to Java?

    George W. Cherry, Sep 13, 2004, in forum: Java
    George W. Cherry
    Sep 14, 2004
  2. Paul Hsieh

    Re: Designing a successor to C

    Paul Hsieh, Jun 24, 2003, in forum: C Programming
    Edward G. Nilges
    Jul 31, 2003
  3. Dan Pop

    Re: Designing a successor to C

    Dan Pop, Jun 24, 2003, in forum: C Programming
    Dan Pop
    Jun 24, 2003
  4. Chris Torek

    Re: Designing a successor to C

    Chris Torek, Jun 27, 2003, in forum: C Programming
    Mark Gordon
    Jul 10, 2003
  5. Bruno Desthuilliers

    Re: Designing a successor to C

    Bruno Desthuilliers, Jul 1, 2003, in forum: C Programming
    Bruno Desthuilliers
    Jul 1, 2003

Share This Page