On Tuesday, 12 March 2013 at 16:28:14 UTC, Nick Sabalausky wrote:
> "Happy accidents" is nothing more than another way of saying "Shit
> fucked up, but by pure dumb luck there was no damage". It's an
> absolutely *terrible* thing to encourage and design for. You may as
> well just go dynamic all the way, a la ActionScript 2 or Python - it's
> all the same "let random things happen by accident and blindly hope it
> just happens to turn out correct" philosophy.
>
> Design-by-accident is an anti-pattern.
>
> To me more specific, the problem with duck typing is that it falsely
> assumes that name+signature uniquely defines semantics (which is
> clearly not a valid assumption). Avoiding accidental screwups under
> duck typing *is* feasible if there's only a few well-known duck types
> that are ever in play (ex: our entire list of available duck types is a
> handful of phobos-defined ranges and basically nothing else). But it
> does not scale: The likelihood of accidental fuckups is multiplied with
> each additional duck type in existence, with non-stdlib duck types
> carrying a greater "accidental fuck up" weight.

I thought about this a bit more, and I agree with the fundamental content of what you said.

The crux of the matter is that we can't specify new semantics with code. We can only specify new semantics through documentation. And compilers don't read documentations.

But, I think a good way to alleviate this problem would be to allow programmers to specify that two different concepts are in fact the same exact concept. Then two unrelated libraries could be made interoperable with each other.

Example:

There are two unrelated libraries, LibA and LibB.

Library LibA defines:
1) concept ConceptA { ... }
2) void functionA(ConceptA A)(A a) { ... }

Library LibB defines:
1) concept ConceptB { ... }
2) void functionB(ConceptB B)(B b) { ... }

The two concepts, ConceptA and ConceptB, specify the same exact concept (this can be verified only by reading their respective documentations). If the end user now creates a type which implements ConceptA:

struct MyStruct implements ConceptA { ... }

...then the problem is that instances of MyStruct can't be passed to functionB. But, if the end-user has a way to say that ConceptA is a synonym to ConceptB, then he can make the two libraries interoperable with each other and with his own types. E.g:

concept ConceptA = ConceptB; // make them synonymous

struct MyStruct implements ConceptA { ... }

MyStruct ms;
functionB(ms); // OK

If ConceptA and ConceptB have happened to use different function names for doing the same conceptual thing, then the end-user should also be able to specify which function names are synonymous with each other.

