On Thursday, 22 June 2017 at 00:27:38 UTC, Timon Gehr wrote:
On 21.06.2017 19:39, MysticZach wrote:
My counterargument to that is that it's possible that the
cognitive dissonance only occurs because of what people are
used to, rather than what is inherent to the syntax.
This is a purely philosophical distinction without empirical
basis.
Well I never experienced the dissonance myself, and was surprised
to find that others did experience it. I just thought my proposal
was a better syntax for `in` and `out` contracts.
Well my impression was that Walter liked it too, although I
could have misinterpreted his comment here:
http://forum.dlang.org/post/ogvt66$1bcp$1...@digitalmars.com
He is saying it is good that a DIP to improve contract syntax
/exists/. I agree with that.
It's really not clear what he meant. I guessed that the highest
probability of what he meant was that he actually liked the DIP,
as opposed to the mere fact that it _was_ a DIP. But as I already
said, I could have misinterpreted his comment. In the face of
lack of knowledge, it's a sign of wisdom to admit that one might
be wrong, I think.
If such an alternative checking system is utilized,
there should be a way to hook into the checking logic.
Improving the checking logic interface may solve at a higher
level the problem I'm trying to solve at a very low one, with
mere syntax changes, and it might be (is probably?) the best
way forward.
Your proposal does not solve this problem, and there is no need
for this DIP to do that.
The goal of this DIP, and the problem I'm trying to solve, is
"Improve Contract Usability." And for this, H.S. Teoh's proposal
is a very good one. But it still has a sticking point, which I
want to resolve, namely that it elevates the existing `assert`
functionality beyond the current requirement that one must
explicitly write `assert`, going so far as to imply it in the
grammar itself. But because of many complaints about the
limitations of the assert mechanism as it currently exists, I
would hesitate to install it into the grammar as the "One Chosen
Way" to bail out of contracts with the new syntax.
However, if the functioning of the `assert` mechanism were more
customizable, then it would be easier to entrust it, in my
opinion, with the "sacred responsibility" of being installed into
the grammar. H.S. Teoh's proposal would then stand on a firmer
foundation, and my initial proposed syntax would become the
inferior optionl. At that point, this DIP could be rewritten to
advocate his syntax instead. (I think it would be better to just
retain the number and title "DIP1009: Improve Contract Usability"
than to make a new one for the same issue. Other DIPs have
followed this pattern, where it was the goal and title that
remained the same, while the specifics changed.)
We are looking for a significant improvement. Otherwise, what's
the point? We need to justify the cost.
The intent of my proposal was to make a small improvement. The
cost (or so I thought, and may still believe) was also small.
Small improvements are still improvements. DIP1003 is an example
of this.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
The point of contracts is assigning blame by documenting
assumptions and guarantees. If something within the function
body crashes, it's ideally the fault of the function
implementation.
...
I like new as long as it is an improvement. This is not. Having
syntax subtrees that do not actually logically belong to their
parent in the grammar is awkward language design, especially if
they affect the parent's signature.
I'm still wondering what, in practice, the difference really is.
With existing syntax:
int fun(int a)
in { assert(a); } // 1
do {
assert(a); // 2
...
}
What will the compiler or programmer actually learn from 1 if it
violates that they won't learn from 2 if it violates? What is the
practical incentive for `in` contracts at all? All my new syntax
does is assume that there is in fact a difference between 1 and
2, and makes 1 easier to write, as:
int fun(int a) {
in assert(a); // 1
assert(a); // 2
...
}
As far as syntax subtrees not belonging to their parent, I can
see where the cognitive dissonance comes from. But it just
doesn't seem that bad to me, since contracts are always executed
as if they are sequential statements anyway. I would imagine that
new programmers who only ever encountered the new proposed syntax
would be surprised that the old syntax ever existed in the first
place, as it's so unnecessarily awkward.
But at this point, we might as well wait for more feedback from
other people.
