These ideas were touched on in a previous thread [1]. Our work would be easier if, as data, we separated a program's AST from its layout. If, for instance, the order in which a library's functions are presented on the page were stored as a "projection", separate from the AST that defined those functions, then one could reorder the functions without obscuring the history of changes to anything that was "moved". I assume I am not alone in making a lot of edits aimed solely at allowing me to read or traverse the code faster? Those within-function changes of presentation, like across-function changes of order, obscure the record of functional (as opposed to cosmetic) changes. They don't have to. Moreover, if projections and the AST were separate data, one could use contradictory hierarchiies|projections|layouts for the same data. One projection might group functions by their common purpose (an "is-tree"), while another grouped them by priority to the reader-rewriter (a "do-tree"). Given current technology, text folding does allow us to impose a hierarchy on a text document (even a Haskell document! you just need to indent the code relative to the comments that define the hierarchy). However, if the code is stored as text, then only one hierarchy is possible. In particular one is presently forced to choose between an "is-tree" and a "do-tree". https://groups.google.com/forum/#!msg/haskell-cafe/d8h8J8VxZxo/BNlKUjWeAgAJ -- Jeffrey Benjamin Brown