"Sean Kelly" <sean@f4.ca> wrote in message news:djjrin$1q93$1@digitaldaemon.com...
> When I try to compile stddef I get this error:
>
> C:\bin\dmd\src\ares\std\c>dmd -c stddef.d
> stddef.d(10): size of type typeof(4) is not known
>
> When I move the alias into object.d however, the error goes away.  This
pattern
> worked fine when I was using version blocks to define the size_t alias, so
it's
> something to do with typeof.  Any ideas?

I can't reproduce the error.

>> And i also agree. This way you cannot have auto objects with type
>> inference and it is a problem. Couldn't another keywoard be added for
>> type inference? Many have been suggested (autotype, var, ...).
>
> I've tried to stay away from 'var', it reminds me of Pascal too much <g>.
>
> Anyhow, I've thought about this problem a lot, and there is an answer for it
> that is simple and consistent. It's just a bit of work to implement :-(.

Huh? Could you please explain that briefly? I am currently writing a compiler myself, and i thought a lot about this problem. Declarations and expressions can look very similar at the beginning, and it requires a lot of lookahead for the parser to decide between the two (which is annoying, as the lexer is more difficult then). I fumbled around with "var" and friends, too, but it looks so annoying if you have to write it everywhere.

Associative arrays in the current syntax are sometimes simply undistinguishable from static arrays without context knowledge (so the D language is not 100% context-free), as in:

char[something] x;

To decide if x is a static or associative array, you need to know whether "something" is a type or a constant. I have not found a nice solution for this problem yet (things like char[type something] look rather disgusting). By the way, this problem is quite similar to the C cast syntax (where the parser is also unable to decide between type and expression).

Ciao
uwe

Is the answer for it is to use a new keyword or to make the compiler smarter ?
Just curious
:D
Sai


