Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The Roboto Programming Language -- Because Robots Should Be Doing the Work
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
Note: This README is out of date. Roboto has settled and, for the most part stabilized. The Cynara library has died of a severe case of maldesign (it was really an odd way of doing things to begin with, but great fun nonetheless), and work on the compiler proper has started. I've nearly settled on a final name for the language (although I am happy to hear any suggestions), and will start pushing to it as soon as simple lambdas compile properly and I've finalized the approach for the top-level. The compiler itself is so far written in a mix of Roboto and C, and after it can compile itself, it the Roboto parts will gradually subsume the C parts. The intermediate language is C (so the compilation process will take Roboto source, produce C source, and enlist a C compiler to produce machine code). This allows for the language to be machine- and ABI-independent and leave the rest to the C compiler. I hope to support at least GCC and Plan 9's 9c, although initially only GCC will be supported. (As tempted as I am to make Go the intermediate language, there are a couple of problems: Go is still a moving target at time of writing, and the language's design goals explicitly exclude making interoperability with C a priority, which is a priority for Roboto.) I am fairly interested in a non-autotools build system, provided there aren't any horrible extra compile-time dependencies. (Libtool is almost too much for me, and CMake and SCons are right out.) I am using plain Makefiles for now; suggestions are welcome. The original README follows. --- I am slowly cleaning up and moving code onto github. In the near term, the only concrete plans are to move code written *in* Roboto to github, rather than start moving Roboto itself over. When Roboto is at the point that it is written in itself, then it will get pushed. The current plan There's some reasoning here, bear with me. This code is worse than alpha. It's super-alpha. Pre-alpha. Negative alpha. The Roboto interpreter, as it stands, has several problems: 0. It's still an interpreter, not yet a compiler; it is still a prototype. But if you want to know the escape plan, have a look at lib/cynara.rl and the Pez project. 1. It's slow. See #1 2. It's buggy, and most bugs will not be fixed in the interpreter version. 3. I like to change the syntax for lambdas once a week. It's in pretty heavy flux. 4. The error messages are unfriendly and sometimes curse at you or sometimes are about the Time Cube, and often have no useful information in them. Because I no longer work in an office full of language wonks, the amount of feedback I get on this language is quite a bit less than it was a few weeks ago. I would like to hear what people think of the design of the language. It's nearing the end of the exploratory phase, and the really real implementation will happen in my copious free time. In other words, I've spent a long time looking at the language and saying "Writing this like X is ugly...What if I could write that like Y instead?" and pushing the code around. Sometimes I'd go jabber at someone for a while about the language, or drag them over to my desk and gesture wildly at my screen. So this seems like as good a time as any to start looking for broader input. The current implementation, after bootstrapping the compiler, is going away, but I'll have to live with the the design decisions that are made before the compiler is written and things are set in stone. So if you have any input on how the language ought to look, how a particular construct should behave, or something along those lines, I'd love to hear what you think. --  The name is based on the idea that, as coders, our entire livelihood is based on using machines to automate tasks that are tedious to people. Robots should be doing the work. This language was designed to eliminate, as much as possible, the tedium I felt when writing code in many other languages, by introducing as much uniformity and transparency into the language as possible.  That person was usually Dan Yoder ( http://github.com/dyoder ), who has always had valuable input. I almost named the language "Ocean" so that he would be forced to port Waves, and he is still upset with me for not going with a bytecode VM, I think. Dan, are we cool yet?  Matthew King ( http://github.com/automatthew ), among others, has also been chastising me for keeping the repository in Darcs, and I recently promised him a few others that I'd put *something* up.