digitalmars.D - Effective D book?

"Szymon Gatner" <noemail gmail.com> writes:
Any plans on that now that language is stable enough? Andrei
authoring maybe?

Jun 14 2013
"Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
Any plans on that now that language is stable enough? Andrei
authoring maybe?

The language is fairly stable, but still far from complete.
There's still several unimplemented and undesigned big features
that could significantly affects what the best practices are
(scope parameters and lack of copy constructors comes to mind).

Also, I think it's still a bit too early to put out a book on
best practices in D. Not many people have lots of experience
writing production D code.

Jun 14 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:56 AM, Peter Alexander wrote:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
Any plans on that now that language is stable enough? Andrei authoring maybe?

The language is fairly stable, but still far from complete. There's still
several unimplemented and undesigned big features that could significantly
affects what the best practices are (scope parameters and lack of copy
constructors comes to mind).

Also, I think it's still a bit too early to put out a book on best practices in
D. Not many people have lots of experience writing production D code.

It's true that "best practices" in D are still evolving. That's not a bad thing
- best practices in C++ have changed a lot over the years.

Jun 14 2013
"monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
Any plans on that now that language is stable enough? Andrei
authoring maybe?

Who would write it?

It seems to me that D is still new and not widespread, which
means that everybody has their own styles and interpretation of
how to use the language.

I could see someone writing a "Programming with Phobos" book(let)
though, for example. But a full blown best practice for the
entire language itself seems excessive to me. In particular,
while *stable*, it *is* still "evolving", which means that while
the old code still works, the patterns are still shifting.

Jun 14 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 11:29 AM, monarch_dodra wrote:
Who would write it?

Anyone who wants to!

It seems to me that D is still new and not widespread, which means that
everybody has their own styles and interpretation of how to use the language.

I could see someone writing a "Programming with Phobos" book(let) though, for
example. But a full blown best practice for the entire language itself seems
excessive to me. In particular, while *stable*, it *is* still "evolving", which
means that while the old code still works, the patterns are still shifting.

Although you are right, the best practices are still evolving, I don't think
that automatically precludes writing a book on the current state of thought on
the matter.

Jun 14 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 11:29 AM, monarch_dodra wrote:
In particular, while *stable*, it *is* still "evolving", which
means that while the old code still works, the patterns are still shifting.

One example of that is Andrei and I have been discussing the idea of moving
import declarations from their traditional place at the top of the file to
being
in the most nested scope in which they are referenced.

Jun 14 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 03:02 AM, Walter Bright wrote:
On 6/14/2013 11:29 AM, monarch_dodra wrote:
In particular, while *stable*, it *is* still "evolving", which
means that while the old code still works, the patterns are still
shifting.

One example of that is Andrei and I have been discussing the idea of
moving import declarations from their traditional place at the top of
the file to being in the most nested scope in which they are referenced.

One issue with local imports is that they hide local symbols.

Jun 15 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:09 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro.

void main()
{
import std.stdio;
void writeln(string) {}
writeln("foo");
std.stdio.writeln("bar");
}

This writes only "bar".

So does this:

void main(){
void writeln(string) {}
writeln("foo");
{
import std.stdio;
writeln("bar");
}
}

Jun 15 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 11:03 AM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:
So does this:

void main(){
void writeln(string) {}
writeln("foo");
{
import std.stdio;
writeln("bar");
}
}

Still not seeing any issue. The first writeln cannot know about the
import because it is at a deeper scope, so only the second writeln will
print anything.

The local import therefore hides a local symbol.

Jun 16 2013
"Tyro[17]" <ridimz yahoo.com> writes:
On 6/16/13 5:34 AM, Timon Gehr wrote:
void main(){
void writeln(string) {}
writeln("foo");
{
import std.stdio;
writeln("bar");
}
}

void main(){
void writeln(string) {}
writeln("foo");
{
import io = std.stdio;
writeln("bar");
io.writeln("baz");
}
}

I see your point... but somehow I don't think it's that big of a
problem. Should be fixed for those not willing to use the mechanism
currently available to resolve the issue, but I wouldn't loose any sleep
if it weren't.

--

Andrew Edwards
--------------------
http://www.akeron.co
string location = " ", period = ".";
return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

Jun 16 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 11:50 AM, Tyro[17] wrote:
On 6/16/13 5:34 AM, Timon Gehr wrote:
void main(){
void writeln(string) {}
writeln("foo");
{
import std.stdio;
writeln("bar");
}
}

