www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Component Programming in D

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

Andrei
Oct 02 2012
next sibling parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


John D. Cook mentions Walter's talk in his blog post at
http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100

I've posted a link to this article in the comments, but it's 
awaiting moderation.
Oct 02 2012
next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 2 October 2012 at 21:51:45 UTC, Rene Zwanenburg wrote:

 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
 wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


 John D. Cook mentions Walter's talk in his blog post at
 http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100

 I've posted a link to this article in the comments, but it's 
 awaiting moderation.


Oops, link should of course be
http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/
Oct 02 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/2/12, Rene Zwanenburg <renezwanenburg gmail.com> wrote:

 John D. Cook mentions Walter's talk in his blog post at
 http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100


He also mentions there might be a video coming up of the event. If
that's true, yay!

Nice article, too!
Oct 02 2012
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
On 10/2/2012 2:51 PM, Rene Zwanenburg wrote:

 John D. Cook mentions Walter's talk in his blog post at
 http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100


 I've posted a link to this article in the comments, but it's awaiting
 moderation.


I had dinner with John last night, we had a great time. His talk on the 
R programming language was right after mine.
Oct 02 2012
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


Nice article!
Oct 02 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/2/12 6:14 PM, Paulo Pinto wrote:

 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/


 Andrei


 Nice article!


I liked it the most of all I've read from Walter.

Andrei
Oct 02 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 03/10/2012 00:45, Andrei Alexandrescu a écrit :

 On 10/2/12 6:14 PM, Paulo Pinto wrote:

 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/



 Andrei


 Nice article!


 I liked it the most of all I've read from Walter.

 Andrei


Same here, this article is shared and loved as it must be !
Oct 02 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 02 Oct 2012 17:27:55 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
 


Excellent article!
Oct 02 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
 _d/


It's definitely the sort of article that we've needed to show what we're trying 
to do with ranges.

- Jonathan M Davis
Oct 02 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 03 Oct 2012 03:05:08 +0200
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:


 On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
 _d/


 
 It's definitely the sort of article that we've needed to show what
 we're trying to do with ranges.
 


Yes, and also why a lot of D's features, esp its metaprogramming
features, are so significant. And why most other languages, including
dynamic languages, don't even come close.

I think I'm starting to get a sense of the next big step, though. There
are other misc improvements I'd like to see, but I think the biggest
weakness our range approach faces now (even as far ahead as we are) is
the effort and, arguably, boilerplate to actually create the ranges.

Especially input/forward ranges: It's pretty well known and accepted
(esp. to those who have created input/forward ranges) that the easiest
way to make a generator is with a straight imperative function. But
ranges turn the whole logic inside-out. Walking a tree can get
particularly convoluted.

So I think the next *big* step from here, in D3 or some other D-derived
language, would be easing the creation of ranges. For example, a
special low-boilerplate syntax for creating bidirectional and
random-access ranges. Or for input (or maybe even forward) ranges, a

range (With input ranges, you can technically get around needing source
transformation right now in D2 using fibers, but that has too
much runtime overhead to be used as a general solution).
Oct 02 2012
parent reply "jerro" <a a.com> writes:
 So I think the next *big* step from here, in D3 or some other 
 D-derived
 language, would be easing the creation of ranges. For example, a
 special low-boilerplate syntax for creating bidirectional and
 random-access ranges. Or for input (or maybe even forward) 
 ranges, a

 into a
 range (With input ranges, you can technically get around 
 needing source
 transformation right now in D2 using fibers, but that has too
 much runtime overhead to be used as a general solution).


I don't think we need language support in order to have an easy 
way to create random access ranges. We could have a function that 
would be used like this:

auto squares = randomAccessRange(len, (size_t i) => i * i);

This probably wouldn't have optimal performance, but wouldn't be 
horribly slow either. Another option would be to have a mixin 
that would generate all other range methods from a method that 
would provide random access to the initial (that is, before the 
first call to popFront or popBack) range and a property that 
would return the length of the initial range.
Oct 02 2012
parent "jerro" <a a.com> writes:
On Wednesday, 3 October 2012 at 06:15:32 UTC, jerro wrote:

 So I think the next *big* step from here, in D3 or some other 
 D-derived
 language, would be easing the creation of ranges. For example, 
 a
 special low-boilerplate syntax for creating bidirectional and
 random-access ranges. Or for input (or maybe even forward) 
 ranges, a

 into a
 range (With input ranges, you can technically get around 
 needing source
 transformation right now in D2 using fibers, but that has too
 much runtime overhead to be used as a general solution).


 I don't think we need language support in order to have an easy 
 way to create random access ranges. We could have a function 
 that would be used like this:

 auto squares = randomAccessRange(len, (size_t i) => i * i);

 This probably wouldn't have optimal performance, but wouldn't 
 be horribly slow either. Another option would be to have a 
 mixin that would generate all other range methods from a method 
 that would provide random access to the initial (that is, 
 before the first call to popFront or popBack) range and a 
 property that would return the length of the initial range.


