"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:btmmt0$12nl$1@digitaldaemon.com...
> Ben Hinkle wrote:
> > Even if you import foo and bar?? I thought that was the whole point of
> > import - to bring symbols into the current scope.
> > Is anyone really suggesting that this mechanism should work *without*
> > requiring import statements?
>
> Import doesn't bring a module into your scope. It only adds it to module search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module.
>
> We had been already arguing with Walter about that. And that this approach is, well, at least somewhat "surprising".
>
> If you make overloads of one function in one module, and some in another, and import both in yours, only one set of overloads should work. The other should be acessible through the module name point notation only.

Importing a modules adds all the toplevel declarations to the current scope *but* what I had not considered was that functions are not exempt from the rule about ambiguous symbols (which if this is what you mean then yes, I think that is a problem with the language since that is the whole point of function overloading).

Using aliases after importing does work with the current language spec, though I was assuming it wasn't needed for functions. For example:

file1.d:
import file2;
alias file2.func func;
import file3;
alias file3.func func;
int main(char[][] args)
{
    func(1);
    func("hello");
    return 0;
}

file2.d
void func(char[] x)
{
    printf("char[] func\n");
}

file3.d:
void func(int x)
{
    printf("int func\n");
}

ugh-ly.

> >>They are not. That's the reason cross-module overloads don't work. They don't work for normal functions. And for operators, it is simply bloody forbidden to use module scope, because it would not make the problem better, just worse!
>
> > Again, that is what "import" is for.
>
> Again, you don't seem to listen, nor to read!

ouch!

>
> -eye.
>

Ilya Minkov wrote:
> Ben Hinkle wrote:
 > Import doesn't bring a module into your scope. It only adds it to module
> search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module.
> 

thats good to know, thanks

Streams are another kind of iterator (input, or output).

It's also another one of those situations that must be extended to any type, and where the code that controls the iteration (exactly what to print) is typically written well after the code that deals with each iteration (how to print each kind of thing) which is written well after the buffering code. But the later code can't be fast unless the buffering code is spread out throughout the outer function calls (heavily inlined to the point where the generated code is just writing bytes directly where they go in the stream buffer, advancing the buffer pointer or calling to allocate more memory periodically).

This is hard.  It needs some kind of code injection that you can do in C++ by class wrapping, but not so easily in D (no real dtors, ill-defined order of shutdown, etc).

Anyway we need to be able to extend it in quite a few different ways.  We need to be able to add new types that can be input or output, or saved and loaded, we need to be able to add new types that can act as streams, and hopefully integrate with the container classes somehow to the point where you could say:

sys.outstream s;
int c[100];
s.print(c[]);

or, better, something like:

s.print(intersperse(c[], ','));

Sean

"davepermen" <davepermen_member@pathlink.com> wrote in message news:btlt7b$2t6n$1@digitaldaemon.com...
> operators have to be in the module you use them (sort of private
operators), or
> in one of the modules of one of the used types. just as overloadable
functions,
> more or less..
>
> on the other hand.. the
>
> print(..) { /+ defines this is chainable +/ } // only two dots, like in
[x..y]
> print(int x) { printf("%i",x); }
> print(char[] x) { printf("%.*s",x); }
> print(vec3 x) { printf("(%f,%f,%f)",x.x,x.y,x.z); }
>
> etc
>
> wich concatenates
>
> print("Hello World, my Name is ",davepermen," I'm ",19," and i life at
> ",position);
>
> wich will then map to
> print(char[]); // print("Hello World, my Name is ");
> print(char[]); // print(davepermen);
> print(char[]); // print(" I'm ");
> print(int);    // print(19);
> print(char[]); // print(" and i life at ");
> print(vec3);   // print(position);
>
> and if this is too implicit, possibly we have to call the function more
like
> this:
>
> print..("Hello World, my Name is ",davepermen," I'm ",19," and i life at ",position); // note the two dots..
>
> or even
>
> print("Hello World, my Name is "..davepermen.." I'm "..19.." and i life at "..position); // hm, a real stream-chain operator
>
> how to mix that with oo? dunno.. :|
>
> anyways.. lot to think about.. how to make the language flexible
extendable
> without issues for the compiler?
>
> one word, walter: shit
>
> :D at least you see my points as well.. now lets find some way to work
this out.
> and then, syntax-sugar it as much as possible:D
>
> In article <btlq6k$2obr$1@digitaldaemon.com>, Walter says...
> >
> >
> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:bthndh$2jdb$1@digitaldaemon.com...
> >> i do understand that. but you simply can't overload your prefered
operator
> >for
> >> ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.
> >> free overloadable functions give the ability to add overloads to your
> >stream
> >> without any rewriting of stream or type.
> >>
> >> THAT is why i want free operators. they are the way operators behave,
and
> >they
> >> are the only way to make streams fast extendable and type save. and
FAST.
> >> everyone cries that they have to be faster than the c++ streams.
believe
> >me they
> >> can be hell fast. and i can for sure overload all sort of types for my
> >stdout
> >> class and then write stdout << a << b << c; but this is nost scalable.
> >>
> >> a library ALWAYS has to provide features a user can use for ANY
situation.
> >that
> >> means he has to have a nice plugin-interface. overloadable free
operators
> >are a
> >> GREAT plugin-interface for streams.
> >
> >I understand your point. But there's got to be a better way than ADL.
> >
> >
>
>

What, do you have to use ..?

with (myalgebra.opAdd)
{
    myalgebra.vecter a,b,c;
    a = b + c;
}

that's the thing with C++, is that all operators are visible all the time, once they're imported, and the only restriction is that the types have to match one of the overloads or be convertible.  You could go and choose one specifically, but you could obtain the same effect by casting the inputs. Most of the time you want all visible scopes searched for operators, not only an "outward" search that stops at the first match.

I find this restrictive on enums as well.  I should have to specify a particular enum type name only if the enum type actually has a name, or only if there is some conflict and I have to choose.

Please get the visibility rules right.

Sean

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:btmmt0$12nl$1@digitaldaemon.com...
> Ben Hinkle wrote:
> > Even if you import foo and bar?? I thought that was the whole point of
> > import - to bring symbols into the current scope.
> > Is anyone really suggesting that this mechanism should work *without*
> > requiring import statements?
>
> Import doesn't bring a module into your scope. It only adds it to module search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module.
>
> We had been already arguing with Walter about that. And that this approach is, well, at least somewhat "surprising".
>
> If you make overloads of one function in one module, and some in another, and import both in yours, only one set of overloads should work. The other should be acessible through the module name point notation only.
>
> >>They are not. That's the reason cross-module overloads don't work. They don't work for normal functions. And for operators, it is simply bloody forbidden to use module scope, because it would not make the problem better, just worse!
>
> > Again, that is what "import" is for.
>
> Again, you don't seem to listen, nor to read!
>
> -eye.
>

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bthrlf$2p6n$2@digitaldaemon.com...
> Hauke Duden wrote:
> Read the manual. Overloads are only possible within one scope. That
> means, when defined on the module level, overloads only work correctly
> within that module. If defined within a class, only within a class. And
> so on.
>
> > If I have two modules, foo and bar, each with a different version of function f, and I call f in another module, isn't that the exact same problem, as if f was an opAdd overload and the call an expression of the kind (a+b)?
>
> The problem is, it doesn't work.

You can make it work by using an alias to overload a function in one module's scope with a function in another module's scope:

    import bar;
    void foo(int);
    alias bar.foo(uint) foo;

Of course, this has to be done deliberately rather than implicitly. There isn't a global scope in D, which I think is a good thing when managing very large programs.