On Mon, May 14, 2012 at 1:25 PM, Eike Scholz <[email protected]> wrote:
> The primary goals of my language are > > - Simplicity and conceptual coherence and consistence > - Simplicity in terms of compiler implementation > - Speed, especially Array acces and tuple member access must be as fast as > possible. > - Meta-Programmable - i.e. Extending the language should be simple. > - A strong strict type system (with an explicit unsafe escape) > > So roughly I aimed for something like scheme, but with static typing and > human/mathematician friendly syntax. Ha! That is exactly where BitC started. In fact, you describe the first version of BitC very closely. The final switch away from S-expression syntax in BitC was fairly recent. But I wanted to comment on the perils of simplicity. Simplicity is a good thing, but it should not be carried to extremes. First, there are some cases where real complexity exists in the world. A language design should not make that worse, but neither should it try to hide complexity that is inherent and real. Abstraction as a means to unify things that actually fit together sensibly is fine. Abstraction as a means to hide *necessary* complexity is a bad thing. Second, I agree that conceptual coherence and consistency are the right kind of consistency, and this sometimes conflicts with simplicity of implementation. A good example from BitC is the way that our quick-and-dirty implementation of by-reference parameters came back to bite us in the ass. We knew that we were stepping on the tail of the region typing tiger, and we decided to do something quick and simple so that we could put off the general regions problem for later. It was a mistake. From this experience I have drawn two lessons: - Given a choice between a general, consistent answer and a quick answer, do the general answer. This may not be the right approach in other types of programs, but compilers and operating systems critically need to be correct, so general approaches with good mathematical underpinnings should be preferred. - Don't give in to temptation on the quick answer. The risk is that it will let you defer the general answer too long, and that by the time you realize your mistake you will be too far along to recover easily. That happened to us on by-reference parameters. Once you have to implement a solution, try to implement the *right* solution. Concerning strong typing, I would really like to see an example where an unsafe escape is required. I know of exactly two such places: - In an operating system kernel, where pointers corresponding to hardware-defined well-known addresses must be declared. - In *very* low-level runtime implementations, like the inside of the storage allocator. Actually, I'm not convinced that unsafe code is required there. Every other use of unsafe code that I have seen exists to correct a deficiency of the language design, most commonly in the area of arrays vs. vectors or in the area of low-level I/O. There are known strongly-typed solutions for both cases. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
