Kim-Ee Yeoh
Aaron Denney wrote:
I find the first far more readable. The compiler should be able to assemble it all at compile time, right?
'Course not. The (++) function like all Haskell functions is only a /promise/ to do its job.
I find this comment rather strange. One of the beauties of a pure language (especially a lazy one) is that there is no requirement for evaluation to take place at at any particular time as long as it's done before it's needed. So the compile-time/run-time dichotomy is only relevant when a value depends on data only available at run-time. Given that "foo "++"bar" can be evaluated at compile time and there are advantages and no disadvantages, it should be evaluated at compile time. In general, I don't think we should clutter the language with syntax for things for which there has to be a more general mechanism; including string breaks in the language was a mistake. Compare "thing1\n\ \thing2\n\ \thing3\n"++ otherThing++ "penultimate thing\n\ \last thing\n" with "thing1\n"++ "thing2\n"++ "thing3\n"++ otherThing++ "penultimate thing\n"++ "last thing\n" What /is/ the advantage of the former? -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk