Cyclone 1.0 released.

Cyclone is a type-safe dialect of C that incorporates a number of features from functional languages, including parametric polymorphism (ML-style, not C++), datatypes, and pattern matching. It also includes a number of features necessary to make C safe, such as fat pointers, tagged unions, and region-based memory management.

We've just put out a new release (1.0) and a new web site:

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


How bad is the overhead of the runtime checks that your compiler inserts to the code it feeds to gcc? Would it make a C program 2x, 8x, 30x slower when ported?



I'm not a member of the

I'm not a member of the cyclone team, but I think it would depend on the nature of the program, and the nature of the port. If your C program is doing a lot of sketchy memory accesses, it'll probably slow down a lot. On the other hand, if you carefully go through and make sure that the compiler can use region analysis and such to protect your accesses statically, I imagine it won't slow things down hardly at all.

It's been a while since I

It's been a while since I read the Cyclone papers, but IIRC most of their type features have the goal of eliminating runtime checks.

For memory management there are regions and linear types/values; plus there are non-null pointers (i.e. you init them, and then you never have to check for NULL). I'd guess they also have some mechanism to detect common array iterations to avoid bounds checks.

So that leaves a few things like conversion checks (covert pointer to non-null pointer), bounds checks, and garbage collection, if you use it (the "global" region is garbage-collected, if you don't want to use regions for everything).

I'd guess not more than 20% overhead for normal (translated) C programs.

"Memory Safety Without Runtime Checks or Garbage Collection"

I wonder if the Cyclone people have seen these papers:

which describe ways to prove the memory safety (that is, Java style "cannot access memory in an unforeseen way") for a subset of C. That seems slightly more promising to me as the alterations needed to most C programs would be small, and yet they'd still be valid C (whereas a Cyclone program is not).

If you want advanced features like pattern matching you may as well use some language with less historical baggage than C to base it on - the primary advantage of a C base seems to be applicability to real world codebases, which checking a subset would work better for.