Hear, hear.

Axel Kittenberger wrote:

> 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.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Think, Russ!  Think, then speak!

I do want to say that I agree with Axel that "shadowing" is not a good thing...maybe even a Bad Thing.  But now that I've thought about it, I've realized that it still doesn't solve the parser problem...the parser has no way of knowing if it's a valid statement or not.

For that, what about just making no-effect lines to be syntax errors (except for
null statements)?  Then any thing that *could* be a declaration (regardless of
context) *must* be one.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C1E6A51.E60BF91A@deming-os.org...
> For that, what about just making no-effect lines to be syntax errors
(except for
> null statements)?  Then any thing that *could* be a declaration
(regardless of
> context) *must* be one.

Hmm. That is a good thought. The no effect error is an irritant in C++, as I use macros that depend on the compiler optimizing away no effect expressions, as in:

    #define printf 1 || printf

and:

    #define assert(e)    0

but in D these become irrelevant, so maybe no effect errors are practical.

It's an intriguing idea. The : version won't work, though, as you'd need some other keyword to turn it off when the statements begin.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkeno$b0s$1@digitaldaemon.com...
> 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?
>
>
>

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9vlm2o$1389$1@digitaldaemon.com...

> 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.

This might be true if Apple was a local class. But what if it resides in other module? In this case, disallowing shadowing would result in breaking code in one module when other gets new type in it - definitely unacceptable...

Russ Lewis wrote:

> Think, Russ!  Think, then speak!
> 
> I do want to say that I agree with Axel that "shadowing" is not a good thing...maybe even a Bad Thing.  But now that I've thought about it, I've realized that it still doesn't solve the parser problem...the parser has no way of knowing if it's a valid statement or not.
> 
> For that, what about just making no-effect lines to be syntax errors
> (except for
> null statements)?  Then any thing that *could* be a declaration
> (regardless of context) *must* be one.

Not necessarly true, the lexer can do type lookups, and return differnt tokens as i.e. mine did. That how I solved the grammatical problem how to differentiate ie.

asdf[2][2] a;
asdf[2][2] = a;

Is "asdf" meant to be the type (declaring an 2x2 array of it) or a identifier accessing the 2/2th element of it? Yes, it is technically distinguishable but not with 1 token lookahead, or with any definitive size of lookahead. To distingish "asdf" between type or variable you need 3 * field dimenions look ahead, where the dimension is normally unlimited.

- Axel

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9voc5a$2vrg$1@digitaldaemon.com...
> Not necessarly true, the lexer can do type lookups, and return differnt tokens as i.e. mine did. That how I solved the grammatical problem how to differentiate ie.
>
> asdf[2][2] a;
> asdf[2][2] = a;
>
> Is "asdf" meant to be the type (declaring an 2x2 array of it) or a identifier accessing the 2/2th element of it? Yes, it is technically distinguishable but not with 1 token lookahead, or with any definitive
size
> of lookahead. To distingish "asdf" between type or variable you need 3 * field dimenions look ahead, where the dimension is normally unlimited.
>
> - Axel

That's why I wound up implementing arbitrary lookahead. -Walter

Walter wrote:

> I'm still in a bit of a quandary about casts. Should casting be:
> 
>     (type)expression
> 
> or:
> 
>     cast(type)expression
> 
>...

Casts are one of my least liked features of C and C++.  Better is a language design that, to the greatest extent possible, eliminates the need for casts.  Still, given the occasional need, I prefer the form:
     cast(type, expression)
Or even:
     cast("type", expression)
though that seems a bit strange.  But so does the idea of passing a type as an argument (unless the language should be extended to make that a "normal" activity).  The thing that bothers me about it is that in this expression the type appears to be a parameter, but normally types aren't allowed to be parameters, and this feels ... unnatural.

Charles Hixson wrote:

> Walter wrote:
> 
>> I'm still in a bit of a quandary about casts. Should casting be:
>>
>>     (type)expression
>>
>> or:
>>
>>     cast(type)expression
>>
>> ...
>


On reading other posts I encountered the proposal to use the syntax:
expression.as(type)

This syntax would be quite clear, but seems to be problematic as it would require that a method be allowed to return a variable type, e.g.:
    (e.as(int) < e.as(Point))
clearly this is somewhat problematical.  OTOH, this same problem is exhibited when one examines an alternate syntax, e.g.:
    (cast (int, e) < cast (Point, e) )
but I suppose that cast may more clearly be considered a "special form".  I dislike special forms, but perhaps they are necessary unless type is a "first class" entity in the language.

Now clearly either of the examples that I used should cause an error (the types int and Point being incommensurate), and this would be true no matter what the syntax.  The inconsistency arises because one can usually depend on methods and functions to return one particular type (or at least a descendant of some particular type).  So it "feels wrong" to have the syntax used in a contrary manner.

The "cleanest way" around this that occurs to me is to eliminate the cast operation, and require the creation of a union for each dually accessed entity.  But for this to be acceptable the frequency with which a cast had to be used would need to be quite low.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3C335780.6070609@earthlink.net...

> This syntax would be quite clear, but seems to be problematic as
> it would require that a method be allowed to return a variable
> type, e.g.:
>      (e.as(int) < e.as(Point))

I don't see any problem e.as(int) returns a value of type int.
e.as(Point) returns a value of type Point. Of course, as() is
a built-in method then.

> The "cleanest way" around this that occurs to me is to eliminate the cast operation, and require the creation of a union for each dually accessed entity.  But for this to be acceptable the frequency with which a cast had to be used would need to be quite low.

Man have you ever tried to code staight WinAPI programs like that? Besides, D (as I understand it) is not a "cleanest" language - it's a _practical_ language. Which means that it tries to make our live easier rather than "cleaner" (the latter is important as well, of course!). Forbidding casts is definitely not the right step in this direction...