Jonathan S. Shapiro wrote: > Sandro: I agree, but note you are now talking about introducing a very > dangerous language feature in order to support .000001% of programmers.
Operators are useful mainly to the end-users, not to the library developers, so the market is rather larger than that. Unless you're referring to functional languages being used by 0.00...1% of programmers? >> So a facility is broken because it doesn't help 0.001% of the market >> reviewing code on paper? I don't find that convincing. > > I do. The fundamental and primary driving objective of BitC is to make > code robust and comprehensible (both in the human sense and the machine > sense). If that doesn't match your priorities, that is okay, but the > language you want isn't BitC. I wasn't speaking to BitC specifically, just for general purpose languages with flexible syntax in general. I would prefer flexible operators over using PEGs or packrat parsing with *fully* customizable syntax (as some languages are adopting). I understand that BitC might target a different market entirely. > That being said, I don't reject the idea of better tools. But ML has had > this feature for decades, and I don't see any tools yet. There also aren't any IDEs, which I would think is a prerequisite for such a tool. It's a shame too. F# is the closest ML-derivative to having an IDE. Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
