On Thu, 2008-01-24 at 10:17 -0500, Sandro Magi wrote: > Combinator libraries are prevalent in functional languages...
Sandro: I agree, but note you are now talking about introducing a very dangerous language feature in order to support .000001% of programmers. C# doesn't have the fixed set of operators that I am thinking about at all. Let me give an example so that we can have the same combination. There would be no difficulty introducing an operator '=>' (which has no other purpose in BitC) as an infix shorthand having known precedence that is equivalent to writing the type class method "becomes" in the usual procedure call notation. The language does not need to specify any meaning for or any default binding of "becomes". If there is a short list of widely useful infix notations of this form, we can add them. Others should be avoided. > >> As for code analysis, I consider that a standard library deficiency. Why > >> isn't the language's parser available in its own standard library? > > > > How would that help the code reviewer who is attempting to review the > > program that has been printed on a piece of paper? > > 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. 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. > Also, in ML you can just rebind infix symbols in your source file to > whatever precedence level you like. If you're really all that concerned > about it (ie. for paper review), enforce such a rebindings for every > file using operators, or define the rebindings for a whole project using > a global include. The latter proposal simply isn't viable. The former may or may not be, but it still leaves the problem of human parsability. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
