www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - "Hello D-world!", imports & South African D-naughts

reply "Andre Artus" <andre.artus gmail.com> writes:
Hello D-world!

My name is Andre Artus, and I'm a programmer from Johannesburg, 
South Africa.

I'm relatively new to D, but so far quite impressed by it. I have 
been reading Andrei Alexandrescu's "The D Programming Language" 
and Ali Çehreli's "Programming in D" to get up to speed. Both are 
quite good.

1st Q: Are there other S'frican D'philes on this forum?

2nd Q:

I have noticed Andrei's use of the following construct with 
regard to static imports (p 346):

static {
   import teleport;
   import time_travel, warp;
}

This does not seem to comport with the grammar specified here:
http://dlang.org/module.html#ImportDeclaration

Is this a deprecated or (fringe| unblessed) form?

Andrei's book, and the aforementioned page (module.html) mentions 
"public imports", which are also absent from the 
ImportDeclaration.

I have put together an ANTLR4 grammar for the import 
declarations, but would like to amend it to reflect the correct 
grammar rules.

grammar DLanguageGrammar;

WS             : [\u0020\u0009\u000b\u000c\u000a\u000d]+ -> skip;
ASSIGN		: '=';
COLON		: ':';
COMMA		: ',';
IMPORT		: 'import';
PUBLIC		: 'public';
SEMICOLON	: ';';
STATIC		: 'static';

//I realize this probably does not cover universal alpha,
// will burn that bridge at some later date.
Identifier : [a-zA-Z_]([a-zA-Z0-9_])*;


importDeclaration:
    (PUBLIC | STATIC)?
    IMPORT importList SEMICOLON
     ;

importList:
     simpleImport (COMMA simpleImport)*
     | importBindings
     ;

simpleImport:
     moduleAliasIdentifier ASSIGN moduleFullyQualifiedName
     | moduleFullyQualifiedName
     ;

importBindings:
     simpleImport COLON importBindList
     ;

importBindList:
     importBind (COMMA importBind)*
     ;
importBind:
     Identifier (ASSIGN Identifier)?
     ;

This seems to work fine against the following:
import std.stdio;
import phobos.std.stdio;
import foo, bar;
static import stat.std.stdio;
public import pub.stdio;
static import teleport, time_travel, warp;
import list = util.container.finite.linear.list;
import widget : fun, gun;
import std.stdio : writefln, foo = writef;

But will of course not work against,
static {
   import teleport;
   import time_travel, warp;
}

is there a similar construct for public, e.g.

public {
   import teleport;
   import time_travel, warp;
}

Thanks,

Andre
Aug 02 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 04:38:13 UTC, Andre Artus wrote:

 Hello D-world!

 My name is Andre Artus, and I'm a programmer from Johannesburg, 
 South Africa.

 I'm relatively new to D, but so far quite impressed by it. I 
 have been reading Andrei Alexandrescu's "The D Programming 
 Language" and Ali Çehreli's "Programming in D" to get up to 
 speed. Both are quite good.

 1st Q: Are there other S'frican D'philes on this forum?

 2nd Q:

 I have noticed Andrei's use of the following construct with 
 regard to static imports (p 346):

 static {
   import teleport;
   import time_travel, warp;
 }


To answer my own question this seems to be an application of the 
AttributeSpecifier rule. Which means that "public" and "static" 
should probably be removed from the ImportDeclaration rule.
Aug 02 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Saturday, 3 August 2013 at 05:24:11 UTC, Andre Artus wrote:

 On Saturday, 3 August 2013 at 04:38:13 UTC, Andre Artus wrote:

 Hello D-world!

 My name is Andre Artus, and I'm a programmer from 
 Johannesburg, South Africa.

 I'm relatively new to D, but so far quite impressed by it. I 
 have been reading Andrei Alexandrescu's "The D Programming 
 Language" and Ali Çehreli's "Programming in D" to get up to 
 speed. Both are quite good.

 1st Q: Are there other S'frican D'philes on this forum?

 2nd Q:

 I have noticed Andrei's use of the following construct with 
 regard to static imports (p 346):

 static {
  import teleport;
  import time_travel, warp;
 }


 To answer my own question this seems to be an application of 
 the AttributeSpecifier rule. Which means that "public" and 
 "static" should probably be removed from the ImportDeclaration 
 rule.