void main(){
void writeln(string) {}
writeln("foo");
{
import io = std.stdio;
writeln("bar");
io.writeln("baz");
}
}

I see your point... but somehow I don't think it's that big of a
problem.

Well, it does not have to be in order to get fixed. The D module system
otherwise avoids this kind of issue.

Should be fixed for those not willing to use the mechanism
currently available to resolve the issue, but I wouldn't loose any sleep
if it weren't.

There is no mechanism in place that reliably avoids silent breakage.

Jun 16 2013
"Tyro[17]" <ridimz yahoo.com> writes:
On 6/16/13 6:07 AM, Timon Gehr wrote:
On 06/16/2013 11:50 AM, Tyro[17] wrote:
On 6/16/13 5:34 AM, Timon Gehr wrote:

Should be fixed for those not willing to use the mechanism
currently available to resolve the issue, but I wouldn't loose any sleep
if it weren't.

There is no mechanism in place that reliably avoids silent breakage.

A very valid point. For this particular case though, I would move to
suggest that an apt resolution would be to documentation the behavior
and suggest that if such behavior is not desired, the use of renamed
imports or static imports is recommended for scoped imports.

import s = std.stdio;
import std.stdio: print = writeln;
static import std.stdio;

any of these options is a valid solution this particular issue while
documentation takes care of the rest.

Having just said that, I took a quick look at the documentation and this
is what it had to say:

"In function scopes, imported symbols only become visible after the
import declaration lexically appears in the function body. In other
words, imported symbols at function scope cannot be forward referenced. "

Even the example given there clearly tells you this will happen:

void main() {
void writeln(string) {}
void foo() {
writeln("bar"); // calls main.writeln
import std.stdio;
writeln("bar"); // calls std.stdio.writeln
void writeln(string) {}
writeln("bar"); // calls main.foo.writeln
}
writeln("bar"); // calls main.writeln
std.stdio.writeln("bar"); // error, std is undefined
}

I don't see the problem.

--

Andrew Edwards
--------------------
http://www.akeron.co
string location = " ", period = ".";
return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

Jun 16 2013
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/13 5:34 AM, Timon Gehr wrote:
On 06/16/2013 11:03 AM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:
So does this:

void main(){
void writeln(string) {}
writeln("foo");
{
import std.stdio;
writeln("bar");
}
}

Still not seeing any issue. The first writeln cannot know about the
import because it is at a deeper scope, so only the second writeln will
print anything.

The local import therefore hides a local symbol.

Yah that's a bug. Has anyone filed it yet?

Andrei

Jun 16 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 06:06 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro.

void main()
{
import std.stdio;
void writeln(string) {}
writeln("foo");
std.stdio.writeln("bar");
}

This writes only "bar".

void writeln(string) {}
void main()
{
import std.stdio;
writeln("foo");
std.stdio.writeln("bar");
}

Oh, but that's not a local symbol, that's a module level symbol. The
import is more local that the module level writeln, so that works as you
would expect.

It also isn't a problem at all, ...

It sure is, the module system is supposed to provide hijacking protection.

Jun 15 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2013 2:34 PM, Timon Gehr wrote:
It sure is, the module system is supposed to provide hijacking protection.

Inner scopes override outer scopes. That isn't what hijacking is.

Jun 15 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 01:36 AM, Walter Bright wrote:
On 6/15/2013 2:34 PM, Timon Gehr wrote:
It sure is, the module system is supposed to provide hijacking
protection.

Inner scopes override outer scopes. That isn't what hijacking is.

A module can introduce a new symbol and silently change what some
identifier lookup refers to, where the previous symbol referred to
resides in a different module.

Jun 15 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2013 2:06 AM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:
On 6/15/2013 2:34 PM, Timon Gehr wrote:
It sure is, the module system is supposed to provide hijacking protection.

Inner scopes override outer scopes. That isn't what hijacking is.

I think this is an issue Walter, consider:

void main()
{
import std.stdio;
string message = "Hello, world!";
writeln(message);
}

It std.stdio contains a symbol called "message" then this will not print
"Hello,
world".

Yes, it will. Current scope overrides imported scope.

Jun 16 2013
Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:09 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro.

void main()
{
import std.stdio;
void writeln(string) {}
writeln("foo");
std.stdio.writeln("bar");
}

This writes only "bar".

More peculiar example:

