May 12, 2008
Janice Caron, el  9 de mayo a las 05:42 me escribiste:
> I'm not sure there's anything further to say, however. The reason is, when you said "Yes, in my suggestion you need to escape false-newline-end-of-statement", you effectively closed all ambiguities. My arguments were predicated on the assumption that there would be no newline-escaping. That means, your plan /is/ workable - but the price (having to escape newlines) is higher than I want to pay. It becomes a matter of taste. I prefer C-style; you prefer Python-style. Maybe you (or someone else who wants this) can write that conversion tool I mentioned somewhere.

I don't think it's entirely a matter of taste. It saves typing and thus makes the code more readable and easier to maintain. Is like saying "auto" it's just a matter of taste, and you say "auto" is bad because we should always have the redundancy of the type declaration.

> But even with the "you need to escape escape false-newline-end-of-statement" rule, there is still room for silent bugs to creep in. For example:
> 
>     foo(int x)  // Danger!
>     {
>         /* stuff */
>     }

Is this valid D?

> Under your scheme that would have to be rewritten as either
> 
>     foo(int x)  {
>         /* stuff */
>     }
> 
> or
> 
>     foo(int x)  \
>     {
>         /* stuff */
>     }
> 
> or else run the risk of being misparsed as
> 
>     foo(int x);
>     {
>         /* stuff */
>     }
> 
> which often times will be valid D. (Not always, but sometimes - e.g. as an inner function). So unless you go "all the way" and aim for full Python style, you run the risk of introducing some very hard to find bugs.

I don't think that's valid D anyway, but I'll assume you meant:
void foo(int x)
{
    /* stuff */
}

If this is the case, the parser should expect a function definition after a function declaration (since function declaration are not *that* usual in D, I think is the better way to go).

So, for a function declaration and a new block of code you write:
void foo(int x); // ; is mandatory for function declaration
{
    // new block
}

For function definition, you just type:
void foo(int x)
{
    /* stuff */
}


BTW, I know this will never make it into D, I just don't think you have the right reasons. I think the only valid reason to not do it (and a very big one) is that D wants to be in the C-like syntax family, so it *wants* to look like C. The ambiguities, redundancy and supposed hidden bugs are all very weak reasons IMHO...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
EL PRIMER MONITO DEL MILENIO...
	-- Crónica TV
May 12, 2008
On 12/05/2008, Leandro Lucarella <llucax@gmail.com> wrote:
>  >     foo(int x)  // Danger!
>  >     {
>  >         /* stuff */
>  >     }
>
>  Is this valid D?

I missed out the word "void". I meant

    void foo(int x) // Danger!
    {
        /* stuff */
    }

or else run the risk of being misparsed as

    void foo(int x);
    {
        /* stuff */
    }

And, yes, I'm sure you can invent some arbitrary ad hoc rule which disambiguates in this case, but there are always going to be more cases. I'm not the only one to have demonstrated an ambiguity which would result from semicolons being optional. Doubtless there are many more ambiguities lying in wait.

But I don't want to get into an endless cycle of "Here's another ambiguity" followed by "Here's the next ad hoc rule to disambiguate". Let's just not go there.
May 14, 2008
Bruce Adams wrote:
>>
>>     Lorem ipsum (dolor sit amet):
>>         consectetur!(adipisicing)(elit, sed)
>>         do:
>>             eiusmod tempor incididunt
>>             ut labore
>>             et dolore
>>         magna aliqua
>>
> My grasp of latin
> is just sufficient to want to make me try to interpret what your saying 

Check out http://www.lipsum.com/ for an explanation.

HTH
Dennis Cote
1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »