View mode: basic / threaded / horizontal-split · Log in · Help
October 06, 2008
Re: shouting versus dotting
On Mon, 06 Oct 2008 16:42:51 +0400, Jarrett Billingsley  
<jarrett.billingsley@gmail.com> wrote:

> On Mon, Oct 6, 2008 at 6:59 AM, Denis Koroskin <2korden@gmail.com> wrote:
>
>> If we don't omit parenthesises, the ambiguity goes away:
>>
>> foo()(5)
>> foo(5)()
>>
>
> No it doesn't.
>
> Stdout("foo")("bar!").newline;

And what causes ambiguity here? I mean, imagine you can't drop empty  
paranthesises.
October 06, 2008
Re: shouting versus dotting
On Mon, Oct 6, 2008 at 9:16 AM, Denis Koroskin <2korden@gmail.com> wrote:
> On Mon, 06 Oct 2008 16:42:51 +0400, Jarrett Billingsley
> <jarrett.billingsley@gmail.com> wrote:
>
>> On Mon, Oct 6, 2008 at 6:59 AM, Denis Koroskin <2korden@gmail.com> wrote:
>>
>>> If we don't omit parenthesises, the ambiguity goes away:
>>>
>>> foo()(5)
>>> foo(5)()
>>>
>>
>> No it doesn't.
>>
>> Stdout("foo")("bar!").newline;
>
> And what causes ambiguity here? I mean, imagine you can't drop empty
> paranthesises.
>

The point is that something like "foo()(5)" could then be either a
template instantiation or a chained call.
October 06, 2008
Re: shouting versus dotting
Jarrett Billingsley wrote:
> On Mon, Oct 6, 2008 at 9:16 AM, Denis Koroskin <2korden@gmail.com> wrote:
>> On Mon, 06 Oct 2008 16:42:51 +0400, Jarrett Billingsley
>> <jarrett.billingsley@gmail.com> wrote:
>>
>>> On Mon, Oct 6, 2008 at 6:59 AM, Denis Koroskin <2korden@gmail.com> wrote:
>>>
>>>> If we don't omit parenthesises, the ambiguity goes away:
>>>>
>>>> foo()(5)
>>>> foo(5)()
>>>>
>>> No it doesn't.
>>>
>>> Stdout("foo")("bar!").newline;
>> And what causes ambiguity here? I mean, imagine you can't drop empty
>> paranthesises.
>>
> 
> The point is that something like "foo()(5)" could then be either a
> template instantiation or a chained call.

I think there is ambiguity, and another problem is that we wanted to 
make things "better"; under these circumstances, terser would be better.

Andrei
October 06, 2008
Re: shouting versus dotting
Bill Baxter wrote:
> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> The problem I see with "!" as a template instantiation is not technical. I
>> write a fair amount of templated code and over years the "!" did not grow on
>> me at all. I was time and again consoled by Walter than one day that will
>> happen, but it never did. I also realized that Walter didn't see a problem
>> with it because he writes only little template code.
> 
> I'm joining this discussion late, but I just wanted to say the !()
> doesn't bother me so much.
> What Walter said to you was pretty much how it went for me.  Seemed
> weird for a while, but I got used to it.
> 
> I had to do several double-takes reading this thread thinking people
> were suggesting to use plain "()" because the little dot is just so
> easy to miss.
> 
> I find !() to at least be easier on the eyes than greater-than
> less-than everywhere in C++.
> 
> I wouldn't be adamantly opposed to a different syntax, but it would
> have to be better by leaps and bounds for me to think it was worth the
> headache.  And .() doesn't seem leaps and bounds better to me.
> 
> I suggest, though, that if you think it looks a lot better you should
> at least post some example code showing "before" and "after" to try to
> convince us.  Seems like not many here see a lot of point in making
> the change, so rather than pleading with everyone to try it out on
> their own, why not just save us the effort and show us how it improves
> the code you're looking at?

Well part of the problem is that many people made up their mind just by 
imagining how it would look like, and it would be hard to sway them.

Since you asked, here are some examples copied verbatim from a source 
file I found handy:

alias DenseMatrix.(num) PulType;
alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;

For functions:

sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
result.id = std.conv.parse.(uint)(line);

I was even more pleased while actually using The Sad Pirate than while 
imagining how it would be like, probably because typing is also easier 
(something that's not self-evident when just looking at the code).

It looks like The Sad Pirate won't make it. People just don't see it as 
bringing enough improvement. But I think it is worth pursuing a number 
of alternatives. The two that to me are the most appealing are:

a) Template{Args}

