Cyclone Language

Home page: http://www.eecs.harvard.edu/~greg/cyclone/

Also see http://www.research.att.com/projects/cyclone/online-manual/main-screen001.html

Cyclone extends C with a raft of features, including type safety enforcements, array bound checks, exceptions, parametric types, and pattern matching. It compiles to C, and can make use of existing C code and libraries.

Terse New Scientist 11/2001 story: http://www.newscientist.com/news/news.jsp?id=ns99991578

Slashdot discussion (poor signal to noise ratio): http://slashdot.org/developers/01/11/16/1757251.shtml

Pointers

To improve safety of pointers, Cyclone introduces new kinds of pointers, via attributes for pointers, some with compile-time restrictions, others with run-time checks.

Pointer attributes:

Pointer subtyping (subtypes may be substituted for types, e.g. in parameters) Pointer coercion

Regions

Other Features Cyclone supports

In someone's opinion: Experimental language, not ready for prime time.

For instance, "Cyclone's straightforward memory leak detection algorithm doesn't lead to a small, well-defined interface. Case in point: in order to implement a garbage collector they had to extend the runtime. It was a small function (only 5 lines of code) but nevertheless it was not possible at the user level. In effect, they had to introduce a new proof rule into the type system. That's disturbing to me -- it means the type system is incomplete. And these are smart people, so if it wasn't complete to start with, that probably means it'll never be complete."

"What's even more disturbing is that at the end of the talk, NormanRamsey asked how they would implement a generational garbage collector. And the answer was 'We haven't figured out how to do that yet... it may require dependent types'"

"Just imagine trying to explain to a systems programmer that the reason they can't implement a "simple" generational GC scheme is because that would require that the type checker be extended to support dependent types. They'll look at you like you have three heads, and then they'll toss you and your silly little language into /dev/null." http://www.kimbly.com/blog/000325.html

Why would you need to implement a generational garbage collector in Cyclone? Cyclone has garbage collection as part of the language (not generational in the current implementation, but it could be). Note that you can't implement a garbage collector for C objects entirely in C, either: it requires some assembler/MachineCode (because it is necessary to obtain the values of processor registers, at least). Technically you can poke code into an unsigned char[] and jump to it, but I would not consider that to be a program written entirely in C.

If you were implementing an interpreter in Cyclone, OTOH, it would be possible to write a GC for objects in the interpreted language entirely in Cyclone, and that wouldn't require dependent types.

Review: http://www.securityfocus.com/guest/9094

But still interesting, and potentially useful as an alternative to C for certain projects.

Limitations

The biggest one I see is that it currently does not support threads.

However see <http://www.cs.washington.edu/homes/djg/papers/cycthreads-abstract.html>.

Some people have gotten used to threaded programming, plus on Windows systems, there's just no other way.

Not just Windows. For many application areas, threads are essential regardless of OS -- Unix, Mac, embedded systems...I don't think I've ever worked on a really huge system that was not multithreaded, although smaller ones don't always need it.

Yes. I meant that you can still use fork in Unix for many application areas. But in windows you just can't (well, Cygwin emulates it by doing some horrible things, and slow things http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html).

So I keep hearing about these languages with stronger type systems (and I'm a static typing fan, I should say), and there's always one question I want to ask... and since Cyclone is C based, it's particularly apropos. There's a standard idiom for StateMachinesInCee? that's has a concept like the following: 

    typedef state (*state)();
That is, a state is a pointer to a function that, when executed, returns a the next state.

Then, states can be used by 

    state current = initial;
    while((current = current()));
with extra code added as needed. Of course, the above isn't valid C... there's no way to do a recursive typedef.

Fortunately, C has WeakTyping, so this can be worked around: 

    typedef void* (*state)();
    state current = initial;
    while((current = (state) current()));
Now, as far as I can tell (having just read the manual for a bit), there's no way to do recursive typedefs in Cyclone. Fine, I can accept that...

But how do you do the above idiom with strong typing? How do you do it in Cyclone at all?

-- AdamBerger

In either Cyclone or C, 

    struct state_t;
    struct state_t {
        struct state_t *(*next)();
    };
    typedef struct state_t *state;


    state current = initial;
    while (current = current->next());
Actually, in Cyclone you'd probably use the closures in the standard library instead.

Hm... now I'm wondering why I never did it that way in C. Good answer! (Although I'm not convinced proliferating structs is a good thing... it's an interesting point that the type systems do allow structs to perform that type of self reference. Of course I've used it a million times in lists and trees and graphs, but never thought about having it there. Thanks -- AdamBerger

The aspect of this that interested you was the use of the function pointer, to allow polymorphism?

The interesting aspect is how it solves either referring a to a typedef in itself (verboten) or the use of a void* (unsafe). By not seeing the struct solution myself, I constructed a false dichotomy by assuming referring to a type in itself was forbidden in general in C, where of course it's only forbidden in typedefs. So the answer reads as 'you're making a mistake about how powerful c's type system is to begin with; you don't need to solve it with a void* in c to begin with, so you certainly don't need to adopt any particular tricks in Cyclone.

That part of it is pretty much identical (I think) to the now-deleted original straight C solution I had posted below, before he offered the function pointer variation, so I still feel a little puzzled -- but since it seems to involve a mental block, I won't worry about it.

Cyclone is mentioned quite a bit in AdvancedTopicsInTypesAndProgrammingLanguages

CategoryProgrammingLanguage

EditText of this page (last edited July 7, 2014) or FindPage with title or text search