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
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

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

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

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.

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.

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);
}

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

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

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 = —
> 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.

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.