void main(){
import std.stdio;
void writefx(string s){writeln(s);}
{
import std.stdio;
writefx("bar"); // error: writefx is private
}
}

'writefx' happens to be a private symbol in std.stdio.

Jun 15 2013
Rainer Schuetze <r.sagitario gmx.de> writes:
On 15.06.2013 17:09, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro.

Here is another example I recently stumbled upon:

/////////
module a;

class A
{
import std.stdio;
}

/////////
module b;

void writeln(string){}

class B : A
{
void foo()
{
writeln("Hi");
}
}

Guess which function is called in foo!

There are conflicting rule sets at work here, the symbol lookup rules
for base classes vs the lookup rules for (private) imports.

Walter seems to be fine as is but I'm not sure
(http://forum.dlang.org/post/5197E695.10807 digitalmars.com - the issue
is not a regression as reported, there seems to be some change to it in
2.063 that I couldn't isolate). At least the symbols imported into the
base class should be private by default (though that won't change
anything in the same module).

OT: This points to another slight non-orthogonality as declarations and
imports have different visibility defaults, which is modified by the
same "public:"/"private:".

Jun 16 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 7:17 PM, Jonathan M Davis wrote:
I'm a bit reticent to bring it up given that I won't be done anytime soon, but
I actually started writing such a book following DConf. After Andrew brought
up the possibility of Effective D in his talk and all of the talk that occurred
at DConf about doing more with tutorials and publishing best practices, I
decided that I'd give it shot.

Awesome!

And while I'm sure that there's plenty more best practices that we'll figure
out over time, and some of what we do know has been shifting as we learn, I
think that we do know enough at this point about best practices in D to fill
such a book.

Keep us posted.

Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc
so that it can easily be converted into latex, html, and e-book formats rather
than being tied to any particular format (I was going to use latex, but Andrei
thought that a macro language would be better as latex is very tied to physical
print and fixed layouts). It'll probably be the first book ever to be written
entirely in ddoc.

This is just being a win all around!

Jun 14 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:15 PM, Jonathan M Davis wrote:
My one major complaint about using ddoc is the need for the $(P ) macro everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should probably create an enhancement request for that (and maybe even try and implement it), but I have enough to do right now that I decided that I'd just put up with it for now. But aside from the need for$(P ) macros, it's
actually quite pleasant to work with.

I do have to process the ddoc before giving it to the compiler in order to
those with just macros), but since I'm using a D script to do the build,
that was actually pretty easy.

So, I'm writing a book on D which is written in D's documentation macro
language and using D to actually drive the build. It's all very D. :)

I'd write it first without bothering with any formatting commands. Add them in
at the end. (This is how I do all my articles.)

Jun 14 2013
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 11:55 AM, H. S. Teoh wrote:
I'm curious about how you manage to factor out / abstract away the
niggling details of LaTeX, like the use of ".\ " after an abbreviation
(to make it produce only an inter-word space, as opposed to the extra
space at the end of a sentence),

ABBRDOT = .\$(SPACE) m-dash MDASH = --- vs. n-dash NDASH = -- , etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? FOOTNOTE = \footnote{$0}

Section
references?

SECREF = \ref{sec:$0} Do you have macros for all of them? Yah. All of the above would go into a latex.ddoc macros file. Then the html.ddoc file would contain things like ABBRDOT = .$(SPACE)
MDASH = &mdash;
etc.

Does it make it a bit
cumbersome to type?

Most likely, but this is the price to pay for supporting multiple
formats. Then, LaTeX wasn't exactly designed for ease of typing, so the
marginal cumbersomeness shouldn't be high.

I do have to process the ddoc before giving it to the compiler in
can't generate those with just macros), but since I'm using a D script
to do the build, that was actually pretty easy.

are you talking about doing that for HTML output?

Yah, all outputs should have TOCs and such.

Andrei

Jun 16 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:43 PM, Szymon Gatner wrote:
Btw: Not sure if "effective" series isn't somehow propertiary and linked to
Herb
Sutter. I know he is not only responsible for c++ but also for c# version

I would refrain from naming it "Effective D". Scott Meyers is the author of
several "Effective C++" books, and it would be disrespectful to try to trade
off
of that, even though there is an "Effective Java" by Bloch and an "Effective
C#"
by Wagner, etc.

Heck, to throw something out there, why not "D Best Practices"?

