Re: 'Cyclone', a safer C--reinventing the wheel

[Brian Rogoff <bpr@bpr.best.vwh.net>]

On 20 Nov 2001, Mike Silva wrote:
> Why the extreme overreaction to this posting, which was mostly just
> direct quotes from a news article?

Why not complain about the original slander, err, posting. 

> What "idiocies" were posted?  

The title, for one. Didn't you read my post? 

> If the inferences the OP drew were incorrect then shouldn't the blame be
> placed on a poorly written news article?  If the OP "doesn't know
> anything" isn't that also the fault of the news article?

No. Do you believe evrything you read? Don't you try to check the veracity
of statements you read? 

> As I said, your extreme reaction makes no sense on the face of it --
> clearly there's something more behind your comments.

What extreme reaction? A Usenet post? One that contains a pointer to the
Cyclone home page, so that ignoramuses can extricate themselves from their 
predicament? I'm guessing you just don't like the fact that I'm calling
idiotic posts idiotic, rather than coming up with long winded, smarmy way 
of calling them idiotic, which is what people typically do here. Too bad, 
if it offends you, plonk me (that means "put my address in your killfile", 
nothing lewd ;) and you'll never need to read a post from me again. 

I notice that you didn't address a single one of the points I made, including 
the one that Ada wheels weren't being reinvented. Serendipity being what it
is, I'll include a post that I got today from the Caml mailing list by
someone who knows better about which wheels are being reinvented, and why
they don't "just use Ada", as other dim bulbs here have suggested. And,
FWIW, I believe Cyclone would have been a better language had they started 
with an Ada subset instead of C...

-- Brian

---------- Forwarded message ----------
Date: Wed, 21 Nov 2001 16:25:12 -0500
From: Michael Hicks <mhicks@cs.cornell.edu>
To: Berke Durak <berke@altern.org>, caml-list@inria.fr
Subject: RE: [Caml-list] Rewriting UNIX in Caml and getting rid of the C
disease

Just to resurrect this thread:

Many of your observations on the inadequacies of C (and those of the
people who followed up) are addressed in a language being developed at
Cornell and AT&T Research called Cyclone.  It incorporates successful
high-level language features to ensure safety, but unlike most
high-level languages, gives the programmer control over data
representation and, to a large extent, memory management (e.g. a GC is
not required).  Furthermore, Cyclone is very close to C, thus
simplifying the process of porting legacy code (we actually parse a
superset of C, but our type-checker is more restrictive, as you would
imagine).  In essence, the language was designed with just your sort of
systems project in mind.  So far we have written a 40,000 line compiler
in Cyclone, and ported nearly 30,000 lines of systems code.

So that I'm not too off-topic, I should say that OCaml has been a strong
influence on Cyclone---many of the OCaml libraries and tools were ported
to Cyclone, and many of OCaml's features have been added to allow more
high-level programming, if desired, including exceptions, pattern
matching, tagged unions (i.e. datatypes), and others.  Of course,
"OCaml-like" is not OCaml itself; OCaml should be the language of choice
for applications where low-level control is not as important (of which
there are many).

http://www.cs.cornell.edu/projects/cyclone/ has more details.  There is
much more to be done, and comments are welcomed.

Mike

> -----Original Message-----
> From: Berke Durak [mailto:berke@altern.org]
> Sent: Sunday, November 11, 2001 12:18 AM
> To: caml-list@inria.fr
> Subject: [Caml-list] Rewriting UNIX in Caml and getting rid of the C
> disease
> 
> 
> Everyone on this list will agree that the C language is far from being
> perfect. More specifically, if we consider its various derivatives
> together (i.e. the C preprocessor and C++) they form the worst piece
> of stinking, pathogen and toxic garbage in the realm of programming
> languages.
> 
> On the other hand, we almost all use and respect UNIX and its
> derivatives, which might seem to be a paradox, given that UNIX is
> entirely based on C.  I'm here considering UNIX from the system
> programmer's view, making abstraction of the way it's
> implemented. Certainly, it could get much better, but, practically, it
> is just fine.
> 
> Unfortunately, the C language acts as a mandatory layer over
> UNIX. Generating an executable for a given brand of UNIX without going
> thru the C library is tricky because it requires to know how the
> system calls work. These are, first, not documented (because you're
> supposed to go thru the C library), and, second, depend precisely on
> #ifdef-infested C source code, and are subject to revision.
> 
> Therefore, in the interests of humanity, I hereby propose that :
> 
>                               ***
> 
> An appropriate sublanguage of Caml should be isolated, and a given,
> well-accepted brand of UNIX should be reimplemented in that language.
> Binary compatibility must be retained as far as possible. Basic system
> utilities (including a shell) should also be translated (into full
> Ocaml). Since the use of Caml will, a) divide the source code size by,
> say, ten and b) automatically remove, say, 95% of all bugs and
> security holes (since most are illnesses resulting from pointer
> manipulation), success is guaranteed.
> 
>                               ***
> 
> Progress has to be made in operating systems. C blocks that progress.
> C must be obliterated.
> 
> The use and existence of a Caml-based UNIX, with a (justified)
> reputation of very good security and integrity, will invariably
> attract a lot of hackers (in the good sense) to Caml. It will also
> make existing Caml programmers a valuable resource.
> 
> The use of Caml might also facilitate the verification of some parts
> of it using Coq, even if I don't know what part of an operating system
> you could usefully verify by formal methods.
> 
> For marketing purposes, a bijective mapping between some sort of
> subgrammar of C and the sublanguage of Caml could be provided.
> 
> For people worrying about speed, I'd just remind them that not so long
> ago, C itself was considered pretty slow and inefficient a language
> (maybe the compilers weren't as good), yet operating systems 
> were written in C and used on computers a thousand times slower than
> what we have today.
> 
> Finally, the task of translating UNIX from C to Caml, if certainly
> not straightforward, is certainly feasible with a predictable amount
> of work, and could even be made semi-automatically.
> --
> Berke
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: 
http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives:
http://caml.inria.fr
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ:
http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives:
http://caml.inria.fr