[racket-dev] consistency in names and signatures

Putting aside the 8 (yeah, really) ways to report errors in Haskell, this
is the option provided by the Maybe (data Maybe a = Something a | Nothing).
While I see many benefits to this approach, I think contracts may provide a
new way out. In most typed languages the major constraint seems to be that
types are checked at compile time and limited in complexity. Contracts,
however, have practically unlimited power. The trick is that one would have
to incorporate some way to reify the calculation checked by the contract.
If you could get a hold of the value produced by contract checking then no
duplicate computation would have to occur inside the function. This is
especially relevant for functions like string->number because the most
obvious implementation checks validity during parsing -- checking the
validity and parsing basically duplicate the function.

Also, if one sees a sort of "inner" function post-contract-check and an
outer function including the contract check then one could even term the
inner function as total and the outer function as partial.

The advantages of this approach, as far as I can see, are that it removes
large amounts of failure checking and it encourages large amounts of
precondition code to move into the contract. Not only is this good for
documentation and interfaces, but it helps with my current project (random
testing through contracts).

2c

Cheers,
Andy

On Tue, Mar 27, 2012 at 5:23 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120327/fe53e88a/attachment.html>