Jun 14 2013
Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Jun-2013 12:07, SomeDude пишет:
On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:
Heck, to throw something out there, why not "D Best Practices"?

Or "D Patterns and Practices" ?
With some David Simcha content in it (if he agrees with that of course).

IMHO D Cookbook sounds about right.

--
Dmitry Olshansky

Jun 15 2013
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 6:19 PM, Jonathan M Davis wrote:
For the book that I'm working on, I'm really not going to worry about the
title at this point. I'm just going to write it, and I'll worry about stuff
like the title and who might publish it or anything along those lines once
it's much closer to completion.

Awesome approach.

Andrei

Jun 16 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2013 3:19 PM, Jonathan M Davis wrote:
For the book that I'm working on, I'm really not going to worry about the
title at this point. I'm just going to write it, and I'll worry about stuff
like the title and who might publish it or anything along those lines once
it's much closer to completion.

+1

Also, I wouldn't worry about formatting until it's near completion, either.

Jun 16 2013
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/13 12:53 PM, Walter Bright wrote:
On 6/15/2013 3:19 PM, Jonathan M Davis wrote:
For the book that I'm working on, I'm really not going to worry about the
title at this point. I'm just going to write it, and I'll worry about
stuff
like the title and who might publish it or anything along those lines
once
it's much closer to completion.

+1

Also, I wouldn't worry about formatting until it's near completion, either.

I think people's styles differ here. I've spent time upfront on TDPL's
page design and then I've enjoyed seeing parts of the finished product
growing as I worked on it.

Andrei

