Would it be possible to keep imports out of the symbol table? For example, this won't compile:

import timer;

TIMERCLASS timer;

...because the instance timer conflicts with the import name. There doesn't seem to be any need for the import name in among the symbols, or at least none that I can see.

Dan

Hmmm, I suppose disambiguating a name by prefixing the module is the problem. That could be solved through a naming convention. One could also complicate the syntax and use something other than "." for module disamibuation -- an example for below is timer.Reset(): does it call the Reset() function in module timer, or the method of class TIMERCLASS?.  Use timer::Reset() for the module?   I suppose that decision's been made...

Dan

"Dan Liebgold" <dliebgold@yahoo.com> wrote in message news:b3kh24$qi0$1@digitaldaemon.com...
> Would it be possible to keep imports out of the symbol table? For example, this won't compile:
>
> import timer;
>
> TIMERCLASS timer;
>
> ...because the instance timer conflicts with the import name. There
doesn't
> seem to be any need for the import name in among the symbols, or at least none that I can see.
>
> Dan
>
>

One thing I tried to get away from is the C++ distinction between ., -> and ::. I also want to get away from all the various context dependent lookup rules in C++, preferring a more straightforward set of rules even if sometimes it results in extra typing.

Of course, D isn't pure this way, as goto labels in functions are in a separate symbol table.

"Dan Liebgold" <dliebgold@yahoo.com> wrote in message news:b3kht8$r4o$1@digitaldaemon.com...
> Hmmm, I suppose disambiguating a name by prefixing the module is the problem. That could be solved through a naming convention. One could also complicate the syntax and use something other than "." for module disamibuation -- an example for below is timer.Reset(): does it call the Reset() function in module timer, or the method of class TIMERCLASS?.  Use timer::Reset() for the module?   I suppose that decision's been made...
>
> Dan
>
> "Dan Liebgold" <dliebgold@yahoo.com> wrote in message news:b3kh24$qi0$1@digitaldaemon.com...
> > Would it be possible to keep imports out of the symbol table? For
example,
> > this won't compile:
> >
> > import timer;
> >
> > TIMERCLASS timer;
> >
> > ...because the instance timer conflicts with the import name. There
> doesn't
> > seem to be any need for the import name in among the symbols, or at
least
> > none that I can see.
> >
> > Dan
> >
> >
>
>

Is there any way we can remove the need for -> for dereferencing pointers?

struct A
{
    int m1, m2;
}

A* pa = new A;

pa.m1 = pa.m2;

But then we get into trouble with pointers to pointers

A* pa = new A;
A** ppa = &pa;

ppa.m1 = ppa.m2;  // requires multiple dereferences

// but what happens if you only wanted to dereference once?

(*ppa + 1).m1 = ppa.m1;  // confusing

Perhaps we could eliminate *p syntax as well?

ppa .  = new A;  // but dot is small and easily overlooked.

In this case there's probably more reasons to stick with C syntax than there are to change it.

Sean



"Walter" <walter@digitalmars.com> wrote in message news:b3tqe6$k47$1@digitaldaemon.com...
> One thing I tried to get away from is the C++ distinction between ., ->
and
> ::. I also want to get away from all the various context dependent lookup rules in C++, preferring a more straightforward set of rules even if sometimes it results in extra typing.