they shouldn't. static imports is handy that way to reduce 
namespace pollution(by forcing fully qualifying names), and 
public imports allow import other necessary modules just by 
importing one.
Aug 02 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 06:51:40 UTC, evilrat wrote:

 On Saturday, 3 August 2013 at 05:24:11 UTC, Andre Artus wrote:

 On Saturday, 3 August 2013 at 04:38:13 UTC, Andre Artus wrote:

 Hello D-world!

 My name is Andre Artus, and I'm a programmer from 
 Johannesburg, South Africa.

 I'm relatively new to D, but so far quite impressed by it. I 
 have been reading Andrei Alexandrescu's "The D Programming 
 Language" and Ali Çehreli's "Programming in D" to get up to 
 speed. Both are quite good.

 1st Q: Are there other S'frican D'philes on this forum?

 2nd Q:

 I have noticed Andrei's use of the following construct with 
 regard to static imports (p 346):

 static {
 import teleport;
 import time_travel, warp;
 }


 To answer my own question this seems to be an application of 
 the AttributeSpecifier rule. Which means that "public" and 
 "static" should probably be removed from the ImportDeclaration 
 rule.


 they shouldn't. static imports is handy that way to reduce 
 namespace pollution(by forcing fully qualifying names), and 
 public imports allow import other necessary modules just by 
 importing one.


I realize I was probably a bit unclear in my writing. I am not 
advocating for the removal of these constructions of 'static' or 
'public' from the language. What I'm proposing is that this 
specific area of the documentation does not accurately reflect 
the grammar (or does so redundantly).

What I tried to say is that the reference to 'static' and 
'public' in my implementation of ImportDeclaration (based on my 
reading of the online docs) was redundant. I have since changed 
my implementation and it now parses all the variants I previously 
described including the following:

static {
   import teleport;
   import time_travel, warp;
}

public {
   import teleport;
   import time_travel, warp;
}