Jun 16 2013
Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2013 1:36 PM, Jonathan M Davis wrote:
I tend to worry about things like how paragraphs are separated and which words
get emphasized as I go along (the same sorts of things that I'd worry about in
a simple forum post), but I'm not going to worry about minute formatting
details like mdash or ndash or anything like that. And I won't worry about the
font style or page layout or anything along those lines until much later.
Without having a bunch of text, I don't know how you'd be able to sort that
out very well anyway, since you wouldn't be able to see what your tweaks did.
But I _am_ doing enough formatting to care about whether I need $(P ) or not - just not a whole lot beyond that. Sure, whatever works best for you! Me, I'm definitely the kind of person who can only think about one thing at a time, and when I'm writing text, I just let it flow in one uninterrupted stream. Interestingly enough, most of the grammatical errors in my text come about because of editing it later.  Jun 16 2013 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes: On 6/15/13 5:43 AM, Szymon Gatner wrote: Btw: Not sure if "effective" series isn't somehow propertiary and linked to Herb Sutter. I know he is not only responsible for c++ but also for c# version The "Effective" series at AWL is directed by Scott Meyers and would not preclude one from using the title elsewhere. That being said, I mentioned the book last night to Scott and he said if the author wants to publish it in that series, he'd be glad to look into it. Andrei  Jun 14 2013 =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes: On 06/14/2013 07:17 PM, Jonathan M Davis wrote: It'll probably be the first book ever to be written entirely in ddoc. The first ddoc book was a D book as well: ;) http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/foreach_opapply.d Ali  Jun 15 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? Did you read what you quoted? :-)  Jun 14 2013 "Szymon Gatner" <noemail gmail.com> writes: On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote: On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? Did you read what you quoted? :-) That was just a suggestion of course ;) And I am asking this after watching David Simcha's talk. There are language idioms clarifying already even if just while writing Phobos. And there can always be new editions with newly discovered idioms / patterns and good practices. But I do see your point on proper battlefield testing first.  Jun 14 2013 "monarch_dodra" <monarchdodra gmail.com> writes: On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote: On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? Did you read what you quoted? :-) I guess it does look silly like that :) But the point I wanted to make came in the next sentence, is that I think that currently, no single person could write said book, because everyone has their own interpretation of best practices, or different types of use. Not even Andrei. We all have our own interpretation right now of how to use D. If the book was released by a single author, it would just be that person's interpretation of "Effective". I would love to be proven wrong of course. Another interesting project, given D's state, could be a collaborative "D idioms and patterns", for example?  Jun 14 2013 "H. S. Teoh" <hsteoh quickfur.ath.cx> writes: On Fri, Jun 14, 2013 at 11:22:14PM +0200, monarch_dodra wrote: On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote: On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? Did you read what you quoted? :-) I guess it does look silly like that :) But the point I wanted to make came in the next sentence, is that I think that currently, no single person could write said book, because everyone has their own interpretation of best practices, or different types of use. Not even Andrei. We all have our own interpretation right now of how to use D. If the book was released by a single author, it would just be that person's interpretation of "Effective". I would love to be proven wrong of course. What about collecting the most common D practices among us and seeing if some common trends show up? Another interesting project, given D's state, could be a collaborative "D idioms and patterns", for example? Isn't there already a section on the wiki dedicated to that? It would help if more people would contribute their experiences. T -- When solving a problem, take care that you do not become part of the problem.  Jun 14 2013 "Jonathan M Davis" <jmdavisProg gmx.com> writes: On Friday, June 14, 2013 20:29:09 monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? I'm a bit reticent to bring it up given that I won't be done anytime soon, but I actually started writing such a book following DConf. After Andrew brought up the possibility of Effective D in his talk and all of the talk that occurred at DConf about doing more with tutorials and publishing best practices, I decided that I'd give it shot. And while I'm sure that there's plenty more best practices that we'll figure out over time, and some of what we do know has been shifting as we learn, I think that we do know enough at this point about best practices in D to fill such a book. Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. - Jonathan M Davis  Jun 14 2013 "Elvis" <nospam pureworld.com> writes: On Saturday, 15 June 2013 at 02:17:59 UTC, Jonathan M Davis wrote: On Friday, June 14, 2013 20:29:09 monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? I'm a bit reticent to bring it up given that I won't be done anytime soon, but I actually started writing such a book following DConf. After Andrew brought up the possibility of Effective D in his talk and all of the talk that occurred at DConf about doing more with tutorials and publishing best practices, I decided that I'd give it shot. And while I'm sure that there's plenty more best practices that we'll figure out over time, and some of what we do know has been shifting as we learn, I think that we do know enough at this point about best practices in D to fill such a book. Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. - Jonathan M Davis Good jobs, I'm very much looking forward to reading it!  Jun 14 2013 "Jonathan M Davis" <jmdavisProg gmx.com> writes: On Friday, June 14, 2013 19:57:52 Walter Bright wrote: Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. This is just being a win all around! My one major complaint about using ddoc is the need for the$(P ) macro
everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should
probably create an enhancement request for that (and maybe even try and
implement it), but I have enough to do right now that I decided that I'd just
put up with it for now. But aside from the need for $(P ) macros, it's actually quite pleasant to work with. I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy. So, I'm writing a book on D which is written in D's documentation macro language and using D to actually drive the build. It's all very D. :) - Jonathan M Davis  Jun 14 2013 "Szymon Gatner" <noemail gmail.com> writes: On Saturday, 15 June 2013 at 02:17:59 UTC, Jonathan M Davis wrote: On Friday, June 14, 2013 20:29:09 monarch_dodra wrote: On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote: Any plans on that now that language is stable enough? Andrei authoring maybe? Who would write it? I'm a bit reticent to bring it up given that I won't be done anytime soon, but I actually started writing such a book following DConf. After Andrew brought up the possibility of Effective D in his talk and all of the talk that occurred at DConf about doing more with tutorials and publishing best practices, I decided that I'd give it shot. And while I'm sure that there's plenty more best practices that we'll figure out over time, and some of what we do know has been shifting as we learn, I think that we do know enough at this point about best practices in D to fill such a book. Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. - Jonathan M Davis Would love to proof read it. Btw: Not sure if "effective" series isn't somehow propertiary and linked to Herb Sutter. I know he is not only responsible for c++ but also for c# version  Jun 14 2013 "Jonathan M Davis" <jmdavisProg gmx.com> writes: On Saturday, June 15, 2013 05:43:11 Szymon Gatner wrote: Btw: Not sure if "effective" series isn't somehow propertiary and linked to Herb Sutter. I know he is not only responsible for c++ but also for c# version Scott Meyers wrote the C++ one, Bill Wagner wrote the C# one, and Joshua Bloch wrote the Javae one. I'm not aware of Herb Sutter having anything to do with any of them. And Effective Java was published via a different publisher from the other two, so my guess is that there would be no problem with the name Effective D. But I'm not married to the name "Effective D." It's simply the name that's been suggested and which would have recognition thanks to books with similar names in other languages. The important thing is the content of the book. If it ends up with a different name, then it ends up with a different name. - Jonathan M Davis  Jun 14 2013 Jonathan M Davis <jmdavisProg gmx.com> writes: On Saturday, June 15, 2013 00:26:55 Ali =C3=87ehreli wrote: On 06/14/2013 07:17 PM, Jonathan M Davis wrote: > It'll probably be the first book ever to be written entirely in dd= =20 The first ddoc book was a D book as well: ;) =20 =20 http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/fore= pply.d So, you wrote your book with ddoc? I didn't know that. That's cool. It'= s a lot=20 more versatile than you'd initially think. - Jonathan M Davis  Jun 15 2013 "SomeDude" <lovelydear mailmetrash.com> writes: On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not "D Best Practices"? Or "D Patterns and Practices" ? With some David Simcha content in it (if he agrees with that of course).  Jun 15 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote: One issue with local imports is that they hide local symbols. Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".  Jun 15 2013 "Mr. Anonymous" <mailnew4ster gmail.com> writes: On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote: On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote: One issue with local imports is that they hide local symbols. Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar". void writeln(string) {} void main() { import std.stdio; writeln("foo"); std.stdio.writeln("bar"); } ?  Jun 15 2013 "H. S. Teoh" <hsteoh quickfur.ath.cx> writes: On Fri, Jun 14, 2013 at 11:15:14PM -0400, Jonathan M Davis wrote: On Friday, June 14, 2013 19:57:52 Walter Bright wrote: Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. This is just being a win all around! My one major complaint about using ddoc is the need for the$(P )
macro everywhere, whereas LaTeX inserts paragraphs based on empty
lines. I should probably create an enhancement request for that (and
maybe even try and implement it), but I have enough to do right now
that I decided that I'd just put up with it for now. But aside from
the need for $(P ) macros, it's actually quite pleasant to work with. I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of ".\ " after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type? I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy. Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output? T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius  Jun 15 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote: On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote: On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote: One issue with local imports is that they hide local symbols. Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar". void writeln(string) {} void main() { import std.stdio; writeln("foo"); std.stdio.writeln("bar"); } Oh, but that's not a local symbol, that's a module level symbol. The import is more local that the module level writeln, so that works as you would expect. It also isn't a problem at all, because you can easily refer to the module level symbol by fully qualifying it. module thismodule; void writeln(string) {} void main() { import std.stdio; thismodule.writeln("foo"); std.stdio.writeln("bar"); } In any case, I'd recommend explicitly choosing which symbols to import in the local import to avoid name clashes.  Jun 15 2013 Jonathan M Davis <jmdavisProg gmx.com> writes: On Saturday, June 15, 2013 08:55:11 H. S. Teoh wrote: I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of ".\ " after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type? I'm early enough in the process that I haven't done much with those yet, and I'm likely to have to go back and fix that sort of thing up later (especially since about all I've done with LaTeX previously is write papers for college, and I didn't necessarily have to get everything as nice and exact as you would for a published book, so I'd likely be screwing some of that up even if I were writing directly in LaTeX). I expect to be using macros for them, but since you have to mark them up when writing in LaTeX anyway, it's not like I lose much using ddoc instead. It's just that the syntax changed. But it may be that if some of those can be automated, I'll end up doing something in the build script to manipulate the text to add that markup for me rather than using macros directly. I'll worry about that level of typesetting later. I wouldn't be worrying about that now even if I were writing directly in LaTeX. And ddoc macros will easily allow me to add it all later. It's just that the ddoc files for stuff like html and epub will ignore them. I don't really need to create something which is completely target-agnostic. I just need to create something that easily converts to all of the target formats that I need. And ddoc will do that just fine. I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy. [...] Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output? LaTeX will autogenerate the table of contents and the index, but html won't (and I don't think that something like epub will either, but I haven't gotten around to generating that yet). So, I have to generate the whole thing as macros, which the latex.ddoc file mostly gets rid of, and the html.ddoc file replaces with the appopriate text and links. - Jonathan M Davis  Jun 15 2013 "matovitch" <camille.brugel laposte.net> writes: I am referring to the beginning of this thread, but definitly wating for such a book to come out I have open a SO question (interactive media for a yet evolving langage) about effective design patterns and best practice in D. So if you have some clever methods you want to share, I am waiting for your answers. :-)  Jun 15 2013 "matovitch" <camille.brugel laposte.net> writes: On Saturday, 15 June 2013 at 19:52:45 UTC, matovitch wrote: I am referring to the beginning of this thread, but definitly wating for such a book to come out I have open a SO question (interactive media for a yet evolving langage) about effective design patterns and best practice in D. So if you have some clever methods you want to share, I am waiting for your answers. :-) the link : http://stackoverflow.com/questions/tagged/d (forget the obvious)  Jun 15 2013 "matovitch" <camille.brugel laposte.net> writes: the 'true' link : http://stackoverflow.com/questions/17127251/effective-d-best-practices-and-design-patterns  Jun 15 2013 "David Nadlinger" <code klickverbot.at> writes: On Saturday, 15 June 2013 at 21:35:20 UTC, Timon Gehr wrote: On 06/15/2013 05:09 PM, Peter Alexander wrote: On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote: One issue with local imports is that they hide local symbols. Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar". More peculiar example: void main(){ import std.stdio; void writefx(string s){writeln(s);} { import std.stdio; writefx("bar"); // error: writefx is private } } 'writefx' happens to be a private symbol in std.stdio. You might want to open a bug report for this. David  Jun 15 2013 Jonathan M Davis <jmdavisProg gmx.com> writes: On Sunday, June 16, 2013 01:55:35 Dmitry Olshansky wrote: 15-Jun-2013 12:07, SomeDude =D0=BF=D0=B8=D1=88=D0=B5=D1=82: On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not "D Best Practices"? Or "D Patterns and Practices" ? With some David Simcha content in it (if he agrees with that of cou= =20 IMHO D Cookbook sounds about right. Cookbook is in a similar situation with Effective, if not worse, as O'R= eilly=20 has a whole line of programming books with that name, and AFAIK, every=20= programming book with Cookbook in its name has been published though th= em. So,=20 an author who wanted to use that title would probably have to publish=20= specifically through O'Reilly to get it into that series. However, from the looks of how the Cookbook books are supposed to be la= id out,=20 they really aren't intended for discussing best practices. They're for = giving=20 solutions to specific programming problems, with the idea that they con= tain a=20 list of such "recipes" that you can look up to figure out how to solve = common=20 programming problems in the language or domain that the book covers. It= would=20 certainly be useful to have that sort of book for D, but I believe that= it=20 would be fundamentally different from what a book which might be publis= hed in=20 the "Effective" series would contain. For the book that I'm working on, I'm really not going to worry about t= he=20 title at this point. I'm just going to write it, and I'll worry about s= tuff=20 like the title and who might publish it or anything along those lines o= nce=20 it's much closer to completion. - Jonathan M Davis  Jun 15 2013 "John Colvin" <john.loughran.colvin gmail.com> writes: On Saturday, 15 June 2013 at 08:07:23 UTC, SomeDude wrote: On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not "D Best Practices"? Or "D Patterns and Practices" ? +1  Jun 15 2013 "deadalnix" <deadalnix gmail.com> writes: On Sunday, 16 June 2013 at 00:42:15 UTC, Timon Gehr wrote: On 06/16/2013 01:36 AM, Walter Bright wrote: On 6/15/2013 2:34 PM, Timon Gehr wrote: It sure is, the module system is supposed to provide hijacking protection. Inner scopes override outer scopes. That isn't what hijacking is. A module can introduce a new symbol and silently change what some identifier lookup refers to, where the previous symbol referred to resides in a different module. It happen to me recently; the bug was very puzzling. I do think that identifier lookup should turtle down in the module before looking at imports.  Jun 15 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote: So does this: void main(){ void writeln(string) {} writeln("foo"); { import std.stdio; writeln("bar"); } } Still not seeing any issue. The first writeln cannot know about the import because it is at a deeper scope, so only the second writeln will print anything. It also isn't a problem at all, ... It sure is, the module system is supposed to provide hijacking protection. Hmm good point. More peculiar example: ... 'writefx' happens to be a private symbol in std.stdio. I think this is just the separate bug where private symbols are visible through imports. Should be solved by DIP22 IIRC.  Jun 16 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote: On 6/15/2013 2:34 PM, Timon Gehr wrote: It sure is, the module system is supposed to provide hijacking protection. Inner scopes override outer scopes. That isn't what hijacking is. I think this is an issue Walter, consider: void main() { import std.stdio; string message = "Hello, world!"; writeln(message); } It std.stdio contains a symbol called "message" then this will not print "Hello, world". Updates to libraries that introduce symbols could subtly break working code. Whether or not this is what hijacking is, I think this is a problem.  Jun 16 2013 Jonathan M Davis <jmdavisProg gmx.com> writes: On Sunday, June 16, 2013 11:06:18 Peter Alexander wrote: On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote: On 6/15/2013 2:34 PM, Timon Gehr wrote: It sure is, the module system is supposed to provide hijacking protection. Inner scopes override outer scopes. That isn't what hijacking is. I think this is an issue Walter, consider: void main() { import std.stdio; string message = "Hello, world!"; writeln(message); } It std.stdio contains a symbol called "message" then this will not print "Hello, world". Updates to libraries that introduce symbols could subtly break working code. Whether or not this is what hijacking is, I think this is a problem. I concur. It may be that it's reasonable for local imports to shadow declarations from outside the function rather than creating conflicts, but they definitely shouldn't shadow symbols inside the function - _especially_ when the local symbol is declared after the local import. The current behavior is just going to create bugs. - Jonathan M Davis  Jun 16 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Sunday, 16 June 2013 at 12:52:52 UTC, Andrei Alexandrescu wrote: On 6/16/13 5:34 AM, Timon Gehr wrote: The local import therefore hides a local symbol. Yah that's a bug. Has anyone filed it yet? Timon has filed that the behaviour is underspecified: http://d.puremagic.com/issues/show_bug.cgi?id=7329 I have now filed it as a bug: http://d.puremagic.com/issues/show_bug.cgi?id=10378  Jun 16 2013 "Peter Alexander" <peter.alexander.au gmail.com> writes: On Sunday, 16 June 2013 at 16:48:46 UTC, Walter Bright wrote: On 6/16/2013 2:06 AM, Peter Alexander wrote: It std.stdio contains a symbol called "message" then this will not print "Hello, world". Yes, it will. Current scope overrides imported scope. Sorry, bad example: string message = "Hello, world!"; void main() { import std.stdio; writeln(message); }  Jun 16 2013 Jonathan M Davis <jmdavisProg gmx.com> writes: On Sunday, June 16, 2013 09:53:55 Walter Bright wrote: On 6/15/2013 3:19 PM, Jonathan M Davis wrote: For the book that I'm working on, I'm really not going to worry about the title at this point. I'm just going to write it, and I'll worry about stuff like the title and who might publish it or anything along those lines once it's much closer to completion. +1 Also, I wouldn't worry about formatting until it's near completion, either. I tend to worry about things like how paragraphs are separated and which words get emphasized as I go along (the same sorts of things that I'd worry about in a simple forum post), but I'm not going to worry about minute formatting details like mdash or ndash or anything like that. And I won't worry about the font style or page layout or anything along those lines until much later. Without having a bunch of text, I don't know how you'd be able to sort that out very well anyway, since you wouldn't be able to see what your tweaks did. But I _am_ doing enough formatting to care about whether I need$(P ) or not -
just not a whole lot beyond that.

- Jonathan M Davis

Jun 16 2013
"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jun 16, 2013 at 07:58:20AM -0400, Andrei Alexandrescu wrote:
On 6/15/13 11:55 AM, H. S. Teoh wrote:
I'm curious about how you manage to factor out / abstract away the
niggling details of LaTeX, like the use of ".\ " after an
abbreviation (to make it produce only an inter-word space, as opposed
to the extra space at the end of a sentence),

ABBRDOT = .\$(SPACE) m-dash MDASH = --- vs. n-dash NDASH = -- , etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? FOOTNOTE = \footnote{$0}

But it doesn't address the problem of how to make $(FOOTNOTE ...) work correctly with HTML output. Is it suppressed completely? Post-processed to appear in a footnote DIV? Something else? Section references? SECREF = \ref{sec:$0}

Do you have macros for all of them?

Yah. All of the above would go into a latex.ddoc macros file. Then
the html.ddoc file would contain things like

ABBRDOT = .\$(SPACE)
MDASH = &mdash;
etc.

Does it make it a bit cumbersome to type?

Most likely, but this is the price to pay for supporting multiple
formats. Then, LaTeX wasn't exactly designed for ease of typing, so
the marginal cumbersomeness shouldn't be high.

Or rather, LaTeX *was* designed for ease of typing, but not for ease of
auto-generation / parsing. Many of the quirks of LaTeX syntax is to make
it easy to type certain formatting elements, but it comes at the expense
of consistency of syntax, which is what makes it tricky for systems like
DDoc to generate output for (and rather hard for external programs to
parse correctly).

T

--
This is a tpyo.

Jun 16 2013