In article <djlsi7$4u4$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:djlqvi$2tn$1@digitaldaemon.com...
>> And i also agree. This way you cannot have auto objects with type inference and it is a problem. Couldn't another keywoard be added for type inference? Many have been suggested (autotype, var, ...).
>
>I've tried to stay away from 'var', it reminds me of Pascal too much <g>.
>
>Anyhow, I've thought about this problem a lot, and there is an answer for it that is simple and consistent. It's just a bit of work to implement :-(.
>
>

"Sai" <Sai_member@pathlink.com> wrote in message news:djm1oj$p58$1@digitaldaemon.com...
> Is the answer for it is to use a new keyword or to make the compiler
smarter ?

It's implementing class objects on the stack with the:
    classname(constructor arguments)
syntax. Then, an RAII class object would be:

    auto c = classname(arguments);

and a non-RAII class object would be:

    auto c = new classname(arguments);

and the old RAII syntax would be supported as:

    auto classname c = new classname(arguments);

and eventually deprecated.

"Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.sy7vgtpb6yjbe6@sandmann.maerchenwald.net...
> Huh? Could you please explain that briefly? I am currently writing a compiler myself, and i thought a lot about this problem. Declarations and expressions can look very similar at the beginning, and it requires a lot of lookahead for the parser to decide between the two (which is annoying, as the lexer is more difficult then). I fumbled around with "var" and friends, too, but it looks so annoying if you have to write it everywhere.

Yes, I've (obviously) run into the same problems. It's not an LALR(1)
grammar (one token lookahead), but doing LALR(1) would have compromised the
look & feel I was trying to achieve. So arbitrary lookahead (LALR(n)) is
needed. (A nit: it isn't a lexer problem, it's a parsing problem.) The lexer
was designed from the start so that arbitrary lookahead is easy to do.

> Associative arrays in the current syntax are sometimes simply undistinguishable from static arrays without context knowledge (so the D language is not 100% context-free), as in:
>
> char[something] x;
>
> To decide if x is a static or associative array, you need to know whether "something" is a type or a constant. I have not found a nice solution for this problem yet (things like char[type something] look rather disgusting). By the way, this problem is quite similar to the C cast syntax (where the parser is also unable to decide between type and expression).

This isn't a big problem to deal with, because the resulting parse tree is the same whether it turns out to be a static array or an associative array. The D parser just creates it as an associative array. If the identifier turns out during semantic analysis not to be a type, but an expression, the type is rewritten as a static array. Since the parse tree remains the same, I believe it technically is a context-free grammar.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:djmgi6$1jtr$1@digitaldaemon.com...
>
> "Sai" <Sai_member@pathlink.com> wrote in message news:djm1oj$p58$1@digitaldaemon.com...
>> Is the answer for it is to use a new keyword or to make the compiler
> smarter ?
>
> It's implementing class objects on the stack with the:
>    classname(constructor arguments)
> syntax. Then, an RAII class object would be:
>
>    auto c = classname(arguments);
>
> and a non-RAII class object would be:
>
>    auto c = new classname(arguments);
>

Hot damn!

> and the old RAII syntax would be supported as:
>
>    auto classname c = new classname(arguments);
>
> and eventually deprecated.
>
> 

Walter Bright escribió:
> "Sai" <Sai_member@pathlink.com> wrote in message
> news:djm1oj$p58$1@digitaldaemon.com...
> 
>>Is the answer for it is to use a new keyword or to make the compiler
> 
> smarter ?
> 
> It's implementing class objects on the stack with the:
>     classname(constructor arguments)
> syntax. Then, an RAII class object would be:
> 
>     auto c = classname(arguments);
> 

Regarding this case, what's gonna happen if "static classname.opCall(whatever)" has been defined?

> and a non-RAII class object would be:
> 
>     auto c = new classname(arguments);
> 
> and the old RAII syntax would be supported as:
> 
>     auto classname c = new classname(arguments);
> 
> and eventually deprecated.
> 
> 


-- 
Carlos Santander Bernal

Walter Bright escribió:
> A couple of oft-requested features.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 

I really like the auto type declaration, but I'd like to suggest something slightly related: can't static strings be of type char[] instead of static char[length]? The problem is that this doesn't work:

auto str = "hi";
str = "hello";


-- 
Carlos Santander Bernal

In article <djmgi7$1jtr$2@digitaldaemon.com>, Walter Bright says...
>
>
>"Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.sy7vgtpb6yjbe6@sandmann.maerchenwald.net...
>> Huh? Could you please explain that briefly? I am currently writing a compiler myself, and i thought a lot about this problem. Declarations and expressions can look very similar at the beginning, and it requires a lot of lookahead for the parser to decide between the two (which is annoying, as the lexer is more difficult then). I fumbled around with "var" and friends, too, but it looks so annoying if you have to write it everywhere.
>
>Yes, I've (obviously) run into the same problems. It's not an LALR(1)
>grammar (one token lookahead), but doing LALR(1) would have compromised the
>look & feel I was trying to achieve. So arbitrary lookahead (LALR(n)) is
>needed. (A nit: it isn't a lexer problem, it's a parsing problem.) The lexer
>was designed from the start so that arbitrary lookahead is easy to do.
>
>> Associative arrays in the current syntax are sometimes simply undistinguishable from static arrays without context knowledge (so the D language is not 100% context-free), as in:
>>
>> char[something] x;
>>
>> To decide if x is a static or associative array, you need to know whether "something" is a type or a constant. I have not found a nice solution for this problem yet (things like char[type something] look rather disgusting). By the way, this problem is quite similar to the C cast syntax (where the parser is also unable to decide between type and expression).
>
>This isn't a big problem to deal with, because the resulting parse tree is the same whether it turns out to be a static array or an associative array. The D parser just creates it as an associative array. If the identifier turns out during semantic analysis not to be a type, but an expression, the type is rewritten as a static array. Since the parse tree remains the same, I believe it technically is a context-free grammar.
>
>

FWIW, I've been playing around with this code recently and it is a beauty to behold how it all comes together (and runs damn fast as well!).

"Carlos Santander" <csantander619@gmail.com> wrote in message news:djmpd4$25oa$2@digitaldaemon.com...
> I really like the auto type declaration, but I'd like to suggest something slightly related: can't static strings be of type char[] instead of static char[length]? The problem is that this doesn't work:
>
> auto str = "hi";
> str = "hello";

I hear you, but it's easier to go from a static array to a dynamic array, but not vice versa. So I think making it a static array type is better.