June 17, 2012
On 06/17/2012 03:53 PM, Philippe Sigaud wrote:
> On Sun, Jun 17, 2012 at 3:11 PM, Guillaume Chatelet
> <chatelet.guillaume@gmail.com>  wrote:
>> On 06/17/12 14:23, Philippe Sigaud wrote:
>
>>> void main(){
>>>     auto a = constrained!(x =>  x>  0)(1);
>>>     auto b = a;
>>>     auto c = b+1;
>>>     auto d = c+a;
>>>     a = b-d; // Boom!
>>> }
>>
>> Very nice :)
>
> The new syntax for lambdas is delightful to use. A bunch of aliases
> should give you the X10 examples.
>
> x =>  ... still has some problem as it's a template, but using a
> standard module-level function gives functionalities akin to X10:
>
> bool pos(int x) { return x>  0;}
> alias Constrained!(int, pos) Positive; // works
>
> // alias Constrained!(int, (int x) { return x>  0;}) Positive; // works
> // alias Constrained!(int, (int x) =>  x>  0) Positive; // works
> // but:
> // alias Constrained!(int, (x) { return x>  0;}) Positive; // ka-boom!
> // alias Constrained!(int, x =>  x>  0) Positive; // no such luck
>

I have reported this bug a few days ago:
http://d.puremagic.com/issues/show_bug.cgi?id=8242

Apparently, Kenji Hara has already fixed it.
June 17, 2012
On 6/16/12 11:29 AM, Guillaume Chatelet wrote:
> On 06/16/12 17:58, bearophile wrote:
>> Guillaume Chatelet:
>>
>>> A minimalistic website maintains the concepts defined so far and the
>>> C++ code
>>> http://www.elementsofprogramming.com/
>>
>> That page looks quite interesting. I'll take a better look later (I have
>> not read that book).
>
> The website is more of a stopgap, the book is way better because it
> shows the paths from concepts to concepts. I should warn the book is not
> easy to read, it's hard and it hurts, but it's good hurt.

I'm surprised by such claims. I found EoP very easy to read.

Andrei
June 17, 2012
On 6/17/12 7:23 AM, Philippe Sigaud wrote:
> An obvious generalization is to template the struct on a predicate:
>
> struct Constrained(T, alias pred) {

Nice idea, but it should be said that making the predicate opaque prevents the implementer from taking advantage of its properties.

Andrei
June 17, 2012
On 06/17/12 18:41, Andrei Alexandrescu wrote:
> I'm surprised by such claims. I found EoP very easy to read.
> 
> Andrei

Ok let me restate this. First, those words are originally from Stepanov
himself "This is not an easy book" is explicitly written in the inner
cover :)
Then it's not a *difficult* book if you have a mathematical background -
any engineer degree would do - but if you came to programming from a
different path, you'd probably find it queasy. I don't expect anyone in
this forum to have this background thus the disclaimer but I may be
wrong. Moreover if you intend to read it the way it's planned by the
author (doing the exercises and proving the lemmas) it's not as fun as
reading TDPL. Let's say you need to think while reading, a bit like for
'Modern C++ design'. I hope these few lines gives a more comprehensive
view of what I meant and won't discourage anyone from reading it.
June 17, 2012
On 06/17/12 18:38, Andrei Alexandrescu wrote:
> 
> This is a good idea because the traits are useful within and outside the algorithms discussed in EoP.
> 
> However, I don't think we need to abide strictly to the nomenclature (e.g. some of the stuff in EoP was already defined with a different name) although some EoP names are more mathematicky (such as "Codomain" vs. "ReturnType"). One issue is when EoP goes off and defines its own terms such as "regular type", which is usually known as "value type". In fact, "regular type" means something completely different in PL research. EoP's terminology didn't catch up outside C++ and sometimes outside a small group within it.
> 
> If I'm allowed to venture an opinion on EoP itself, it's an interesting book but I don't find it as big or great as some of its fans believe. It's not breaking any new ground, instead it explores more along already well-trodden territory, and it fails to find new mother lodes. Some (many?) chapters (such as transformations and orbits) describe some self-important notions but fail to demonstrate their general applicability. Nevertheless, the code really is exquisitely written, and studying it has significantly changed my approach and style in implementing algorithms.
> 
> 
> Andrei

