A recent message on -edu reminded me of a discussion I started with Robby at ICFP and never continued.
When you read an ML program, you read the signatures of the modules; you may read the functor compositions, if any. And then you have a pretty good idea of which modules takes on which responsibility. This whole readability thing is 'baked' into the language, it's a linguistic concept. All they need in terms of extra-linguistic support are -- naming conventions -- parameter (ordering) conventions -- and an occasional purpose statement that explains a function if the name doesn't make it obvious Then you hone in on those pieces you care about and this is where you think you reach the same level of complexity as in Racket, but it isn't so. This is no true for Racket modules in our base and fails for many of my own modules, even if I make a serious effort to write down the interface to a module in one place. Worse, I could imagine that Jon finishes his addition to the DrRacket module browser one day (extracting provide and provide/typed information) and I would still not be as happy as with the few large ML systems I have seen. Question 1: is it the macro-full-ness of our code that does it? Is it a lack of conventions? Is it the size of the functions/modules that we have? Question 2: if you could pick three guidelines, what would you suggest to everyone else who contributes to the code base? (This isn't about 'if' indenting, though I have my thoughts on that, too.) I am thinking of expanding on our coding guidelines, and this call for thoughts is just one possible source of inputs. -- Matthias _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
