Lambda the Ultimate

Pretty sure ATS doesn't require a GC if you stick to the subset that doesn't require the runtime.

You are correct you don't need the GC for ATS. Much of the runtime also doesn't need the GC. The libraries often have a GC version of a data structure and a non-GC version. Almost all of my ATS programming has been done without using the GC.

Often the not-as-bad C alternatives are missing the point as alternatives. C is neither a high nor a low level language because it exists at two levels at once. Each structured object can be manipulated as a buffer, which is both the reason for C's benefits and dangers. "Close to the metal" just means this correspondence.

So it isn't quite that one could preserve the benefits of C by adding guards everywhere or use more complicated internal representations but instead help programmers to achieve what they want by using e.g. monadic style programming where for certain ( if not all ) manipulations of a struct it has to be wrapped into a monad which may provide additional safety checks - or does nothing which would reproduce the current behavior.

Ordinary safety checks as envisioned by better-than-C alternatives may not suffice in certain domains. In security oriented programming, data elements may be guarded by a checksum, which is checked on read and re-computed on write. A different checksum may indicate corruption or attack and irreversibly kills the system i.e. leave a trace in a section of persistent memory which is checked on startup. So while C doesn't have anything to offer here out of the box programmers at least don't mess with semi-intelligent compilers and their default assumptions. This is the primary reason why many people believe that C cannot be significantly improved. Static metaprogramming may be the way to go. Maybe one might even get rid of the preprocessor?

Thanks to the pointer to ATS it looks interesting, and I had not stumbled across it before.

i'm not bought into the blog post e.g. a counter point (if we are blog fighting) is here, with counter-counter-points in the comments of course.

i wouldn't personally want to use C, and have been using e.g. haxe of late for fun, but at the same time i do pretty much agree that there is tremendous danger in using a VM or sufficiently smart compiler. :-) or in not having a real debugger, etc.

the irony of course is that in these days i figure C compilers are pretty crazy technology in and of themselves wrt getting performance out of the underlying machine.

"everything is a trade-off." and the trade-offs are then evaluated subjectively.

nevertheless, it got me considering what kinds of things don't rely on vms and jits and gcs. :-)

'restrict' makes the aliasing performance complaint obsolete, although the analysis cost is pushed onto the programmer.

The restrict keyword is quite clumsy for expressing alias information. For example, you cannot express 'a' and 'b' never alias, while both may alias with 'c'.

You can specify that *p and *q never alias one another for the lifetimes of p and q.

The comment that C does not provide a standard ABI is rather bizarre.

Most if not all ABIs are defined in terms are of C ABI for a platform/architecture. I can think of 1 or maybe 2 ABI issues with C over the last 20 years. Nor have I ever worried about code compiled with different C compilers being ABI incompatible.

Perhaps you were thinking of C++ which has had a fair share of issues over the years.

The ABI for x86-64 for Windows (Win64) is different to the Unix ABI (arguments are passed in different registers). In fact the same is true for Win32 functions which use the Pascal calling convention, although most code still uses the standard calling convention for x86.

The C ABI only exists as common ABI in the OSs written in C, that is not the case in the few OS that used other language.

C has a lot of implementation and target dependent features, such as size and endian-ness of integers, potentially the layout of pointers. Algorithms by C developers must often be explicitly cache aware. C's model of the machine is a useful abstraction, but I wouldn't call it a non-leaking abstraction.

The idea that we need to "understand abstraction *and* its implementation in order to use it effectively" isn't really about whether or not the abstraction is leaky, but whether the abstraction is compositional. By definition, 'compositional' properties are exactly those for which you don't need to know the implementation of each component - i.e. P(X*Y)=f(P(X),'*',P(Y)). If your abstractions are not compositional, then most software grows monolithic because it requires a deep understanding of implementation.

C's abstractions are not very compositional, unless they fit into the narrow band of expressiveness associated with simple procedures (no signals, callbacks, main-loops).

Disagree. Even the abstraction of local variables within a function is leaky. One can take a local's address, pass it around (even let that pointer escape, for a truly nasty surprise later), and through bad pointer arithmetic destroy other local variables as well. Actually, I am hard pressed to think of a single abstraction in C that *does not* leak. One can always wield pointers and blast holes in the world underneath--and worse yet, some styles, many deep library functions, and the implementations of C's lower level facilities and operating system support, and a lot of code in the wild *does*.

I think you misunderstood. It isn't local variables that I claim don't leak; it's the way C models the hardware that doesn't leak.

The model of the hardware presented by C includes the general concept of pointers. And because the hardware model does not leak, pointers can point absolutely anywhere on the machine. To restrict pointers would force the hardware abstraction to have holes in it. It follows that everything which has a specific location in memory, including local variables, can be pointed at.

To restrict the "escape" of those addresses, you'd have to force inconsistencies in the way values are handled -- at the very least you'd have to introduce things that happen even though there is no specific call to specific source code that instructs the machine to do them. The absence of routines that happen when they are not specifically called is one of the few constraints that C programmers can use (and rely on using) to trace and analyze their code.

This results from presenting the simplest possible mental model of a pointer for programmers to deal with, and having it be absolutely general within the context of the hardware abstraction. Absolutely every constraint anyone might want on pointers for "safety" would make the pointers more complex and harder to understand, and would force the hardware abstraction that C programmers work with to have conspicuous gaps.

In short, if you want higher-level abstractions (like local variables) that cannot be forced to leak, you absolutely cannot achieve them while simultaneously providing a non-leaky model of general pointers.

Ray

