"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vk5gl$4hk$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9vj9l0$2n1j$2@digitaldaemon.com...
> > There's a related issue for declarations, is:
> >
> >     a * b;
> >
> > a declaration or an expression? Currently, the ambiguity is resolved
with
> > the rule "if it will parse as a declaration, it is a declaration". I'm
not
> > particularly thrilled with that, as it requires lookahead in the parser.
> One
>
> If "a" is type in current scope, it's a declaration;
> If "a" is something else, it's an expression, so:
>
>     class Apple { }
>
>     int main()
>     {
>         Apple * x;    // x is pointer to apple
>         int Apple;
>         Apple * y;    // multiply Apple by y
>     }

The trouble there is I am trying to separate the syntactic from the semantic. Recognizing that an identifier is a type requires semantic analysis (i.e. building a symbol table). The separation of the two functions will make it easy to write things like source code formatters and analyzers.

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:9vj9l0$2n1j$2@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:9vhegn$1l01$1@digitaldaemon.com...
> > I'm still in a bit of a quandary about casts. Should casting be:
> >
> >     (type)expression
> >
> > or:
> >
> >     cast(type)expression
> >
> > ? The latter is far easier to parse. I'm so used to the former I am reluctant to give it up. A kludgy compromise might be allowing the
former
> > only for types that start with a keyword, not a typedef.

I prefer the keyword way. It's always easier to find a cast in a
million-operand expression
(like one of my co-workers does ever and ever) if the editor highlight the
keyword in the
middle of it.
As for the syntax, I once thougth about it for days, without finding a good
solution.
I think the type should be separated from the expression for clearity.
So (type)cast(expression) is better for me (though ugly...), or
cast[type](expression) or
(type)##(expression), etc...  I still don't have the right idea :-(

> There's a related issue for declarations, is:
>
>     a * b;
>
> a declaration or an expression? Currently, the ambiguity is resolved with the rule "if it will parse as a declaration, it is a declaration". I'm not particularly thrilled with that, as it requires lookahead in the parser.
One
> solution is to require a "var" keyword in front of declarations. But to my eyes, typing all those var's in is annoying:
>
>     void func()
>     {    var int i,j;
>          var X* y;
>         ....
>     }

This is another thing I always thought of. Again, I found no better way.
The fact is that typing 'var' or something at every declaration is abig
waste of
typing. But:

var {
    int i;
    X* j;
}                // <-- this should not limit the scope :-(

i : int;
j : X*;                // good ole Pascal! But
a : int = 6 * K;   // where's the initializer? after the type :-(

# int i;
# X* j;
 An operator is not always better than a keyword :-(

Anything anyone?

"Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:9vk5gl$4hk$1@digitaldaemon.com...
> If "a" is type in current scope, it's a declaration;
> If "a" is something else, it's an expression, so:
>
>     class Apple { }
>
>     int main()
>     {
>         Apple * x;    // x is pointer to apple
>         int Apple;
>         Apple * y;    // multiply Apple by y
>     }

Please, save me from this! ;-)

I guess you can't have everything.  Either that or you have the coder specify 'var' in front of all declarations.  I for one wouldn't mind that, since it clears up so many other things.  I did just that in fact when programming Pascal for all those years.  I was far more upset about having to type 'begin' and 'end' and 'then' and 'do' all over the place than I ever was about telling the compiler I'm about to do a variable declaration.

If you ask me, anyone writing a source code analyzer or formatter can easily check for variable declarations and typedefs so it knows what symbols are what at current scope.  It doesn't even really need to keep track of the exact type, just that a variable or type has been declared there with that name.  Source beautifiers builtin to the IDE is something I'd really love to see, so if doing that means the IDE has to keep track of declarations, well, that's nothing VB or VC hasn't been doing for many years now already.  Hell, Instant Pascal way back on the Apple II did that.  So did Think Pascal on the Mac.  Then again Pascal used the var keyword.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9vk9nj$8eq$3@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vk5gl$4hk$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:9vj9l0$2n1j$2@digitaldaemon.com...
> > > There's a related issue for declarations, is:
> > >
> > >     a * b;
> > >
> > > a declaration or an expression? Currently, the ambiguity is resolved
> with
> > > the rule "if it will parse as a declaration, it is a declaration". I'm
> not
> > > particularly thrilled with that, as it requires lookahead in the
parser.
> > One
> >
> > If "a" is type in current scope, it's a declaration;
> > If "a" is something else, it's an expression, so:
> >
> >     class Apple { }
> >
> >     int main()
> >     {
> >         Apple * x;    // x is pointer to apple
> >         int Apple;
> >         Apple * y;    // multiply Apple by y
> >     }
>
> The trouble there is I am trying to separate the syntactic from the semantic. Recognizing that an identifier is a type requires semantic analysis (i.e. building a symbol table). The separation of the two
functions
> will make it easy to write things like source code formatters and
analyzers.

I just thought of something.  Yes, typing var is kinda annoying.  But how about if one could type the keyword 'var' fairly infrequently, such as:

var:
   int a;
   int b;
   Foo myfoo;

Or perhaps:

var
{
   int a;
   int b;
   Foo myfoo;
}

Or even perhaps this (I think I like this one best):

var int a, int b, Foo myfoo; // can declare multiple vars of different types with one var keyword

or

var int a, b, Foo myfoo, c; // b is also an int, but myfoo and c are both Foo's

Whaddya think?  Maybe we could subsitute 'public' or 'private' for the 'var' keyword instead?

public  // statements can't go inside public blocks.
{
  int a, b;
  Foo myfoo;
}

public:  // begin a public declara
  int i, j;
for (i=0; i<5; ++i)   // this statement terminates the previous public
section.  However here we run into the original problem again.  Perhaps
disallow the 'label:' style attribute format?
{
   j += i;
}
public:
  int c;

Sean

> > There's a related issue for declarations, is:
> >
> >     a * b;
> >
> > a declaration or an expression? Currently, the ambiguity is resolved
with
> > the rule "if it will parse as a declaration, it is a declaration". I'm
not
> > particularly thrilled with that, as it requires lookahead in the parser.
> One
> > solution is to require a "var" keyword in front of declarations. But to
my
> > eyes, typing all those var's in is annoying:
> >
> >     void func()
> >     {    var int i,j;
> >          var X* y;
> >         ....
> >     }
>
> This is another thing I always thought of. Again, I found no better way.
> The fact is that typing 'var' or something at every declaration is abig
> waste of
> typing. But:
>
> var {
>     int i;
>     X* j;
> }                // <-- this should not limit the scope :-(
>
> i : int;
> j : X*;                // good ole Pascal! But
> a : int = 6 * K;   // where's the initializer? after the type :-(
>
> # int i;
> # X* j;
>  An operator is not always better than a keyword :-(
>
> Anything anyone?

"Walter" <walter@digitalmars.com> wrote in message news:9vk9nj$8eq$3@digitaldaemon.com...

> The trouble there is I am trying to separate the syntactic from the semantic. Recognizing that an identifier is a type requires semantic analysis (i.e. building a symbol table). The separation of the two
functions
> will make it easy to write things like source code formatters and
analyzers.

Yes, I see. Personally, I woudln't mind typing "var" here and there, got quite used to it in Pascal and then UnrealScript...

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkeno$b0s$1@digitaldaemon.com...

> Or perhaps:
>
> var
> {
>    int a;
>    int b;
>    Foo myfoo;
> }

Sounds good.

> Or even perhaps this (I think I like this one best):
>
> var int a, int b, Foo myfoo; // can declare multiple vars of different
types
> with one var keyword
>
> or
>
> var int a, b, Foo myfoo, c; // b is also an int, but myfoo and c are both Foo's

Yeah... looks somewhat like VB.NET declarations, but I like the idea. And should have no problem being parsed.

> Whaddya think?  Maybe we could subsitute 'public' or 'private' for the
'var'
> keyword instead?

"local"?

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vke8m$amq$1@digitaldaemon.com...
> I guess you can't have everything.  Either that or you have the coder specify 'var' in front of all declarations.  I for one wouldn't mind that, since it clears up so many other things.  I did just that in fact when programming Pascal for all those years.  I was far more upset about having to type 'begin' and 'end' and 'then' and 'do' all over the place than I
ever
> was about telling the compiler I'm about to do a variable declaration.

Having the "if it parses as a declaration, it is a declaration" rule does seem to work.

> If you ask me, anyone writing a source code analyzer or formatter can
easily
> check for variable declarations and typedefs so it knows what symbols are what at current scope.  It doesn't even really need to keep track of the exact type, just that a variable or type has been declared there with that name.  Source beautifiers builtin to the IDE is something I'd really love
to
> see, so if doing that means the IDE has to keep track of declarations,
well,
> that's nothing VB or VC hasn't been doing for many years now already.
Hell,
> Instant Pascal way back on the Apple II did that.  So did Think Pascal on the Mac.  Then again Pascal used the var keyword.

VC has had millions of man-hours of development in it - and with access to a full blown compiler, you can tell if an identifier is a type or not. To do so in D, you'd have to find all the imports, parse them all, etc., just like in a full blown compiler to be able to tell with certainty if it's a type or not. You can fake it and work 93% of the time, but getting that last 7% right requires the whole thing. Most C beautifers that aren't hooked into a full blown compiler get it right about 93% of the time. Heck, many of them don't even handle the \ line splice completely correctly.

With D, the idea is it can be gotten 100% correct with only a modest effort by one person.

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:9vkbg9$9d5$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:9vk5gl$4hk$1@digitaldaemon.com...
> > If "a" is type in current scope, it's a declaration;
> > If "a" is something else, it's an expression, so:
> >
> >     class Apple { }
> >
> >     int main()
> >     {
> >         Apple * x;    // x is pointer to apple
> >         int Apple;
> >         Apple * y;    // multiply Apple by y
> >     }
>
> Please, save me from this! ;-)

Currently, D issues the following error message for the Apple*y:

symbol 'Apple' is not a type

Walter wrote:

> 
> "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:9vkbg9$9d5$1@digitaldaemon.com...
>>
>> "Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:9vk5gl$4hk$1@digitaldaemon.com...
>> > If "a" is type in current scope, it's a declaration;
>> > If "a" is something else, it's an expression, so:
>> >
>> >     class Apple { }
>> >
>> >     int main()
>> >     {
>> >         Apple * x;    // x is pointer to apple
>> >         int Apple;

In my opinion 'int Apple' should better raise an error if Apple is defined as type. Shadowing is nice in theory, and looks cool in compiler implementation, but is bad in practice, as it is error prone for the programmer who easy mismatches a variable/type when it's understanding differes from context.