Er, the alternate printer would only differ in printing applications and (possibly) function types, and could defer to the standard printer for everything else. I don't see how it would require maintenance, since the output would be purely for human viewing. It seems like a pain-free way of keeping a potentially beneficial option open, while not blocking progress.
And forgive me for being thick, but I thought the conclusion was that curry-style *semantics* were not compatible with native calling conventions -- juxtaposition-for-application is simple matter of arity-based lifting. Whether currying syntax would be a barrier for programmers from the Pascal tradition is another matter... On Wed, Aug 11, 2010 at 12:57 AM, Jonathan S. Shapiro <s...@eros-os.org>wrote: > On Tue, Aug 10, 2010 at 5:25 PM, Ben Karel <esc...@gmail.com> wrote: > >> Regardless of which input surface syntax is provisionally chosen, it might >> be nice to retain prettyprinters for both, so that as the stdlib evolves, >> you (and we!) can see real, non-trivial concrete examples for direct >> comparison. >> > > I'm not sure I understand. Much of the debate over the last week has been > determining whether a curry-style syntax is compatible with fast calling > conventions. We can now see that the answer is "no". > > I'm disinclined to maintain multiple pretty printers. It's hard enough to > maintain *one* compiler. My plan is to make a reference lexer, parser, and > type checker part of the standard library. That should go a long way toward > letting people experiment in the way that you suggest, and also toward > supporting various sorts of analysis tools. > > shap > > > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
