Re: The Many Faces of D - slides
On 10/05/2010 02:42 AM, Walter Bright wrote: Max Samukha wrote: He said "movable using memcpy()". He didn't say anything about adjusting pointers. A moving GC should and will adjust pointers, but I don't see how the memcpy() is relevant here. The moving GC would adjust the pointers, but the memcpy() means that other things would not need to be done, such as incrementing counters, all the things that non-trivial copy constructors do. Now I see what you meant. Thanks for the explanation.
Re: The Many Faces of D - slides
Max Samukha wrote: He said "movable using memcpy()". He didn't say anything about adjusting pointers. A moving GC should and will adjust pointers, but I don't see how the memcpy() is relevant here. The moving GC would adjust the pointers, but the memcpy() means that other things would not need to be done, such as incrementing counters, all the things that non-trivial copy constructors do.
Re: The Many Faces of D - slides
Gary Whatmore Wrote: > Walter Bright Wrote: > > > Looks like it hit reddit: > > > > http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/ http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/c11d2ie There's a new tough comment that would make our efforts look amateurish if some reddit troll manages to answer it too quickly! - G.W.
Re: The Many Faces of D - slides
On 10/04/2010 10:47 PM, Simen kjaeraas wrote:
Max Samukha wrote:
On 10/03/2010 10:47 PM, Walter Bright wrote:
In D, all struct (and class) instances are, by definition, movable using
memcpy().
Structs are ok. Classes are not. Do you really want to forbid this use
case:
class A
{
private A _parent;
private A[] _children;
this(A parent)
{
if (parent !is null) {
_parent = parent;
_parent._children ~= this;
}
}
}
auto parent = new A;
auto child = new A(parent);
?
I don't see how that is incompatible with what Walter said. Of course
one would need to update pointers to the moved classes.
He said "movable using memcpy()". He didn't say anything about adjusting
pointers. A moving GC should and will adjust pointers, but I don't see
how the memcpy() is relevant here.
Re: The Many Faces of D - slides
Max Samukha wrote:
On 10/03/2010 10:47 PM, Walter Bright wrote:
In D, all struct (and class) instances are, by definition, movable using
memcpy().
Structs are ok. Classes are not. Do you really want to forbid this use
case:
class A
{
private A _parent;
private A[] _children;
this(A parent)
{
if (parent !is null) {
_parent = parent;
_parent._children ~= this;
}
}
}
auto parent = new A;
auto child = new A(parent);
?
I don't see how that is incompatible with what Walter said. Of course
one would need to update pointers to the moved classes.
--
Simen
Re: The Many Faces of D - slides
On 10/03/2010 10:47 PM, Walter Bright wrote:
In D, all struct (and class) instances are, by definition, movable using
memcpy().
Structs are ok. Classes are not. Do you really want to forbid this use case:
class A
{
private A _parent;
private A[] _children;
this(A parent)
{
if (parent !is null) {
_parent = parent;
_parent._children ~= this;
}
}
}
auto parent = new A;
auto child = new A(parent);
?
Re: The Many Faces of D - slides [ot]
Justin Johansson wrote: On 4/10/2010 6:35 AM, Walter Bright wrote: Justin Johansson wrote: May I ask Walter if, as coming away from the meeting, you felt that there might be converts (to D) amongst this group? I can say it was a very friendly and engaging audience, and they asked good questions. Congrats. Sounds like speaker and audience alike enjoyed the talk. Intriguingly, the audience showed a lot of interest in D's scripting capabilities (thanks, Andrei!).
Re: The Many Faces of D - slides
Peter Alexander wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
This works:
import std.stdio;
import std.algorithm;
alias reduce!"a+b" sum;
auto sumOfSquares( R )( R range ) {
return sum( map!"a*a"( range ) );
}
void main()
{
writeln(sumOfSquares([1,2,3]));
}
But then this doesn't:
Darn!
int[] xs = [];
writeln(sum(xs));
but mathematically the sum is well-defined as 0 (and the product as 1).
Re: The Many Faces of D - slides
Hello bearophile, Russel Winder: I continue to be intrigued by people who believe that code, unlike text, is more readable in a monospace font. Personally I think monospace fonts make code unreadable,< I guess it's a matter of personal preferences. But non-proportional fonts have two advantages: - it's easy to count spaces, vertical alignments and so on; Bingo. While it might be possible to make a single line of code in proportional font as readable as in mon-space, as soon as you have more than one line you can't make things line up, and I want that way to often to give it up. def sumOfSquares (sequence): return sum(item * item for item in sequence) I have suggested few times a list/lazy comp syntax for D too, and I have tried to explain why it's a good thing (it helps "chunking" in the mind of the programmer). I believe that you can do it via map/reduce. -- ... <
Re: The Many Faces of D - slides
Simen kjaeraas wrote:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
This can be defined instead as:
alias reduce!"a+b" sum;
Re: The Many Faces of D - slides
Peter Alexander wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
This can be defined instead as:
alias reduce!"a+b" sum;
But then you have to write:
sum(sequence, 0)
which is very unintuitive.
This works:
import std.stdio;
import std.algorithm;
alias reduce!"a+b" sum;
auto sumOfSquares( R )( R range ) {
return sum( map!"a*a"( range ) );
}
void main()
{
writeln(sumOfSquares([1,2,3]));
}
Re: The Many Faces of D - slides [ot]
On 4/10/2010 6:35 AM, Walter Bright wrote: Justin Johansson wrote: May I ask Walter if, as coming away from the meeting, you felt that there might be converts (to D) amongst this group? I can say it was a very friendly and engaging audience, and they asked good questions. Congrats. Sounds like speaker and audience alike enjoyed the talk.
Re: The Many Faces of D - slides
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> This works:
> import std.stdio;
> import std.algorithm;
> alias reduce!"a+b" sum;
> auto sumOfSquares( R )( R range ) {
> return sum( map!"a*a"( range ) );
> }
> void main()
> {
> writeln(sumOfSquares([1,2,3]));
> }
But then this doesn't:
int[] xs = [];
writeln(sum(xs));
but mathematically the sum is well-defined as 0 (and the product as 1).
Re: The Many Faces of D - slides
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> This can be defined instead as:
> alias reduce!"a+b" sum;
But then you have to write:
sum(sequence, 0)
which is very unintuitive.
Haskell has foldl1 and foldr1 in addition to foldl and foldr, which partially
take care of this issue (by
assuming a non-zero length list), but this is not ideal as it's perfectly
reasonable to expect a sum of a
zero-length range of integers to be 0.
In an ideal world, we would be able to define reduce something like:
auto reduce(alias Func, Range)(Range range, ElementType!Range init =
Identity!(Func,
ElementType!Range))
where
Identity!("a+b", int) = 0
Identity!("a*b", int) = 1
Identity!("a~b", char[]) = "";
etc.
However, what if people wrote reduce!((a, b) { return a+b; })(...) instead?
There's no way you could
easily relate the two; you would have to try and equate the expression trees of
the functions, which I
imagine would be no easy task, and even then you have to figure out a common
syntax for Identity...
Actually, I'm now curious as to how Andrei plans on adding sum to the standard
library in a way that
supports all summable types. Simply using 0 as the initialiser is incorrect, as
it won't work for vectors
or matrices, and requiring the user to specify the 0 (for ints) seems
unacceptable in my opinion.
Re: The Many Faces of D - slides [ot]
> Heh, I'm still using OpenOffice 1.1 just because it doesn't have those > terribly ugly menubar/toolbar gradients (an old screenshot I used to > demonstrate it to the boneheaded OOO developers who tried to tell me that it > was just my system and not OpenOffice: > http://www.semitwist.com/download/OpenOfficeVisualCompare.jpg They ended up > ignoring it.) I know that's a really trivial reason, but I haven't had any > problems with 1.1, so I've had no real reason to upgrade either. Nick OpenOffice (at least version 3.2 that I have on my Ubuntu box), picks up the menu and toolbar styling from your Desktop theme. And I am using the Gnome Desktop. Well, I am also trying to tell you that it might be just your system :-) Regards - Puneet
Re: The Many Faces of D - slides
Walter Bright Wrote: > Looks like it hit reddit: > > http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/ Their already criticizing D. We must defend ourselves. - G.W.
Re: The Many Faces of D - slides
Andrei Alexandrescu wrote:
assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ), [2,6,10]
) );
assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
}
I wonder to what extent this improves
assert(equal(map!"2 * a"(filter!"a & 1"([1,2,3,4,5])), [2,6,10]));
One thing that's nicer with comprehensions is that you save a bit on
nested parens.
In my opinion, it improves it by looking more like math language (with
which I am familiar, but this is of course a subjective measure):
( list!"2 * a" | [ 1, 2, 3, 4, 5 ] & where!"a & 1" )
vs
{ 2 * a | a ∈ [ 1, 2, 3, 4, 5 ], a & 1 != 0 }
I also feel it is less cluttered and 'flows' better than your example,
but this may very well be the same issue as above.
--
Simen
Re: The Many Faces of D - slides
Peter Alexander wrote:
It would be nice if we could just write:
assert(equal(iota(1,6).filter!("a&1").map!("2*a"), [2,6,10]));
Incidentally, why doesn't the uniform function call syntax allow this?
Mostly because it isn't implemented yet, I think. Well, it is for arrays,
but not for any other type, like the lazier ranges returned from iota,
filter and map.
--
Simen
Re: The Many Faces of D - slides
Looks like it hit reddit: http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/
Re: The Many Faces of D - slides
On Sunday 03 October 2010 16:05:19 Walter Bright wrote: > I also think you're way, way overstating your case when you argue that the > only language D is grammatically similar to is C and C++. It's also > similar to Java and C#, and when you combine the users of C, C++, Java, > and C# you're probably covering 90+% of the programmers out there. That's > a feature, not something sad. Oh course it's sad. That 90% should be using D instead. ;) - Jonathan M Davis
Re: The Many Faces of D - slides
retard wrote: Is this also true for Haskell/OCaml/SML/Erlang/Clojure/Lisp programmers? Nothing new to learn when using the "functional" features of D? Does TCO work well? Other common optimizations such as common deforestation techniques? The sad fact is, there's no need to learn new stuff ONLY when one comes from C/C++. Users of every other language have very much to learn. Not necessarily in a good way. If they're already using D, they don't have to learn a totally new grammar/style when deciding to use a functional style. Really, *why* force people to rewrite their loops to use tail recursion? It's a giant turn-off, and completely unnecessary. And D does do tail call elimination, if you *want* to write your code that way. The point is, D doesn't require it if you don't like it. I also think you're way, way overstating your case when you argue that the only language D is grammatically similar to is C and C++. It's also similar to Java and C#, and when you combine the users of C, C++, Java, and C# you're probably covering 90+% of the programmers out there. That's a feature, not something sad.
Re: The Many Faces of D - slides
On Mon, Oct 4, 2010 at 12:44 AM, retard wrote: > Sun, 03 Oct 2010 12:43:07 -0700, Walter Bright wrote: >> It's like what's wrong with C++ metaprogramming - you have to learn a >> whole new language. D metaprogramming can be done using ordinary D >> functions. Nothing new to learn. > > Is this also true for Haskell/OCaml/SML/Erlang/Clojure/Lisp programmers? > Nothing new to learn when using the "functional" features of D? Does TCO > work well? Other common optimizations such as common deforestation > techniques? The sad fact is, there's no need to learn new stuff ONLY when > one comes from C/C++. Users of every other language have very much to > learn. Not necessarily in a good way. > If you're gonna use the "functional features" in D you'll want to learn "normal" D and its syntax anyway, so what's your point?
Re: The Many Faces of D - slides
Sun, 03 Oct 2010 12:43:07 -0700, Walter Bright wrote: > Russel Winder wrote: >> On Sun, 2010-10-03 at 09:59 -0400, bearophile wrote: >>> Page 20: is that functional? It even contains a mutable "sum" value. >>> It may be seen as kind-of-functional. A more functional style is to >>> use a reduce (fold) there, from std.algorithm. >> >> I agree this is a weird sort of an example of "functional". >> sum_of_squares as a function has no external side-effects (though >> clearly the iteration has a side effect internally) and is >> referentially transparent. So as a thing that can be used as a >> "functional programming" function it is fine, its implementation is >> though very much imperative programming -- at its worst ;-) >> >> Given an imperative language with no tail recursion capability then one >> has to declare a non-functional floor even when doing functional style >> programming. In effect the execution graph has to be allowed to have >> leaqf nodes that are implemented imperatively. >> > > This is quite deliberate on my part, and I'm glad it piqued your > interest. D's support for functional programming is NOT about all data > being immutable. It is about being able to draw a circle around a block > of code (i.e. a function) and saying that "THIS block of code has no > side effects." If it modifies variables internally that is of no import > if those modifications are not visible outside of that block. > > This is, in my not so humble opinion, of great value in that one does > NOT have to rethink one's approach to coding in order to gain the > advantages of functional programming. I.e. one can write a normal loop > such as the sum one, rather than trying to figure out list > comprehensions and tail recursion. > > It's like what's wrong with C++ metaprogramming - you have to learn a > whole new language. D metaprogramming can be done using ordinary D > functions. Nothing new to learn. Is this also true for Haskell/OCaml/SML/Erlang/Clojure/Lisp programmers? Nothing new to learn when using the "functional" features of D? Does TCO work well? Other common optimizations such as common deforestation techniques? The sad fact is, there's no need to learn new stuff ONLY when one comes from C/C++. Users of every other language have very much to learn. Not necessarily in a good way.
Re: The Many Faces of D - slides [ot]
Sun, 03 Oct 2010 16:46:19 -0400, Nick Sabalausky wrote: > "retard" wrote in message > news:i89npm$ts...@digitalmars.com... >> Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote: >> >>> The slides for my Sep. 15 talk at NWCPP: >>> >>> http://nwcpp.org/images/stories/nwcpp-2010-09.pdf >> >> On a side note, I noticed that Walter is still using OpenOffice 2.4 >> from March 2008. 9 new releases have been announced after that :-) I >> doubt it has any effect on these slides, but the latest versions might >> offer better user experience. > > Heh, I'm still using OpenOffice 1.1 just because it doesn't have those > terribly ugly menubar/toolbar gradients (an old screenshot I used to > demonstrate it to the boneheaded OOO developers who tried to tell me > that it was just my system and not OpenOffice: > http://www.semitwist.com/download/OpenOfficeVisualCompare.jpg They ended > up ignoring it.) I know that's a really trivial reason, but I haven't > had any problems with 1.1, so I've had no real reason to upgrade either. This is what OpenOffice 3.2.1 looks like [on Linux] (sorry for having a bit larger resolution): http://www.freeimagehosting.net/image.php?72b470923c.png Last time I heard, the next OpenOffice/LibreOffice might switch to the ribbon style, though. The more recent versions have lots of new features. For example compatibility with the unholy office xml formats is much better.
Re: The Many Faces of D - slides [ot]
"retard" wrote in message news:i89npm$ts...@digitalmars.com... > Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote: > >> The slides for my Sep. 15 talk at NWCPP: >> >> http://nwcpp.org/images/stories/nwcpp-2010-09.pdf > > On a side note, I noticed that Walter is still using OpenOffice 2.4 from > March 2008. 9 new releases have been announced after that :-) I doubt it > has any effect on these slides, but the latest versions might offer > better user experience. Heh, I'm still using OpenOffice 1.1 just because it doesn't have those terribly ugly menubar/toolbar gradients (an old screenshot I used to demonstrate it to the boneheaded OOO developers who tried to tell me that it was just my system and not OpenOffice: http://www.semitwist.com/download/OpenOfficeVisualCompare.jpg They ended up ignoring it.) I know that's a really trivial reason, but I haven't had any problems with 1.1, so I've had no real reason to upgrade either.
Re: The Many Faces of D - slides
Michel Fortin wrote: On 2010-10-03 09:59:16 -0400, bearophile said: Page 19: Unlike C++, values can be moved in memory Postblit is used to “adjust” things after a move< OK, so a moving GC needs to call the Postblit each time it moves a struct. But isn't postblit used only when doing a copy? I think the last word in the quote should be "copy", not "move". So a moving GC does not have to call postblit. Right. In D, all struct (and class) instances are, by definition, movable using memcpy(). The advantage is not just enabling a moving GC, but it also enables a whole host of optimizations that are not possible in C++. C++0x tries to address this problem with rvalue references and moving constructors.
Re: The Many Faces of D - slides
Russel Winder wrote: On Sun, 2010-10-03 at 09:59 -0400, bearophile wrote: Page 20: is that functional? It even contains a mutable "sum" value. It may be seen as kind-of-functional. A more functional style is to use a reduce (fold) there, from std.algorithm. I agree this is a weird sort of an example of "functional". sum_of_squares as a function has no external side-effects (though clearly the iteration has a side effect internally) and is referentially transparent. So as a thing that can be used as a "functional programming" function it is fine, its implementation is though very much imperative programming -- at its worst ;-) Given an imperative language with no tail recursion capability then one has to declare a non-functional floor even when doing functional style programming. In effect the execution graph has to be allowed to have leaqf nodes that are implemented imperatively. Coming from a Pythonic realization of these ideas, list comprehensions seems to be the best way out of this sort of thing, so instead of: def sumOfSquares ( sequence ) : sum = 0.0 for item in sequence : sum += item * item return sum it is better to write: def sumOfSquares ( sequence ) : return sum ( [ item * item for item in sequence ] ) So the question is whether there is an idiomatic D version of this. This is quite deliberate on my part, and I'm glad it piqued your interest. D's support for functional programming is NOT about all data being immutable. It is about being able to draw a circle around a block of code (i.e. a function) and saying that "THIS block of code has no side effects." If it modifies variables internally that is of no import if those modifications are not visible outside of that block. This is, in my not so humble opinion, of great value in that one does NOT have to rethink one's approach to coding in order to gain the advantages of functional programming. I.e. one can write a normal loop such as the sum one, rather than trying to figure out list comprehensions and tail recursion. It's like what's wrong with C++ metaprogramming - you have to learn a whole new language. D metaprogramming can be done using ordinary D functions. Nothing new to learn.
Re: The Many Faces of D - slides
> Page 30: that little concurrent test program gives me an error:
> ...\dmd\src\phobos\std\typecons.d(336): Error: no property 'length' for type
> 'immutable(char)'
A reduced test case:
import std.concurrency: spawn, send;
void foo() {}
void main() {
foreach (b; [cast(immutable(ubyte)[])[1]])
send(spawn(&foo), b);
}
Bye,
bearophile
Re: The Many Faces of D - slides
bearophile wrote: Page 10, and in other pages I'd like a non-proportional font for the code, because I find it a little more readable (even better if it's colorized, there are online tools able to produce colorized HTML from D1 code too). I normally prefer monospaced fonts for code, but using a proportional font here made it easier to fit more code on the slide. Presenting meaningful code on a slide is always a big problem.
Re: The Many Faces of D - slides [ot]
Justin Johansson wrote: May I ask Walter if, as coming away from the meeting, you felt that there might be converts (to D) amongst this group? I can say it was a very friendly and engaging audience, and they asked good questions.
Re: The Many Faces of D - slides [ot]
retard wrote: On a side note, I noticed that Walter is still using OpenOffice 2.4 from March 2008. 9 new releases have been announced after that :-) I doubt it has any effect on these slides, but the latest versions might offer better user experience. The last time I upgraded Ubuntu it destroyed all the installed software, all my vmware subsystems, etc. I had to wipe the hard disk, reformat, and start over. Since then, I've been reluctant to upgrade.
Re: The Many Faces of D - slides
Emil Madsen wrote: Interesting, would have loved to be there :) It was actually one of the most fun ones I've done. The audience was very engaging.
Re: The Many Faces of D - slides [ot]
retard wrote: > Sun, 03 Oct 2010 11:00:43 -0500, Andrei Alexandrescu wrote: > >> On 10/03/2010 06:57 AM, Russel Winder wrote: >>> On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote: [ . . . ] I just use latex for everything. That way I can use vim. It's much more pleasant that way. >>> >>> Also you can put the material into version control since the source is >>> mergeable -- unlike OOo files. >>> >>> Sadly though LaTeX, even with the beamer package, just isn't up to >>> doing what is easy with OOo. >> >> I agree, though I'd also add that the likes of PowerPoint don't make it >> easy to create good presetations. In PowerPoint et al you are forced to >> focus on a flat structure that gets you boggled in details. For example >> it's trivial in PowerPoint to move slides around, which should be rare >> and odd in a well-conceived presentation. However imparting hierarchy to >> a presentation is not a feature. >> >> Though a text-based presentation engine does not help with structure >> either, at least it doesn't stay in the way. > > LyX (lyx.org) provides an alternative with WYSIWYM GUI and TeX export > (LyX is very close to LaTeX). The only problem is, embedded TeX code > blocks sometimes do not work and sometimes LyX stumbles into parsing bugs > or fails to produce valid LaTeX for the backend. If I have to choose > between the real PowerPoint and OpenOffice Impress, PowerPoint beats > OpenOffice hands down. I have good experience with making a presentation with Lyx, even starting with almost zero knowledge of Latex. Some things with beamer you get for free are more cumbersome to do with PP / Impress.
Re: The Many Faces of D - slides
On 2010-10-03 09:59:16 -0400, bearophile said: Page 19: Unlike C++, values can be moved in memory Postblit is used to adjust things after a move< OK, so a moving GC needs to call the Postblit each time it moves a struct. But isn't postblit used only when doing a copy? I think the last word in the quote should be "copy", not "move". So a moving GC does not have to call postblit. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: The Many Faces of D - slides
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 10/03/2010 10:21 AM, Simen kjaeraas wrote:
> > unittest {
> > assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ), [2,6,10]
> > ) );
> > assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
> > }
> I wonder to what extent this improves
> assert(equal(map!"2 * a"(filter!"a & 1"([1,2,3,4,5])), [2,6,10]));
> One thing that's nicer with comprehensions is that you save a bit on
> nested parens.
> Andrei
It would be nice if we could just write:
assert(equal(iota(1,6).filter!("a&1").map!("2*a"), [2,6,10]));
Incidentally, why doesn't the uniform function call syntax allow this?
Re: The Many Faces of D - slides
On 10/03/2010 10:21 AM, Simen kjaeraas wrote:
Simen kjaeraas wrote:
Russel Winder wrote:
def sumOfSquares ( sequence ) :
return sum ( [ item * item for item in sequence ] )
So the question is whether there is an idiomatic D version of this.
Probably this:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
auto sumOfSquares( R )( R range ) {
return sum( map!"a*a"( range ) );
}
I have written an implementation of list
comprehensions for D, but it is not perfect.
Usage example:
( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" )
"2 * a" and "a & 1" may be replaced by any callable or a string
mixin, just like functions in std.algorithm.
[1,2,3,4,5] may be replaced with any range.
This is actually two parts, so the following are also allowed
usages:
( list!"2 * a" | [1,2,3] )
( [1,2,3] & where!"a & 1" )
Using this, the solution to the above would be:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
auto sumOfSquares( R )( R range ) {
return sum( list!"a*a" | range );
}
Sorry, code was wrong. Update:
module listcomp;
import std.algorithm;
import std.range;
import std.array;
struct List( alias pred ) {
auto opBinary( string op : "|", Range )( Range other ) {
return map!pred(other);
}
}
struct Where( alias pred ) {
auto opBinaryRight( string op : "&", R )( R range ) {
return filter!pred(range);
}
}
@property
auto where( alias pred )( ) {
Where!pred result;
return result;
}
@property
auto list( alias pred )( ) {
List!pred result;
return result;
}
unittest {
assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ), [2,6,10]
) );
assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
}
I wonder to what extent this improves
assert(equal(map!"2 * a"(filter!"a & 1"([1,2,3,4,5])), [2,6,10]));
One thing that's nicer with comprehensions is that you save a bit on
nested parens.
Andrei
Re: The Many Faces of D - slides [ot]
Sun, 03 Oct 2010 11:00:43 -0500, Andrei Alexandrescu wrote: > On 10/03/2010 06:57 AM, Russel Winder wrote: >> On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote: [ . . . ] >>> I just use latex for everything. That way I can use vim. It's much >>> more pleasant that way. >> >> Also you can put the material into version control since the source is >> mergeable -- unlike OOo files. >> >> Sadly though LaTeX, even with the beamer package, just isn't up to >> doing what is easy with OOo. > > I agree, though I'd also add that the likes of PowerPoint don't make it > easy to create good presetations. In PowerPoint et al you are forced to > focus on a flat structure that gets you boggled in details. For example > it's trivial in PowerPoint to move slides around, which should be rare > and odd in a well-conceived presentation. However imparting hierarchy to > a presentation is not a feature. > > Though a text-based presentation engine does not help with structure > either, at least it doesn't stay in the way. LyX (lyx.org) provides an alternative with WYSIWYM GUI and TeX export (LyX is very close to LaTeX). The only problem is, embedded TeX code blocks sometimes do not work and sometimes LyX stumbles into parsing bugs or fails to produce valid LaTeX for the backend. If I have to choose between the real PowerPoint and OpenOffice Impress, PowerPoint beats OpenOffice hands down.
Re: The Many Faces of D - slides [ot]
On 10/03/2010 06:57 AM, Russel Winder wrote: On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote: [ . . . ] I just use latex for everything. That way I can use vim. It's much more pleasant that way. Also you can put the material into version control since the source is mergeable -- unlike OOo files. Sadly though LaTeX, even with the beamer package, just isn't up to doing what is easy with OOo. I agree, though I'd also add that the likes of PowerPoint don't make it easy to create good presetations. In PowerPoint et al you are forced to focus on a flat structure that gets you boggled in details. For example it's trivial in PowerPoint to move slides around, which should be rare and odd in a well-conceived presentation. However imparting hierarchy to a presentation is not a feature. Though a text-based presentation engine does not help with structure either, at least it doesn't stay in the way. Andrei
Re: The Many Faces of D - slides [ot]
Justin Johansson Wrote: > On 3/10/2010 10:01 PM, retard wrote: > > Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote: > > > >> The slides for my Sep. 15 talk at NWCPP: > >> > >> http://nwcpp.org/images/stories/nwcpp-2010-09.pdf > > > > On a side note, I noticed that Walter is still using OpenOffice 2.4 from > > March 2008. 9 new releases have been announced after that :-) I doubt it > > has any effect on these slides, but the latest versions might offer > > better user experience. > > Ahh, while that is a polite observation, it is not (to me at least) very > interesting. What would be more interesting is some indication of > interest to take up D as a PL from this (C++) audience***. > > *** http://www.nwcpp.org/ > > May I ask Walter if, as coming away from the meeting, you felt > that there might be converts (to D) amongst this group? I bet all democrats and friends of heavier music like me enjoyed it :)
Re: The Many Faces of D - slides
Simen kjaeraas:
> auto sum( R )( R range ) {
> return reduce!"a+b"( 0, range );
> }
Summing an iterable is a really common operation, and using reduce is not an
intuitive&easy thing. So I think a sum() needs to be added to std.algorithm,
this was my enhancement request for it:
http://d.puremagic.com/issues/show_bug.cgi?id=4725
Bye,
bearophile
Re: The Many Faces of D - slides
Simen kjaeraas wrote:
Russel Winder wrote:
def sumOfSquares ( sequence ) :
return sum ( [ item * item for item in sequence ] )
So the question is whether there is an idiomatic D version of this.
Probably this:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
auto sumOfSquares( R )( R range ) {
return sum( map!"a*a"( range ) );
}
I have written an implementation of list
comprehensions for D, but it is not perfect.
Usage example:
( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" )
"2 * a" and "a & 1" may be replaced by any callable or a string
mixin, just like functions in std.algorithm.
[1,2,3,4,5] may be replaced with any range.
This is actually two parts, so the following are also allowed
usages:
( list!"2 * a" | [1,2,3] )
( [1,2,3] & where!"a & 1" )
Using this, the solution to the above would be:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
auto sumOfSquares( R )( R range ) {
return sum( list!"a*a" | range );
}
Sorry, code was wrong. Update:
module listcomp;
import std.algorithm;
import std.range;
import std.array;
struct List( alias pred ) {
auto opBinary( string op : "|", Range )( Range other ) {
return map!pred(other);
}
}
struct Where( alias pred ) {
auto opBinaryRight( string op : "&", R )( R range ) {
return filter!pred(range);
}
}
@property
auto where( alias pred )( ) {
Where!pred result;
return result;
}
@property
auto list( alias pred )( ) {
List!pred result;
return result;
}
unittest {
assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ),
[2,6,10] ) );
assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
}
--
Simen
Re: The Many Faces of D - slides
Russel Winder wrote:
def sumOfSquares ( sequence ) :
return sum ( [ item * item for item in sequence ] )
So the question is whether there is an idiomatic D version of this.
Probably this:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
auto sumOfSquares( R )( R range ) {
return sum( map!"a*a"( range ) );
}
I have written an implementation of list
comprehensions for D, but it is not perfect.
Usage example:
( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" )
"2 * a" and "a & 1" may be replaced by any callable or a string
mixin, just like functions in std.algorithm.
[1,2,3,4,5] may be replaced with any range.
This is actually two parts, so the following are also allowed
usages:
( list!"2 * a" | [1,2,3] )
( [1,2,3] & where!"a & 1" )
Using this, the solution to the above would be:
auto sum( R )( R range ) {
return reduce!"a+b"( 0, range );
}
auto sumOfSquares( R )( R range ) {
return sum( list!"a*a" | range );
}
module listcomp;
import std.algorithm;
import std.range;
import std.array;
struct List( alias pred ) {
auto opBinary( string op : "|", Range )( Range other ) {
return map!pred(other);
}
}
struct Where( alias pred ) {
auto opBinaryRight( string op : "&", R )( R range ) {
return filter!pred(range);
}
}
@property
whereImpl!pred where( alias pred )( ) {
Where!pred result;
return result;
}
@property
listImpl!pred list( alias pred )( ) {
List!pred result;
return result;
}
unittest {
assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ),
[2,6,10] ) );
assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
}
--
Simen
Re: The Many Faces of D - slides
Russel Winder: >I continue to be intrigued by people who believe that code, unlike text, is >more readable in a monospace font. Personally I think monospace fonts make >code unreadable,< I guess it's a matter of personal preferences. But non-proportional fonts have two advantages: - it's easy to count spaces, vertical alignments and so on; - often if the non-proportional is well designed it's simpler to tell apart glyphs like Jl1j0oO;:. > Given an imperative language with no tail recursion capability Both DMD and LDC (and probably GDC too) currently are able to turn some cases of tail recursion to iterative code. > def sumOfSquares ( sequence ) : > return sum ( [ item * item for item in sequence ] ) Since many years and many versions of Python the pythonic way to write that is to use a lazy iterable: def sumOfSquares (sequence): return sum(item * item for item in sequence) I have suggested few times a list/lazy comp syntax for D too, and I have tried to explain why it's a good thing (it helps "chunking" in the mind of the programmer). Bye, bearophile
Re: The Many Faces of D - slides
On Sun, 2010-10-03 at 09:59 -0400, bearophile wrote: [ . . . ] > Page 10, and in other pages I'd like a non-proportional font for the > code, because I find it a little more readable (even better if it's > colorized, there are online tools able to produce colorized HTML from > D1 code too). I continue to be intrigued by people who believe that code, unlike text, is more readable in a monospace font. Personally I think monospace fonts make code unreadable, I always prefer proportional fonts for code. Currently I use Ocean Sans MT. Colourized though, I agree, makes things more readable -- as long as the colourization theme matches the semantics of the code fragment, obviously. [ . . . ] > Page 20: is that functional? It even contains a mutable "sum" value. > It may be seen as kind-of-functional. A more functional style is to > use a reduce (fold) there, from std.algorithm. I agree this is a weird sort of an example of "functional". sum_of_squares as a function has no external side-effects (though clearly the iteration has a side effect internally) and is referentially transparent. So as a thing that can be used as a "functional programming" function it is fine, its implementation is though very much imperative programming -- at its worst ;-) Given an imperative language with no tail recursion capability then one has to declare a non-functional floor even when doing functional style programming. In effect the execution graph has to be allowed to have leaqf nodes that are implemented imperatively. Coming from a Pythonic realization of these ideas, list comprehensions seems to be the best way out of this sort of thing, so instead of: def sumOfSquares ( sequence ) : sum = 0.0 for item in sequence : sum += item * item return sum it is better to write: def sumOfSquares ( sequence ) : return sum ( [ item * item for item in sequence ] ) So the question is whether there is an idiomatic D version of this. [ . . . ] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: The Many Faces of D - slides
Walter Bright:
> The slides for my Sep. 15 talk at NWCPP:
> http://nwcpp.org/images/stories/nwcpp-2010-09.pdf
Thank you for the slides.
Few comments:
Page 10, and in other pages I'd like a non-proportional font for the code,
because I find it a little more readable (even better if it's colorized, there
are online tools able to produce colorized HTML from D1 code too).
Page 19:
>Unlike C++, values can be moved in memory Postblit is used to adjust things
>after a move<
OK, so a moving GC needs to call the Postblit each time it moves a struct.
Page 20: is that functional? It even contains a mutable "sum" value. It may be
seen as kind-of-functional. A more functional style is to use a reduce (fold)
there, from std.algorithm.
Page 30: that little concurrent test program gives me an error:
...\dmd\src\phobos\std\typecons.d(336): Error: no property 'length' for type
'immutable(char)'
This is the part of typecons.d that gives the error:
static string injectNamedFields()
{
string decl = "";
foreach (i, name; staticMap!(extractName, fieldSpecs))
{
autofield = text("Identity!(field[", i, "])");
auto numbered = text("_", i);
decl ~= text("alias ", field, " ", numbered, ";");
if (name.length != 0) // line 336
{
decl ~= text("alias ", numbered, " ", name, ";");
}
}
return decl;
}
Bye,
bearophile
Re: The Many Faces of D - slides [ot]
On 3/10/2010 10:01 PM, retard wrote: Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote: The slides for my Sep. 15 talk at NWCPP: http://nwcpp.org/images/stories/nwcpp-2010-09.pdf On a side note, I noticed that Walter is still using OpenOffice 2.4 from March 2008. 9 new releases have been announced after that :-) I doubt it has any effect on these slides, but the latest versions might offer better user experience. Ahh, while that is a polite observation, it is not (to me at least) very interesting. What would be more interesting is some indication of interest to take up D as a PL from this (C++) audience***. *** http://www.nwcpp.org/ May I ask Walter if, as coming away from the meeting, you felt that there might be converts (to D) amongst this group? Cheers Justin Johansson
Re: The Many Faces of D - slides [ot]
On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote: [ . . . ] > I just use latex for everything. That way I can use vim. It's much more > pleasant > that way. Also you can put the material into version control since the source is mergeable -- unlike OOo files. Sadly though LaTeX, even with the beamer package, just isn't up to doing what is easy with OOo. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: The Many Faces of D - slides [ot]
On Sunday 03 October 2010 04:01:10 retard wrote: > Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote: > > The slides for my Sep. 15 talk at NWCPP: > > > > http://nwcpp.org/images/stories/nwcpp-2010-09.pdf > > On a side note, I noticed that Walter is still using OpenOffice 2.4 from > March 2008. 9 new releases have been announced after that :-) I doubt it > has any effect on these slides, but the latest versions might offer > better user experience. I just use latex for everything. That way I can use vim. It's much more pleasant that way. - Jonathan M Davis
Re: The Many Faces of D - slides [ot]
Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote: > The slides for my Sep. 15 talk at NWCPP: > > http://nwcpp.org/images/stories/nwcpp-2010-09.pdf On a side note, I noticed that Walter is still using OpenOffice 2.4 from March 2008. 9 new releases have been announced after that :-) I doubt it has any effect on these slides, but the latest versions might offer better user experience.
Re: The Many Faces of D - slides
Interesting, would have loved to be there :) On 3 October 2010 12:28, Walter Bright wrote: > The slides for my Sep. 15 talk at NWCPP: > > http://nwcpp.org/images/stories/nwcpp-2010-09.pdf > -- // Yours sincerely // Emil 'Skeen' Madsen
The Many Faces of D - slides
The slides for my Sep. 15 talk at NWCPP: http://nwcpp.org/images/stories/nwcpp-2010-09.pdf