Experience with Perl has shown that using {} as parens in addition to 
blocks is easy to pick up and easy on the eyes. Another argument in 
favor is that {} are "the right thing" - meaning they are parens that 
pair properly, as opposed to "<>". Also, they make today's "!()" look 
like a contraption that creates a new kind of parens from an existing 
(and ambiguous) kind of parens by prefixing it with a marker.

b) Template@Arg and Template@(Args)

This approach not only accepts the need for a contraption, it actually 
leverages it by allowing you to drop the parens if you only have one 
argument. That way "@" becomes a true operator, the template 
instantiation operator. Note that this can be done with the current "!" 
as well, except that Template!Arg does not look to me like anything 
enticing.


Andrei
October 06, 2008
Re: shouting versus dotting
Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>> The problem I see with "!" as a template instantiation is not 
>>> technical. I
>>> write a fair amount of templated code and over years the "!" did not 
>>> grow on
>>> me at all. I was time and again consoled by Walter than one day that 
>>> will
>>> happen, but it never did. I also realized that Walter didn't see a 
>>> problem
>>> with it because he writes only little template code.
>>
>> I'm joining this discussion late, but I just wanted to say the !()
>> doesn't bother me so much.
>> What Walter said to you was pretty much how it went for me.  Seemed
>> weird for a while, but I got used to it.
>>
>> I had to do several double-takes reading this thread thinking people
>> were suggesting to use plain "()" because the little dot is just so
>> easy to miss.
>>
>> I find !() to at least be easier on the eyes than greater-than
>> less-than everywhere in C++.
>>
>> I wouldn't be adamantly opposed to a different syntax, but it would
>> have to be better by leaps and bounds for me to think it was worth the
>> headache.  And .() doesn't seem leaps and bounds better to me.
>>
>> I suggest, though, that if you think it looks a lot better you should
>> at least post some example code showing "before" and "after" to try to
>> convince us.  Seems like not many here see a lot of point in making
>> the change, so rather than pleading with everyone to try it out on
>> their own, why not just save us the effort and show us how it improves
>> the code you're looking at?
> 
> Well part of the problem is that many people made up their mind just by 
> imagining how it would look like, and it would be hard to sway them.
> 
> Since you asked, here are some examples copied verbatim from a source 
> file I found handy:
> 
> alias DenseMatrix.(num) PulType;
> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
> 
> For functions:
> 
> sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
> result.id = std.conv.parse.(uint)(line);
> 
> I was even more pleased while actually using The Sad Pirate than while 
> imagining how it would be like, probably because typing is also easier 
> (something that's not self-evident when just looking at the code).
> 
> It looks like The Sad Pirate won't make it. People just don't see it as 
> bringing enough improvement. But I think it is worth pursuing a number 
> of alternatives. The two that to me are the most appealing are:
> 
> a) Template{Args}
> 
> Experience with Perl has shown that using {} as parens in addition to 
> blocks is easy to pick up and easy on the eyes. Another argument in 
> favor is that {} are "the right thing" - meaning they are parens that 
> pair properly, as opposed to "<>". Also, they make today's "!()" look 
> like a contraption that creates a new kind of parens from an existing 
> (and ambiguous) kind of parens by prefixing it with a marker.
> 
> b) Template@Arg and Template@(Args)
> 
> This approach not only accepts the need for a contraption, it actually 
> leverages it by allowing you to drop the parens if you only have one 
> argument. That way "@" becomes a true operator, the template 
> instantiation operator. Note that this can be done with the current "!" 
> as well, except that Template!Arg does not look to me like anything 
> enticing.

So let's have them written down to be able to compare them easier:

The sad pirate
----------------

alias DenseMatrix.(num) PulType;
alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;

The curly braces
----------------

alias DenseMatrix{num} PulType;
alias SparseRowsMatrix{num, HashSparseVector} PuuType;
alias BiMap{uint, Tuple{uint, uint}, BiMapOptions.lhDense} DicType;

The at
----------------

alias DenseMatrix@num PulType;
alias SparseRowsMatrix@(num, HashSparseVector) PuuType;
alias BiMap@(uint, Tuple@(uint, uint), BiMapOptions.lhDense) DicType;

---

Personally, I find the {} easier to understand, and it's less typing, 
but it doesn't allow to omit the closing } for one argument.

