Currently code like

   import c.stdio;
   ...
   char c;
   char buf[256];
   c.stdio.fgets(&buf[0],buf.size,c.stdio.stdin);
   c=buf[0];

won't compile because of an

   no property 'stdio' for type 'char'

error.

Could this be changed, so that the compiler checks for an interpretation that makes sense if there a more than one? Otherwise any module in any library is a potential candidate for such collisions!

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

In article <3EE2FA45.29B11971@chello.at>, Helmut Leitner says...
>
>Currently code like
>
>   import c.stdio;
>   ...
>   char c;
>   char buf[256];
>   c.stdio.fgets(&buf[0],buf.size,c.stdio.stdin);
>   c=buf[0];
>
>won't compile because of an
>
>   no property 'stdio' for type 'char'
>
>error.
>
>Could this be changed, so that the compiler checks for an interpretation that makes sense if there a more than one? Otherwise any module in any library is a potential candidate for such collisions!
It seems that D modules and other D elements need their own name space for compilation purposes like C does. "More than one" shouldn't have anything to do with it.

You can work around this by prepending the module name:

module foo;
...
foo.c.stdio.fgets(...

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EE2FA45.29B11971@chello.at...
> Currently code like
>
>    import c.stdio;
>    ...
>    char c;
>    char buf[256];
>    c.stdio.fgets(&buf[0],buf.size,c.stdio.stdin);
>    c=buf[0];
>
> won't compile because of an
>
>    no property 'stdio' for type 'char'
>
> error.
>
> Could this be changed, so that the compiler checks for an interpretation that makes sense if there a more than one? Otherwise any module in any library is a potential candidate for such collisions!
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

In the next version, I've added a module scope operator, ., which should resolve this problem properly, as in:

.c.stdio.fgets(&buf[0],buf.size,.c.stdio.stdin);

It works analogously to the C++ global scope operator ::.


"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EE2FA45.29B11971@chello.at...
> Currently code like
>
>    import c.stdio;
>    ...
>    char c;
>    char buf[256];
>    c.stdio.fgets(&buf[0],buf.size,c.stdio.stdin);
>    c=buf[0];
>
> won't compile because of an
>
>    no property 'stdio' for type 'char'
>
> error.
>
> Could this be changed, so that the compiler checks for an interpretation that makes sense if there a more than one? Otherwise any module in any library is a potential candidate for such collisions!
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

In article <bc3343$1dgn$1@digitaldaemon.com>, Walter says...
>
>In the next version, I've added a module scope operator, ., which should resolve this problem properly, as in:
>
>.c.stdio.fgets(&buf[0],buf.size,.c.stdio.stdin);
>
>It works analogously to the C++ global scope operator ::.

IMHO this looks really ugly,  doesn't "import" give enough info to avoid this ??

I thought the whole idea was to be cleaner than C++.

"Mark T" <Mark_member@pathlink.com> wrote in message news:bc9r3j$1bpm$1@digitaldaemon.com...
> In article <bc3343$1dgn$1@digitaldaemon.com>, Walter says...
> >
> >In the next version, I've added a module scope operator, ., which should resolve this problem properly, as in: .c.stdio.fgets(&buf[0],buf.size,.c.stdio.stdin);
> >
> >It works analogously to the C++ global scope operator ::.
>
> IMHO this looks really ugly,  doesn't "import" give enough info to avoid
this ??

No.

> I thought the whole idea was to be cleaner than C++.

If there's a better way to resolve that problem, I want to know about it!

>> >It works analogously to the C++ global scope operator ::.
>>
>> IMHO this looks really ugly,  doesn't "import" give enough info to avoid
>this ??
>
>No.
>
>> I thought the whole idea was to be cleaner than C++.
>
>If there's a better way to resolve that problem, I want to know about it!

I think this should be studied together with the Private Import b.a.A issue.

Maybe a lot of folks have reasoned deeply into this, but so far the
recent discussion here about this has been shallow, almost like
"this looks nice, lets do it this way", when we should really
consider the _meaning_ of imports, private imports, indirect
inclusion (i.e. the b.a.A issue), visibility, and propagation
of visibility, as manifestations of a single concept.
Like _what_ is one really attempting to acheve with all these.

We ought to get a crystal clear understanding, not least because if this is done wrong now then later there'll be hell to pay.

Once we understand this, then the separate answers to these "separate" issues, I believe, will become obvious.

Georg Wrede wrote:
> >If there's a better way to resolve that problem, I want to know about it!
> 
> I think this should be studied together with the Private Import b.a.A issue.
> 
> Maybe a lot of folks have reasoned deeply into this, but so far the
> recent discussion here about this has been shallow, almost like
> "this looks nice, lets do it this way", when we should really
> consider the _meaning_ of imports, private imports, indirect
> inclusion (i.e. the b.a.A issue), visibility, and propagation
> of visibility, as manifestations of a single concept.
> Like _what_ is one really attempting to acheve with all these.
> 
> We ought to get a crystal clear understanding, not least because if this is done wrong now then later there'll be hell to pay.
> 
> Once we understand this, then the separate answers to these "separate" issues, I believe, will become obvious.

I think you are absolutely right.

I'm unhappy about the current situation but I can't offer a solution. But I think we should try to discuss this more thoroughly.

Walters viewpoint as a compiler builder is naturally quite different from your viewpoint as an academic teacher. There are a number of other viewpoints in this group. I would summarize my own viewpoint as that of an "pragmatic application programmer".

I started 1979 with an USCD Pascal statistical project done on an Apple II and I did about 120 projects during these 24 years. Currently I actively work at 5 projects and maintain about a dozen Most are written in C, Perl or VB. I own my code and I therefore care for my code and its reusability in a special way.

In all my projects I want to create a single language space. I think of programming as building a new language on top of the programming language and the selected tool libraries. This new language should maintain its semantics across all borders of modules, projects and libraries without additional effort.

In VB and Perl you work in a single namespace.

In C you can work with a central header file, if you have collisions you will see them while compiling this central header, thats fine.

In D you can use a central header file but the collisions are distributed across place and time. They turn up every now and then. This is IMHO an unbearable situation. It must be possible to change the language space and see its effects (correct any resulting problems) at the time of change.

After separated decisions about the language space from the actual
source written, it must be possible to use the selected functions
in their native form. The problem I started this thread with,
that the variable
   char c;
created a problem to call
   fgets(...)
can't be considered solved when a syntactical solution like
   .c.stdio.fgets(...)
is possible. (The compiler builder will think so)

It would be solved, when I can decide:
   prefer c.stdio over phobos.file;
or:
   priorities: variable.namespace,c.stdio,phobos.file,....;

where I can direct the compiler how to resolve ambiguities on a
project level or a higher level.

Solving such things at the source or module level creates
"local language" and makes code dependant on these local decisions.
This makes code hard to read, move, refactor and reuse.

The projects of tomorrow will make us work with 10.000+ functions/methods/modules. Individually importing the mecessary modules and resolving conflicts is a mess.

IMHO.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> [...]
> 
> After separated decisions about the language space from the actual
> source written, it must be possible to use the selected functions
> in their native form. The problem I started this thread with,
> that the variable
>    char c;
> created a problem to call
>    fgets(...)
> can't be considered solved when a syntactical solution like
>    .c.stdio.fgets(...)
> is possible. (The compiler builder will think so)
> 
> It would be solved, when I can decide:
>    prefer c.stdio over phobos.file;
> or:
>    priorities: variable.namespace,c.stdio,phobos.file,....;
> 
> where I can direct the compiler how to resolve ambiguities on a project level or a higher level.
>      Solving such things at the source or module level creates "local language" and makes code dependant on these local decisions.
> This makes code hard to read, move, refactor and reuse.
> 
> The projects of tomorrow will make us work with 10.000+ functions/methods/modules. Individually importing the
> mecessary modules and resolving conflicts is a mess. 
> 
> IMHO.
> 

I think the solution in this case is pretty simple.  Remove the fgets definition from phobos.file.  In fact, it's not in my copy (0.66) at all, so I can't see the problem happening.

If push comes to shove, you could always make an alias:

   alias fgets .c.stdio.fgets;

Private imports should further alleviate this situation, as we now have explicit control over what gets dumped into a namespace.

Mark T wrote:
> In article <bc3343$1dgn$1@digitaldaemon.com>, Walter says...
> 
>>In the next version, I've added a module scope operator, ., which should
>>resolve this problem properly, as in:
>>
>>.c.stdio.fgets(&buf[0],buf.size,.c.stdio.stdin);
>>
>>It works analogously to the C++ global scope operator ::.
> 
> 
> IMHO this looks really ugly,  doesn't "import" give enough info to avoid this ??
> 
> I thought the whole idea was to be cleaner than C++.

You have a point. How about...

module.c.stdio.fgets(&buf[0],buf.size,module.c.stdio.stdin);

By reusing the 'module' keyword to resolve the collision
you would also make it absolutly clear what is happening.

(The module keyword, as it is only used once in a file
written under the current D specifications should parse
easily in this situation.)

Having to resolve a collision would be a fairly rare
occurance with well chosen module names so having to
type 'module.' before the resolution should not be
required often.

Comments on this proposal anyone?

C 2003/6/13