October 11, 2008
On Fri, 10 Oct 2008 14:15:12 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>We seem to have reached a dead end on finding a significantly better alternative than foo!(bar).
>
>All is not lost, though. Andrei is working on an emacs module that will parse D code and replace foo!(bar) with foo?bar? for display only when the editor is in D mode, the underlying text will still be foo!(bar). (This doesn't affect D at all, only its display in Emacs.)
>
>Also, we're going to try using ! for single argument syntax, as in:
>
>foo!bar  is same as   foo!(bar)
>foo!10   is same as   foo!(10)
>
>etc. 0 arguments or more than 1 argument or arguments that are more than one token long will still require !( ). We'll see how that works. I think it looks rather nice.

I hope this insignificant issue is not taking too much of your and Andrei's time.
October 11, 2008
Sergey Gromov wrote:
> so that even a!b!c!(x,y) works as a!(b!(c!(x,y))), but a!(b)!(c) is not accepted.

I don't think it's a good idea to say that a!(b)!(c) is never allowed. It intuitively means that a!(b) is aliased to another template.
October 11, 2008
Max Samukha wrote:
> I hope this insignificant issue is not taking too much of your and
> Andrei's time.

Implementing it isn't a problem. The volume of messages about it consumes the bulk of the time <g>.

I don't agree that it is insignificant. A lot of programmers are put off by C++ templates, myself included. The question is, why? They shouldn't conceptually be that complicated. I think syntax is a big part of it. I just can never seem to get a mental grip on the C++ template syntax. Like makefiles, I write C++ templates by copy/paste/modify related ones. This is just wrong. If the syntax can be made more intuitive and appealing, I believe it will break down the barriers to using templates naturally.

I've seen this happen for other things. Syntax matters.
October 11, 2008
Parentheses establish context as does semicolons, of course. Still, parantheses are more prominent.

I hope this drive away from parentheses, which started as a discussion of "shouting vs dotting", doesn't end up with the same approach for function call syntax.

a!b@c

Let's look at that for a while, while we ponder the concept of aesthetics. The defense rests.

- Bent

"Benji Smith" <dlanguage@benjismith.net> skrev i meddelelsen news:gcpf66$uup$1@digitalmars.com...
> bearophile wrote:
>> Bye,
>> bearophile
>
> I think it's funny that, in the same post, you argue against optional parentheses while arguing for optional semicolons.
>
> --benji 

October 11, 2008
That's a great idea. A meta-syntax for the editor.

Also, foo«bar» looks much better than any of the other suggestions.

- Bent

"Walter Bright" <newshound1@digitalmars.com> skrev i meddelelsen news:gcogl4$28ui$1@digitalmars.com...
> We seem to have reached a dead end on finding a significantly better alternative than foo!(bar).
>
> All is not lost, though. Andrei is working on an emacs module that will parse D code and replace foo!(bar) with foo«bar» for display only when the editor is in D mode, the underlying text will still be foo!(bar). (This doesn't affect D at all, only its display in Emacs.)
>
> Also, we're going to try using ! for single argument syntax, as in:
>
> foo!bar  is same as   foo!(bar)
> foo!10   is same as   foo!(10)
>
> etc. 0 arguments or more than 1 argument or arguments that are more than one token long will still require !( ). We'll see how that works. I think it looks rather nice. 

October 11, 2008
On Sat, Oct 11, 2008 at 3:29 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Max Samukha wrote:
>>
>> I hope this insignificant issue is not taking too much of your and Andrei's time.
>
> Implementing it isn't a problem. The volume of messages about it consumes the bulk of the time <g>.
>
> I don't agree that it is insignificant. A lot of programmers are put off by C++ templates, myself included. The question is, why? They shouldn't conceptually be that complicated. I think syntax is a big part of it. I just can never seem to get a mental grip on the C++ template syntax. Like makefiles, I write C++ templates by copy/paste/modify related ones. This is just wrong. If the syntax can be made more intuitive and appealing, I believe it will break down the barriers to using templates naturally.
>
> I've seen this happen for other things. Syntax matters.

But it's not the << and >> that make C++ templates hard to understand.
 Replacing that with some other character or character sequence would
make very little difference in how difficult they are to understand.
It's more the lack of a straighforward equivalent for things like
static if.
Changing details like the character used for this or that can make the
code more or less readable though.  But that doesn't really affect how
difficult it is to remember how to write something.

--bb
October 11, 2008
On Fri, 10 Oct 2008 23:29:21 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>Max Samukha wrote:
>> I hope this insignificant issue is not taking too much of your and Andrei's time.
>
>Implementing it isn't a problem. The volume of messages about it consumes the bulk of the time <g>.
>
>I don't agree that it is insignificant. A lot of programmers are put off by C++ templates, myself included. The question is, why? They shouldn't conceptually be that complicated. I think syntax is a big part of it.
Right, but D template syntax and meaning are way easier to grasp. And dropping () for single argument instances doesn't seem to make them look much better. Maybe I just got used to current syntax.

> I just can never seem to get a mental grip on the C++ template syntax.
>Like makefiles, I write C++ templates by copy/paste/modify related ones. This is just wrong. If the syntax can be made more intuitive and appealing, I believe it will break down the barriers to using templates naturally.
>
>I've seen this happen for other things. Syntax matters.
Ok. Let's try the lonesome !.
October 11, 2008
Bill Baxter wrote:
> But it's not the << and >> that make C++ templates hard to understand.

I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.

>  Replacing that with some other character or character sequence would
> make very little difference in how difficult they are to understand.
> It's more the lack of a straighforward equivalent for things like
> static if.

There are a lot of issues that needed improvement.

> Changing details like the character used for this or that can make the
> code more or less readable though.  But that doesn't really affect how
> difficult it is to remember how to write something.

I disagree with that assessment. There are aesthetics to architecture, fonts, web pages, cars, dance, clothes, etc. Break those aesthetics, and you've got something people just don't like, even if they cannot identify why.

Take the immutable vs invariant aesthetic. There is no technical reason to prefer one over the other. But people seem to just like immutable better.
October 11, 2008
Bent Rasmussen wrote:
> Parentheses establish context as does semicolons, of course. Still, parantheses are more prominent.
> 
> I hope this drive away from parentheses, which started as a discussion of "shouting vs dotting", doesn't end up with the same approach for function call syntax.
> 
> a!b@c
> 
> Let's look at that for a while, while we ponder the concept of aesthetics. The defense rests.

One could rationally extend the argument to not need parentheses for one argument function calls. But, ugh. I don't know why I hate it, but I do.
October 11, 2008
On Sat, 11 Oct 2008 02:57:29 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>Bill Baxter wrote:
>> But it's not the << and >> that make C++ templates hard to understand.
>
>I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
>
>>  Replacing that with some other character or character sequence would
>> make very little difference in how difficult they are to understand.
>> It's more the lack of a straighforward equivalent for things like
>> static if.
>
>There are a lot of issues that needed improvement.
>
>> Changing details like the character used for this or that can make the code more or less readable though.  But that doesn't really affect how difficult it is to remember how to write something.
>
>I disagree with that assessment. There are aesthetics to architecture, fonts, web pages, cars, dance, clothes, etc. Break those aesthetics, and you've got something people just don't like, even if they cannot identify why.
>
>Take the immutable vs invariant aesthetic. There is no technical reason to prefer one over the other. But people seem to just like immutable better.

Wait a sec! Not everybody expressed his aesthetic feeling towards immutable. I don't like the double m inside immutable and prefer invariant :).