> 
> 
> Andrei
October 06, 2008
Re: shouting versus dotting
"Ary Borenszweig" wrote
> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> The problem I see with "!" as a template instantiation is not 
>>>> technical. I
>>>> write a fair amount of templated code and over years the "!" did not 
>>>> grow on
>>>> me at all. I was time and again consoled by Walter than one day that 
>>>> will
>>>> happen, but it never did. I also realized that Walter didn't see a 
>>>> problem
>>>> with it because he writes only little template code.
>>>
>>> I'm joining this discussion late, but I just wanted to say the !()
>>> doesn't bother me so much.
>>> What Walter said to you was pretty much how it went for me.  Seemed
>>> weird for a while, but I got used to it.
>>>
>>> I had to do several double-takes reading this thread thinking people
>>> were suggesting to use plain "()" because the little dot is just so
>>> easy to miss.
>>>
>>> I find !() to at least be easier on the eyes than greater-than
>>> less-than everywhere in C++.
>>>
>>> I wouldn't be adamantly opposed to a different syntax, but it would
>>> have to be better by leaps and bounds for me to think it was worth the
>>> headache.  And .() doesn't seem leaps and bounds better to me.
>>>
>>> I suggest, though, that if you think it looks a lot better you should
>>> at least post some example code showing "before" and "after" to try to
>>> convince us.  Seems like not many here see a lot of point in making
>>> the change, so rather than pleading with everyone to try it out on
>>> their own, why not just save us the effort and show us how it improves
>>> the code you're looking at?
>>
>> Well part of the problem is that many people made up their mind just by 
>> imagining how it would look like, and it would be hard to sway them.
>>
>> Since you asked, here are some examples copied verbatim from a source 
>> file I found handy:
>>
>> alias DenseMatrix.(num) PulType;
>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>
>> For functions:
>>
>> sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
>> result.id = std.conv.parse.(uint)(line);
>>
>> I was even more pleased while actually using The Sad Pirate than while 
>> imagining how it would be like, probably because typing is also easier 
>> (something that's not self-evident when just looking at the code).
>>
>> It looks like The Sad Pirate won't make it. People just don't see it as 
>> bringing enough improvement. But I think it is worth pursuing a number of 
>> alternatives. The two that to me are the most appealing are:
>>
>> a) Template{Args}
>>
>> Experience with Perl has shown that using {} as parens in addition to 
>> blocks is easy to pick up and easy on the eyes. Another argument in favor 
>> is that {} are "the right thing" - meaning they are parens that pair 
>> properly, as opposed to "<>". Also, they make today's "!()" look like a 
>> contraption that creates a new kind of parens from an existing (and 
>> ambiguous) kind of parens by prefixing it with a marker.
>>
>> b) Template@Arg and Template@(Args)
>>
>> This approach not only accepts the need for a contraption, it actually 
>> leverages it by allowing you to drop the parens if you only have one 
>> argument. That way "@" becomes a true operator, the template 
>> instantiation operator. Note that this can be done with the current "!" 
>> as well, except that Template!Arg does not look to me like anything 
>> enticing.
>
> So let's have them written down to be able to compare them easier:
>
> The sad pirate
> ----------------
>
> alias DenseMatrix.(num) PulType;
> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>
> The curly braces
> ----------------
>
> alias DenseMatrix{num} PulType;
> alias SparseRowsMatrix{num, HashSparseVector} PuuType;
> alias BiMap{uint, Tuple{uint, uint}, BiMapOptions.lhDense} DicType;
>
> The at
> ----------------
>
> alias DenseMatrix@num PulType;
> alias SparseRowsMatrix@(num, HashSparseVector) PuuType;
> alias BiMap@(uint, Tuple@(uint, uint), BiMapOptions.lhDense) DicType;
>
> ---
>
> Personally, I find the {} easier to understand, and it's less typing, but 
> it doesn't allow to omit the closing } for one argument.

I find the {} much easier to read than the . syntax.

The omitting of the braces is not a huge savings.  You are sacrificing a 
couple characters, actually only one if you are comparing @ with {}, at the 
expense of clarity.  I think it's a special case that is not really worth 
the trouble.  Besides, it's not hard to type {} when you are so used to it 
anyways, and if you are interested in saving characters, aliasing is a much 
better approach.