The rule "static import ImportList ;" production given in 
[ImportDeclaration](http://dlang.org/module.html#ImportDeclaration) 
is redundant because it is already covered by 
[AttributeSpecifier] 
(http://dlang.org/attribute.html#AttributeSpecifier).

ImportDeclaration:
	import ImportList ;
	**static import ImportList ; ** // seems redundant


AttributeSpecifier:
     Attribute :
     Attribute DeclarationBlock


Attribute:
     // ...
     ProtectionAttribute
     **static**
     // ...

ProtectionAttribute:
     private
     package
     protected
     **public**
     export
Aug 03 2013
parent reply "Bosak" <bosak gmail.com> writes:
On Saturday, 3 August 2013 at 09:02:32 UTC, Andre Artus wrote:

 On Saturday, 3 August 2013 at 06:51:40 UTC, evilrat wrote:

 On Saturday, 3 August 2013 at 05:24:11 UTC, Andre Artus wrote:

 On Saturday, 3 August 2013 at 04:38:13 UTC, Andre Artus wrote:

 Hello D-world!

 My name is Andre Artus, and I'm a programmer from 
 Johannesburg, South Africa.

 I'm relatively new to D, but so far quite impressed by it. I 
 have been reading Andrei Alexandrescu's "The D Programming 
 Language" and Ali Çehreli's "Programming in D" to get up to 
 speed. Both are quite good.

 1st Q: Are there other S'frican D'philes on this forum?

 2nd Q:

 I have noticed Andrei's use of the following construct with 
 regard to static imports (p 346):

 static {
 import teleport;
 import time_travel, warp;
 }


 To answer my own question this seems to be an application of 
 the AttributeSpecifier rule. Which means that "public" and 
 "static" should probably be removed from the 
 ImportDeclaration rule.


 they shouldn't. static imports is handy that way to reduce 
 namespace pollution(by forcing fully qualifying names), and 
 public imports allow import other necessary modules just by 
 importing one.


 I realize I was probably a bit unclear in my writing. I am not 
 advocating for the removal of these constructions of 'static' 
 or 'public' from the language. What I'm proposing is that this 
 specific area of the documentation does not accurately reflect 
 the grammar (or does so redundantly).

 What I tried to say is that the reference to 'static' and 
 'public' in my implementation of ImportDeclaration (based on my 
 reading of the online docs) was redundant. I have since changed 
 my implementation and it now parses all the variants I 
 previously described including the following:

 static {
   import teleport;
   import time_travel, warp;
 }

 public {
   import teleport;
   import time_travel, warp;
 }


 The rule "static import ImportList ;" production given in 
 [ImportDeclaration](http://dlang.org/module.html#ImportDeclaration) 
 is redundant because it is already covered by 
 [AttributeSpecifier] 
 (http://dlang.org/attribute.html#AttributeSpecifier).

 ImportDeclaration:
 	import ImportList ;
 	**static import ImportList ; ** // seems redundant


 AttributeSpecifier:
     Attribute :
     Attribute DeclarationBlock


 Attribute:
     // ...
     ProtectionAttribute
     **static**
     // ...

 ProtectionAttribute:
     private
     package
     protected
     **public**
     export


"The D Programming Language" is kind of old and out of date for 
the current version of D. There aren't many books for D so you 
have not much choice.
Attributes can be declared with 3 different syntaxes. For example 
one could write:
//--1--
/*Explicitly state attribute before every declaration*/
public int number;
public string name;
//--2--
/*State the attribute and then curly brackets and all the 
declarations inside have the attribute specified. Also note that 
those brackets don't introduce a new scope*/
public
{

}
Aug 03 2013
parent reply "Bosak" <bosak gmail.com> writes:
"The D Programming Language" is kind of old and out of date for
the current version of D. There aren't many books for D so you
have not much choice.
Attributes can be declared with 3 different syntaxes. For
example one could write:
//--1--
/*Explicitly state attribute before every declaration*/
public int number;
public string name;
//--2--
/*State the attribute and then curly brackets and all the
declarations inside have the attribute specified. Also note
that those brackets don't introduce a new scope*/
public
{
     int number;
     string name;
}
//--3--
/*Use C++ style atributes. All the declarations after the 
attribute declaration have the attribute. If you declare another 
attribute the same way after that, then the old attribute is 
replaced with the new one for the declarations that follow*/
public:
     int number;
     string value;
private:
     //everything below is private
Aug 03 2013
parent "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 09:24:25 UTC, Bosak wrote:

 "The D Programming Language" is kind of old and out of date for
 the current version of D. There aren't many books for D so you
 have not much choice.
 Attributes can be declared with 3 different syntaxes. For
 example one could write:
 //--1--
 /*Explicitly state attribute before every declaration*/
 public int number;
 public string name;
 //--2--
 /*State the attribute and then curly brackets and all the
 declarations inside have the attribute specified. Also note
 that those brackets don't introduce a new scope*/
 public
 {
     int number;
     string name;
 }
 //--3--
 /*Use C++ style atributes. All the declarations after the 
 attribute declaration have the attribute. If you declare 
 another attribute the same way after that, then the old 
 attribute is replaced with the new one for the declarations 
 that follow*/
 public:
     int number;
     string value;
 private:
     //everything below is private


Thank you Bosak, I managed to glean as much from the 
'Attributes'[http://dlang.org/attribute.htm] page. What tripped 
me up is the redundancy in the 'import' declaration 
[http://dlang.org/module.html#ImportDeclaration].

If you follow the documentation (as it currently stands) to it's 
conclusion then the following should be valid D:

static {
   *static* import teleport;
   *static* import time_travel, warp;
}

--AND--

static:
   *static* import teleport;
   *static* import time_travel, warp;


Whereas all the following constructions can just as easily be 
parsed when the 'static import ImportList ;' production is 
removed from 'ImportDeclaration'.

static {
   import teleport;
   public import time_travel, warp;
}

static:
   import teleport;
   public import time_travel, warp;

public:
   import teleport;
   static import time_travel, warp;

private:
   import teleport;
   static import time_travel, warp;

along with the more standard fare:

import std.stdio;
import phobos.std.stdio;
import foo, bar;
static import stat.std.stdio;
public import pub.stdio;
static import teleport, time_travel, warp;
import list = util.container.finite.linear.list;
import widget : fun, gun;
import std.stdio : writefln, foo = writef;


The only issue for the parser is that I need to keep track of the 
implied block for the 'Attribute :' construction. By that I mean 
that the parse trees for X in 'public { X }' and 'public: X' 
should probably be indistinguishable, and naively rewriting 
'Attribute :' into 'Attribute : DeclDefs?' will not do.
Aug 03 2013