[erlang-questions] Static type checking...

[Steve Davis]

It's my experience that attempts at static type checks ends up in "turtles all the way down" and enormously onerous code.

So I'm thinking that Joe A had a very big deal point (beyond the design of UBF) with regard to UBF contracts?

Is this because, despite the limitations of records, what really lacks is some kind of way of expressing formal boundary checking?

I do know that RV expresses a liking for, and recommends, boundary checks (which work for me).

Is this validation "layer" really the missing link? Is it possible to find an enforcement for that (and not engage in strict typing)?

Throwing this out as my 2c,
/s
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Jesper Louis Andersen]

On Apr 30, 2013, at 2:40 AM, Steve Davis <steven.cha...@gmail.com> wrote:

> It's my experience that attempts at static type checks ends up in "turtles all the way down" and enormously onerous code.

Static typing, preferably with inference of the types, is a really nice tool for finding and killing bugs early. But interestingly, there is not that much formality when it comes to checking the *protocol* between two processes. Since Erlang processes are often simple internally, it becomes way more interesting to have a formal protocol checker to verify adherence. I don't care what you are doing internally in your process. You could write it in any language you desired, as long as you adhere to the protocol we laid out on top.

There is a similarity to having a signature on a module specifying a skeleton of how that code will execute type-wise.

There are two things needed with a validation layer:

It has to be effective. It needs to catch bugs. It needs to remove bugs before they wreak havoc on the system.

It has to be simple. We can't afford the layer to take up considerable human resources to specify a protocol contract. Otherwise, we end up wasting time. If you are going to pay time up-front, you better know that you find errors later on in the process. Otherwise, that time was just wasted.

Jesper Louis Andersen
Erlang Solutions Ltd., Copenhagen

[Steve Davis]

Thanks, Jesper, for the considered answer... I fully agree and support that you recognize the importance of protocol.

And given the problem, the interesting part is defining a boundary (which defines state, not just types) beyond which you should be able to assume good data or blow up.

Defining that boundary at every possible library point is onerous.

Static typing (compared to protocol contracts) does not account for state (which any process could potentially maintain)...

What to do? I wish I had the answer, i.e. an answer that was complete and beyond just an intent of solving that issue.

/s