Never mind, I just realized that is what std.range.sequence 
already does.
Oct 02 2012
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


The article contains a bug due to the pernicious behaviour of 
seedless reduce.

This section:

Just to show how flexible algorithms can be, reduce can also 
compute multiple values with one pass through the data (which is 
pretty useful for streaming data and would be expensive to save 
for a second pass through it). Multiple lambdas produce a tuple 
result, here the sum and sum of squares is computed:

     int[] arr = [1,2,3,4,5];
     auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b);
     writefln("sum = %s, sum of squares = %s", r[0], r[1]);
Which prints: sum = 15, sum of squares = 55

That is the correct answer for the squares but only because 1*1 
is 1. The first element of a seedless reduce does not have any 
operation carried out on it.

If we change the array to [2,2,2,2,2] we would expect the squares 
sum to be 20. It's 18 because the seed element at arr[0] has no 
operation carried out on it.
Oct 02 2012
prev sibling next sibling parent reply "ixid" <nuaccount gmail.com> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


The article contains a bug due to the pernicious behaviour of 
seedless reduce.

This section:

"Just to show how flexible algorithms can be, reduce can also 
compute multiple values with one pass through the data (which is 
pretty useful for streaming data and would be expensive to save 
for a second pass through it). Multiple lambdas produce a tuple 
result, here the sum and sum of squares is computed:

     int[] arr = [1,2,3,4,5];
     auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b);
     writefln("sum = %s, sum of squares = %s", r[0], r[1]);

Which prints: sum = 15, sum of squares = 55"

That is the correct answer for the squares sum but only because 
1*1 is 1, what it's really doing here is 1 + (2 * 2) + (3 * 3) + 
(4 * 4) + (5 * 5) which happens to work in this case and for "a + 
b" and "a - b" but is otherwise broken. The first element of a 
seedless reduce does not have any operation carried out on it.

If we change the array to [2,2,2,2,2] we would expect the squares 
sum to be 20. It's 18 because the seed element at arr[0] has no 
operation carried out on it other than the addition of the other 
elements to it.
Oct 02 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ixid:


 The article contains a bug due to the pernicious behaviour of 
 seedless reduce.


Hopefully Walter will be able to fix the article.

Bye,
bearophile
Oct 03 2012
prev sibling parent reply "Martin Friesen" <mhfriesen shaw.ca> writes:
On Wednesday, 3 October 2012 at 01:40:05 UTC, ixid wrote:

 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
 wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


 The article contains a bug due to the pernicious behaviour of 
 seedless reduce.

 This section:

 "Just to show how flexible algorithms can be, reduce can also 
 compute multiple values with one pass through the data (which 
 is pretty useful for streaming data and would be expensive to 
 save for a second pass through it). Multiple lambdas produce a 
 tuple result, here the sum and sum of squares is computed:

     int[] arr = [1,2,3,4,5];
     auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b);
     writefln("sum = %s, sum of squares = %s", r[0], r[1]);

 Which prints: sum = 15, sum of squares = 55"

 That is the correct answer for the squares sum but only because 
 1*1 is 1, what it's really doing here is 1 + (2 * 2) + (3 * 3) 
 + (4 * 4) + (5 * 5) which happens to work in this case and for 
 "a + b" and "a - b" but is otherwise broken. The first element 
 of a seedless reduce does not have any operation carried out on 
 it.

 If we change the array to [2,2,2,2,2] we would expect the 
 squares sum to be 20. It's 18 because the seed element at 
 arr[0] has no operation carried out on it other than the 
 addition of the other elements to it.