On Tuesday, 12 March 2013 at 16:59:41 UTC, H. S. Teoh wrote:
> On Tue, Mar 12, 2013 at 12:28:07PM -0400, Nick Sabalausky wrote:
>> On Tue, 12 Mar 2013 16:02:24 +0100
>> "TommiT" <tommitissari@hotmail.com> wrote:
>> 
>> > On Tuesday, 12 March 2013 at 13:44:35 UTC, Nick Sabalausky wrote:
>> > > On Tue, 12 Mar 2013 12:51:03 +0100
>> > > "TommiT" <tommitissari@hotmail.com> wrote:
>> > >
>> > >> On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
>> > >> > struct S1 implements A2 {
>> > >> >     void foo() { }
>> > >> >     void bar() { }
>> > >> > }
>> > >> 
>> > >> That's not good. Types shouldn't have to explicitly say that they implement a concept.
>> > >
>> > > I *strongly* disagree. A much as I love ranges (for example),
>> > > their duckiness is the one thing I consider to be a huge mistake.
>> > 
>> > The problem with having to explicitl specify that a type implements a certain concept, is the resulting strong coupling between the concept definition and the type. This prevents "happy accidents" like the following from happening:
>> > 
>> > Alice and Bob write libraries without knowing anything about each other or each other's code. Alice implements the following in her library:
>> > 
>> > concept IntegerLike {
>> >      ...
>> > }
>> > 
>> > void foo(IntegerLike N)(N n) { }
>> > 
>> > Bob implements the following in his library:
>> > 
>> > struct SafeInt {
>> >      ...
>> > }
>> > 
>> > Later Bob realizes that Alice has written this cool function foo which accepts his type SafeInt as an argument because SafeInt just so happens to fulfill the requirements of the IntegerLike concept defined in Alice's library.
>> > 
>> > Although, the majority of concepts should come from the standard library.
>> 
>> "Happy accidents" is nothing more than another way of saying "Shit
>> fucked up, but by pure dumb luck there was no damage". It's an
>> absolutely *terrible* thing to encourage and design for. You may as
>> well just go dynamic all the way, a la ActionScript 2 or Python - it's
>> all the same "let random things happen by accident and blindly hope it
>> just happens to turn out correct" philosophy.
>> 
>> Design-by-accident is an anti-pattern.
>> 
>> To me more specific, the problem with duck typing is that it falsely
>> assumes that name+signature uniquely defines semantics (which is
>> clearly not a valid assumption). Avoiding accidental screwups under
>> duck typing *is* feasible if there's only a few well-known duck types
>> that are ever in play (ex: our entire list of available duck types is
>> a handful of phobos-defined ranges and basically nothing else). But it
>> does not scale: The likelihood of accidental fuckups is multiplied
>> with each additional duck type in existence, with non-stdlib duck
>> types carrying a greater "accidental fuck up" weight.
>
> I see it from another perspective: I've had to deal with proprietary
> libraries that defined types that couldn't be used with a particular
> container type, just because the container type expects the item type to
> implement a particular interface, but it doesn't. But actually, it
> *does* have the requisite members to implement that interface; it just
> didn't *say* it implemented that interface. So there's the need for Yet
> Another Useless Java-style Wrapper Class just to work around this
> nonsense. Duck-typing solves this problem.
>
> Of course, full-out ducktyping has its own problems, like you said; but
> there needs to be a way of rewriting APIs such that you could say "type
> T doesn't implement interface I right now, but actually, if you rewrite
> T.A to T.X and T.B to T.Y, then T implements interface I just fine".
> Though with D, I suspect this may actually be possible via alias this:
>
> 	struct RewireInterface(T, Interface, Tuple!(string,string)... rewrites)
> 	{
> 		T t;
> 		alias t this;
> 		foreach (rewrite; rewrites) {
> 			alias rewrite[0] = rewrite[1];
> 		}
> 	}
>
> OK, maybe not. But the foreach could be replace with a suitable
> recursive template so that the generated aliases are at the top-level in
> RewireInterface. Probably some other hack is needed to work around the
> need for Tuple in the compile-time parameters, which I'm pretty sure DMD
> rejects right now. But assuming all this can be worked around, you could
> do something like this:
>
> 	struct StraitJacketedProprietaryItem {
> 		int propX() { ... }
> 		int propY() { ... }
> 	}
>
> 	concept MyInterface {
> 		int myX();
> 		int myY();
> 	}
>
> 	alias NonStraitJacketedItem = RewireInterface!(
> 		StraitJacketedProprietaryItem, MyInterface,
> 		"myX", "propX",
> 		"myY", "propY"
> 	);
>
> 	assert(NonStraitJacketedItem implements MyInterface);
>
> OK, lots of pseudo-code going on here, but you get the idea.
>
>
> T

D current compile time capabilities already allow this kind of stuff. I don't see concept as a good idea to introduce into D right now, but definitively something to look at for the future.

Just for complete information, the static_if feature isn't rejected but
discussion/effort on it is now delayed.
See minutes: http://isocpp.org/files/papers/N3576.pdf
My understanding is that focusing on concepts(-light) is a priority for
this working group now.

Walter was in the meeting so he got the details.

Joel Lamotte

On 13 March 2013 08:29, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:

> Just for complete information, the static_if feature isn't rejected but
> discussion/effort on it is now delayed.
> See minutes: http://isocpp.org/files/papers/N3576.pdf
> My understanding is that focusing on concepts(-light) is a priority for
> this working group now.
>
> Walter was in the meeting so he got the details.
>
>
Looking at the minutes, that was Walter Brown, not Bright.  Incase you got confused about the difference. ;)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 13 March 2013 at 14:06:33 UTC, Iain Buclaw wrote:
> On 13 March 2013 08:29, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
>
>> Just for complete information, the static_if feature isn't rejected but
>> discussion/effort on it is now delayed.
>> See minutes: http://isocpp.org/files/papers/N3576.pdf
>> My understanding is that focusing on concepts(-light) is a priority for
>> this working group now.
>>
>> Walter was in the meeting so he got the details.
>>
>>
> Looking at the minutes, that was Walter Brown, not Bright.  Incase you got
> confused about the difference. ;)

