From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,beb0b7471c6440e3 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-22 22:46:05 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: mjsilva697@earthlink.net (Mike Silva) Newsgroups: comp.lang.ada Subject: Re: 'Cyclone', a safer C--reinventing the wheel Date: 22 Nov 2001 22:46:05 -0800 Organization: http://groups.google.com/ Message-ID: <27085883.0111222246.1358dcdf@posting.google.com> References: <3BFA4095.8325D016@earthlink.net> <27085883.0111201750.234ce321@posting.google.com> NNTP-Posting-Host: 209.179.218.199 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1006497965 32145 127.0.0.1 (23 Nov 2001 06:46:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Nov 2001 06:46:05 GMT Xref: archiver1.google.com comp.lang.ada:16892 Date: 2001-11-23T06:46:05+00:00 List-Id: Brian, I still have to wonder if we're reading the same post. For example, you claim in another post that the in the OP "C is referred to as a toxic piece of garbage." Huh??? Anyway, I don't dislike what you said, nor am I offended, just bewildered. And I have no desire to killfile you, since you are a frequent contributor to the group, and thus to my desire to learn. Mike Brian Rogoff wrote in message news:... > 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 > To: Berke Durak , 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