One thing I should mention, since this is all about asthetics, my news 
reader keeps treating the name@param as a linked email address.  Somthing 
that will be very annoying if we adopt the @ syntax and end up discussing 
templates on the NG.

I still vote to keep ! as it's the easiest solution, and I never have found 
it annoying ;)

-Steve
October 06, 2008
Re: shouting versus dotting
Ary Borenszweig wrote:
Ary Borenszweig wrote:
> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> The problem I see with "!" as a template instantiation is not 
>>>> technical. I
>>>> write a fair amount of templated code and over years the "!" did not 
>>>> grow on
>>>> me at all. I was time and again consoled by Walter than one day that 
>>>> will
>>>> happen, but it never did. I also realized that Walter didn't see a 
>>>> problem
>>>> with it because he writes only little template code.
>>>
>>> I'm joining this discussion late, but I just wanted to say the !()
>>> doesn't bother me so much.
>>> What Walter said to you was pretty much how it went for me.  Seemed
>>> weird for a while, but I got used to it.
>>>
>>> I had to do several double-takes reading this thread thinking people
>>> were suggesting to use plain "()" because the little dot is just so
>>> easy to miss.
>>>
>>> I find !() to at least be easier on the eyes than greater-than
>>> less-than everywhere in C++.
>>>
>>> I wouldn't be adamantly opposed to a different syntax, but it would
>>> have to be better by leaps and bounds for me to think it was worth the
>>> headache.  And .() doesn't seem leaps and bounds better to me.
>>>
>>> I suggest, though, that if you think it looks a lot better you should
>>> at least post some example code showing "before" and "after" to try to
>>> convince us.  Seems like not many here see a lot of point in making
>>> the change, so rather than pleading with everyone to try it out on
>>> their own, why not just save us the effort and show us how it improves
>>> the code you're looking at?
>>
>> Well part of the problem is that many people made up their mind just 
>> by imagining how it would look like, and it would be hard to sway them.
>>
>> Since you asked, here are some examples copied verbatim from a source 
>> file I found handy:
>>
>> alias DenseMatrix.(num) PulType;
>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>
>> For functions:
>>
>> sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
>> result.id = std.conv.parse.(uint)(line);
>>
>> I was even more pleased while actually using The Sad Pirate than while 
>> imagining how it would be like, probably because typing is also easier 
>> (something that's not self-evident when just looking at the code).
>>
>> It looks like The Sad Pirate won't make it. People just don't see it 
>> as bringing enough improvement. But I think it is worth pursuing a 
>> number of alternatives. The two that to me are the most appealing are:
>>
>> a) Template{Args}
>>
>> Experience with Perl has shown that using {} as parens in addition to 
>> blocks is easy to pick up and easy on the eyes. Another argument in 
>> favor is that {} are "the right thing" - meaning they are parens that 
>> pair properly, as opposed to "<>". Also, they make today's "!()" look 
>> like a contraption that creates a new kind of parens from an existing 
>> (and ambiguous) kind of parens by prefixing it with a marker.
>>
>> b) Template@Arg and Template@(Args)
>>
>> This approach not only accepts the need for a contraption, it actually 
>> leverages it by allowing you to drop the parens if you only have one 
>> argument. That way "@" becomes a true operator, the template 
>> instantiation operator. Note that this can be done with the current 
>> "!" as well, except that Template!Arg does not look to me like 
>> anything enticing.
> 
> So let's have them written down to be able to compare them easier:
> 
> The sad pirate
> ----------------
> 
> alias DenseMatrix.(num) PulType;
> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
> 
> The curly braces
> ----------------
> 
> alias DenseMatrix{num} PulType;
> alias SparseRowsMatrix{num, HashSparseVector} PuuType;
> alias BiMap{uint, Tuple{uint, uint}, BiMapOptions.lhDense} DicType;
> 
> The at
> ----------------
> 
> alias DenseMatrix@num PulType;
> alias SparseRowsMatrix@(num, HashSparseVector) PuuType;
> alias BiMap@(uint, Tuple@(uint, uint), BiMapOptions.lhDense) DicType;
> 
> ---
> 
> Personally, I find the {} easier to understand, and it's less typing, 
> but it doesn't allow to omit the closing } for one argument.
> 
>>
>>
>> Andrei

> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> The problem I see with "!" as a template instantiation is not 
>>>> technical. I
>>>> write a fair amount of templated code and over years the "!" did not 
>>>> grow on
>>>> me at all. I was time and again consoled by Walter than one day that 
>>>> will
>>>> happen, but it never did. I also realized that Walter didn't see a 
>>>> problem
>>>> with it because he writes only little template code.
>>>
>>> I'm joining this discussion late, but I just wanted to say the !()
>>> doesn't bother me so much.
>>> What Walter said to you was pretty much how it went for me.  Seemed
>>> weird for a while, but I got used to it.
>>>
>>> I had to do several double-takes reading this thread thinking people
>>> were suggesting to use plain "()" because the little dot is just so
>>> easy to miss.
>>>
>>> I find !() to at least be easier on the eyes than greater-than
>>> less-than everywhere in C++.
>>>
>>> I wouldn't be adamantly opposed to a different syntax, but it would
>>> have to be better by leaps and bounds for me to think it was worth the
>>> headache.  And .() doesn't seem leaps and bounds better to me.
>>>
>>> I suggest, though, that if you think it looks a lot better you should
>>> at least post some example code showing "before" and "after" to try to
>>> convince us.  Seems like not many here see a lot of point in making
>>> the change, so rather than pleading with everyone to try it out on
>>> their own, why not just save us the effort and show us how it improves
>>> the code you're looking at?
>>
>> Well part of the problem is that many people made up their mind just 
>> by imagining how it would look like, and it would be hard to sway them.
>>
>> Since you asked, here are some examples copied verbatim from a source 
>> file I found handy:
>>
>> alias DenseMatrix.(num) PulType;
>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>
>> For functions:
>>
>> sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
>> result.id = std.conv.parse.(uint)(line);
>>
>> I was even more pleased while actually using The Sad Pirate than while 
>> imagining how it would be like, probably because typing is also easier 
>> (something that's not self-evident when just looking at the code).
>>
>> It looks like The Sad Pirate won't make it. People just don't see it 
>> as bringing enough improvement. But I think it is worth pursuing a 
>> number of alternatives. The two that to me are the most appealing are:
>>
>> a) Template{Args}
>>
>> Experience with Perl has shown that using {} as parens in addition to 
>> blocks is easy to pick up and easy on the eyes. Another argument in 
>> favor is that {} are "the right thing" - meaning they are parens that 
>> pair properly, as opposed to "<>". Also, they make today's "!()" look 
>> like a contraption that creates a new kind of parens from an existing 
>> (and ambiguous) kind of parens by prefixing it with a marker.
>>
>> b) Template@Arg and Template@(Args)
>>
>> This approach not only accepts the need for a contraption, it actually 
>> leverages it by allowing you to drop the parens if you only have one 
>> argument. That way "@" becomes a true operator, the template 
>> instantiation operator. Note that this can be done with the current 
>> "!" as well, except that Template!Arg does not look to me like 
>> anything enticing.
> 
> So let's have them written down to be able to compare them easier:
> 
> The sad pirate
> ----------------
> 
> alias DenseMatrix.(num) PulType;
> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
> 
> The curly braces
> ----------------
> 
> alias DenseMatrix{num} PulType;
> alias SparseRowsMatrix{num, HashSparseVector} PuuType;
> alias BiMap{uint, Tuple{uint, uint}, BiMapOptions.lhDense} DicType;
> 
> The at
> ----------------
> 
> alias DenseMatrix@num PulType;
> alias SparseRowsMatrix@(num, HashSparseVector) PuuType;
> alias BiMap@(uint, Tuple@(uint, uint), BiMapOptions.lhDense) DicType;
> 
> ---
> 
> Personally, I find the {} easier to understand, and it's less typing, 
> but it doesn't allow to omit the closing } for one argument.
> 
>>
>>
>> Andrei

I don't think being able to omit {} is a big problem. Well, we used f(x) 
in a function with 1 parameter so long without complaining anyway.