What would you recommend ?

Something more practical as Stroustrup and Sutton N3351's proposal : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf We can also get inspired by Sutton's origin project : http://code.google.com/p/origin
June 17, 2012
On Sun, Jun 17, 2012 at 6:39 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> // alias Constrained!(int, (x) { return x>  0;}) Positive; // ka-boom!
>> // alias Constrained!(int, x =>  x>  0) Positive; // no such luck
>>
>
> I have reported this bug a few days ago: http://d.puremagic.com/issues/show_bug.cgi?id=8242
>
> Apparently, Kenji Hara has already fixed it.

No wonder, it takes him about 23 minutes, on average, to fix bugs once they are reported :)

But, if he really fixed it (in the general case, lambda context botch and all), then he just corrected one of the most annoying bugs as far as I'm concerned. I hit it in every D project I have. Then I'll be, once more, forever grateful to Kenji Hara.
June 17, 2012
On 06/17/12 18:38, Andrei Alexandrescu wrote:
> However, I don't think we need to abide strictly to the nomenclature (e.g. some of the stuff in EoP was already defined with a different name) although some EoP names are more mathematicky (such as "Codomain" vs. "ReturnType"). One issue is when EoP goes off and defines its own terms such as "regular type", which is usually known as "value type". In fact, "regular type" means something completely different in PL research. EoP's terminology didn't catch up outside C++ and sometimes outside a small group within it.

Yes. As you noticed CoDomain is simply an alias to ReturnType.

The purpose of this thread was to measure the interest of the D community in going further in this direction. I thought it would be great to benefit from the work the C++ community has already done in this domain. Brilliant people are working on it for years and the more basic Concepts look stable now so it might be a good starting point.

My take on it is that Concept modeling improves in designing and extending complex generic libraries. As an example see the Generic Image Library (GIL) by Adobe and now part of Boost. http://stlab.adobe.com/gil/html/gildesignguide.html

Of course, the idioms being different, I was also looking for some feedback. I did ask myself what naming convention should be used considering some traits were already implemented as you pointed out. I sticked to the D _isXXXX_ convention instead of the plain CamelCase name. I was tempted to use a _hasValueSemantic_ traits (Concept) instead of _isRegular_. Also _isPure_ could replace _isFunctionalProcedure_. Basically this is just a proposal and everything can change at this point. I'm also not convinced we should add every single Concepts Stepanov is describing, we have to be pragmatic here.

So what do you think should be the next move ? Try to integrate those concepts within phobos ? try to add more of them ?

More comments are definitely welcome. Many thanks for everyones feedback.
June 18, 2012
On 6/17/12 4:47 PM, Guillaume Chatelet wrote:
> On 06/17/12 18:38, Andrei Alexandrescu wrote:
>> However, I don't think we need to abide strictly to the nomenclature
>> (e.g. some of the stuff in EoP was already defined with a different
>> name) although some EoP names are more mathematicky (such as "Codomain"
>> vs. "ReturnType"). One issue is when EoP goes off and defines its own
>> terms such as "regular type", which is usually known as "value type". In
>> fact, "regular type" means something completely different in PL
>> research. EoP's terminology didn't catch up outside C++ and sometimes
>> outside a small group within it.
>
> Yes. As you noticed CoDomain is simply an alias to ReturnType.
>
> The purpose of this thread was to measure the interest of the D
> community in going further in this direction. I thought it would be
> great to benefit from the work the C++ community has already done in
> this domain. Brilliant people are working on it for years and the more
> basic Concepts look stable now so it might be a good starting point.

That's great. On the other hand D is not C++, and it naturally fosters a different dynamics of idioms.