The model of the hardware presented by C includes the general concept of pointers. … It follows that everything which has a specific location in memory, including local variables, can be pointed at.

Not in the recent (C99/C1x) specifications. For example,

extern void foo (char *);
int bar ()
{
        char str = 'c';
        char * ptr = malloc(1);
        *ptr = 1;
        foo(&str);
        return *ptr;
}

compiles to

        pushq   %rax # stack alignment noise
        movb    $99, 7(%rsp)
        leaq    7(%rsp), %rdi
        callq   _foo
        movl    $1, %eax # no need to read *ptr after call
        popq    %rdx
        ret

with clang 3.2 (gcc 4.7 is similar). str and ptr are different allocations, so, while foo can do anything to str, a standard compliant program can never get to the malloced data. Better: the C compiler is even able to eliminate the very call to malloc.

The standard actually specifies pointers as offsets in objects. Even pointer arithmetic isn't supposed to go more than one past the end of the object (allocation) whence the pointer originates:

If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

You might argue that the spec is mandating a very abstract model, but that actual implementations are more transparent. That might be true at the runtime level. However, as shown above, compilers do exploit the spec's abstractness to enable aggressive optimisations. The example in this post is more than benign, but look at all the bugs caused by programs that check for signed overflow after the fact: the spec says that overflow on signed arithmetic is undefined behaviour, and compilers thus assume it doesn't happen.

Signed overflow is a bit besides the point, but still interesting, so here's an example with gcc 4.7 (clang 3.2 is similar, but doesn't even need the redundant conditional).

long overflow (long x)
{
        if (x >= 0) return 0; /* redundant but bamboozles GCC into emitting wrong code */
        return (-x) > 0;
}

is turned into

        movq    %rdi, %rax
        shrq    $63, %rax
        ret

GCC is telling us that the result of negating a long is positive iff the argument is negative. That's almost always true: the exception is LONG_MIN (check your custom bignum code, that's affected Clozure CL until very recently)… but that's an overflow, and, as is commonly known, overflows never happen.

C-the-spec isn't close to the machine, and C-the-implementations have been taking advantage of that for some time now. The C that doubled as a convenient assembler doesn't exist anymore.

Besides the points made above, C doesn't abstract over L1 cache any more than machine code. Caches are something that CPUs manage behind your back (with the exception of prefetch instructions).

If you want to write high performance stuff then you very much need to know about hardware details; cache lines L1-L3 caches; virtual memory TLB tables; how memory and the bus work. Modern hardware architecture has become terribly complex, if one compares it with the PC of the early 90s; well all this is important for writing servers, writing games, any system where performance matters and Java can't be used.

Please see "What Every Programmer Should Know About Memory" by Ulrich Drepper

http://www.akkadia.org/drepper/cpumemory.pdf

1) C doesn't provide the overflow or carry flags on integers, that's a very leaky abstraction on a basic type.

2) nearly all the languages abstract the register and cache so this isn't C-specific.

3) as for the other abstractions provided by higher level languages, it depends: in C++ you're not obliged to use them (many use C++ as a 'better typed' C) in other languages you're correct.

Can Fortran be used as the source for an operating system? Can Java? Haskell?

Yes. Yes. Yes.

If C/C++ is to be criticized, wouldn't it make sense to compare it to one of it's peers rather than PLs that were clearly designed for other programming problem domains?

C or C++ can reasonably be compared to any other general purpose programming language. They're all peers.

Is a Swiss army knife better than a Bowie knife or a good pair of scissors?

Tools are a misleading metaphor for languages. Tools go away when the project ends. It is easy to switch between tools many times during development. Tools rarely need to be integrated (though it can be convenient to package them together, like a Swiss army knife or a toolbox).

Languages are materials; balsa, bone, fiberglass, steel, Lego brick. Materials stick around when the project is finished, and may occasionally need maintenance or extension. Materials have varying qualities e.g. robustness, rigidity, resilience, flexibility, mass. Some materials are brittle and break easily if stressed; some might cut you upon doing so. Integrating different materials, i.e. into composite materials or fused components, is often a challenge with impedance issues (though may be worth the overhead in some cases).

Treating languages as tools to make a point in an argument is the 'fallacy of the right tool'.

One can certainly compare materials, and judge some more effective for some purposes than for others. But due to the integration challenges, it is quite fair to criticize general purpose languages (e.g. C/C++, or Haskell) for any problem domain, whether it be machine learning, operating systems, or web apps.

Similarly, treating languages as an apple vs. orange comparison is an analogy that breaks down very quickly. Apples and oranges at least have similar pre-processes (growth on trees, shipping, sales) and similar post-processes (digestion in stomach, nutrients). If you want languages to be a matter of taste, then you'll need to guarantee similar properties - e.g. different syntax but a common model for development, linking, and integration. There are some ecosystems of languages that have such properties (e.g. .Net).

Shouldn't there be some context in the discussion of the relative merits of PLs and the features they possess?

With a general purpose language, every context is fair game. You can bring up GUIs or web-app servers or OS or any other context if you want to make a particular point.

Continuations might be a great feature in a language that you are using to build another PL but is it appropriate in a language used to make an accounting system for a company? A web based game?

Interestingly, the idea of continuations for stateless web-app development is quite useful. I vaguely recall that some OCaml project was the first to use them. Continuations in distributed systems can model mobile agents. I imagine you could model a valid distributed account transaction system using continuations.

It can be difficult to judge whether a given feature is useful for a problem or domain. I believe we can make sound judgements only based on language properties, not language features.