(Some mathematicians use f`1 to indicate f(1) to avoid confusion with 
multiplication; and many cases the ( ) are even omitted, e.g. sin 1. So 
f(x) is not "the" norm.)
October 06, 2008
Re: shouting versus dotting
Steven Schveighoffer wrote:
> "Ary Borenszweig" wrote
>> Andrei Alexandrescu wrote:
>>> Bill Baxter wrote:
>>>> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>>> The problem I see with "!" as a template instantiation is not 
>>>>> technical. I
>>>>> write a fair amount of templated code and over years the "!" did not 
>>>>> grow on
>>>>> me at all. I was time and again consoled by Walter than one day that 
>>>>> will
>>>>> happen, but it never did. I also realized that Walter didn't see a 
>>>>> problem
>>>>> with it because he writes only little template code.
>>>> I'm joining this discussion late, but I just wanted to say the !()
>>>> doesn't bother me so much.
>>>> What Walter said to you was pretty much how it went for me.  Seemed
>>>> weird for a while, but I got used to it.
>>>>
>>>> I had to do several double-takes reading this thread thinking people
>>>> were suggesting to use plain "()" because the little dot is just so
>>>> easy to miss.
>>>>
>>>> I find !() to at least be easier on the eyes than greater-than
>>>> less-than everywhere in C++.
>>>>
>>>> I wouldn't be adamantly opposed to a different syntax, but it would
>>>> have to be better by leaps and bounds for me to think it was worth the
>>>> headache.  And .() doesn't seem leaps and bounds better to me.
>>>>
>>>> I suggest, though, that if you think it looks a lot better you should
>>>> at least post some example code showing "before" and "after" to try to
>>>> convince us.  Seems like not many here see a lot of point in making
>>>> the change, so rather than pleading with everyone to try it out on
>>>> their own, why not just save us the effort and show us how it improves
>>>> the code you're looking at?
>>> Well part of the problem is that many people made up their mind just by 
>>> imagining how it would look like, and it would be hard to sway them.
>>>
>>> Since you asked, here are some examples copied verbatim from a source 
>>> file I found handy:
>>>
>>> alias DenseMatrix.(num) PulType;
>>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>>
>>> For functions:
>>>
>>> sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
>>> result.id = std.conv.parse.(uint)(line);
>>>
>>> I was even more pleased while actually using The Sad Pirate than while 
>>> imagining how it would be like, probably because typing is also easier 
>>> (something that's not self-evident when just looking at the code).
>>>
>>> It looks like The Sad Pirate won't make it. People just don't see it as 
>>> bringing enough improvement. But I think it is worth pursuing a number of 
>>> alternatives. The two that to me are the most appealing are:
>>>
>>> a) Template{Args}
>>>
>>> Experience with Perl has shown that using {} as parens in addition to 
>>> blocks is easy to pick up and easy on the eyes. Another argument in favor 
>>> is that {} are "the right thing" - meaning they are parens that pair 
>>> properly, as opposed to "<>". Also, they make today's "!()" look like a 
>>> contraption that creates a new kind of parens from an existing (and 
>>> ambiguous) kind of parens by prefixing it with a marker.
>>>
>>> b) Template@Arg and Template@(Args)
>>>
>>> This approach not only accepts the need for a contraption, it actually 
>>> leverages it by allowing you to drop the parens if you only have one 
>>> argument. That way "@" becomes a true operator, the template 
>>> instantiation operator. Note that this can be done with the current "!" 
>>> as well, except that Template!Arg does not look to me like anything 
>>> enticing.
>> So let's have them written down to be able to compare them easier:
>>
>> The sad pirate
>> ----------------
>>
>> alias DenseMatrix.(num) PulType;
>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>
>> The curly braces
>> ----------------
>>
>> alias DenseMatrix{num} PulType;
>> alias SparseRowsMatrix{num, HashSparseVector} PuuType;
>> alias BiMap{uint, Tuple{uint, uint}, BiMapOptions.lhDense} DicType;
>>
>> The at
>> ----------------
>>
>> alias DenseMatrix@num PulType;
>> alias SparseRowsMatrix@(num, HashSparseVector) PuuType;
>> alias BiMap@(uint, Tuple@(uint, uint), BiMapOptions.lhDense) DicType;
>>
>> ---
>>
>> Personally, I find the {} easier to understand, and it's less typing, but 
>> it doesn't allow to omit the closing } for one argument.
> 
> I find the {} much easier to read than the . syntax.

To me too.

> The omitting of the braces is not a huge savings.  You are sacrificing a 
> couple characters, actually only one if you are comparing @ with {}, at the 
> expense of clarity.  I think it's a special case that is not really worth 
> the trouble.  Besides, it's not hard to type {} when you are so used to it 
> anyways, and if you are interested in saving characters, aliasing is a much 
> better approach.

One thing I kinda dislike about Template@Arg is that adding a second arg 
also asks for the parens. This is a problem present with single- vs. 
multi-statement blocks as well:

if (a)
    b;

If you want to add another statement, you need to add the curls as well:

if (a)
{
    b;
    c;
}

But then if you want to remove one of the statement you'd want to remove 
the curls too to stay consistent:

if (a)
    c;

This becomes tenuous enough that many people and some coding standards 
actually prefer to use full block statements to start with, even when 
they only contain one statement.

> One thing I should mention, since this is all about asthetics, my news 
> reader keeps treating the name@param as a linked email address.  Somthing 
> that will be very annoying if we adopt the @ syntax and end up discussing 
> templates on the NG.

Walter made another point, namely that "@" has "a lot of ink" in it. I 
know what he means. I guess people who wanted templates to be 
distinguished will find that an advantage :o).

> I still vote to keep ! as it's the easiest solution, and I never have found 
> it annoying ;)

Well would you go on a strike if there was a little experimentation with 
the curls?


Andrei
October 06, 2008
Re: shouting versus dotting
On Mon, Oct 6, 2008 at 11:58 PM, Steven Schveighoffer
<schveiguy@yahoo.com> wrote:
> "Ary Borenszweig" wrote

> I still vote to keep ! as it's the easiest solution, and I never have found
> it annoying ;)

Yeh, me too.

The @ (and #) also take up too much width in a small mono-space font
like the Proggy font I use.  And so they run into the previous and
following chars making them less readable.   ! is nice and thin so it
doesn't have that problem.

{ } vs ( ) is also a fairly subtle distinction in a small font.
Usually the context and usage is different enough that that doesn't
matter.   But of course you may just tell me I should change my font
in that case.  But I still say ! stands out better.

And honestly, my eyes totally just see !(...) as a symbolic string
now, devoid of any meaning beyond "this is a template".  Mentions of
it looking like shouting or negation or anything else brought back a
vague recollection of a time long ago when I still could see that.
But I can only make it look like shouting in my mind now if I
purposefully pretend the parentheses are part of a different word, or
pretend to myself that I'm not looking at D code.

--bb
October 06, 2008
Re: shouting versus dotting
"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>>
>> I find the {} much easier to read than the . syntax.
>
> To me too.
>
>> The omitting of the braces is not a huge savings.  You are sacrificing a 
>> couple characters, actually only one if you are comparing @ with {}, at 
>> the expense of clarity.  I think it's a special case that is not really 
>> worth the trouble.  Besides, it's not hard to type {} when you are so 
>> used to it anyways, and if you are interested in saving characters, 
>> aliasing is a much better approach.
>
> One thing I kinda dislike about Template@Arg is that adding a second arg 
> also asks for the parens. This is a problem present with single- vs. 
> multi-statement blocks as well:
>
> if (a)
>     b;
>
> If you want to add another statement, you need to add the curls as well:
>
> if (a)
> {
>     b;
>     c;
> }
>
> But then if you want to remove one of the statement you'd want to remove 
> the curls too to stay consistent:
>
> if (a)
>     c;
>
> This becomes tenuous enough that many people and some coding standards 
> actually prefer to use full block statements to start with, even when they 
> only contain one statement.

Yeah, I find myself doing that also, removing the {} braces when possible, 
but that can't apply here for technical reasons.

Conversely, I don't think anyone is complaining that they always have to use 
braces for one-line functions.

>> One thing I should mention, since this is all about asthetics, my news 
>> reader keeps treating the name@param as a linked email address.  Somthing 
>> that will be very annoying if we adopt the @ syntax and end up discussing 
>> templates on the NG.
>
> Walter made another point, namely that "@" has "a lot of ink" in it. I 
> know what he means. I guess people who wanted templates to be 
> distinguished will find that an advantage :o).

Yeah, but ! is just as good then, and we don't have to change thousands of 
lines of code ;)

>
>> I still vote to keep ! as it's the easiest solution, and I never have 
>> found it annoying ;)
>
> Well would you go on a strike if there was a little experimentation with 
> the curls?

I like D too much to give it up based on this one thing.  But I would be 
cursing you profusely as I changed all my existing D code when I move to 
support D2.  I don't think I'd ever feel that it was an improvement, but if 
it means so much to everyone to abolish the ! syntax, I'd just do the 
updates and move on.  Like I said, it's a bicycle shed color.

BTW, this would be another notch in the D1/D2 incompatibility belt (perhaps 
an insurmountable one), but that ship may have already sailed.

-Steve
15 16 17 18 19 20 21 22 23
Top | Discussion index | About this forum | D home