Bug report 12652 reminded me of a topic that I brought up a while back, that I tried to incorporate into the Style Guide, and that I forgot to re-introduce here.
Background: a lot of people think that consistency in naming, signature/contract, and functionality (for methods and functions) is a key element to successful software projects. If you saw Yaron Minsky's talk at POPL or if you are in a department where he delivered his OCAML is great for trading talk, you know what I mean. He formulates this point well, and he gives good examples. Topic: In our world, we have functions such as string->number string->path string->url bytes->string/utf-8 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 I consider this less than desirable. I understand arguments for #f and exceptional behavior in an ML-style world. In a Racket/Lisp style world, I see the behavior of string->number as ideal. I get two behaviors in one function: (1) parsing in the spirit of formal languages (is this 'string' accepted by this 'machine') (2) translation in the case of success. One advantage of such total functions is of course that they are performant. The signatures/contracts are simple and their functionality is easy to figure out. A disadvantage is that they deepen our dependence on occurrence typing, but so what. I could also understand providing two versions of the function: string->path : String -> Path u False string->path/exn: String -> Path | effect: exn:fail:contract? 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. -- Matthias _________________________ Racket Developers list: http://lists.racket-lang.org/dev