D has static if and restricted templates, which are the concept equivalent of lambda functions. That changes the play field considerably because in C++ the syntactic overhead of expressing any constraint is so high, the normal tendency is to name everything. In D, you only need to name things that are often used and relatively complex.

So I don't think copying the laundry list of C++ concepts is the best way to go, because some of those overcome insufficiencies that are obviated by D.

Nevertheless, a good design is a good design, and we could and should use is as inspiration.

> My take on it is that Concept modeling improves in designing and
> extending complex generic libraries. As an example see the Generic Image
> Library (GIL) by Adobe and now part of Boost.
> http://stlab.adobe.com/gil/html/gildesignguide.html
>
> Of course, the idioms being different, I was also looking for some
> feedback. I did ask myself what naming convention should be used
> considering some traits were already implemented as you pointed out. I
> sticked to the D _isXXXX_ convention instead of the plain CamelCase
> name.

I think either way is fine. One convention I tried to foster was to name all symbols that ultimately expand to values starting with a lowercase, e.g. isXXX or hasXXX, and symbols that ultimately yield non-values should start with an uppercase, e.g. Unsigned or Unqual.

> I was tempted to use a _hasValueSemantic_ traits (Concept) instead
> of _isRegular_.

I personally would love that. Honest I think isRegular is provincial. Just google for "regular type" to see what I mean.

> Also _isPure_ could replace _isFunctionalProcedure_.
> Basically this is just a proposal and everything can change at this
> point. I'm also not convinced we should add every single Concepts
> Stepanov is describing, we have to be pragmatic here.

Awesome, my thoughts above (written before I saw this paragraph) reflect the same view.

> So what do you think should be the next move ? Try to integrate those
> concepts within phobos ? try to add more of them ?
>
> More comments are definitely welcome. Many thanks for everyones feedback.

I think traits are something that we could add piecemeal, without a large proposal - just as pull requests. For each particular concept there should be 1-2 compelling examples in the documentation, enough to make a case that the notion being added is worthwhile.

For a simple example I'd like "arity" (I'm unclear whether it belongs in std.traits or std.functional). Sure, I could write ParameterTypeTuple!fun.length, but that's quite a roundabout way to go about it.


Andrei
June 18, 2012
16.06.2012 20:11, Walter Bright пишет:
> On 6/16/2012 8:26 AM, Guillaume Chatelet wrote:
>> And then we wonder why software is
>> notorious for being delivered late and full of bugs, while other
>> engineers routinely deliver finished bridges, automobiles, electrical
>> appliances, etc., on time and with only minor defects.
>
> I have a nit to pick with that statement, as a former mechanical
> engineer who has done professional mechanical designs and has taken
> apart a lot of others.
>
> Bridges, automobiles, electrical appliances, etc., are full of design
> errors.

You all probably know a canonical example, Tacoma Narrows Bridge:
http://www.youtube.com/watch?v=j-zczJXSxnw
Let's forgive its designers because it was the first such accident with bridge.

But in Russia we still (2010) have this:
http://www.youtube.com/watch?v=rVzYDIlBQ0w
And this bridge still works without rebuilding, but with attenuator now.


-- 
Денис В. Шеломовский
Denis V. Shelomovskij


June 22, 2012
On 06/18/12 04:18, Andrei Alexandrescu wrote:
> I think traits are something that we could add piecemeal, without a large proposal - just as pull requests. For each particular concept there should be 1-2 compelling examples in the documentation, enough to make a case that the notion being added is worthwhile.
> 
> For a simple example I'd like "arity" (I'm unclear whether it belongs in std.traits or std.functional). Sure, I could write ParameterTypeTuple!fun.length, but that's quite a roundabout way to go about it.
> 
> 
> Andrei

So here it is. A first very small patch to add arity to std.traits.

As you stated it could really go either in std.traits or std.functional. I chose to keep it in std.traits because std.functional is more about creating new functions of modifying existing ones whereas std.traits is about deducing properties.

Guillaume