On Tue, Mar 27, 2012 at 06:23:16PM -0400, Matthias Felleisen wrote: > The naming consistency is good, but they aren't really consistent at > the signature or functionality level: > > string->number produces #f when called on "hello world" or "\0" > string->path fails on "\0" > string->url succeeds on "\0" and produces a url
... > Q: Would it be worth our while to comb through the libraries and make > the world consistent, even breaking backwards compatibility? I would > be willing to run such a project. I think you are asking whether an effort should be made to change existing function names so they better indicate the function signature. Besides the obvious backward-compatibility concerns, such an effort seems likely to be at cross-purposes with the separately stated goal of reducing the length of identifiers and making programs more concise. (Presumably if equally concise names that better reflected function signatures were available, they would have been used in the first place.) Though I haven't heard the talks you referenced, I agree that naming is very important. As you mention, the naming consistency in Racket is already good. (The quality of the function names is probably one of the things that drew me to Scheme.) The examples you mention point out problems with inputs that might be considered "edge cases". One might argue that these are the cases where it would be helpful for the name to give more information. On the other hand, such information might be harmful in that it reduces the abstraction level and increases the information that a developer reading the code must process. Basically, at some point, more information in the name is worse. Without suggestions of proposed name changes, I find it difficult to imagine names that are so much better in the area of expressing function signatures that they make up for these drawbacks. (non-compatibility, less abstract, longer, etc.) In addition, what alternative project would be postponed in order to run this one? David _________________________ Racket Developers list: http://lists.racket-lang.org/dev