Are you saying that Walter Brown isn't bright ?

/me runaway

On 13 March 2013 14:12, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 13 March 2013 at 14:06:33 UTC, Iain Buclaw wrote:
>
>> On 13 March 2013 08:29, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
>>
>>  Just for complete information, the static_if feature isn't rejected but
>>> discussion/effort on it is now delayed.
>>> See minutes: http://isocpp.org/files/**papers/N3576.pdf<http://isocpp.org/files/papers/N3576.pdf>
>>> My understanding is that focusing on concepts(-light) is a priority for
>>> this working group now.
>>>
>>> Walter was in the meeting so he got the details.
>>>
>>>
>>>  Looking at the minutes, that was Walter Brown, not Bright.  Incase you
>> got
>> confused about the difference. ;)
>>
>
> Are you saying that Walter Brown isn't bright ?
>
> /me runaway
>

He's neither Black, Blue, or Bubblegum flavour either.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
> On 3/8/2013 5:19 PM, Brad Anderson wrote:
>> On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
>>>      Are they full of it? Has it caused the problems they mention
>>> in
>>> D?
>>
>> Well, the two guys with an alternative proposal (concepts-lite) seem to hate
>> static if (along with a third guy).
>>
>> There seems to be a lot of strawman arguments in this paper.
>
> Many of the criticisms in the paper are addressed by our positive experience with static if in D.

I think the hard-to-analyze argument is a good one.

I've created an enhancement for some analysis we could do without too much work:
http://d.puremagic.com/issues/show_bug.cgi?id=9715
(I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).

On 03/14/13 10:26, Don wrote:
> On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
>> On 3/8/2013 5:19 PM, Brad Anderson wrote:
>>> On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
>>>>      Are they full of it? Has it caused the problems they mention
>>>> in
>>>> D?
>>>
>>> Well, the two guys with an alternative proposal (concepts-lite) seem to hate
>>> static if (along with a third guy).
>>>
>>> There seems to be a lot of strawman arguments in this paper.
>>
>> Many of the criticisms in the paper are addressed by our positive experience with static if in D.
> 
> I think the hard-to-analyze argument is a good one.
> 
> I've created an enhancement for some analysis we could do without too much work:
> http://d.puremagic.com/issues/show_bug.cgi?id=9715
> (I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).
> 

The gain from such checks would be minimal. Eg "return x.toray;".

artur

On Thursday, 14 March 2013 at 11:04:59 UTC, Artur Skawina wrote:
> On 03/14/13 10:26, Don wrote:
>> On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
>>> On 3/8/2013 5:19 PM, Brad Anderson wrote:
>>>> On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
>>>>>      Are they full of it? Has it caused the problems they mention
>>>>> in
>>>>> D?
>>>>
>>>> Well, the two guys with an alternative proposal (concepts-lite) seem to hate
>>>> static if (along with a third guy).
>>>>
>>>> There seems to be a lot of strawman arguments in this paper.
>>>
>>> Many of the criticisms in the paper are addressed by our positive experience with static if in D.
>> 
>> I think the hard-to-analyze argument is a good one.
>> 
>> I've created an enhancement for some analysis we could do without too much work:
>> http://d.puremagic.com/issues/show_bug.cgi?id=9715
>> (I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).
>> 
>
> The gain from such checks would be minimal. Eg "return x.toray;".
>
> artur

I've already found plenty of such bugs in phobos, and wouldn't be surprised if this was one of its bigger sources of bugs.

Sure, phobos is template and static "super heavy", given it is more or less the D-STL, but still.

If the compiler can statically determine that a template branch simply *can't* compile, then the code should be turned down.

Having to instantiate a template just to check to make sure it is semantically correct is a huge pain.

Artur Skawina:

> The gain from such checks would be minimal. Eg "return x.toray;".

I think we have no statistics about how much gain that's going to give.

And even small improvement are good to have, if they are automatic (done by the compiler instead of the programmer), and if they have no false positives.

Once such checks are in place, it will be possible to add better checks and further improvements :-) So I think ER 9715 is a good idea.

Bye,
bearophile