Pernicious? Bug? I've never used D, but it looks obvious that 
arr.reduce does what it's compile time parameter promises with 
'a' as the "seed". It seems that using [0,1,2,3,4,5] or 
[0]~[1,2,3,4,5] or ([0]~arr).reduce! would have reflected a more 
general "sum of squares" idea simply enough.
Oct 03 2012
parent "rmr" <rmr mailinator.com> writes:
On Wednesday, 3 October 2012 at 19:11:55 UTC, Martin Friesen 
wrote:

 On Wednesday, 3 October 2012 at 01:40:05 UTC, ixid wrote:

 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei 
 Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei


 The article contains a bug due to the pernicious behaviour of 
 seedless reduce.

 This section:

 "Just to show how flexible algorithms can be, reduce can also 
 compute multiple values with one pass through the data (which 
 is pretty useful for streaming data and would be expensive to 
 save for a second pass through it). Multiple lambdas produce a 
 tuple result, here the sum and sum of squares is computed:

    int[] arr = [1,2,3,4,5];
    auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b);
    writefln("sum = %s, sum of squares = %s", r[0], r[1]);

 Which prints: sum = 15, sum of squares = 55"

 That is the correct answer for the squares sum but only 
 because 1*1 is 1, what it's really doing here is 1 + (2 * 2) + 
 (3 * 3) + (4 * 4) + (5 * 5) which happens to work in this case 
 and for "a + b" and "a - b" but is otherwise broken. The first 
 element of a seedless reduce does not have any operation 
 carried out on it.

 If we change the array to [2,2,2,2,2] we would expect the 
 squares sum to be 20. It's 18 because the seed element at 
 arr[0] has no operation carried out on it other than the 
 addition of the other elements to it.


 Pernicious? Bug? I've never used D, but it looks obvious that 
 arr.reduce does what it's compile time parameter promises with 
 'a' as the "seed". It seems that using [0,1,2,3,4,5] or 
 [0]~[1,2,3,4,5] or ([0]~arr).reduce! would have reflected a 
 more general "sum of squares" idea simply enough.


Alternatively:

     auto r = reduce!((a,b) => a + b, (a,b) => a + b * b) (0, arr);

Regards,
rmr
Oct 03 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/


Nice article!

There, I found an interesting way of writing ranges that are not 
explicitly initialized:

     private import core.stdc.stdio;

     struct StdinByChar {

	 property bool empty() {
	    if (hasChar)
		return false;
	    auto c = fgetc(stdin);
	    if (c == EOF)
		return true;
	    ch = cast(char)c;
	    hasChar = true;
	    return false;
	}

	 property char front() {
	    return ch;
         }

	void popFront() {
	    hasChar = false;
	}

       private:
	char ch;
	bool hasChar;
     }

This is unusual to me that popFront() code is shifted to empty(), but I 
guess that's necessary because structs doesn't have () ctors.
Oct 03 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Piotr Szturmaj wrote:

 guess that's necessary because structs doesn't have () ctors.


should be "don't"
Oct 03 2012
prev sibling parent reply "renoX" <renozyx gmail.com> writes:
I have some mixed feeling about component programming: add in all 
the examples the requirement to give the context (line number for 
example) where something happened (either a match or an error) 
and suddendly component programming becomes much more "tricky"!!

So for me component programming looks good on paper, but not so 
much in the real world..

renoX
Oct 03 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/03/2012 05:59 PM, renoX wrote:

 I have some mixed feeling about component programming: add in all the
 examples the requirement to give the context (line number for example)
 where something happened (either a match or an error) and suddendly
 component programming becomes much more "tricky"!!


Just zip the range with a range of context information, just as would be 
done with an explicit loop.


 So for me component programming looks good on paper, but not so much in
 the real world..

 renoX
Oct 03 2012
parent "renoX" <renozyx gmail.com> writes:
On Wednesday, 3 October 2012 at 21:40:06 UTC, Timon Gehr wrote:

 On 10/03/2012 05:59 PM, renoX wrote:

 I have some mixed feeling about component programming: add in 
 all the
 examples the requirement to give the context (line number for 
 example)
 where something happened (either a match or an error) and 
 suddendly
 component programming becomes much more "tricky"!!


 Just zip the range with a range of context information, just as 
 would be done with an explicit loop.


Yes, of course it's possible, but when you add filename, line 
numbers, column numbers (etc) the beautiful pipeline looks much 
less pretty..
Worse: each time you want to add some context, you have to modify 
the pipeline in a non-local way: take a -> b -> c -> d: you want 
to have more information in d from a's context, b and c must be 
modified to propagate the context..

When you have objects which encapsulate contexts, this becomes 
less an issue..

renoX


 So for me component programming looks good on paper, but not 
 so much in
 the real world..

 renoX
Oct 04 2012