View mode: basic / threaded / horizontal-split · Log in · Help
October 06, 2008
Re: shouting versus dotting
Andrei Alexandrescu a écrit :
>> "enum" as the way to declare manifest constants were much more ugly than
>> "!(", and most of the people were against it. I don't see why ".(" should
>> be introduced.
> 
> Ugly or not, enumerated symbols were manifest constants to begin with. 

Sure. However manifest constants weren't enumerated symbols to begin with.

-- 
Etienne Dechamps / e-t172 - AKE Group

Website: http://www.e-t172.net/
Contact: e-t172@akegroup.org

Phone: +33547414942
October 06, 2008
Re: shouting versus dotting
Andrei Alexandrescu wrote:
> 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
> 

Frankly speaking one disadvantage of {} is that it is more difficult to 
refactor it (unlike .() where you just do a s/!\(/.(/g.)

If this is gonna effective, I suggest still keeping !() for a while, but 
make it deprecated, like what has been done to the === operator (the 
grace period from 0.72 (introduction of "is") to 0.126 (=== deprecated) 
to 0.174 (=== illegal)).
October 06, 2008
Re: shouting versus dotting
Benji Smith wrote:
> Andrei Alexandrescu wrote:
>> I'd want to give it a try. How do others feel about Template{arguments}?
> 
> 
> At first glance, I like it better than !(), especially since it saves a 
> character, making nested templates much nicer:
> 
>    auto map = new Map{T[], List{MyType}}();     // not too bad
>    auto map = new Map!(T[], List!(MyType))();   // not too good
>    auto map = new Map<T[], List<MyType>>();     // still my favorite
> 
> It's too bad the shift operators can't be changed. Personally, I think 
> the angle brackets are more valuable as a matched pair of enclosures.
> 
> We could redefine the shift operators to be:
> 
>    -->  RIGHT SHIFT
>    <--  LEFT SHIFT
>    -->> SIGNED RIGHT SHIFT
> 
> And then the angle brackets could be coopted for templates.

No way! :(
’em pointed brackets are way too pointy. I like having parenthesis for 
templates.
October 06, 2008
Re: shouting versus dotting
Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> 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.

There's no need to worry about it at all. The !() syntax can stay for a 
long time in vigor as an alternative that gets used less and less, then 
mentioned less and less, until essentially disabling it becomes a 
non-event. PL history has many examples of such changes that were 
successful, and I'll give a few:

1. The K&R function declaration syntax:

int foo(a)
    int a;
{
    return a;
}

Before trying: do you believe gcc would accept it? How many of us wrote 
one like that?

2. C++'s member function definition:

class A { void foo(); }
void A.foo() {}

3. Perl, having a very experimental attitude towards syntax, has 
effectively "forgot" quite a few syntaxes that weren't successful, but 
remained harmless. For example, "?pattern?" is equivalent with the 
well-known "/pattern/", and still accepted - yet hardly anyone uses it 
anymore. (There was IIRC an odd operator for accessing a package member 
that also fell into obsolescence, incidentally it might have been "!", 
does anyone know?)

Of course it's ineffective to allow a lot of things and then leave them 
hanging around, but it is possible to operate a syntax change without 
too much disruption.


Andrei
October 06, 2008
Re: shouting versus dotting
Alexander Pánek wrote:
> Benji Smith wrote:
>> Andrei Alexandrescu wrote:
>>> I'd want to give it a try. How do others feel about Template{arguments}?
>>
>>
>> At first glance, I like it better than !(), especially since it saves 
>> a character, making nested templates much nicer:
>>
>>    auto map = new Map{T[], List{MyType}}();     // not too bad
>>    auto map = new Map!(T[], List!(MyType))();   // not too good
>>    auto map = new Map<T[], List<MyType>>();     // still my favorite
>>
>> It's too bad the shift operators can't be changed. Personally, I think 
>> the angle brackets are more valuable as a matched pair of enclosures.
>>
>> We could redefine the shift operators to be:
>>
>>    -->  RIGHT SHIFT
>>    <--  LEFT SHIFT
>>    -->> SIGNED RIGHT SHIFT
>>
>> And then the angle brackets could be coopted for templates.
> 
> No way! :(
> ’em pointed brackets are way too pointy. I like having parenthesis for 
> templates.

Well another problem is we'd need to redefine the less-than and 
greater-than operators too.

Andrei
October 06, 2008
Re: shouting versus dotting
Bill Baxter Wrote:

> 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.

spoken like a true prodigy. yeah. change yer font. 

>  But I still say ! stands out better.

it stands out. unsure about the `better' part.

> 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.

i'm sober now eh.

thing is that's important. i don't mind !() much myself. like a mole on an otherwise fine piece of ass. got used to it. but like u i also remember in the beginning i was like, what's wrong with walt did he run out of ideas or what. 

to some1 coming anew to d stuff like what!(the!(hell!())) is freakin' weird. no two ways about it. you just keep starin' at that mole like austin powers. if there's a way to get rid of it then whynot. helps attract newcomerz eh.

parallel with perl is good. much stuff i thot and still think is plain weird in perl. but hash access was never one. looks good & works like a charm.
October 06, 2008
Re: shouting versus dotting
Andrei Alexandrescu, el  5 de octubre a las 17:45 me escribiste:
> >"enum" as the way to declare manifest constants were much more ugly than
> >"!(", and most of the people were against it. I don't see why ".(" should
> >be introduced.
> 
> Ugly or not [...]

But this thread started about uglyness, and enum SOMETHING = 1 is plain
ugly =)

> >And if it's introduced, you'll have to read a lot of "!(" anyways, is not
> >that you will be solving any problems, because all D1-ported code (and
> >code of people who like "!(" better) will use it instead of ".(" (unless
> >"!(" stops working, in which case it's really dumb to make D1 incompatible
> >with D2 for this such a small aesthetic issue). So you'll just make things
> >whorse.
> >-1 for ".("
> >PS: I wont use Positive!() either ;)
> 
> Would you use Bounded? It takes a type, a minimum, and a maximum.

I don't make much numeric/math programming, but it sounds much more useful
than Positive.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
You look so tired-unhappy,
bring down the government,
they don't, they don't speak for us.
October 06, 2008
Re: Positive
Reply to Andrei,

> Well I guess it all depends on how hard the glance is and how sharp
> your eye is... :o)
> 
> Andrei
> 

Easier is better. I'd rather spend my time and effort on other things.
October 07, 2008
Re: shouting versus dotting
On Tue, Oct 7, 2008 at 2:25 AM, superdan <super@dan.org> wrote:
> Bill Baxter Wrote:
>
>> 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.
>
> spoken like a true prodigy. yeah. change yer font.

Well, I think it's more a matter of the size than the particular font,
though.  So the remedy would probably be to switch to a font that
takes up more screen real-estate, meaning I'll get fewer lines of D to
the page.

But there *is* a difference between { and ( even with Proggy at 6x10
-- 2 pixels are shifted one position.  I suppose it's not any more
subtle than the difference between . and , which is seen everywhere.
I'm sure I could get used to it if it's what the D community thinks is
best.   Anyway I think foo{} is more readable than foo.().

> thing is that's important. i don't mind !() much myself. like a mole on an otherwise fine piece of ass. got used to it. but like u i also remember in the beginning i was like, what's wrong with walt did he run out of ideas or what.
>
> to some1 coming anew to d stuff like what!(the!(hell!())) is freakin' weird. no two ways about it. you just keep starin' at that mole like austin powers. if there's a way to get rid of it then whynot. helps attract newcomerz eh.

I thought it was bizarre till I read the justification here
  http://www.digitalmars.com/d/1.0/templates-revisited.html.
Then  I thought, OK.  Not a bad idea.  It's better than parsing
ambiguities, and being forced to insert spaces between punctuation to
avoid them.

But I agree that as an utter newbie to D, foo{bar} would probably have
seemed more elegant and obvious as a template syntax than re-purposing
the unary NOT operator.  The newbie's response to "foo{bar} is a
template instantiation" would probably be "ok, sure." instead of
"Why??"

Still it seems like a big bike shed issue.  And it's bizarre coming
from the guy who's usually the first one to call "bike shed" anytime
anyone else makes a suggestion to improve aesthetics.

--bb
October 07, 2008
Re: shouting versus dotting
Bill Baxter wrote:
> On Tue, Oct 7, 2008 at 2:25 AM, superdan <super@dan.org> wrote:
>> Bill Baxter Wrote:
>>
>>> 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.
>> spoken like a true prodigy. yeah. change yer font.
> 
> Well, I think it's more a matter of the size than the particular font,
> though.  So the remedy would probably be to switch to a font that
> takes up more screen real-estate, meaning I'll get fewer lines of D to
> the page.
> 
> But there *is* a difference between { and ( even with Proggy at 6x10
> -- 2 pixels are shifted one position.  I suppose it's not any more
> subtle than the difference between . and , which is seen everywhere.
> I'm sure I could get used to it if it's what the D community thinks is
> best.   Anyway I think foo{} is more readable than foo.().
> 
>> thing is that's important. i don't mind !() much myself. like a mole on an otherwise fine piece of ass. got used to it. but like u i also remember in the beginning i was like, what's wrong with walt did he run out of ideas or what.
>>
>> to some1 coming anew to d stuff like what!(the!(hell!())) is freakin' weird. no two ways about it. you just keep starin' at that mole like austin powers. if there's a way to get rid of it then whynot. helps attract newcomerz eh.
> 
> I thought it was bizarre till I read the justification here
>    http://www.digitalmars.com/d/1.0/templates-revisited.html.
> Then  I thought, OK.  Not a bad idea.  It's better than parsing
> ambiguities, and being forced to insert spaces between punctuation to
> avoid them.
> 
> But I agree that as an utter newbie to D, foo{bar} would probably have
> seemed more elegant and obvious as a template syntax than re-purposing
> the unary NOT operator.  The newbie's response to "foo{bar} is a
> template instantiation" would probably be "ok, sure." instead of
> "Why??"
> 
> Still it seems like a big bike shed issue.  And it's bizarre coming
> from the guy who's usually the first one to call "bike shed" anytime
> anyone else makes a suggestion to improve aesthetics.

I agree with all these. There's a lot of other things I wish Andrei were 
working on instead.
I'd hope for a colossal benefit, from something which would break almost 
all my code...

(BTW Putting template parameters inside normal parens would be an 
adequate benefit).
16 17 18 19 20 21 22 23 24
Top | Discussion index | About this forum | D home