October 06, 2008
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
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
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
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
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
"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
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
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
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
"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


9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Top | Discussion index | About this forum | D home