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.

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.

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.

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

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.

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

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.

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:".

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

Yah, all outputs should have TOCs and such.


Andrei

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