www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Revised RFC on range design for D2

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
In wake of the many excellent comments and suggestions made here, I made 
one more pass through the draft proposal for ranges.

http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

There are some comments in red illustrating some uncertainties (not 
all), and the names of the primitives have been updated. Bicycle shed 
galore! But don't forget to comment on the reactor as well :o).


Andrei
Sep 11 2008
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
Well done. I think the design has come together very nicely. I'm especially happy with all the new names, which make a big difference for me in being able to visualize how the proposal works. The old names (fromLeft, etc) were very opaque to me. (btw: head & toe? i love it!) In its current state, this actually gets me pretty excited about D2. Maybe even enough to finally slog my way through all the const stuff. One tiny typo, though: In the "Forward range" section, the code sample still uses "left" instead of "head". And, there are two sections (which I think are related to one another) that left me scratching my head: Input Ranges: "In case ElementType!(R) has aliases (such as a reference, pointer, or array type), the iterator is free to recycle it it upon the call to r.next, so client code must do a deep copy if preserving the value is needed. [NOTE: This is a weakness in the design. A better way of figuring recycling should be found.] The call is defined only right after r.done returned false." Forward Ranges: "Also, forward ranges iterate over "real" elements, which makes in-place mutation of r.head possible." Those paragraphs are completely greek to me. Can you elaborate? --benji
Sep 11 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
Well done. I think the design has come together very nicely. I'm especially happy with all the new names, which make a big difference for me in being able to visualize how the proposal works. The old names (fromLeft, etc) were very opaque to me. (btw: head & toe? i love it!) In its current state, this actually gets me pretty excited about D2. Maybe even enough to finally slog my way through all the const stuff. One tiny typo, though: In the "Forward range" section, the code sample still uses "left" instead of "head".
Fixed, thanks.
 And, there are two sections (which I think are related to one another) 
 that left me scratching my head:
 
 Input Ranges:
 "In case ElementType!(R) has aliases (such as a reference, pointer, or 
 array type), the iterator is free to recycle it it upon the call to 
 r.next, so client code must do a deep copy if preserving the value is 
 needed. [NOTE: This is a weakness in the design. A better way of 
 figuring recycling should be found.] The call is defined only right 
 after r.done returned false."
 
 Forward Ranges:
 "Also, forward ranges iterate over "real" elements, which makes in-place 
 mutation of r.head possible."
 
 Those paragraphs are completely greek to me. Can you elaborate?
Consider iterating over an array of int[], specifically an int[][]. Then when you call r.head you see the current int[]. You can store it and use it a few steps later or even after the iteration is done for as long as the array is around. Contrast that with iterating a file containing lines of integers. The file has a buffer of type int[]. Every time you call r.next, the file range reads a new line, parses the integers, and REFILLS the array with them. If if generated a new array every line, that would cause a great deal of allocations. Same about the in-place thing. If you modify elements in the array, they stay modified. If you modify the buffer of a file, your changes get overwritten upon r.next. Andrei
Sep 12 2008
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Consider iterating over an array of int[], specifically an int[][]. Then 
 when you call r.head you see the current int[]. You can store it and use 
 it a few steps later or even after the iteration is done for as long as 
 the array is around.
 
 Contrast that with iterating a file containing lines of integers. The 
 file has a buffer of type int[]. Every time you call r.next, the file 
 range reads a new line, parses the integers, and REFILLS the array with 
 them. If if generated a new array every line, that would cause a great 
 deal of allocations.
Gotcha. I understand now. Thinking off the top of my head, though, is it actually necessary define input ranges as reusing the same array? Wouldn't a peephole optimizer get rid of those extra allocations anyhow? --benji
Sep 12 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
Well done. I think the design has come together very nicely. I'm especially happy with all the new names, which make a big difference for me in being able to visualize how the proposal works. The old names (fromLeft, etc) were very opaque to me. (btw: head & toe? i love it!) In its current state, this actually gets me pretty excited about D2. Maybe even enough to finally slog my way through all the const stuff. One tiny typo, though: In the "Forward range" section, the code sample still uses "left" instead of "head".
Fixed, thanks.
 And, there are two sections (which I think are related to one another) 
 that left me scratching my head:

 Input Ranges:
 "In case ElementType!(R) has aliases (such as a reference, pointer, or 
 array type), the iterator is free to recycle it it upon the call to 
 r.next, so client code must do a deep copy if preserving the value is 
 needed. [NOTE: This is a weakness in the design. A better way of 
 figuring recycling should be found.] The call is defined only right 
 after r.done returned false."

 Forward Ranges:
 "Also, forward ranges iterate over "real" elements, which makes 
 in-place mutation of r.head possible."

 Those paragraphs are completely greek to me. Can you elaborate?
Consider iterating over an array of int[], specifically an int[][]. Then when you call r.head you see the current int[]. You can store it and use it a few steps later or even after the iteration is done for as long as the array is around. Contrast that with iterating a file containing lines of integers. The file has a buffer of type int[]. Every time you call r.next, the file range reads a new line, parses the integers, and REFILLS the array with them. If if generated a new array every line, that would cause a great deal of allocations. Same about the in-place thing. If you modify elements in the array, they stay modified. If you modify the buffer of a file, your changes get overwritten upon r.next. Andrei
How about having the element type of the file-containing-lines-of-integers range be const(int[]) instead of int[]? I think it would solve the ownership problem, but it might introduce other problems, such as, how to make InputRange!(int[]) be covariant with InputRange!(const(int[]). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 25 2008
prev sibling next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
I propose to finally move to D group from D.announce. The best way would be to post your announcement there.
Sep 12 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 2:44 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made one
 more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not all),
 and the names of the primitives have been updated. Bicycle shed galore! But
 don't forget to comment on the reactor as well :o).
Reactor? You meant "refactor" maybe? --bb
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 2:44 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made one
 more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not all),
 and the names of the primitives have been updated. Bicycle shed galore! But
 don't forget to comment on the reactor as well :o).
Reactor? You meant "refactor" maybe?
I think the original bicicle shed story was about a nuclear plant design including a bicycle shed. So I meant to ask you to comment about the nuclear reactor, not only the bicycle shed. Andrei
Sep 12 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

In some situations (longer functions, where there are 2 or more types, etc) It
may be better to use longer & more descriptive names for types, instead of E T
etc.

Bye,
bearophile
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 In some situations (longer functions, where there are 2 or more types, etc) It
may be better to use longer & more descriptive names for types, instead of E T
etc.
 
 Bye,
 bearophile
Fixed, thanks. Andrei
Sep 12 2008
prev sibling next sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
 
 
 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:
 
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
Sep 12 2008
next sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Andrei Alexandrescu Wrote:

 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:
 
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
Well, in the first place thanks to you! I really enjoy this enthusiastic attitude. About "first", well, I didn't mentioned "first" as an alternative to "head" but "header" which is not necessarily an animal-like characteristic. Anyway, "head" is definitely more poly-meaning than "toe"!!!! I definitely would look for neutral alternative... What about "isDone"? And yes, to have a personality in the naming is nice but I guess that in this case seems too concrete, anthropocentric, I don't know, what the heck! even "tail" is semantically wider! Keep this great interaction! Thanks!
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says. Andrei
Sep 12 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there. --bb
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
Sep 12 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Sep 13, 2008 at 12:03 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
Hmm. One semantic issue I have is that the tip usually refers to the infinitessimal point at the end. Not a thing with substance. I'm having trouble feeling like I'm going to get an item back when I look at "x.tip". Head has huge history being used for the item at the front of a list, so I think that's much less likely to cause anyone looking at D code to scratch their heads. It will be obvious what it means even in relative isolation. head/tip will often appear without "toe" in forward range algos. So you need to be able to easily recognize what "tip" means without seeing that "toe" to give context. Toe on the other hand will probably almost always appear with his mate. Ooh, another scale thing, but a head is obviously a very different scale than a toe. A foot is closer to the same scale. Maybe head/foot is better than head/toe. The connection between retreating / feet is stronger that retreating / toes, too! --bb
Sep 12 2008
parent reply Pablo Ripolles <in-call gmx.net> writes:
Bill Baxter Wrote:

 On Sat, Sep 13, 2008 at 12:03 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
Hmm. One semantic issue I have is that the tip usually refers to the infinitessimal point at the end. Not a thing with substance. I'm having trouble feeling like I'm going to get an item back when I look at "x.tip". Head has huge history being used for the item at the front of a list, so I think that's much less likely to cause anyone looking at D code to scratch their heads. It will be obvious what it means even in relative isolation. head/tip will often appear without "toe" in forward range algos. So you need to be able to easily recognize what "tip" means without seeing that "toe" to give context. Toe on the other hand will probably almost always appear with his mate. Ooh, another scale thing, but a head is obviously a very different scale than a toe. A foot is closer to the same scale. Maybe head/foot is better than head/toe. The connection between retreating / feet is stronger that retreating / toes, too! --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"... my problem with foot is that there is necessarily more than one. perhaps in the world of the anatomy of the chordates we can find something... dunno, "coccyx" is pretty weird but at least there is only one. Cheers!
Sep 12 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Hmm.  One semantic issue I have is that the tip usually refers to the
 infinitessimal point at the end.  Not a thing with substance.  I'm
 having trouble feeling like I'm going to get an item back when I look
 at "x.tip".  Head has huge history being used for the item at the
 front of a list, so I think that's much less likely to cause anyone
 looking at D code to scratch their heads.  It will be obvious what it
 means even in relative isolation.  head/tip will often appear without
 "toe" in forward range algos.  So you need to be able to easily
 recognize what "tip" means without seeing that "toe" to give context.
 Toe on the other hand will probably almost always appear with his
 mate.

 Ooh, another scale thing, but a head is obviously a very different
 scale than a toe.  A foot is closer to the same scale.  Maybe
 head/foot is better than head/toe.  The connection between retreating
 / feet is stronger that retreating / toes, too!

 --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
Nope. I'm pretty sure that the discussion is about replacing "head" with "tip". There's an expression "from tip to toe". But I think your confusion (or is it mine?) about which end would be the tip is pretty damning.
 my problem with foot is that there is necessarily more than one.
There's also more than one toe. But I guess you thought that "toe" was out.
 perhaps in the world of the anatomy of the chordates we can find something...
dunno, "coccyx" is pretty weird but at least there is only one.
Well, there is only one tail... but it's what functional guys call everything but the head, so Anrdrei wants to avoid it. --bb
Sep 12 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Hmm.  One semantic issue I have is that the tip usually refers to the
 infinitessimal point at the end.  Not a thing with substance.  I'm
 having trouble feeling like I'm going to get an item back when I look
 at "x.tip".  Head has huge history being used for the item at the
 front of a list, so I think that's much less likely to cause anyone
 looking at D code to scratch their heads.  It will be obvious what it
 means even in relative isolation.  head/tip will often appear without
 "toe" in forward range algos.  So you need to be able to easily
 recognize what "tip" means without seeing that "toe" to give context.
 Toe on the other hand will probably almost always appear with his
 mate.

 Ooh, another scale thing, but a head is obviously a very different
 scale than a toe.  A foot is closer to the same scale.  Maybe
 head/foot is better than head/toe.  The connection between retreating
 / feet is stronger that retreating / toes, too!

 --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
Nope. I'm pretty sure that the discussion is about replacing "head" with "tip". There's an expression "from tip to toe".
There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.
 Well, there is only one tail... but it's what functional guys call
 everything but the head, so Anrdrei wants to avoid it.
And what was wrong with first/last? Sean
Sep 12 2008
next sibling parent reply Jerry Quinn <jlquinn optonline.net> writes:
Sean Kelly Wrote:

 Bill Baxter wrote:
 On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Hmm.  One semantic issue I have is that the tip usually refers to the
 infinitessimal point at the end.  Not a thing with substance.  I'm
 having trouble feeling like I'm going to get an item back when I look
 at "x.tip".  Head has huge history being used for the item at the
 front of a list, so I think that's much less likely to cause anyone
 looking at D code to scratch their heads.  It will be obvious what it
 means even in relative isolation.  head/tip will often appear without
 "toe" in forward range algos.  So you need to be able to easily
 recognize what "tip" means without seeing that "toe" to give context.
 Toe on the other hand will probably almost always appear with his
 mate.

 Ooh, another scale thing, but a head is obviously a very different
 scale than a toe.  A foot is closer to the same scale.  Maybe
 head/foot is better than head/toe.  The connection between retreating
 / feet is stronger that retreating / toes, too!

 --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
Nope. I'm pretty sure that the discussion is about replacing "head" with "tip". There's an expression "from tip to toe".
There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.
 Well, there is only one tail... but it's what functional guys call
 everything but the head, so Anrdrei wants to avoid it.
And what was wrong with first/last?
Another few possibilities fore/aft front/back start/end begin/end
Sep 12 2008
parent reply downs <default_357-line yahoo.de> writes:
Jerry Quinn wrote:
 Sean Kelly Wrote:
 
 Bill Baxter wrote:
 On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Hmm.  One semantic issue I have is that the tip usually refers to the
 infinitessimal point at the end.  Not a thing with substance.  I'm
 having trouble feeling like I'm going to get an item back when I look
 at "x.tip".  Head has huge history being used for the item at the
 front of a list, so I think that's much less likely to cause anyone
 looking at D code to scratch their heads.  It will be obvious what it
 means even in relative isolation.  head/tip will often appear without
 "toe" in forward range algos.  So you need to be able to easily
 recognize what "tip" means without seeing that "toe" to give context.
 Toe on the other hand will probably almost always appear with his
 mate.

 Ooh, another scale thing, but a head is obviously a very different
 scale than a toe.  A foot is closer to the same scale.  Maybe
 head/foot is better than head/toe.  The connection between retreating
 / feet is stronger that retreating / toes, too!

 --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
Nope. I'm pretty sure that the discussion is about replacing "head" with "tip". There's an expression "from tip to toe".
There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.
 Well, there is only one tail... but it's what functional guys call
 everything but the head, so Anrdrei wants to avoid it.
And what was wrong with first/last?
Another few possibilities fore/aft front/back start/end begin/end
Bow/stern? Of course, if we ever get a tree implementation, we have to use port/starboard :p
Sep 12 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Sep 13, 2008 at 12:16 PM, downs <default_357-line yahoo.de> wrote:
 Jerry Quinn wrote:
 Sean Kelly Wrote:


 Another few possibilities

 fore/aft
 front/back
 start/end
 begin/end
Bow/stern? Of course, if we ever get a tree implementation, we have to use port/starboard :p
PeanutButter/Jelly? Sonny/Cher? Ooh I know: Obama/McCain! Then we can have fun seeing how far to the left() McCain can go and how far to the right() Obama can! It's a race to see who can get to the middle ground mass appeal positions first! Seriously though, its head/foot. End of story. --bb
Sep 12 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Sean Kelly <sean invisibleduck.org> wrote:
 Bill Baxter wrote:
 On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Hmm.  One semantic issue I have is that the tip usually refers to the
 infinitessimal point at the end.  Not a thing with substance.  I'm
 having trouble feeling like I'm going to get an item back when I look
 at "x.tip".  Head has huge history being used for the item at the
 front of a list, so I think that's much less likely to cause anyone
 looking at D code to scratch their heads.  It will be obvious what it
 means even in relative isolation.  head/tip will often appear without
 "toe" in forward range algos.  So you need to be able to easily
 recognize what "tip" means without seeing that "toe" to give context.
 Toe on the other hand will probably almost always appear with his
 mate.

 Ooh, another scale thing, but a head is obviously a very different
 scale than a toe.  A foot is closer to the same scale.  Maybe
 head/foot is better than head/toe.  The connection between retreating
 / feet is stronger that retreating / toes, too!

 --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
Nope. I'm pretty sure that the discussion is about replacing "head" with "tip". There's an expression "from tip to toe".
There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.
 Well, there is only one tail... but it's what functional guys call
 everything but the head, so Anrdrei wants to avoid it.
And what was wrong with first/last?
AFAIK, after Andrei switched to isEmpty/next/first for an Input range some algos started to look ugly to him. I can't remember him mentioning which algorithms made him so upset that he reconsidered the name. Perhaps it was something about input stream where you called its next and then accessed its first... Probably it looked a bit bad. But if we ever get rid of first/head/tip/Obama in Input range then I cannot see a reason why ban first/last. It's the most clean and abstract pair of all the body/airplane/politician parts being proposed.
Sep 13 2008
prev sibling next sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Andrei Alexandrescu Wrote:

 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
brilliant! I think "tip" is just fantastic! "head" and "tip" wonderful couple. yes, *this* one is as neutral as it can be! besides, the tip of something is unique! if you hold something by its toe, which one of how many are you holding? :) when I name boolean identifiers, I kind follow these "rules": *properties: the instance is the grammatical subject, so it is very natural to use "is" as in self.isDone *scalar variables: I tend to append the "whether" as in whetherDone *array variables: here you have that the index to access the value is related to the grammatical subject, then I use something as visited[i] *functions: here you have that the argument to be passed to the function might be the grammatical subject, then I use something as searched(x) or pointIsInCell(P, C) Its always nice that a std library is as regular as it can be, perhaps as your own library. for special, particular words we already have the keywords, right? Cheers!
Sep 12 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:
 
 Bill Baxter wrote:

 -- snip --

 Andrei

 P.S. The more I think of it, the more I like "tip" of the range. Short, 
 poignant, easy to remember. Not pressing the red button just yet.
brilliant! I think "tip" is just fantastic! "head" and "tip" wonderful couple. yes, *this* one is as neutral as it can be! besides, the tip of something is unique! if you hold something by its toe, which one of how many are you holding? :) -- snip -- Cheers!
I don't think people know what rng.tip means at the first glance. I interpret it as a sharp, pointy object, and that makes no sense for an iterator/range. I still favor "traditional" names e.g. ".tail", ".back" or ".last". Cheers, Kenny. P.S. ".retreat" is a very nice name. I like it. :)
Sep 13 2008
parent Pablo Ripolles <in-call gmx.net> writes:
KennyTM~ Wrote:

 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:
 
 Bill Baxter wrote:
>> >> -- snip --
 Andrei

 P.S. The more I think of it, the more I like "tip" of the range. Short, 
 poignant, easy to remember. Not pressing the red button just yet.
brilliant! I think "tip" is just fantastic! "head" and "tip" wonderful couple. yes, *this* one is as neutral as it can be! besides, the tip of something is unique! if you hold something by its toe, which one of how many are you holding? :) -- snip -- Cheers!
I don't think people know what rng.tip means at the first glance. I interpret it as a sharp, pointy object, and that makes no sense for an iterator/range. I still favor "traditional" names e.g. ".tail", ".back" or ".last".
Well, me too although I misinterpreted as an alternative to .toe which wasn't the intent anyway... :$ So, yes, I agree .tip is not a nice option, however not for its "sharpness"... Cheers!
Sep 14 2008
prev sibling next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 P.S. The more I think of it, the more I like "tip" of the range. Short, 
 poignant, easy to remember. Not pressing the red button just yet.
When I see "x.tip", it makes me think of the verb ("a function that tips x over"). If I force myself to think of the noun-sense, "tip" is obviously at one of the limits of the range, but is it at the front or the back? I'd have to check the docs to remember. --benji
Sep 12 2008
prev sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Andrei Alexandrescu Wrote:

 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
A perhaps more aeronautical term but short and nice as an alternative to "tip" might be "aft". So, what about "aft" instead of "tip"? "head"/"aft" it's not that bad, is it? Cheers!
Sep 12 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
According to http://en.wikipedia.org/wiki/Aft
The opposite of aft is forward, pronounced "forrard" for some reason.
Not good I think.

I see nothing wrong with head/foot.
There's "head of a bed / foot of a bed" so it is not the case that
these words always refer to people or that
there's always more than one foot.

---bb

On Sat, Sep 13, 2008 at 7:12 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Andrei Alexandrescu Wrote:

 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
A perhaps more aeronautical term but short and nice as an alternative to "tip" might be "aft". So, what about "aft" instead of "tip"? "head"/"aft" it's not that bad, is it? Cheers!
Sep 12 2008
parent Pablo Ripolles <in-call gmx.net> writes:
Bill Baxter Wrote:

 According to http://en.wikipedia.org/wiki/Aft
 The opposite of aft is forward, pronounced "forrard" for some reason.
 Not good I think.
Well, those are the adjective forms. I was thinking about the aft of an airplane...
 
 I see nothing wrong with head/foot.
 There's "head of a bed / foot of a bed" so it is not the case that
 these words always refer to people or that
 there's always more than one foot.
Ok, that sounds more convincing than "head"/"toe", that's for sure.
 
 ---bb
 
 On Sat, Sep 13, 2008 at 7:12 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Andrei Alexandrescu Wrote:

 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
A perhaps more aeronautical term but short and nice as an alternative to "tip" might be "aft". So, what about "aft" instead of "tip"? "head"/"aft" it's not that bad, is it? Cheers!
Sep 12 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 12 de septiembre a las 09:39 me escribiste:
 Pablo Ripolles wrote:
What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
I much prefer done, because is shorter, and, well, maybe because I hate CamelCase too ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Creativity is great but plagiarism is faster
Sep 12 2008
next sibling parent Pablo Ripolles <in-call gmx.net> writes:
Leandro Lucarella Wrote:

 Andrei Alexandrescu, el 12 de septiembre a las 09:39 me escribiste:
 Pablo Ripolles wrote:
What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
I much prefer done, because is shorter, and, well, maybe because I hate CamelCase too ;)
I do not like it either, we already have it though. I definitely prefer CamelCase than inconsistency. Cheers!
Sep 12 2008
prev sibling parent Pablo Ripolles <in-call gmx.net> writes:
Leandro Lucarella Wrote:

 Andrei Alexandrescu, el 12 de septiembre a las 09:39 me escribiste:
 Pablo Ripolles wrote:
What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
I much prefer done, because is shorter, and, well, maybe because I hate CamelCase too ;)
I do not like it either, we already have it though. I definitely prefer CamelCase than inconsistency. Cheers!
Sep 12 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Thanks. One problem in coding with first and last was that sometimes the 
 code looks unnatural, especially when your range exposes a few more 
 functions. In a stream parser, dealing with the "first" element is not 
 the most natural way to think of it. But I agree that first and last are 
 definitely palatable and natural most of the time. But then again, 
 shouldn't any design have the inevitable cutesy that makes it memorable? 
 :o)
One consideration when selecting names is how it would interact with google. One advantage to head/toe is there is already head/tail when thinking of a list, and head/toe would fit into that naturally.
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Thanks. One problem in coding with first and last was that sometimes 
 the code looks unnatural, especially when your range exposes a few 
 more functions. In a stream parser, dealing with the "first" element 
 is not the most natural way to think of it. But I agree that first and 
 last are definitely palatable and natural most of the time. But then 
 again, shouldn't any design have the inevitable cutesy that makes it 
 memorable? :o)
One consideration when selecting names is how it would interact with google. One advantage to head/toe is there is already head/tail when thinking of a list, and head/toe would fit into that naturally.
I agree. Sorry tipsters. I think head/toe has one established thing and one cutesy. Tip/toe has two cutesies. An unwritten (or perhaps actually written) rule of good humor is that you shouldn't make a double pun. They somehow don't add to double effect. Andrei
Sep 12 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Sep 13, 2008 at 5:11 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Thanks. One problem in coding with first and last was that sometimes the
 code looks unnatural, especially when your range exposes a few more
 functions. In a stream parser, dealing with the "first" element is not the
 most natural way to think of it. But I agree that first and last are
 definitely palatable and natural most of the time. But then again, shouldn't
 any design have the inevitable cutesy that makes it memorable? :o)
One consideration when selecting names is how it would interact with google. One advantage to head/toe is there is already head/tail when thinking of a list, and head/toe would fit into that naturally.
I agree. Sorry tipsters. I think head/toe has one established thing and one cutesy. Tip/toe has two cutesies. An unwritten (or perhaps actually written) rule of good humor is that you shouldn't make a double pun. They somehow don't add to double effect. Andrei
Head / foot! No cutesie == even better! --bb
Sep 12 2008
prev sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gadn7c$oe5$4 digitalmars.com...
 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
From the limited posts I've had the time to read, it seems this topic has probably been already beaten to death, but how about "tail" instead of "toe". And instead of the "yellow" primitive, why not "intersect(r,s)" , "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc. Wasn't "intersect" the original? Thanks, - Dave
Sep 12 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:
 
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gadn7c$oe5$4 digitalmars.com...
 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle 
 shed galore! But don't forget to comment on the reactor as well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
From the limited posts I've had the time to read, it seems this topic has probably been already beaten to death, but how about "tail" instead of "toe". And instead of the "yellow" primitive, why not "intersect(r,s)" , "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc. Wasn't "intersect" the original?
Intersect is good but doesn't reveal an important detail: the operation is not commutative. Andrei
Sep 14 2008
next sibling parent Pablo Ripolles <in-call gmx.net> writes:
Andrei Alexandrescu Wrote:

 Dave wrote:
 
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gadn7c$oe5$4 digitalmars.com...
 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle 
 shed galore! But don't forget to comment on the reactor as well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
From the limited posts I've had the time to read, it seems this topic has probably been already beaten to death, but how about "tail" instead of "toe". And instead of the "yellow" primitive, why not "intersect(r,s)" , "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc. Wasn't "intersect" the original?
Intersect is good but doesn't reveal an important detail: the operation is not commutative.
What about wedge(r, s) or r.wedge(s)? Perhaps meet(r, s) or r.meet(s)? The source of these proposals is based on the symbols and terms used in the field of algebraic topology. The meet operation in commutative topologies is the standard intersection, whereas in noncommutative topologies it is implemented employing noncommutative intersection. In both cases the term (meet) and the symbol (wedge) are used. Cheers!
Sep 15 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 Dave wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gadn7c$oe5$4 digitalmars.com...
 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle 
 shed galore! But don't forget to comment on the reactor as well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
From the limited posts I've had the time to read, it seems this topic has probably been already beaten to death, but how about "tail" instead of "toe". And instead of the "yellow" primitive, why not "intersect(r,s)" , "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc. Wasn't "intersect" the original?
Intersect is good but doesn't reveal an important detail: the operation is not commutative. Andrei
.cross ? .across ? .join ? .onlyAlso ? By the way, how does "yellow" not commutative?
Sep 15 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 Dave wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in 
 message news:gadn7c$oe5$4 digitalmars.com...
 Pablo Ripolles wrote:
 Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, 
 I made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties 
 (not all), and the names of the primitives have been updated. 
 Bicycle shed galore! But don't forget to comment on the reactor as 
 well :o).


 Andrei
Well, it looks prety clean! :D However, I'm not completely sure I like these "head" and "toe" names selection. It projects to much on it, doesn't it? couldn't it be more neutral? perhaps more conceptual? I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice. If "head" is the header item, why not call it "header"? If ''toe" is the last item, why not call it "last"? Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"? Cheers!
Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) Andrei
From the limited posts I've had the time to read, it seems this topic has probably been already beaten to death, but how about "tail" instead of "toe". And instead of the "yellow" primitive, why not "intersect(r,s)" , "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc. Wasn't "intersect" the original?
Intersect is good but doesn't reveal an important detail: the operation is not commutative. Andrei
.cross ? .across ? .join ? .onlyAlso ? By the way, how does "yellow" not commutative?
In the forward ranges realm, if you start from the wrong range, you never get to compute the "yellow". Andrei
Sep 15 2008
prev sibling parent Lars Kyllingstad <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 Dave wrote:
 And instead of the "yellow" primitive, why not "intersect(r,s)" , 
 "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc.

 Wasn't "intersect" the original?
Intersect is good but doesn't reveal an important detail: the operation is not commutative.
How about 'overlap', then? Still not perfect, but at least it doesn't carry the name of an inherently commutative mathematical operation. -Lars
Sep 16 2008
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Dave wrote:
 And instead of the "yellow" primitive, why not "intersect(r,s)" , 
 "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc.
When I first read this, I thought it said yellow = intersect(r,g) which, of course, only works in the RGB scheme. :)
Sep 15 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
 
 
 Andrei
Just a little typo, in the "Output range" example: // Copies a range to another void copy(R1, R2)(R1 src, R2 tgt) { for (; !src.done; src.head) { tgt.put(src.head); } } the for increment should be src.next
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
Just a little typo, in the "Output range" example: // Copies a range to another void copy(R1, R2)(R1 src, R2 tgt) { for (; !src.done; src.head) { tgt.put(src.head); } } the for increment should be src.next
Fixed, thanks Ary. Andrei
Sep 12 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
I've got a heap of virtual sticky notes all over my monitor while reading the edited version, so here they are. *) done/next/head thing got even more confusing. Range is not a process, you cannot be done with it. If you call a spade a spade, then done() is actually a safe, guarded prefetch, head is, well, sort of what it claims to be, and next() just relaxes done's guard. The look ahead/fetch next approach was much more intuitive. I don't understand why you dropped it. I remember you saying that Bill convinced you it was wrong but I either missed the arguments themselves or hadn't understood them. *) How do you enforce noncopyable/release semantics over a range? I don't think D got any means for that. Also if an input range is a class passed by reference, will you allow it? *) before() is valid for a single-linked list, forward iterators should support it. *) You've replaced tail with toe because people may think tail could contain many elements. But it doesn't pair well with head, and besides, if I split a list in the middle I'd call the halves a head and a tail which form a logical pair. Maybe you consider tip-toe, or top-toe, from the top of my head? ;) *) A typo: in Output range sample: for (; !src.done; src.head) should be for (; !src.done; src.next) *) next() is specified to return a value, but reduce() is not. This is probably a typo. I'd prefer them both be implemented as (done(), head) and (reduce(), toe) respectively, but I don't know what your intention was. *) Still uncertain support for shrink-on-read, no support for shrink-on- write and slicing forward and bidirectional ranges. Are they going into a library?
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
I've got a heap of virtual sticky notes all over my monitor while reading the edited version, so here they are. *) done/next/head thing got even more confusing. Range is not a process, you cannot be done with it. If you call a spade a spade, then done() is actually a safe, guarded prefetch, head is, well, sort of what it claims to be, and next() just relaxes done's guard.
The art is to find something that's reasonably evocative without being too long. I doubt safeGuardedPrefetch will fare very well, although I agree it's very precise. Inevitably a shorter word will also be less precise.
 The look ahead/fetch next approach was much more intuitive.  I don't 
 understand why you dropped it.  I remember you saying that Bill 
 convinced you it was wrong but I either missed the arguments themselves 
 or hadn't understood them.
 
 *)
 How do you enforce noncopyable/release semantics over a range?  I don't 
 think D got any means for that.  Also if an input range is a class 
 passed by reference, will you allow it?
Walter is working on adding that feature now.
 *)
 before() is valid for a single-linked list, forward iterators should 
 support it.
This is subtle. Consider a singly-linked list that uses a Node* as a range. Condition for termination is p.next == null. Now to build list.before(another) you'd have to express a fragment of a list, so the one-Node* representation is insufficient. You have to return a range with TWO Node* objects, one pointing to the beginning and the other to the end of the fragment. That can be done, but it also means that the before operation is not closed under your Range type. You'd have to return a different Range type, a fatter one. Or we could impose that all lists use fat ranges to start with. But I don't want that. I hate people discussing, "Oh you want a list? use std.slist, it's cool. But beware, if you want a really fast list you better do it yourself." This is a no-go because whenever you're in the mood of using a singly-linked list, it being lightweight is invariably the main concern. So I want to write a singly-linked list that is as fast as the classic singly-linked list implemented by hand from first principles. If we fail to do so, we can as well go home. If we want to achieve that, we need to model the slist fundamentals properly. Part of that proper modeling is that slist is not closed under the "before" operation.
 *)
 You've replaced tail with toe because people may think tail could 
 contain many elements.  But it doesn't pair well with head, and besides, 
 if I split a list in the middle I'd call the halves a head and a tail 
 which form a logical pair.  Maybe you consider tip-toe, or top-toe, from 
 the top of my head? ;)
Head to toe is culturally appealing for English speakers. But tip to toe is also cool. Nice tip, thanks. :o)
 *)
 A typo: in Output range sample:
 	for (; !src.done; src.head)
 should be
 	for (; !src.done; src.next)
Fixed, thanks.
 *)
 next() is specified to return a value, but reduce() is not.  This is 
 probably a typo.  I'd prefer them both be implemented as (done(), head) 
 and (reduce(), toe) respectively, but I don't know what your intention 
 was.
Neither of next and retreat should return a value. In wake of constructors/destructors, we shouldn't return by-value lightly.
 *)
 Still uncertain support for shrink-on-read, no support for shrink-on-
 write and slicing forward and bidirectional ranges.  Are they going into 
 a library?
Yes, excellent point. The document on ranges tells what they must define. The standard library can and will define convenience functions using those primitives. This is appealing because there will be many range implementations and you don't want to burden everyone with implementing a ton of non-orthogonal stuff. Andrei
Sep 12 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 *)
 next() is specified to return a value, but reduce() is not.  This is 
 probably a typo.  I'd prefer them both be implemented as (done(), head) 
 and (reduce(), toe) respectively, but I don't know what your intention 
 was.
Neither of next and retreat should return a value. In wake of constructors/destructors, we shouldn't return by-value lightly.
Then, in Input range primitives, e=r.next must be just r.next.
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 *)
 next() is specified to return a value, but reduce() is not.  This is 
 probably a typo.  I'd prefer them both be implemented as (done(), head) 
 and (reduce(), toe) respectively, but I don't know what your intention 
 was.
Neither of next and retreat should return a value. In wake of constructors/destructors, we shouldn't return by-value lightly.
Then, in Input range primitives, e=r.next must be just r.next.
Oh, now I see. Fixed. But I still want us to contemplate the possibility of unifying input ranges with recycling, and other ranges, under the same interface. Andrei
Sep 12 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 2:44 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made one
 more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not all),
 and the names of the primitives have been updated. Bicycle shed galore! But
 don't forget to comment on the reactor as well :o).
Looking better! I disagree with this: """ User code may pair iterators wrongly to create meaningless ranges. For example, given collections a and b of the same type, a.begin to b.begin makes no sense as a range, yet both the compiler and the runtime are hard-pressed in rejecting such mistakes. Such problems are often (though not always) avoided if range is the primitive. """ You can just as easily create nonsensical ranges using before() and after(). And I don't recall ever making the mistake of mixing up one container's begin() with another's end(). I disagree here too: """ A bidirectional range models the natural way of iterating a doubly-linked list. """ It maybe provides an efficient way to implement many algorithms on a doubly linked list. But to say it implements the natural way of iterating one is a big stretch. I was about to argue that "head" should be "value" and "toe" should be "tvalue" on the grounds that most of the time iteration with a range going to be all about the head. For all intents and purposes it *is* the current value. Another benefit is that the terminology of ".value" generalizes to plain iterators well. And it may be useful for users to create iterators that support some but not all of the range interface (like .value and .next). The name .value doesn't work for the random access concept so well, but if you are using the random access range like a forward range it does, and if you aren't using it like a forward range, then you'd use r[0] anyway instead of r.value. However, that was mainly motivated by the feeling that if we ever do have iterators, that having to make the dereference op be .head would look fatally silly. But I think eventually if you get out of the iterator mindset, and think of ranges as everything, then it's not so silly to describe an iterator as a poor castrated half-range that knows where its head is, where it's next is, but isn't so sure about the rest. So I think I can live with .head. Even for iterators if we end up having them. But I do have some suggestions nonetheless! Marked with ==> below. -- Universal -- r.done r.init --- Input : Universal --- e=r.head e=r.next r1=r.release ==> r.transfer? Release sounds like ref counting (e.g. in COM) Also seems like r.transfer(r1) could make implementation more efficient. Or perhaps make it a .swap like STL. Maybe you have something against .swap? -- Output : Universal -- r.put(e) -- Forward : Input, (optional) Output -- r1 = r r.head = e t=r.after(s) -- Bidirectional : Forward -- e = r.toe r.toe = e r.reduce ==> r.retreat -- aka "pull back" t = r.before(s) -- Random access : Bidirectional -- l = r.length e = r[n] r[n] = e r1 = r[n1..n2] ------------ Just those two! --bb
Sep 12 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Bill Baxter <wbaxter gmail.com> wrote:
 But I do have some suggestions nonetheless!  Marked with ==> below.
 
 -- Universal --
 r.done
 r.init
 
 --- Input : Universal ---
 e=r.head
 e=r.next
 r1=r.release  ==> r.transfer?  Release sounds like ref counting (e.g. in COM)
                           Also seems like r.transfer(r1) could make
 implementation more efficient.
                           Or perhaps make it a .swap like STL.  Maybe
 you have something against .swap?
 
 -- Output : Universal --
 r.put(e)
 
 -- Forward : Input, (optional) Output  --
 r1 = r
 r.head = e
 t=r.after(s)
 
 -- Bidirectional : Forward --
 e = r.toe
 r.toe = e
 r.reduce           ==> r.retreat  -- aka "pull back"
 t = r.before(s)
 
 -- Random access : Bidirectional --
 l = r.length
 e = r[n]
 r[n] = e
 r1 = r[n1..n2]
 ------------
 
 Just those two!
I've got a bit of insight! XD -- Common r.empty -- InOut v = r.next; => T R.next(); r.next = v; => T R.next(T v); -- Forward: InOut, copyable v = r.tip r.tip = v r1 = r.before(s) r1 = r.after(s) -- Bidir: Forward v = r.prev r.prev = v v = r.toe r.toe = v -- Random: Bidir no changes prev() seems very misleading, otherwise I like it.
Sep 12 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 11:22 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 But I do have some suggestions nonetheless!  Marked with ==> below.

 -- Universal --
 r.done
 r.init

 --- Input : Universal ---
 e=r.head
 e=r.next
 r1=r.release  ==> r.transfer?  Release sounds like ref counting (e.g. in COM)
                           Also seems like r.transfer(r1) could make
 implementation more efficient.
                           Or perhaps make it a .swap like STL.  Maybe
 you have something against .swap?

 -- Output : Universal --
 r.put(e)

 -- Forward : Input, (optional) Output  --
 r1 = r
 r.head = e
 t=r.after(s)

 -- Bidirectional : Forward --
 e = r.toe
 r.toe = e
 r.reduce           ==> r.retreat  -- aka "pull back"
 t = r.before(s)

 -- Random access : Bidirectional --
 l = r.length
 e = r[n]
 r[n] = e
 r1 = r[n1..n2]
 ------------

 Just those two!
I've got a bit of insight! XD -- Common r.empty -- InOut v = r.next; => T R.next(); r.next = v; => T R.next(T v); -- Forward: InOut, copyable v = r.tip r.tip = v r1 = r.before(s) r1 = r.after(s) -- Bidir: Forward v = r.prev r.prev = v v = r.toe r.toe = v -- Random: Bidir no changes prev() seems very misleading, otherwise I like it.
So basically you changed done ==> empty head ==> tip retreat ==> prev ? I'm actually ok with either "done" or "empty". "Done" is weird on a random access range, but "empty" is weird on file input range, or a generator. Or on the HMM example which is "done" when it reaches an end state, but is not really "empty". "head to toe" is a perfectly common expression, at least in American English. Not sure why you don't like it. But tip to toe is kinda cool for being 1 less letter! And no less clear. "prev" is horrible. I still like "retreat" best so far. We need the contrapositive of "next" not the "opposite". :-) And since that doesn't exist we should just go for a word that sorta means the right thing and won't be confused with being the opposite (or with being something else entirely like "reduce"). --bb
Sep 12 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:22 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 But I do have some suggestions nonetheless!  Marked with ==> below.

 -- Universal --
 r.done
 r.init

 --- Input : Universal ---
 e=r.head
 e=r.next
 r1=r.release  ==> r.transfer?  Release sounds like ref counting (e.g. in COM)
                           Also seems like r.transfer(r1) could make
 implementation more efficient.
                           Or perhaps make it a .swap like STL.  Maybe
 you have something against .swap?

 -- Output : Universal --
 r.put(e)

 -- Forward : Input, (optional) Output  --
 r1 = r
 r.head = e
 t=r.after(s)

 -- Bidirectional : Forward --
 e = r.toe
 r.toe = e
 r.reduce           ==> r.retreat  -- aka "pull back"
 t = r.before(s)

 -- Random access : Bidirectional --
 l = r.length
 e = r[n]
 r[n] = e
 r1 = r[n1..n2]
 ------------

 Just those two!
I've got a bit of insight! XD -- Common r.empty -- InOut v = r.next; => T R.next(); r.next = v; => T R.next(T v); -- Forward: InOut, copyable v = r.tip r.tip = v r1 = r.before(s) r1 = r.after(s) -- Bidir: Forward v = r.prev r.prev = v v = r.toe r.toe = v -- Random: Bidir no changes prev() seems very misleading, otherwise I like it.
So basically you changed done ==> empty head ==> tip retreat ==> prev ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
 "prev" is horrible.  I still like "retreat" best so far.  We need the
 contrapositive of "next" not the "opposite".  :-)  And since that
 doesn't exist we should just go for a word that sorta means the right
 thing and won't be  confused with being the opposite (or with being
 something else entirely like "reduce").
v = r.retreat r.retreat = v It's definitely better than prev. Thank you for proposing. I'm not a native speaker so inventing names could be a tricky business for me.
Sep 12 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well. But maybe it's too cute for too little gain? It's pretty darn obvious what a "put" function is for. you can also search for it more easily then a bunch of next's that could be either writes or not writes. --bb
Sep 12 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well.
Exactly, I wanted it to be while (!i.done) o.next = i.next; because I didn't want any head in an input range.
 But maybe it's too cute for too little gain?  It's pretty darn obvious
 what a "put" function is for.  you can also search for it more easily
 then a bunch of next's that could be either writes or not writes.
I'm still not sure. The usability can only be measured by actual usage.
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well.
Exactly, I wanted it to be while (!i.done) o.next = i.next;
Hmm, let's see. So: a) If i is an input range, then i.next returns by value. b) If i is a forward range, then i.next returns by reference. I assume that's what you had in mind? Andrei
Sep 12 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well.
Exactly, I wanted it to be while (!i.done) o.next = i.next;
Hmm, let's see. So: a) If i is an input range, then i.next returns by value. b) If i is a forward range, then i.next returns by reference. I assume that's what you had in mind?
Not quite. You cannot mutate an input range, it must be in specs. Therefore it's up to the range designer what to return. LineEater will return a const reference to an internal buffer. RNG will return int. Array will return a const reference to its element. Some could return a new class instance every time. If you want to mutate though, you require a forward range and use its i.first which must be a reference to the first element in the range. Then you can safely ignore the i.next result which will most likely be a reference to the previous i.first contents.
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well.
Exactly, I wanted it to be while (!i.done) o.next = i.next;
Hmm, let's see. So: a) If i is an input range, then i.next returns by value. b) If i is a forward range, then i.next returns by reference. I assume that's what you had in mind?
Not quite. You cannot mutate an input range, it must be in specs. Therefore it's up to the range designer what to return. LineEater will return a const reference to an internal buffer. RNG will return int. Array will return a const reference to its element. Some could return a new class instance every time.
Given that in D const is transitive, we can't operate with const the same way C++ does. Consider something as trivial as a copy: Tgt copy(Src, Tgt)(Src src, Tgt tgt) { for (; !src.done; src.next) tgt.put(src.tip); } Problem is, you won't be able to copy e.g. an int[][] to another because the types aren't compatible.
 If you want to mutate though, you require a forward range and use its 
 i.first which must be a reference to the first element in the range.  
 Then you can safely ignore the i.next result which will most likely be a 
 reference to the previous i.first contents.
This part does, I think, work. Andrei
Sep 12 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well.
Exactly, I wanted it to be while (!i.done) o.next = i.next;
Hmm, let's see. So: a) If i is an input range, then i.next returns by value. b) If i is a forward range, then i.next returns by reference. I assume that's what you had in mind?
Not quite. You cannot mutate an input range, it must be in specs. Therefore it's up to the range designer what to return. LineEater will return a const reference to an internal buffer. RNG will return int. Array will return a const reference to its element. Some could return a new class instance every time.
Given that in D const is transitive, we can't operate with const the same way C++ does. Consider something as trivial as a copy: Tgt copy(Src, Tgt)(Src src, Tgt tgt) { for (; !src.done; src.next) tgt.put(src.tip); } Problem is, you won't be able to copy e.g. an int[][] to another because the types aren't compatible.
If Src is an input range you must make a deep copy. This holds true for your current design also. So this algorithm is flawed and it's good if it won't compile. I don't know how to make a generic deep copy, but I believe your meta-fu is much stronger than mine, so I'll leave it to you. ;)
Sep 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 So basically you changed
 done ==> empty
 head ==> tip
 retreat ==> prev
 ?
The insight was about get/put ==> next. That's the most significant change, others are merely renames as you rightfully point out. Hence the "prev" which should mean both "get at the end" and "put to the end".
Ah ok. Your switching to declaration syntax instead of usage syntax confused me. :-) That is cute. So r.put(e) ==> r.next = e It would also mean the copy to output idiom would become for(; ! i.done; i.next) o.next = i.head; Would be cooler if it could be just while(!i.done) o.next = i.next; .. oh well.
Exactly, I wanted it to be while (!i.done) o.next = i.next;
Hmm, let's see. So: a) If i is an input range, then i.next returns by value. b) If i is a forward range, then i.next returns by reference. I assume that's what you had in mind?
Not quite. You cannot mutate an input range, it must be in specs. Therefore it's up to the range designer what to return. LineEater will return a const reference to an internal buffer. RNG will return int. Array will return a const reference to its element. Some could return a new class instance every time.
Given that in D const is transitive, we can't operate with const the same way C++ does. Consider something as trivial as a copy: Tgt copy(Src, Tgt)(Src src, Tgt tgt) { for (; !src.done; src.next) tgt.put(src.tip); } Problem is, you won't be able to copy e.g. an int[][] to another because the types aren't compatible.
If Src is an input range you must make a deep copy. This holds true for your current design also. So this algorithm is flawed and it's good if it won't compile.
Great point. I need to sleep on this some more.
 I don't know how to make a generic deep copy, but I believe your meta-fu 
 is much stronger than mine, so I'll leave it to you.  ;)
It is doable, and if not, Walter will make it so :o). Andrei
Sep 12 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Given that in D const is transitive, we can't operate with const the 
 same way C++ does. Consider something as trivial as a copy:

 Tgt copy(Src, Tgt)(Src src, Tgt tgt)
 {
      for (; !src.done; src.next) tgt.put(src.tip);
 }

 Problem is, you won't be able to copy e.g. an int[][] to another because 
 the types aren't compatible.
If Src is an input range you must make a deep copy. This holds true for your current design also. So this algorithm is flawed and it's good if it won't compile.
Great point. I need to sleep on this some more.
Then I'll continue to think aloud. ------------------------ Here are implementations of a byte-oriented input range on top of a file in both 2- and 3-component input range bases. I thought 2-component version would be simpler. They turned out to be almost equivalent. class FileByteRange2 { private FILE* file; bool empty() { int c = fgetc(file); if (c == -1) { return true; } ungetc(c, file); return false; } ubyte next() { int c = fgetc(file); if (c == -1) { throw new Exception("File is empty!"); } return cast(ubyte) c; } } class FileByteRange3 { private FILE* file; private bool cached; ubyte head; bool done() { if (!cached) { int c = fgetc(file); if (c == -1) { return true; } head = cast(ubyte) c; } return false; } void next() { cached = false; } } ------------------------- A nice pair for .retreat() is .advance(). The words are even of the same length. Although I find it hard to imagine advancing or retreating a range. Needless to say that "next" has nothing to do with ranges at all. ------------------------ Done is not the word. Range is empty. It's not good when a range is done for. Besides, one can be done with a range before it's empty.
Sep 13 2008
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-13 12:42:56 -0400, Sergey Gromov <snake.scaly gmail.com> said:

 A nice pair for .retreat() is .advance().  The words are even of the
 same length.
But then, why not .next() and .pull()? They're the same length too. :-) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 14 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Sep 14, 2008 at 8:55 PM, Michel Fortin
<michel.fortin michelf.com> wrote:
 On 2008-09-13 12:42:56 -0400, Sergey Gromov <snake.scaly gmail.com> said:

 A nice pair for .retreat() is .advance().  The words are even of the
 same length.
My reasoning was that if you pick any pair of antonyms then its going to suggest that the operation applies to the same thing. It's the opposite direction *and* the opposite thing, which is why I compared it to the "contrapositive" in another message. I like retreat because it's the exact opposite of a word that's similar to "next", but not. Therefore it doesn't lead you to expect that it manipulates the same element. Another way of looking at it is that both ends are actually doing the same thing -- they're both "advancing" or doing "next". Just their notion of next is different. In that sense you could call it more like the "converse" operation. You could use a notation like STL reverse iterators and have "rhead" and "rnext", (where r is for "reverse"). I like that in that it recognizes that. I don't like using made-up words, though.
 But then, why not .next() and .pull()? They're the same length too. :-)
I thought about pull -- I think I discarded it sounds like you're pulling something in from somewhere and as a result your range should become bigger. --bb
Sep 14 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Given that in D const is transitive, we can't operate with const the 
 same way C++ does. Consider something as trivial as a copy:

 Tgt copy(Src, Tgt)(Src src, Tgt tgt)
 {
      for (; !src.done; src.next) tgt.put(src.tip);
 }

 Problem is, you won't be able to copy e.g. an int[][] to another because 
 the types aren't compatible.
If Src is an input range you must make a deep copy. This holds true for your current design also. So this algorithm is flawed and it's good if it won't compile.
Great point. I need to sleep on this some more.
Then I'll continue to think aloud.
[snip] Thanks for the code samples, they're cool. I hit a problem related to the return type of head. Consider writing a range that iterates two other ranges in lockstep. A very useful generic range. I started coding it like this: struct Lockstep(R0, R1) { private R0 _r0; private R1 _r1; this(R0 r0, R1 r1) { _r0 = r0; _r1 = r1; } bool empty() { return _r0.empty || _r1.empty; } Tuple!(ElementType!(R0), ElementType!(R1)) head() { return tuple(_r0.head, _r1.head); } void next() { _r0.next; _r1.next; } } Before long I realized that the type of head was wrong. Along the way, the fact that the two ranges return by REFERENCE was irretrivably lost. Returning a ref Tuple!(ElementType!(R0), ElementType!(R1)) won't work either, because how do you move the references of the _r0.head and _r1._head in a common tuple? The type Tuple!(ref ElementType!(R0), ref ElementType!(R1)) does not exist because ref is not a type constructor. This is quite a pickle because it reveals that ref is not composable. I have a few ideas on how to handle this, but I don't want to bias anyone. If you have ideas, please fire them up! Andrei
Sep 14 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Given that in D const is transitive, we can't operate with const the 
 same way C++ does. Consider something as trivial as a copy:

 Tgt copy(Src, Tgt)(Src src, Tgt tgt)
 {
      for (; !src.done; src.next) tgt.put(src.tip);
 }

 Problem is, you won't be able to copy e.g. an int[][] to another because 
 the types aren't compatible.
If Src is an input range you must make a deep copy. This holds true for your current design also. So this algorithm is flawed and it's good if it won't compile.
Great point. I need to sleep on this some more.
Then I'll continue to think aloud.
[snip] Thanks for the code samples, they're cool. I hit a problem related to the return type of head. Consider writing a range that iterates two other ranges in lockstep. A very useful generic range. I started coding it like this: struct Lockstep(R0, R1) { private R0 _r0; private R1 _r1; this(R0 r0, R1 r1) { _r0 = r0; _r1 = r1; } bool empty() { return _r0.empty || _r1.empty; } Tuple!(ElementType!(R0), ElementType!(R1)) head() { return tuple(_r0.head, _r1.head); } void next() { _r0.next; _r1.next; } }
Thinking aloud is fun. :P What you basically want to achieve is that Lockstep l1, l2; l1.head = l2.head; translates into l1._r0.head = l2._r0.head; l1._r1.head = l2._r1.head; all by itself. Umm... The simplest for a programmer would be compiler- supported multiple return values and multiple assignment: ref typeof(R0.head), ref typeof(R1.head) head() { return _r0.head, _r1.head; } then l1.head = l2.head is actually l1._r0.head, l1._r1.head = l2._r0.head, l2._r1.head; I'm not expecting this to be implemented though. Other methods, including returning a Tulpe!(), all return a struct. There's no use in returning references there, even if we could, as long as structs are bit-copied. All the tricks with reference fields rely substantially on the compiler performing specific actions on a per-field basis.
Sep 16 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Given that in D const is transitive, we can't operate with const the 
 same way C++ does. Consider something as trivial as a copy:

 Tgt copy(Src, Tgt)(Src src, Tgt tgt)
 {
      for (; !src.done; src.next) tgt.put(src.tip);
 }

 Problem is, you won't be able to copy e.g. an int[][] to another because 
 the types aren't compatible.
If Src is an input range you must make a deep copy. This holds true for your current design also. So this algorithm is flawed and it's good if it won't compile.
Great point. I need to sleep on this some more.
Then I'll continue to think aloud.
[snip] Thanks for the code samples, they're cool. I hit a problem related to the return type of head. Consider writing a range that iterates two other ranges in lockstep. A very useful generic range. I started coding it like this: struct Lockstep(R0, R1) { private R0 _r0; private R1 _r1; this(R0 r0, R1 r1) { _r0 = r0; _r1 = r1; } bool empty() { return _r0.empty || _r1.empty; } Tuple!(ElementType!(R0), ElementType!(R1)) head() { return tuple(_r0.head, _r1.head); } void next() { _r0.next; _r1.next; } }
Thinking aloud is fun. :P What you basically want to achieve is that Lockstep l1, l2; l1.head = l2.head; translates into l1._r0.head = l2._r0.head; l1._r1.head = l2._r1.head; all by itself. Umm... The simplest for a programmer would be compiler- supported multiple return values and multiple assignment: ref typeof(R0.head), ref typeof(R1.head) head() { return _r0.head, _r1.head; } then l1.head = l2.head is actually l1._r0.head, l1._r1.head = l2._r0.head, l2._r1.head; I'm not expecting this to be implemented though. Other methods, including returning a Tulpe!(), all return a struct. There's no use in returning references there, even if we could, as long as structs are bit-copied. All the tricks with reference fields rely substantially on the compiler performing specific actions on a per-field basis.
I figured a deceptively simple(r) solution. With apologies to Abba, I let the code speak: /** Defines a range that moves two given ranges in lockstep. */ struct Lockstep(R0, R1) { struct ElementType { private R0 _r0; private R1 _r1; auto _0() { return _r0.head; } auto _1() { return _r1.head; } } private ElementType _e; this(R0 r0, R1 r1) { _e._r0 = r0; _e._r1 = r1; } bool empty() { return _e._r0.empty || _e._r1.empty; } ref ElementType head() { return _e; } void next() { _e._r0.next; _e._r1.next; } } Now when I write: Lockstep.(RA, RB) r; auto x = r.head._0; then I simply access whatever RA.head returns, be it by reference or value. Problem solved. Andrei
Sep 16 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 What you basically want to achieve is that
 
 	Lockstep l1, l2;
 	l1.head = l2.head;
 
 translates into
 
 	l1._r0.head = l2._r0.head;
 	l1._r1.head = l2._r1.head;
 
 all by itself.  Umm...  The simplest for a programmer would be compiler-
 supported multiple return values and multiple assignment:
 
 	ref typeof(R0.head), ref typeof(R1.head) head()
 	{
 	  return _r0.head, _r1.head;
 	}
 
 then
 
 	l1.head = l2.head
 
 is actually
 
 	l1._r0.head, l1._r1.head = l2._r0.head, l2._r1.head;
 
 I'm not expecting this to be implemented though.  Other methods, 
 including returning a Tulpe!(), all return a struct.  There's no use in 
 returning references there, even if we could, as long as structs are 
 bit-copied.  All the tricks with reference fields rely substantially on 
 the compiler performing specific actions on a per-field basis.
I figured a deceptively simple(r) solution. With apologies to Abba, I let the code speak: /** Defines a range that moves two given ranges in lockstep. */ struct Lockstep(R0, R1) { struct ElementType { private R0 _r0; private R1 _r1; auto _0() { return _r0.head; } auto _1() { return _r1.head; } } private ElementType _e; this(R0 r0, R1 r1) { _e._r0 = r0; _e._r1 = r1; } bool empty() { return _e._r0.empty || _e._r1.empty; } ref ElementType head() { return _e; } void next() { _e._r0.next; _e._r1.next; } }
Yes it should work. I wish it were less complex though. BTW here's another variant of your solution:
 struct Lockstep(R0, R1)
 {
      private R0 _r0;
      private R1 _r1;

      private alias typeof(this) this_type;

      struct ElementType
      {
          private this_type outer;
          typeof(outer._r0.head) _0() { return outer._r0.head; }
          typeof(outer._r0.head) _1() { return outer._r1.head; }
      }
 
      this(R0 r0, R1 r1)
      {
         _r0 = r0;
         _r1 = r1;
      }
 
      bool empty()
      {
          return _r0.empty || _r1.empty;
      }
 
      ElementType head()
      {
          return ElementType(this);
      }
 
      void next()
      {
          _r0.next;
          _r1.next;
      }
 }
Sep 17 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:22 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 I'm actually ok with either "done" or "empty".  "Done" is weird on a
 random access range, but "empty" is weird on file input range, or a
 generator.  Or on the HMM example which is "done" when it reaches an
 end state, but is not really "empty".
That's exactly right. "Empty" is a state, and "done", while also a state, also evokes process. I found it very nice to write stream ranges that become "done" after some point. "Empty" was less clear because it suggested e.g. the underlying file is empty. On the other hand it's odd to receive a fresh new range and ask yourself whether it's "done". As I wrote Walter and Bartosz a while ago, this all reminds me of a funny dialog in Alice in Wonderland (http://www.cs.indiana.edu/metastuff/wonder/ch7.html): `Take some more tea,' the March Hare said to Alice, very earnestly. `I've had nothing yet,' Alice replied in an offended tone, `so I can't take more.' `You mean you can't take LESS,' said the Hatter: `it's very easy to take MORE than nothing.'
 "head to toe" is a perfectly common expression, at least in American
 English.  Not sure why you don't like it.  But tip to toe is kinda
 cool for being 1 less letter!  And no less clear.
I like "tip" too. And as Pablo said, it's less anthropocentric than head+toe. You know what's the name of Sergey's empty range that lies right at the end of a range? Toenail! :o)
 "prev" is horrible.  I still like "retreat" best so far.  We need the
 contrapositive of "next" not the "opposite".  :-)  And since that
 doesn't exist we should just go for a word that sorta means the right
 thing and won't be  confused with being the opposite (or with being
 something else entirely like "reduce").
Retreat is a great word. I replaced reduce with it. That was easy because this time I had the foresight of defining ddoc macros for all primitive names :o). Thanks! Andrei
Sep 12 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 2:44 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made one
 more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not all),
 and the names of the primitives have been updated. Bicycle shed galore! But
 don't forget to comment on the reactor as well :o).
Looking better! I disagree with this: """ User code may pair iterators wrongly to create meaningless ranges. For example, given collections a and b of the same type, a.begin to b.begin makes no sense as a range, yet both the compiler and the runtime are hard-pressed in rejecting such mistakes. Such problems are often (though not always) avoided if range is the primitive. """ You can just as easily create nonsensical ranges using before() and after(). And I don't recall ever making the mistake of mixing up one container's begin() with another's end(). I disagree here too: """ A bidirectional range models the natural way of iterating a doubly-linked list. """ It maybe provides an efficient way to implement many algorithms on a doubly linked list. But to say it implements the natural way of iterating one is a big stretch.
I hear you! I'll amend the doc later.
 r1=r.release  ==> r.transfer?  Release sounds like ref counting (e.g. in COM)
                           Also seems like r.transfer(r1) could make
 implementation more efficient.
                           Or perhaps make it a .swap like STL.  Maybe
 you have something against .swap?
Are you kidding? I wrote the best swap in the world. Check the source of std.algorithm. You'll have to convince Bartosz about dropping the name "release". He held a gun to my head, and five of the six chambers were loaded. Couldn't take the risk. As far as efficiency goes, Walter has RVO down and all so I'm not worried. Andrei
Sep 12 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Sep 13, 2008 at 12:29 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 r1=r.release  ==> r.transfer?  Release sounds like ref counting (e.g. in
 COM)
                          Also seems like r.transfer(r1) could make
 implementation more efficient.
                          Or perhaps make it a .swap like STL.  Maybe
 you have something against .swap?
Are you kidding? I wrote the best swap in the world. Check the source of std.algorithm.
I mean like stdvector.swap(stdvector0), not the algorithm swap. Or maybe your swap subsumes both kinds?
 You'll have to convince Bartosz about dropping the name "release". He held a
 gun to my head, and five of the six chambers were loaded. Couldn't take the
 risk.
Hmm. I would have thought Walter would veto "release" since he cared enough about COM to write it into the D spec. Release is *the* word used throughout COM to signal that you want to decrement an objects reference counter. So basically you do an obj->Release on a COM object any time you would have done a "delete obj" on a regular object.
 As far as efficiency goes, Walter has RVO down and all so I'm not
 worried.
What if you don't put a return object there? Will that be ok too? Even if there are OS resources and such involved? --bb
Sep 12 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not all), 
 and the names of the primitives have been updated. Bicycle shed galore! 
 But don't forget to comment on the reactor as well :o).
You know my position ;) But here are some things: 1. I like the new names of things much better. This is a much prettier bicycle shed :) And in this case, I think the bicycle shed is a little closer to the heart of the design than the nuclear reactor. Maybe the core is better described as a bicycle shop :) 2. Saw this typo in the section on input range: e=r.head Returns the element at the current position, which is of type ElementType!(R). In case ElementType!(R) has aliases (such as a reference, pointer, or array type), the **iterator** is free to recycle it it upon the call to r.next... 3. In output iterator (more bicycle shed stuff): writing one object and moving to the next one are an organic operation What's an organic operation? I'm assuming it means 'coupled' like you can't do one without the other? I've never heard that term before. -Steve
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not all), 
 and the names of the primitives have been updated. Bicycle shed galore! 
 But don't forget to comment on the reactor as well :o).
You know my position ;) But here are some things: 1. I like the new names of things much better. This is a much prettier bicycle shed :) And in this case, I think the bicycle shed is a little closer to the heart of the design than the nuclear reactor. Maybe the core is better described as a bicycle shop :) 2. Saw this typo in the section on input range: e=r.head Returns the element at the current position, which is of type ElementType!(R). In case ElementType!(R) has aliases (such as a reference, pointer, or array type), the **iterator** is free to recycle it it upon the call to r.next...
Fixed, thanks. You see, it's your influence :o).
 3. In output iterator (more bicycle shed stuff):
 
 writing one object and moving to the next one are an organic operation
 
 What's an organic operation?  I'm assuming it means 'coupled' like you can't 
 do one without the other?  I've never heard that term before.
http://www.merriam-webster.com/dictionary/organic (2): of, relating to, yielding, or involving the use of food produced with the use of feed or fertilizer of plant or animal origin without employment of chemically formulated fertilizers, growth stimulants, antibiotics, or pesticides Just wanted to throw you off :o). This one: 4 a: forming an integral element of a whole : fundamental <incidental music rather than organic parts of the action — Francis Fergusson> b: having systematic coordination of parts : organized <an organic whole> Andrei
Sep 12 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
The colorful diagram is nice, but it doesn't belong at the top of the article. Is it possible to find a better spot? It may be best following the "Coding with ranges also has disadvatages" paragraph. PS: You're missing an n in disadvantages. I read past it several times, but my spell checker caught it.
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 In wake of the many excellent comments and suggestions made here, I
 made one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not
  all), and the names of the primitives have been updated. Bicycle
 shed galore! But don't forget to comment on the reactor as well
 :o).
The colorful diagram is nice, but it doesn't belong at the top of the article. Is it possible to find a better spot? It may be best following the "Coding with ranges also has disadvatages" paragraph.
I agree. I just plopped it in there in an intermediate revision and left it there. Moved it now.
 PS: You're missing an n in disadvantages.  I read past it several
 times, but my spell checker caught it.
Thanks, fixed. I keep on hoping someone develops a simple way for emacs to spellcheck comments... Andrei
Sep 12 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
I've found superdan's post that convinced you. I honestly cannot see why. Suppose I want to allow recycling in empty/next pair. Then I cpecify that: * next() returns stuff; * stuff is guaranteed to survive until the subsequent call to next(); * stuff becomes undefined after next() is called again; * stuff is guaranteed to survive intermediate calls to empty(). The last point can make implementation more complex in some cases but it's definitely possible to implement. If we revert to empty/next, or whateve names you think better, then we can also revert to using first/last for forward/bidirectional range outermost elements and stop that body parts discussion. I really hope this makes sense.
Sep 12 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
I've found superdan's post that convinced you. I honestly cannot see why. Suppose I want to allow recycling in empty/next pair. Then I cpecify that: * next() returns stuff; * stuff is guaranteed to survive until the subsequent call to next(); * stuff becomes undefined after next() is called again; * stuff is guaranteed to survive intermediate calls to empty(). The last point can make implementation more complex in some cases but it's definitely possible to implement. If we revert to empty/next, or whateve names you think better, then we can also revert to using first/last for forward/bidirectional range outermost elements and stop that body parts discussion. I really hope this makes sense.
He did convince me. With your API you can't write efficient algorithms that work with input ranges and forward ranges crawling on actual containers. Andrei
Sep 12 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
 
 
 Andrei
Two questions: - Is it possible to add elements to a range? Suppose a linked list, you want to traverse it's elements until a condition is met on an element, and then add something after it. Or before it. I see there's "put", but it also says "An output range models a one-pass forward writing iteration.", so I think it's not the same. - The same question applies if you want to delete an element from a range. As for the names, I think it's impossible to find one-word names for the concepts you want to express. I always prefer expressive, easy to remember names instead of shorter but less meaningful names. Maybe: head --> first toe --> last next --> moveFirst / dropFirst / skipFirst retreat -> moveLast / dropLast / skipLast done --> isEmpty (it's strange to think of a range as done) So it's like dropFirst / dropLast shrink the range from either end, until it's empty. Sorry if these things were already discussed, I didn't have time to read the hundreds of posts of the previous discussion, just some and the next proposal.
Sep 12 2008
next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Ary Borenszweig <ary esperanto.org.ar> wrote:
 Two questions:
 - Is it possible to add elements to a range? Suppose a linked list, you 
 want to traverse it's elements until a condition is met on an element, 
 and then add something after it. Or before it. I see there's "put", but 
 it also says "An output range models a one-pass forward writing 
 iteration.", so I think it's not the same.
 - The same question applies if you want to delete an element from a range.
The idea is that a container is responsible for mutators, not range. Therefore you'd have list.insertBefore(range, value). Likewise there'd be list.remove(range), list.removeBefore(range) and list.removeFirst (range).
Sep 12 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
Two questions: - Is it possible to add elements to a range? Suppose a linked list, you want to traverse it's elements until a condition is met on an element, and then add something after it. Or before it. I see there's "put", but it also says "An output range models a one-pass forward writing iteration.", so I think it's not the same.
Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
 - The same question applies if you want to delete an element from a range.
Same.
 As for the names, I think it's impossible to find one-word names for the 
 concepts you want to express. I always prefer expressive, easy to 
 remember names instead of shorter but less meaningful names. Maybe:
 
 head --> first
 toe --> last
 next --> moveFirst / dropFirst / skipFirst
 retreat -> moveLast / dropLast / skipLast
 done --> isEmpty (it's strange to think of a range as done)
 
 So it's like dropFirst / dropLast shrink the range from either end, 
 until it's empty.
 
 Sorry if these things were already discussed, I didn't have time to read 
 the hundreds of posts of the previous discussion, just some and the next 
 proposal.
Yeah it's getting crazy. Andrei
Sep 12 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 - Is it possible to add elements to a range? Suppose a linked list, 
 you want to traverse it's elements until a condition is met on an 
 element, and then add something after it. Or before it. I see there's 
 "put", but it also says "An output range models a one-pass forward 
 writing iteration.", so I think it's not the same.
Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
Sep 12 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 - Is it possible to add elements to a range? Suppose a linked list, you 
 want to traverse it's elements until a condition is met on an element, 
 and then add something after it. Or before it. I see there's "put", but 
 it also says "An output range models a one-pass forward writing 
 iteration.", so I think it's not the same.
Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
I allow removal during foreach in dcollections. However, it is done by the opApply function at the request of the delegate (I pass in a ref boolean). I don't think this method violates the foreach contract. I use this when I'm iterating over a container trying to decide whether elements should be removed. If you don't allow this, then either you must use an iterator/range model, or build a separate list of elements to delete once you have exited the foreach loop. Using this model, I can do things like O(n) traverse and remove from an array. -Steve
Sep 12 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 - Is it possible to add elements to a range? Suppose a linked list, 
 you want to traverse it's elements until a condition is met on an 
 element, and then add something after it. Or before it. I see there's 
 "put", but it also says "An output range models a one-pass forward 
 writing iteration.", so I think it's not the same.
Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
I've found this invaluable at times. And it's actually supported by C++ containers. Something along the lines of: for( auto i = c.begin(); i != c.end(); ) { if( shouldRemove( *i ) ) i = c.remove( i ); else ++i; } In fact, it may not even be possible to remove elements of a container outside the inspection loop. For example, let's say the container is actually a SQL resultset and the iterator is a cursor. It's easy to mark a row as 'deleted' in this instance, but storing information to perform a deletion later often simply can't be done. Though I suppose you could argue that the 'container' abstraction may be inappropriate for such temporal data. Sean
Sep 12 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I've found this invaluable at times.  And it's actually supported by C++ 
 containers.
It's a bad idea, as it can screw up optimization. For example, if you are using a change-and-swap method of updating a collection, the collection cached by the foreach may get trashed.
Sep 12 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 I've found this invaluable at times.  And it's actually supported by 
 C++ containers.
It's a bad idea, as it can screw up optimization. For example, if you are using a change-and-swap method of updating a collection, the collection cached by the foreach may get trashed.
That's fine... the optimizer has to impose certain requirements. For such things I'll simply continue using for loops. Sean
Sep 12 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 I've found this invaluable at times.  And it's actually supported by 
 C++ containers.
It's a bad idea, as it can screw up optimization. For example, if you are using a change-and-swap method of updating a collection, the collection cached by the foreach may get trashed.
I like the erase(remove) idiom used by STL, see http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Erase-Remove. Oddly enough, it's a variant of moveToFront, the function that allegedly nobody needs :o). It's efficient and safe. Removing from a collection while iterating runs the risk of becoming quadratic if more than a few elements get removed. Andrei
Sep 12 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Sean Kelly <sean invisibleduck.org> wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 - Is it possible to add elements to a range? Suppose a linked list, 
 you want to traverse it's elements until a condition is met on an 
 element, and then add something after it. Or before it. I see there's 
 "put", but it also says "An output range models a one-pass forward 
 writing iteration.", so I think it's not the same.
Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
In fact, it may not even be possible to remove elements of a container outside the inspection loop. For example, let's say the container is actually a SQL resultset and the iterator is a cursor. It's easy to mark a row as 'deleted' in this instance, but storing information to perform a deletion later often simply can't be done. Though I suppose you could argue that the 'container' abstraction may be inappropriate for such temporal data.
I think that the Input Range abstraction works fine here. That is, the 'head' of the Select range is actually a cursor object which has a markForDeletion() method. It may be bad to allow deletion in generic case, but you can always have a special case to work around.
Sep 13 2008
prev sibling next sibling parent Pablo Ripolles <in-call gmx.net> writes:
Bill Baxter Wrote:

 On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call gmx.net> wrote:
 Hmm.  One semantic issue I have is that the tip usually refers to the
 infinitessimal point at the end.  Not a thing with substance.  I'm
 having trouble feeling like I'm going to get an item back when I look
 at "x.tip".  Head has huge history being used for the item at the
 front of a list, so I think that's much less likely to cause anyone
 looking at D code to scratch their heads.  It will be obvious what it
 means even in relative isolation.  head/tip will often appear without
 "toe" in forward range algos.  So you need to be able to easily
 recognize what "tip" means without seeing that "toe" to give context.
 Toe on the other hand will probably almost always appear with his
 mate.

 Ooh, another scale thing, but a head is obviously a very different
 scale than a toe.  A foot is closer to the same scale.  Maybe
 head/foot is better than head/toe.  The connection between retreating
 / feet is stronger that retreating / toes, too!

 --bb
neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal... I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
Nope. I'm pretty sure that the discussion is about replacing "head" with "tip". There's an expression "from tip to toe".
:D yes! ok! I missed that! sorry.
 
 But I think your confusion (or is it mine?) about which end would be
 the tip is pretty damning.
I agree with that! indeed it is.
 
 my problem with foot is that there is necessarily more than one.
There's also more than one toe. But I guess you thought that "toe" was out.
Exactly!
 
 perhaps in the world of the anatomy of the chordates we can find something...
dunno, "coccyx" is pretty weird but at least there is only one.
Well, there is only one tail... but it's what functional guys call everything but the head, so Anrdrei wants to avoid it.
Yes, thanks, I didn't really now that was the reason but I do agree. My last idea was the pair "head" and "aft"... Cheers!
Sep 12 2008
prev sibling next sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Bill Baxter Wrote:

 On Sat, Sep 13, 2008 at 12:03 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Pablo Ripolles wrote:
 What about "isDone"?
isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. So I agree. Stick the "is" in there.
Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. Andrei P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
Hmm. One semantic issue I have is that the tip usually refers to the infinitessimal point at the end. Not a thing with substance. I'm having trouble feeling like I'm going to get an item back when I look at "x.tip". Head has huge history being used for the item at the front of a list, so I think that's much less likely to cause anyone looking at D code to scratch their heads. It will be obvious what it means even in relative isolation. head/tip will often appear without "toe" in forward range algos. So you need to be able to easily recognize what "tip" means without seeing that "toe" to give context. Toe on the other hand will probably almost always appear with his mate. Ooh, another scale thing, but a head is obviously a very different scale than a toe. A foot is closer to the same scale. Maybe head/foot is better than head/toe. The connection between retreating / feet is stronger that retreating / toes, too! --bb
After having had some sleep, I kind of support Bill's proposal, that is, head/foot, definitely better than head/toe. It's like the header and the footer! sounds very reasonable. Of course I also like fore/aft, but thats because my aeronautical engineering bias. tip is too ambiguous. tail refers to all what comes after the head, not to its tip. Cheers!
Sep 13 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-13 04:18:20 -0400, Pablo Ripolles <in-call gmx.net> said:

 After having had some sleep, I kind of support Bill's proposal, that 
 is, head/foot, definitely better than head/toe.  It's like the header 
 and the footer! sounds very reasonable.  Of course I also like 
 fore/aft, but thats because my aeronautical engineering bias.
 
 tip is too ambiguous.
 
 tail refers to all what comes after the head, not to its tip.
 
 Cheers!
Anyone suggested head/rear yet? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 14 2008
parent reply Pablo Ripolles <in-call gmx.net> writes:
Michel Fortin Wrote:

 On 2008-09-13 04:18:20 -0400, Pablo Ripolles <in-call gmx.net> said:
 
 After having had some sleep, I kind of support Bill's proposal, that 
 is, head/foot, definitely better than head/toe.  It's like the header 
 and the footer! sounds very reasonable.  Of course I also like 
 fore/aft, but thats because my aeronautical engineering bias.
 
 tip is too ambiguous.
 
 tail refers to all what comes after the head, not to its tip.
 
 Cheers!
Anyone suggested head/rear yet?
Hello, if I remember well, yes. I also like it! I don't recall the argument against it though...
Sep 14 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Sep 14, 2008 at 9:29 PM, Pablo Ripolles <in-call gmx.net> wrote:
 Michel Fortin Wrote:

 On 2008-09-13 04:18:20 -0400, Pablo Ripolles <in-call gmx.net> said:

 After having had some sleep, I kind of support Bill's proposal, that
 is, head/foot, definitely better than head/toe.  It's like the header
 and the footer! sounds very reasonable.  Of course I also like
 fore/aft, but thats because my aeronautical engineering bias.

 tip is too ambiguous.

 tail refers to all what comes after the head, not to its tip.

 Cheers!
Anyone suggested head/rear yet?
Hello, if I remember well, yes. I also like it! I don't recall the argument against it though...
I think it was that if you're thinking body parts, then "rear" means someone's bottom. There's an expression -- "get your head out of your rear" -- that comes to mind. --bb
Sep 14 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
I have re-read the page again, and I am now starting to understand its contents. When I'll understand 90-95% of that page then I think it's dumbed enough for most programmers ;-) In lines like: t=r.before(s) I suggest to add a more natural spacing: t = range.before(s) But maybe adding an "all" to that method name you it can show better that it generates a new range: t = range.allbefore(s) This is one of the functions shown in that page: // Increments all elements in a range void bump(R)(R r) { for (; !r.done; r.next) { ++r.head; } } But that's not readable. This improves readability 5X (note current instead of head and isdone instead of done): /// Increments all items of a Forward range void bump(R)(R range) { while (!range.isdone) { range.current++; range.next(); } } If the D language will keep the foreach(), then where possible I suggest to add a version that uses foreach() too: /// Increments all items of a Forward range void bump(R)(R range) { foreach (ref item; range) item++; } In that document you can also show 1 example for all functions/ methods/ attributes, like r.after(s), etc. I think that good names and some sugar may make this stuff usable (not easy, but usable). Bye, bearophile
Sep 16 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
I have re-read the page again, and I am now starting to understand its contents. When I'll understand 90-95% of that page then I think it's dumbed enough for most programmers ;-) In lines like: t=r.before(s) I suggest to add a more natural spacing: t = range.before(s)
That's a good point. At the time I wrote that document, inserting the spaces would really mess up the table by breaking the expression. Since then I fixed the style, but not (yet) the document.
 But maybe adding an "all" to that method name you it can show better that it
generates a new range:
 t = range.allbefore(s)
So many good proposals for names have been put forth, it will be definitely impossible to find one set of names that will please everybody. So everybody, please expect to be disappointed. I *do* need to do some actual work instead of getting ready to do it.
 This is one of the functions shown in that page:
 
 // Increments all elements in a range
 void bump(R)(R r)
 {
     for (; !r.done; r.next)
     {
         ++r.head;
     }
 }
 
 But that's not readable. This improves readability 5X (note current instead of
head and isdone instead of done):
 
 /// Increments all items of a Forward range
 void bump(R)(R range) {
     while (!range.isdone) {
         range.current++;
         range.next();
     }
 }
Maybe 5X is a bit exaggerated, but if the point was that good names are important, I entirely agree. One problem with the done/current approach to naming is that it does not dovetail well with non-temporal collections (I'm computing a fresh range; how come I have to query whether it's "done"? And what's "current" to an array?) But then there are problems with, and advantages of, any naming scheme ever mentioned here. At the end of the day I'll have to choose one. Again, everybody, prepare to be disappointed.
 If the D language will keep the foreach(), then where possible I suggest to
add a version that uses foreach() too:
 
 /// Increments all items of a Forward range
 void bump(R)(R range) {
     foreach (ref item; range)
         item++;
 }
Walter will have foreach automatically detect and use ranges.
 In that document you can also show 1 example for all functions/ methods/
attributes, like r.after(s), etc.
 
 I think that good names and some sugar may make this stuff usable (not easy,
but usable).
I agree that good names and some sugar are helpful. Now, if you could tell how I can make things actually easy, that would be huge. I hoped three functions would be easy. True, defining their semantics in excruciating detail will not be as easy, but it will have the advantage to be rigorous enough to produce reliable implementations. Andrei
Sep 16 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I made 
 one more pass through the draft proposal for ranges.
 
 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
 
 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).
 
 
 Andrei
""" All ranges satisfy certain invariants outlined below. (r is an object of a range type R.) """ By "object" you actually mean struct no? Struct instance to be even more precise. Also, some more on important bike shed issues: for (; !src.done; src.next) { tgt.put(src.head); } As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that. So "src.next" would be must better as "src.next()" as "src.next" really just makes me cringe. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 25 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbgpak$2q10$1 digitalmars.com>, 
brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }
 
 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes state 
 is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next" really 
 just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Sep 25 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 In article <gbgpak$2q10$1 digitalmars.com>, 
 brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }

 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes state 
 is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next" really 
 just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use. Two nice examples of the undesirability of distinct notation are the std::pair first and second members in the STL, which made what seemed like an innocuous decision turn into a catastrophe, and also std::numeric_limits<T>::min and max, which partially prompted creation of an entire language feature(!). Andrei
Sep 25 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbgu0h$5sq$1 digitalmars.com>, SeeWebsiteForEmail erdani.org 
says...
 Sergey Gromov wrote:
 I think that property function call feature in general adds an 
 unnecessary ambiguity to the language.  I'd prefer functions to be 
 callable only with regular function call syntax, and properties be 
 usable only with member access syntax.  The same stands for 'unified 
 function call' feature: if you want to inject a method into an 'array of 
 chars' class you do so explicitly, and only the member call syntax is 
 allowed on that method.  Otherwise code tends to become ambiguous and 
 unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
Sorry I may have been unclear. I'm not against interchangeability between properties and property accessor methods. I'm against using property accessors as methods, and against using methods as if they were property accessors. The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore. And you cannot replace public void delegate(int) foo; with an accessor method because the code 'instance.foo();' will stop working as it used to.
Sep 25 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 In article <gbgu0h$5sq$1 digitalmars.com>, SeeWebsiteForEmail erdani.org 
 says...
 Sergey Gromov wrote:
 I think that property function call feature in general adds an 
 unnecessary ambiguity to the language.  I'd prefer functions to be 
 callable only with regular function call syntax, and properties be 
 usable only with member access syntax.  The same stands for 'unified 
 function call' feature: if you want to inject a method into an 'array of 
 chars' class you do so explicitly, and only the member call syntax is 
 allowed on that method.  Otherwise code tends to become ambiguous and 
 unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
Sorry I may have been unclear. I'm not against interchangeability between properties and property accessor methods. I'm against using property accessors as methods, and against using methods as if they were property accessors. The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore. And you cannot replace public void delegate(int) foo; with an accessor method because the code 'instance.foo();' will stop working as it used to.
I am a bit confused about terminology. Could you please clarify with examples what you mean, also defining all terms (e.g. what does "property accessor" mean?) Thanks. Andrei
Sep 26 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbiqbo$m1e$1 digitalmars.com>, SeeWebsiteForEmail erdani.org 
says...
 Sergey Gromov wrote:
 In article <gbgu0h$5sq$1 digitalmars.com>, SeeWebsiteForEmail erdani.org 
 says...
 Sergey Gromov wrote:
 I think that property function call feature in general adds an 
 unnecessary ambiguity to the language.  I'd prefer functions to be 
 callable only with regular function call syntax, and properties be 
 usable only with member access syntax.  The same stands for 'unified 
 function call' feature: if you want to inject a method into an 'array of 
 chars' class you do so explicitly, and only the member call syntax is 
 allowed on that method.  Otherwise code tends to become ambiguous and 
 unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
Sorry I may have been unclear. I'm not against interchangeability between properties and property accessor methods. I'm against using property accessors as methods, and against using methods as if they were property accessors. The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore. And you cannot replace public void delegate(int) foo; with an accessor method because the code 'instance.foo();' will stop working as it used to.
I am a bit confused about terminology. Could you please clarify with examples what you mean, also defining all terms (e.g. what does "property accessor" mean?) Thanks.
Property accessor is a method which is invoked when you syntactically access a data field. They are called getters and setters in many languages. In current D, any function or method with zero or one argument is considered a property accessor: class Foo { int prop() { return field + 1; } int prop(int value) { return field = value + 3; } private int field; } void useFoo(Foo f) { auto x = f.prop; f.prop = 5; auto y = f.prop(); // also allowed f.prop(8); // ditto } The 'prop' family of methods are property accessors in my terminology, and they can be replaced with an actual data field: class Foo { int prop; } void useFoo(Foo f) { auto x = f.prop; // fine! f.prop = 5; // works auto y = f.prop(); // Error: function expected f.prop(8); // Error: function expected } You see, properties and methods are *not* interchangeable in current D. Therefore your correct thesis:
 Experience with other languages has shown that using identical syntax 
 for genuine member access and member function access helps 
 maintainability because it allows a type implementer to switch back and 
 forth between implementing a property as a direct member or as a 
 function, transparently to that type's use.
does not apply to D. Here's another example: class Bar { int delegate() meth; } int useBar(Bar b) { return b.meth(); } Can you replace 'meth' with a getter? class Bar { int delegate() meth() { return {return 5;}; } } int useBar(Bar b) { return b.meth(); // Error: cannot implicitly convert expression // (b.meth()) of type int delegate() to int } No you cannot. But you could be able to do all those nice things if you had an explicit syntax for getters and setters: class Foo { property int prop() {...} property int prop(int value) {...} property int prop(int v, char c) {...} // syntax error, 2 arguments property int delegate() meth() {...} } void useFoo(Foo f) { auto x = f.prop; // OK f.prop = 5; // OK auto y = f.prop(); // syntax error, function expected f.prop(8); // syntax error, function expected int z = f.meth(); // OK, the delegate is called } That being said, I want the same explicit syntax for property and method injection, which are elements of aspect-oriented programming. Let's call it inject: inject T[] reverse(T)(T[] arr) {...} inject property T middle(T)(T[] arr) { return arr[$/2]; } auto s = "abcde"; auto sr = s.reverse(); // "edcba" auto sm = s.middle; // 'c' reverse(s); // undefined identifier With this, you receive an additional freedom which comes from removing the ambiguity. Imagine I want my personal hell: class Hell { private enum random = 666; private inject property size_t realLen(T)(T[] any) { return random; } void tellTheTruth(string s) { writefln("real length of '%s' is %s", s, s.realLen); } } Here I've injected a useful property into all arrays but the injection is private to my hell only so I can pretend there's still paradise around.
Sep 26 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 In article <gbiqbo$m1e$1 digitalmars.com>, SeeWebsiteForEmail erdani.org 
 says...
 Sergey Gromov wrote:
 In article <gbgu0h$5sq$1 digitalmars.com>, SeeWebsiteForEmail erdani.org 
 says...
 Sergey Gromov wrote:
 I think that property function call feature in general adds an 
 unnecessary ambiguity to the language.  I'd prefer functions to be 
 callable only with regular function call syntax, and properties be 
 usable only with member access syntax.  The same stands for 'unified 
 function call' feature: if you want to inject a method into an 'array of 
 chars' class you do so explicitly, and only the member call syntax is 
 allowed on that method.  Otherwise code tends to become ambiguous and 
 unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
Sorry I may have been unclear. I'm not against interchangeability between properties and property accessor methods. I'm against using property accessors as methods, and against using methods as if they were property accessors. The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore. And you cannot replace public void delegate(int) foo; with an accessor method because the code 'instance.foo();' will stop working as it used to.
I am a bit confused about terminology. Could you please clarify with examples what you mean, also defining all terms (e.g. what does "property accessor" mean?) Thanks.
Property accessor is a method which is invoked when you syntactically access a data field. They are called getters and setters in many languages. In current D, any function or method with zero or one argument is considered a property accessor: class Foo { int prop() { return field + 1; } int prop(int value) { return field = value + 3; } private int field; } void useFoo(Foo f) { auto x = f.prop; f.prop = 5; auto y = f.prop(); // also allowed f.prop(8); // ditto }
Ok, so far so good.
 The 'prop' family of methods are property accessors in my terminology, 
 and they can be replaced with an actual data field:
 
 class Foo
 {
   int prop;
 }
 
 void useFoo(Foo f)
 {
   auto x = f.prop;  // fine!
   f.prop = 5;  // works
 
   auto y = f.prop();  // Error: function expected
   f.prop(8);  // Error: function expected
 }
 
 You see, properties and methods are *not* interchangeable in current D.  
 Therefore your correct thesis:
 
 Experience with other languages has shown that using identical syntax 
 for genuine member access and member function access helps 
 maintainability because it allows a type implementer to switch back and 
 forth between implementing a property as a direct member or as a 
 function, transparently to that type's use.
does not apply to D.
It does apply, just only one direction. From the above, it looks like a good guideline is to always use the syntax: auto x = f.prop; f.prop = x; because it is more general. And indeed, consider something as innocuous as the empty member for a range. Some here said I should write range.empty() throughout. But that, aside from wrist and eye pain, precludes infinite ranges from implementing empty as simple as: struct Generator { ... enum empty = false; } But if that implementation were allowed, that would be a boon for generic code because it can easily detect infinite ranges statically.
 Here's another example:
 
 class Bar
 {
   int delegate() meth;
 }
 
 int useBar(Bar b)
 {
   return b.meth();
 }
 
 Can you replace 'meth' with a getter?
 
 class Bar
 {
   int delegate() meth()
   {
     return {return 5;};
   }
 
 }
 
 int useBar(Bar b)
 {
   return b.meth();  // Error: cannot implicitly convert expression
   // (b.meth()) of type int delegate() to int
 }
 
 No you cannot.  But you could be able to do all those nice things if you 
 had an explicit syntax for getters and setters:
 
 class Foo
 {
   property int prop() {...}
   property int prop(int value) {...}
   property int prop(int v, char c) {...} // syntax error, 2 arguments
   property int delegate() meth() {...}
 }
I agree. But there's a simpler solution: int useBar(Bar crystal) { return (crystal.meth)(); } Looks a bit uneasy on the eye? I agree. But count the lines you use member delegates in; then count the lines you use non-delegate member access; divide the first by the second; multiply by 100; and... is that worth a language feature?
 void useFoo(Foo f)
 {
   auto x = f.prop;  // OK
   f.prop = 5;  // OK
 
   auto y = f.prop();  // syntax error, function expected
   f.prop(8);  // syntax error, function expected
 
   int z = f.meth();  // OK, the delegate is called
 }
 
 That being said, I want the same explicit syntax for property and method 
 injection, which are elements of aspect-oriented programming.  Let's 
 call it inject:
 
 inject T[] reverse(T)(T[] arr) {...}
 inject property T middle(T)(T[] arr)
 {
   return arr[$/2];
 }
 auto s = "abcde";
 auto sr = s.reverse();  // "edcba"
 auto sm = s.middle;  // 'c'
 reverse(s);  // undefined identifier
 
 With this, you receive an additional freedom which comes from removing 
 the ambiguity.  Imagine I want my personal hell:
 
 class Hell
 {
   private enum random = 666;
   private inject property size_t realLen(T)(T[] any)
   {
     return random;
   }
   void tellTheTruth(string s)
   {
     writefln("real length of '%s' is %s", s, s.realLen);
   }
 }
 
 Here I've injected a useful property into all arrays but the injection 
 is private to my hell only so I can pretend there's still paradise 
 around.
I can imagine you want your personal hell, but I hardly can understand its usefulness to you or the rest of us :o). Andrei
Sep 27 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 27 Sep 2008 08:56:42 -0500,
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 The 'prop' family of methods are property accessors in my terminology, 
 and they can be replaced with an actual data field:
 
 class Foo
 {
   int prop;
 }
 
 void useFoo(Foo f)
 {
   auto x = f.prop;  // fine!
   f.prop = 5;  // works
 
   auto y = f.prop();  // Error: function expected
   f.prop(8);  // Error: function expected
 }
 
 You see, properties and methods are *not* interchangeable in current D.  
 Therefore your correct thesis:
 
 Experience with other languages has shown that using identical syntax 
 for genuine member access and member function access helps 
 maintainability because it allows a type implementer to switch back and 
 forth between implementing a property as a direct member or as a 
 function, transparently to that type's use.
does not apply to D.
It does apply, just only one direction. From the above, it looks like a good guideline is to always use the syntax: auto x = f.prop; f.prop = x; because it is more general.
Now you say that for maintainability to work all users of your library must respect some *guidelines*. In practice this means that if you have a property method you cannot change it to be a variable because everybody *never* respects guidelines---you know, because you can never please him.
 And indeed, consider something as innocuous 
 as the empty member for a range. Some here said I should write 
 range.empty() throughout. But that, aside from wrist and eye pain, 
 precludes infinite ranges from implementing empty as simple as:
 
 struct Generator {
      ...
      enum empty = false;
 }
 
 But if that implementation were allowed, that would be a boon for 
 generic code because it can easily detect infinite ranges statically.
Again, my proposal is not about how you write your code. It's about how others *use* your code and how they limit your freedom in changing your code. With explicit syntax, if you specified 'empty' being a property and someone put parens after it it would be a syntax error. Right now you may yell about it's intended to be interchangeable with a constant but someone *will* put parens after it and *their* code will break after you change *your* library.
 Here's another example:
 
 class Bar
 {
   int delegate() meth;
 }
 
 int useBar(Bar b)
 {
   return b.meth();
 }
 
 Can you replace 'meth' with a getter?
 
 class Bar
 {
   int delegate() meth()
   {
     return {return 5;};
   }
 }
 
 int useBar(Bar b)
 {
   return b.meth();  // Error: cannot implicitly convert expression
   // (b.meth()) of type int delegate() to int
 }
 
 No you cannot.  But you could be able to do all those nice things if you 
 had an explicit syntax for getters and setters:
 
 class Foo
 {
   property int prop() {...}
   property int prop(int value) {...}
   property int prop(int v, char c) {...} // syntax error, 2 arguments
   property int delegate() meth() {...}
 }
I agree. But there's a simpler solution: int useBar(Bar crystal) { return (crystal.meth)(); }
Yes there are ways to write generic code. But there are also ways to write non-generic code, and it may be user code which you mignt have no influence upon, and you may be required to keep the user code working no matter what. Explicit properties grant you such influence, making it impossible for the user to write non-generic code.
 Looks a bit uneasy on the eye? I agree. But count the lines you use 
 member delegates in; then count the lines you use non-delegate member 
 access; divide the first by the second; multiply by 100; and... is that 
 worth a language feature?
Explicit properties solve a much wider range of problems than introduced by naked delegate members. They just happen to solve this issue, too.
 That being said, I want the same explicit syntax for property and method 
 injection, which are elements of aspect-oriented programming.  Let's 
 call it inject:
 
 inject T[] reverse(T)(T[] arr) {...}
 inject property T middle(T)(T[] arr)
 {
   return arr[$/2];
 }
 auto s = "abcde";
 auto sr = s.reverse();  // "edcba"
 auto sm = s.middle;  // 'c'
 reverse(s);  // undefined identifier
I can imagine you want your personal hell, but I hardly can understand its usefulness to you or the rest of us :o).
Do you have a clear understanding of how name resolution should work in 'unified call syntax' as it is now? bool even(char[] a) {...} class Foo { private OptimizedEvenComputer ec; bool even(char[] a) {return ec.even(a);} void foo() { bool even(char[] a) {...} char[] l; auto x = l.even; auto y = even(l); } } What happens here? What *should* happen here? Even now people are confused because the mechanism works against their expectations. And, most importantly, they disagree in their expectations. Explicit injection solves this ambiguity once and for all. And I'm yet to hear *actual* arguments from you. Till now it was that you didn't like to type parentheses, you didn't like a bit of strictness in the language, and you didn't see any problem in not being able to replace methods with vars. Oh wait, you did see the problem. So what's your point then?
Sep 27 2008
next sibling parent Jason House <jason.james.house gmail.com> writes:
Sergey Gromov wrote:

 Do you have a clear understanding of how name resolution should work in
 'unified call syntax' as it is now?
 
 bool even(char[] a) {...}
 class Foo
 {
   private OptimizedEvenComputer ec;
   bool even(char[] a) {return ec.even(a);}
   void foo()
   {
     bool even(char[] a) {...}
     char[] l;
     auto x = l.even;
     auto y = even(l);
   }
 }
I would really hope that the D2 compiler would flag Foo.foo.even as a shadowing violation. I am not a D2 user yet, but I'd hope that Foo.even and Foo.foo.even would not override l.even; it just seems too error prone.
Sep 27 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Sat, 27 Sep 2008 08:56:42 -0500,
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 The 'prop' family of methods are property accessors in my terminology, 
 and they can be replaced with an actual data field:

 class Foo
 {
   int prop;
 }

 void useFoo(Foo f)
 {
   auto x = f.prop;  // fine!
   f.prop = 5;  // works

   auto y = f.prop();  // Error: function expected
   f.prop(8);  // Error: function expected
 }

 You see, properties and methods are *not* interchangeable in current D.  
 Therefore your correct thesis:

 Experience with other languages has shown that using identical syntax 
 for genuine member access and member function access helps 
 maintainability because it allows a type implementer to switch back and 
 forth between implementing a property as a direct member or as a 
 function, transparently to that type's use.
does not apply to D.
It does apply, just only one direction. From the above, it looks like a good guideline is to always use the syntax: auto x = f.prop; f.prop = x; because it is more general.
Now you say that for maintainability to work all users of your library must respect some *guidelines*. In practice this means that if you have a property method you cannot change it to be a variable because everybody *never* respects guidelines---you know, because you can never please him.
 And indeed, consider something as innocuous 
 as the empty member for a range. Some here said I should write 
 range.empty() throughout. But that, aside from wrist and eye pain, 
 precludes infinite ranges from implementing empty as simple as:

 struct Generator {
      ...
      enum empty = false;
 }

 But if that implementation were allowed, that would be a boon for 
 generic code because it can easily detect infinite ranges statically.
Again, my proposal is not about how you write your code. It's about how others *use* your code and how they limit your freedom in changing your code. With explicit syntax, if you specified 'empty' being a property and someone put parens after it it would be a syntax error. Right now you may yell about it's intended to be interchangeable with a constant but someone *will* put parens after it and *their* code will break after you change *your* library.
 Here's another example:

 class Bar
 {
   int delegate() meth;
 }

 int useBar(Bar b)
 {
   return b.meth();
 }

 Can you replace 'meth' with a getter?

 class Bar
 {
   int delegate() meth()
   {
     return {return 5;};
   }
 }

 int useBar(Bar b)
 {
   return b.meth();  // Error: cannot implicitly convert expression
   // (b.meth()) of type int delegate() to int
 }

 No you cannot.  But you could be able to do all those nice things if you 
 had an explicit syntax for getters and setters:

 class Foo
 {
   property int prop() {...}
   property int prop(int value) {...}
   property int prop(int v, char c) {...} // syntax error, 2 arguments
   property int delegate() meth() {...}
 }
I agree. But there's a simpler solution: int useBar(Bar crystal) { return (crystal.meth)(); }
Yes there are ways to write generic code. But there are also ways to write non-generic code, and it may be user code which you mignt have no influence upon, and you may be required to keep the user code working no matter what. Explicit properties grant you such influence, making it impossible for the user to write non-generic code.
 Looks a bit uneasy on the eye? I agree. But count the lines you use 
 member delegates in; then count the lines you use non-delegate member 
 access; divide the first by the second; multiply by 100; and... is that 
 worth a language feature?
Explicit properties solve a much wider range of problems than introduced by naked delegate members. They just happen to solve this issue, too.
 That being said, I want the same explicit syntax for property and method 
 injection, which are elements of aspect-oriented programming.  Let's 
 call it inject:

 inject T[] reverse(T)(T[] arr) {...}
 inject property T middle(T)(T[] arr)
 {
   return arr[$/2];
 }
 auto s = "abcde";
 auto sr = s.reverse();  // "edcba"
 auto sm = s.middle;  // 'c'
 reverse(s);  // undefined identifier
I can imagine you want your personal hell, but I hardly can understand its usefulness to you or the rest of us :o).
Do you have a clear understanding of how name resolution should work in 'unified call syntax' as it is now? bool even(char[] a) {...} class Foo { private OptimizedEvenComputer ec; bool even(char[] a) {return ec.even(a);} void foo() { bool even(char[] a) {...} char[] l; auto x = l.even; auto y = even(l); } } What happens here? What *should* happen here? Even now people are confused because the mechanism works against their expectations. And, most importantly, they disagree in their expectations. Explicit injection solves this ambiguity once and for all. And I'm yet to hear *actual* arguments from you. Till now it was that you didn't like to type parentheses, you didn't like a bit of strictness in the language, and you didn't see any problem in not being able to replace methods with vars. Oh wait, you did see the problem. So what's your point then?
My point is that I agree with all concerns you are raising but I am not sure they warrant adding a language feature. Andrei
Sep 27 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 27 Sep 2008 15:19:01 -0500,
Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Sep 27 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas? Andrei
Sep 27 2008
next sibling parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
Just trying to think of something that could be easily parsed... void foo(char t)!={ /*do something with t*/} void bar(char t) { /*do something with t*/} void main() { foo('t'); // okay foo='t'; // not okay because of the "!=" bar('t'); // okay bar='t'; // okay } My thinking is that it doesn't break existing code. One could change the order to precede the argument list, but I don't like that as much because it becomes ambiguous when used in conjunction with templates. Just my $0.02.
Sep 27 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 27 Sep 2008 23:08:43 -0700,
Chris R. Miller wrote:
 Andrei Alexandrescu wrote:
 I think we all agree that there are some annoyances related to the whole 
 property business, among which the main one is:
 
 writeln = 4;
 
 That is quite indefensible :o|. I consider the others rather minor, but 
 that's just a personal opinion.
 
 How about this. Maybe if we attacked this annoyance in particular, that 
 would be a large bang for the buck without a landslide change in the 
 compiler. We only need some way to inform the compiler, "yes, it's ok to 
 call a.b(c) as a.b = c". Ideas?
Just trying to think of something that could be easily parsed... void foo(char t)!={ /*do something with t*/} void bar(char t) { /*do something with t*/} void main() { foo('t'); // okay foo='t'; // not okay because of the "!=" bar('t'); // okay bar='t'; // okay } My thinking is that it doesn't break existing code. One could change the order to precede the argument list, but I don't like that as much because it becomes ambiguous when used in conjunction with templates.
I cannot see how trickery with an existing syntax is less a feature than a new keyword.
Sep 28 2008
parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Sergey Gromov wrote:
 Sat, 27 Sep 2008 23:08:43 -0700,
 Chris R. Miller wrote:
 Andrei Alexandrescu wrote:
 I think we all agree that there are some annoyances related to the whole 
 property business, among which the main one is:

 writeln = 4;

 That is quite indefensible :o|. I consider the others rather minor, but 
 that's just a personal opinion.

 How about this. Maybe if we attacked this annoyance in particular, that 
 would be a large bang for the buck without a landslide change in the 
 compiler. We only need some way to inform the compiler, "yes, it's ok to 
 call a.b(c) as a.b = c". Ideas?
Just trying to think of something that could be easily parsed... void foo(char t)!={ /*do something with t*/} void bar(char t) { /*do something with t*/} void main() { foo('t'); // okay foo='t'; // not okay because of the "!=" bar('t'); // okay bar='t'; // okay } My thinking is that it doesn't break existing code. One could change the order to precede the argument list, but I don't like that as much because it becomes ambiguous when used in conjunction with templates.
I cannot see how trickery with an existing syntax is less a feature than a new keyword.
Awe, but making the syntax more complex makes the code look so much more unfriendly ;-) My thought process hadn't even touched upon the idea of adding another keyword. But then what would the keyword be? "noeq"? "noprop"? "propless"? "muffin"? (I vote for muffin!) ;-)
Sep 28 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu wrote:
 
 I think we all agree that there are some annoyances related to the whole
 property business, among which the main one is:
 
 writeln = 4;
 
 That is quite indefensible :o|. I consider the others rather minor, but
 that's just a personal opinion.
 
 How about this. Maybe if we attacked this annoyance in particular, that
 would be a large bang for the buck without a landslide change in the
 compiler. We only need some way to inform the compiler, "yes, it's ok to
 call a.b(c) as a.b = c". Ideas?
That seems like a bad idea if it allows a forgetful/lazy/overworked library writer to cause users to be unable to use property syntax in natural cases. I'd say explicit forbidding of property syntax is a better idea. Based on some people's view of properties, allowing property get syntax for pure functions would make a lot of sense. Others would hate that. I'm not sure if restricting users would be all that popular. It may be better placed in some kind of lint tool.
Sep 28 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu wrote:
  
 I think we all agree that there are some annoyances related to the whole
 property business, among which the main one is:

 writeln = 4;

 That is quite indefensible :o|. I consider the others rather minor, but
 that's just a personal opinion.

 How about this. Maybe if we attacked this annoyance in particular, that
 would be a large bang for the buck without a landslide change in the
 compiler. We only need some way to inform the compiler, "yes, it's ok to
 call a.b(c) as a.b = c". Ideas?
That seems like a bad idea if it allows a forgetful/lazy/overworked library writer to cause users to be unable to use property syntax in natural cases. I'd say explicit forbidding of property syntax is a better idea. Based on some people's view of properties, allowing property get syntax for pure functions would make a lot of sense. Others would hate that. I'm not sure if restricting users would be all that popular. It may be better placed in some kind of lint tool.
But I'm talking about property set syntax, not get. Andrei
Sep 28 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
Andrei Alexandrescu wrote:
 I think we all agree that there are some annoyances related to the whole 
 property business, among which the main one is:
 
 writeln = 4;
 
 That is quite indefensible :o|. I consider the others rather minor, but 
 that's just a personal opinion.
 
 How about this. Maybe if we attacked this annoyance in particular, that 
 would be a large bang for the buck without a landslide change in the 
 compiler. We only need some way to inform the compiler, "yes, it's ok to 
 call a.b(c) as a.b = c". Ideas?
 
Using an equals sign to say that assignment syntax is allowed seems natural: void prop(=int x) { } // assignment syntax ok void prop(= int x) { } // same thing Other cases: void prop(=int x=0) { } // can called as 'prop;' or 'int z = prop;' void prop(=int x, int y) { } // probably syntax error void prop(=int x, int y=0) { } // unusual but ok? Functions with no arguments can still be called without parens.
Sep 28 2008
next sibling parent torhu <no spam.invalid> writes:
torhu wrote:
 Other cases:
 void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
Oops, I meant "can be called as 'prop;' or 'prop = 7;'
Sep 28 2008
prev sibling parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
torhu wrote:
 Andrei Alexandrescu wrote:
 I think we all agree that there are some annoyances related to the 
 whole property business, among which the main one is:

 writeln = 4;

 That is quite indefensible :o|. I consider the others rather minor, 
 but that's just a personal opinion.

 How about this. Maybe if we attacked this annoyance in particular, 
 that would be a large bang for the buck without a landslide change in 
 the compiler. We only need some way to inform the compiler, "yes, it's 
 ok to call a.b(c) as a.b = c". Ideas?
Using an equals sign to say that assignment syntax is allowed seems natural: void prop(=int x) { } // assignment syntax ok void prop(= int x) { } // same thing Other cases: void prop(=int x=0) { } // can called as 'prop;' or 'int z = prop;' void prop(=int x, int y) { } // probably syntax error void prop(=int x, int y=0) { } // unusual but ok? Functions with no arguments can still be called without parens.
My concern is that this could break existing code. If the presence of an equals sign allows the use of the property syntax, then suddenly code needs to be updated that is supposed to be able to be used like a property. Perhaps something to explicitly disallow the use of the property syntax?
Sep 28 2008
parent reply torhu <no spam.invalid> writes:
Chris R. Miller wrote:
 torhu wrote:
 Using an equals sign to say that assignment syntax is allowed seems 
 natural:
 
 void prop(=int x) { }  // assignment syntax ok
 void prop(= int x) { }  // same thing
 
 Other cases:
 void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
 void prop(=int x, int y) { }  // probably syntax error
 void prop(=int x, int y=0) { }  // unusual but ok?
 
 
 Functions with no arguments can still be called without parens.
My concern is that this could break existing code. If the presence of an equals sign allows the use of the property syntax, then suddenly code needs to be updated that is supposed to be able to be used like a property. Perhaps something to explicitly disallow the use of the property syntax?
Well, isn't this just for D 2.0? The implicit property setters could be just deprecated, like volatile recently was, so compiling with -d will make them work again.
Sep 28 2008
parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
torhu wrote:
 Chris R. Miller wrote:
 torhu wrote:
 Using an equals sign to say that assignment syntax is allowed seems 
 natural:

 void prop(=int x) { }  // assignment syntax ok
 void prop(= int x) { }  // same thing

 Other cases:
 void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
 void prop(=int x, int y) { }  // probably syntax error
 void prop(=int x, int y=0) { }  // unusual but ok?


 Functions with no arguments can still be called without parens.
My concern is that this could break existing code. If the presence of an equals sign allows the use of the property syntax, then suddenly code needs to be updated that is supposed to be able to be used like a property. Perhaps something to explicitly disallow the use of the property syntax?
Well, isn't this just for D 2.0? The implicit property setters could be just deprecated, like volatile recently was, so compiling with -d will make them work again.
D 2.0 isn't so different that every line of code will have to be rewritten for it though. Why force people to have to rewrite more code for D2.0 if we aren't sure we have to? Also, are we considering these properties? void doFoo() { } int main() { doFoo; // same as doFoo(); }
Sep 28 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas? Andrei
I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway. It would break the code, yes, but it is very easy to fix. Solution of my preference: class Foo { // allow property syntax: property void bar(int baz); // allows "foo.bar = 42;" // allow omitting parens property int bar(); // allows writing "int x = foo.bar;" } Think long term, don't be afraid to break existing code and introduce new features if they improve the language signaficantly. Wrong decision made today may make huge negative impact over time.
Sep 28 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas? Andrei
I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway.
By whom aren't they expected?
 It would break the code, yes, but it is very easy to fix.
 
 Solution of my preference:
 
 class Foo
 {
     // allow property syntax:
     property void bar(int baz); // allows "foo.bar = 42;"
 
     // allow omitting parens
     property int bar();         // allows writing "int x = foo.bar;"
 }
 
 Think long term, don't be afraid to break existing code and introduce 
 new features if they improve the language signaficantly. Wrong decision 
 made today may make huge negative impact over time.
Without solid argument, all this is just talk. What is the negative impact over time? Andrei
Sep 28 2008
parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am 
 not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas? Andrei
I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway.
By whom aren't they expected?
 It would break the code, yes, but it is very easy to fix.

 Solution of my preference:

 class Foo
 {
     // allow property syntax:
     property void bar(int baz); // allows "foo.bar = 42;"

     // allow omitting parens
     property int bar();         // allows writing "int x = foo.bar;"
 }

 Think long term, don't be afraid to break existing code and introduce 
 new features if they improve the language signaficantly. Wrong 
 decision made today may make huge negative impact over time.
Without solid argument, all this is just talk. What is the negative impact over time?
Improper use of properties make code that looks ambiguous. Is that a public member or a method? It reduces codebase coherency, which is normally not a huge problem except when new programmers are reading through the code to see how it works. If someone mistook that method call via property as a member, then they might use it as such in code they write. Because it's actually a method, it has the potential to rope in serious amounts of processor work. It's the same reason you don't want to overload simple operators in C++ with potentially large algorithms, since it creates an illusion that the operator is really a simple operation when in fact it could be quite tedious. This is - of course - a matter of practice with C++, and isn't a language requirement, but it does illustrate that it's something to be conscious of. Similarly, you wouldn't want to load up a D invariant with a lot of hard processor work, since that would incur a lot of overhead following each public function call. There's nothing explicitly wrong about doing it, it's just bad practice (according to some). I hope that was coherent. I believe I read about it in /Code Complete/, if you want a source.
Sep 28 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chris R. Miller wrote:
 Improper use of properties make code that looks ambiguous.  Is that a 
 public member or a method?
Under what circumstances is that distinction important?
 It reduces codebase coherency
How? Why?
, which is 
 normally not a huge problem except when new programmers are reading 
 through the code to see how it works.
Why do they need to know whether it's a computed or a state value?
 If someone mistook that method 
 call via property as a member, then they might use it as such in code 
 they write.  Because it's actually a method, it has the potential to 
 rope in serious amounts of processor work.
That is the complexity issue that was discussed a while ago in the digitalmars.d group. I agree that certain interfaces should come with a complexity guarantee. But the line is definitely not drawn at member/computed value. Besides public members are bad style to start with, so essentially the argument is that everybody must litter their code with (). Why? Because there is the implied assumption that what doesn't have the () is a member variable access. I am challenging that assumption.
 It's the same reason you don't want to overload simple operators in C++ 
 with potentially large algorithms, since it creates an illusion that the 
 operator is really a simple operation when in fact it could be quite 
 tedious.
I agree. That is what the STL does.
 This is - of course - a matter of practice with C++, and isn't 
 a language requirement, but it does illustrate that it's something to be 
 conscious of.  Similarly, you wouldn't want to load up a D invariant 
 with a lot of hard processor work, since that would incur a lot of 
 overhead following each public function call.  There's nothing 
 explicitly wrong about doing it, it's just bad practice (according to 
 some).
 
 I hope that was coherent.  I believe I read about it in /Code Complete/, 
 if you want a source.
I don't have the latest, so a quote would be helpful. Andrei
Sep 28 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chris R. Miller wrote:
 Improper use of properties make code that looks ambiguous.  Is that a 
 public member or a method?
Under what circumstances is that distinction important?
 It reduces codebase coherency
How? Why?
, which is 
 normally not a huge problem except when new programmers are reading 
 through the code to see how it works.
Why do they need to know whether it's a computed or a state value?
 If someone mistook that method 
 call via property as a member, then they might use it as such in code 
 they write.  Because it's actually a method, it has the potential to 
 rope in serious amounts of processor work.
That is the complexity issue that was discussed a while ago in the digitalmars.d group. I agree that certain interfaces should come with a complexity guarantee. But the line is definitely not drawn at member/computed value. Besides public members are bad style to start with, so essentially the argument is that everybody must litter their code with (). Why? Because there is the implied assumption that what doesn't have the () is a member variable access. I am challenging that assumption.
 It's the same reason you don't want to overload simple operators in C++ 
 with potentially large algorithms, since it creates an illusion that the 
 operator is really a simple operation when in fact it could be quite 
 tedious.
I agree. That is what the STL does.
 This is - of course - a matter of practice with C++, and isn't 
 a language requirement, but it does illustrate that it's something to be 
 conscious of.  Similarly, you wouldn't want to load up a D invariant 
 with a lot of hard processor work, since that would incur a lot of 
 overhead following each public function call.  There's nothing 
 explicitly wrong about doing it, it's just bad practice (according to 
 some).
 
 I hope that was coherent.  I believe I read about it in /Code Complete/, 
 if you want a source.
I don't have the latest, so a quote would be helpful. Andrei
Sep 28 2008
parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Andrei Alexandrescu wrote:
 Chris R. Miller wrote:
 Improper use of properties make code that looks ambiguous.  Is that a 
 public member or a method?
Under what circumstances is that distinction important?
My lack of example situations is offset by my fear of one day finding one as a problem.
 It reduces codebase coherency
How? Why?
In Java, if something was called like a function with the () and everything, you could be pretty dang sure it's a method. In D, if it doesn't have a () when you see it, it could still be a method called as a property. The only way to find out is to look it up, which can be tedious and boring. If you don't look it up, you may never know, which reduces the coherency of the code.
 , which is normally not a huge problem except when new programmers are 
 reading through the code to see how it works.
Why do they need to know whether it's a computed or a state value?
I prefer to know what I'm doing when using an API - or any other code, for that matter. I think the more information you have about a system, the better able you are to make use of it. A method call indicates a potential for additional machinery behind the scenes, which can be useful information when deciding how to craft an algorithm that makes use of other code.
 If someone mistook that method call via property as a member, then 
 they might use it as such in code they write.  Because it's actually a 
 method, it has the potential to rope in serious amounts of processor 
 work.
That is the complexity issue that was discussed a while ago in the digitalmars.d group. I agree that certain interfaces should come with a complexity guarantee. But the line is definitely not drawn at member/computed value. Besides public members are bad style to start with, so essentially the argument is that everybody must litter their code with (). Why? Because there is the implied assumption that what doesn't have the () is a member variable access. I am challenging that assumption.
We could just do as Objective-C and use that strange typid foo = [NSObject toString]; syntax, which would negate the need for the whole discussion. ;-)
 It's the same reason you don't want to overload simple operators in 
 C++ with potentially large algorithms, since it creates an illusion 
 that the operator is really a simple operation when in fact it could 
 be quite tedious.
I agree. That is what the STL does.
STL is... strange, and I have not yet been well versed in it. The likes of superdan has convinced me that there is something of substance in it, though until I can really find some time to sink my teeth into it, I can have but no comment.
 This is - of course - a matter of practice with C++, and isn't a 
 language requirement, but it does illustrate that it's something to be 
 conscious of.  Similarly, you wouldn't want to load up a D invariant 
 with a lot of hard processor work, since that would incur a lot of 
 overhead following each public function call.  There's nothing 
 explicitly wrong about doing it, it's just bad practice (according to 
 some).

 I hope that was coherent.  I believe I read about it in /Code 
 Complete/, if you want a source.
I don't have the latest, so a quote would be helpful.
Actually I think it was from "Game Coding Complete" (Mike McShaffery, 2003). I seem to remember it being in proximity to another rant about how polydimensional vector addition using overloaded operators is a Bad Thing (TM) because junior programmers will do it left and right thinking "Eh, it's an operator, therefore fast!" when in fact is was a hugely expensive operation that should be avoided to speed up things. My brain leaks, I may never fully remember where it came from until I find that book again (somewhere in my room, though not sure where).
Sep 28 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chris R. Miller wrote:
 STL is... strange, and I have not yet been well versed in it.  The likes 
 of superdan has convinced me that there is something of substance in it, 
 though until I can really find some time to sink my teeth into it, I can 
 have but no comment.
That was an interesting thread. I am glad you decided to learn STL, you will derive a lot of good stuff from there. Andrei
Sep 28 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Chris R. Miller, el 28 de septiembre a las 19:50 me escribiste:
It reduces codebase coherency
How? Why?
In Java, if something was called like a function with the () and everything, you could be pretty dang sure it's a method. In D, if it doesn't have a () when you see it, it could still be a method called as a property. The only way to find out is to look it up, which can be tedious and boring. If you don't look it up, you may never know, which reduces the coherency of the code.
In Java you have the exact same problem. Since it doesn't support properties, and people don't want to chage thousands of LOC if they need to change a simple member variable to a function, they use functions just in case. So when you look at a function, for example, getSomething() you still wonder: is this just a simple return something;? Or is *really* a function? The problem is the same, you just have to use uglier syntax =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- CHINO ATRAPA COTORRAS -- Crónica TV
Sep 29 2008
parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Leandro Lucarella wrote:
 Chris R. Miller, el 28 de septiembre a las 19:50 me escribiste:
 It reduces codebase coherency
How? Why?
In Java, if something was called like a function with the () and everything, you could be pretty dang sure it's a method. In D, if it doesn't have a () when you see it, it could still be a method called as a property. The only way to find out is to look it up, which can be tedious and boring. If you don't look it up, you may never know, which reduces the coherency of the code.
In Java you have the exact same problem. Since it doesn't support properties, and people don't want to chage thousands of LOC if they need to change a simple member variable to a function, they use functions just in case. So when you look at a function, for example, getSomething() you still wonder: is this just a simple return something;? Or is *really* a function? The problem is the same, you just have to use uglier syntax =)
In Java for some reason the "Industry Standard" was that using non-constant public members was a Bad Thing (TM), and that getters and setters were the only acceptable thing. For most things this was more or less just an annoying function set that looked like this: class Foo { private String bar; public void setBar(String bar){ this.bar=bar; } public String getBar(){ return this.bar; } } Other times (rare, I never personally needed it) they were important to allow input checking (what we'd do like this: void setBar(char[] bar) in { assert(bar.length>=3); } body { this.bar=bar; } And some times (such as in certain Swing/AWT code) they would immediately affect something, eg. setting the text on a window would immediately send a message to the rendering engine and make a change happen the next time the window was painted. Overall it wasn't a fault with Java, just with the Java programmers. They were so used to using getFoo/setFoo they just used it all the time.
Sep 29 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chris R. Miller wrote:
 Leandro Lucarella wrote:
 Chris R. Miller, el 28 de septiembre a las 19:50 me escribiste:
 It reduces codebase coherency
How? Why?
In Java, if something was called like a function with the () and everything, you could be pretty dang sure it's a method. In D, if it doesn't have a () when you see it, it could still be a method called as a property. The only way to find out is to look it up, which can be tedious and boring. If you don't look it up, you may never know, which reduces the coherency of the code.
In Java you have the exact same problem. Since it doesn't support properties, and people don't want to chage thousands of LOC if they need to change a simple member variable to a function, they use functions just in case. So when you look at a function, for example, getSomething() you still wonder: is this just a simple return something;? Or is *really* a function? The problem is the same, you just have to use uglier syntax =)
In Java for some reason the "Industry Standard" was that using non-constant public members was a Bad Thing (TM), and that getters and setters were the only acceptable thing. For most things this was more or less just an annoying function set that looked like this: class Foo { private String bar; public void setBar(String bar){ this.bar=bar; } public String getBar(){ return this.bar; } } Other times (rare, I never personally needed it) they were important to allow input checking (what we'd do like this: void setBar(char[] bar) in { assert(bar.length>=3); } body { this.bar=bar; } And some times (such as in certain Swing/AWT code) they would immediately affect something, eg. setting the text on a window would immediately send a message to the rendering engine and make a change happen the next time the window was painted. Overall it wasn't a fault with Java, just with the Java programmers. They were so used to using getFoo/setFoo they just used it all the time.
Great point. This getFoo/setFoo crap is so retarded. It is a good illustration of the road to hell paved with good intentions. Yes, it's good to give the object a crack to enforce its invariant upon setting and maybe to compute/adjust a value upon getting. Here things took the wrong turn in Java - instead of unifying fields with properties, they postulated there must be no public fields. Andrei
Sep 29 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chris R. Miller wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I 
 am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas? Andrei
I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway.
By whom aren't they expected?
 It would break the code, yes, but it is very easy to fix.

 Solution of my preference:

 class Foo
 {
     // allow property syntax:
     property void bar(int baz); // allows "foo.bar = 42;"

     // allow omitting parens
     property int bar();         // allows writing "int x = foo.bar;"
 }

 Think long term, don't be afraid to break existing code and introduce 
 new features if they improve the language signaficantly. Wrong 
 decision made today may make huge negative impact over time.
Without solid argument, all this is just talk. What is the negative impact over time?
Improper use of properties make code that looks ambiguous. Is that a public member or a method? It reduces codebase coherency, which is normally not a huge problem except when new programmers are reading through the code to see how it works. If someone mistook that method call via property as a member, then they might use it as such in code they write. Because it's actually a method, it has the potential to rope in serious amounts of processor work. It's the same reason you don't want to overload simple operators in C++ with potentially large algorithms, since it creates an illusion that the operator is really a simple operation when in fact it could be quite tedious. This is - of course - a matter of practice with C++, and isn't a language requirement, but it does illustrate that it's something to be conscious of. Similarly, you wouldn't want to load up a D invariant with a lot of hard processor work, since that would incur a lot of overhead following each public function call. There's nothing explicitly wrong about doing it, it's just bad practice (according to some). I hope that was coherent. I believe I read about it in /Code Complete/, if you want a source.
Oh, besides - if computed properties are allowed, they also can perform arbitrary amounts of work. No? Andrei
Sep 28 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Denis Koroskin wrote:
 On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Sergey Gromov wrote:
 Sat, 27 Sep 2008 15:19:01 -0500,
 Andrei Alexandrescu wrote:
 My point is that I agree with all concerns you are raising but I am not
 sure they warrant adding a language feature.
I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint. So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy. The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
Very wise words. I think we all agree that there are some annoyances related to the whole property business, among which the main one is: writeln = 4; That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion. How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas? Andrei
I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway. It would break the code, yes, but it is very easy to fix. Solution of my preference: class Foo { // allow property syntax: property void bar(int baz); // allows "foo.bar = 42;" // allow omitting parens property int bar(); // allows writing "int x = foo.bar;" } Think long term, don't be afraid to break existing code and introduce new features if they improve the language signaficantly. Wrong decision made today may make huge negative impact over time.
Or just issue a warning if property syntax is used without the "property" keyword. But hey, since all of you dislike warnings, this is surely not a solution, right?
Sep 29 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 29 Sep 2008 19:49:49 +0800,
KennyTM~ wrote:
 But hey, since all of you dislike warnings, this is surely not a 
 solution, right?
Right now warnings in DMD are either not shown or are considered errors. I don't know if this is 2.019 only, but there are effectively no warnings: either there are less errors or more errors.
Sep 29 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:
 How about this. Maybe if we attacked this annoyance in particular, that 
 would be a large bang for the buck without a landslide change in the 
 compiler. We only need some way to inform the compiler, "yes, it's ok to 
 call a.b(c) as a.b = c". Ideas?
I actually did have something in mind when I wrote this, just didn't want to bias anyone. My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a function a.b(T x) should be allowed if and only if there also exists a function a.b() that returns a value of type T. Example: struct S1 { void prop(int x); } S1 s1; s1 = x; // error, prop is not a property struct S2 { void prop(int x); int prop(); } S2 s2; s2.prop = 42; // fine, prop is a property because it also has a getter This solution does not require any syntactic addition. Its drawback is that it makes it hard to define write-only properties. Are they important? Andrei
Sep 28 2008
next sibling parent Kenny B <funisher gmail.com> writes:
Andrei Alexandrescu wrote:
 Andrei Alexandrescu wrote:
 How about this. Maybe if we attacked this annoyance in particular,
 that would be a large bang for the buck without a landslide change in
 the compiler. We only need some way to inform the compiler, "yes, it's
 ok to call a.b(c) as a.b = c". Ideas?
I actually did have something in mind when I wrote this, just didn't want to bias anyone.
For the record, you have my vote on this idea. it would greatly simplify a lot of my aliases and template usage in particular (though I'm using D1) +1
Sep 28 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Sep 29, 2008 at 8:32 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Andrei Alexandrescu wrote:
 How about this. Maybe if we attacked this annoyance in particular, that
 would be a large bang for the buck without a landslide change in the
 compiler. We only need some way to inform the compiler, "yes, it's ok to
 call a.b(c) as a.b = c". Ideas?
I actually did have something in mind when I wrote this, just didn't want to bias anyone. My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a function a.b(T x) should be allowed if and only if there also exists a function a.b() that returns a value of type T. Example: struct S1 { void prop(int x); } S1 s1; s1 = x; // error, prop is not a property struct S2 { void prop(int x); int prop(); } S2 s2; s2.prop = 42; // fine, prop is a property because it also has a getter This solution does not require any syntactic addition. Its drawback is that it makes it hard to define write-only properties. Are they important?
Seems a little too subtle to me. Maybe no problem for the compiler, but yet another kooky rule the human has to hold in their brain when trying to read D code. The rule is trivial, you may say. But how about co-variant return types? If FooSub is a subclass of Foo, then is it ok for the getter to return one and setter to take the other? Or vice versa? Or how about implicit conversions. If my getter takes a long, but my setter returns an int, is that ok? How do const variations fit in? Probably there's a way to fit those all neatly in an automatic rule (or just disallow them), but it just makes the rule longer and even harder to keep in mind (or cuts off functionality people may need). Also how about preventing the calling of property setters as functions? s2.next(42) looks like it will do something quite different from s2.next = 42. I would like for property syntax to also disallow function call syntax. --- Somewhat unrelated, but there still exists the annoyance in D that if you have to functions with the same name and you want to take the address of one of them, you can't. Furthermore I can't think of a reasonable syntax to do that easily. For that reason, I really think the best getter and setter functionality in D would be something where you have distinctly named *functions* getProp and setProp for when you want/need functions mirroring samely-named *properties* for which only property syntax would work. Basically there's no convenient way to take the address of one of a getter/setter function pair, currently. I think that should factor in the solution here. --bb
Sep 28 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Sep 29, 2008 at 8:32 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Andrei Alexandrescu wrote:
 How about this. Maybe if we attacked this annoyance in particular, that
 would be a large bang for the buck without a landslide change in the
 compiler. We only need some way to inform the compiler, "yes, it's ok to
 call a.b(c) as a.b = c". Ideas?
I actually did have something in mind when I wrote this, just didn't want to bias anyone. My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a function a.b(T x) should be allowed if and only if there also exists a function a.b() that returns a value of type T. Example: struct S1 { void prop(int x); } S1 s1; s1 = x; // error, prop is not a property struct S2 { void prop(int x); int prop(); } S2 s2; s2.prop = 42; // fine, prop is a property because it also has a getter This solution does not require any syntactic addition. Its drawback is that it makes it hard to define write-only properties. Are they important?
Seems a little too subtle to me. Maybe no problem for the compiler, but yet another kooky rule the human has to hold in their brain when trying to read D code. The rule is trivial, you may say. But how about co-variant return types? If FooSub is a subclass of Foo, then is it ok for the getter to return one and setter to take the other? Or vice versa? Or how about implicit conversions. If my getter takes a long, but my setter returns an int, is that ok? How do const variations fit in? Probably there's a way to fit those all neatly in an automatic rule (or just disallow them), but it just makes the rule longer and even harder to keep in mind (or cuts off functionality people may need).
Yah, I was thinking of all these and then some more while I was posting. I think it's another duck typing thing. If you can call: entity.prop(entity.prop); then you can consider prop a property, period. Entity could be anything that allows the dot member access (object, class, struct, union, template, or module). Given that there is no global scope in D, that takes care of everything. I think it's really hard to get any simpler than that.
 Also how about preventing the calling of property setters as functions?
 
 s2.next(42) looks like it will do something quite different from
 s2.next = 42.  I would like for property syntax to also disallow
 function call syntax.
I'd also like plenty many things, but they cost.
 ---
 Somewhat unrelated, but there still exists the annoyance in D that if
 you have to functions with the same name and you want to take the
 address of one of them, you can't.  Furthermore I can't think of a
 reasonable syntax to do that easily.  For that reason,  I really think
 the best getter and setter functionality in D would be something where
 you have distinctly named *functions* getProp and setProp for when you
 want/need functions mirroring samely-named *properties* for which only
 property syntax would work.
 
 Basically there's no convenient way to take the address of one of a
 getter/setter function pair, currently.  I think that should factor in
 the solution here.
Overloading is the issue, and that's quite a different story. If you know the exact type, you can take the address of something. struct S { int foo() {} void foo(int) {} } void main() { S s; void delegate(int) x = &s.foo; int delegate() y = &s.foo; } Andrei
Sep 28 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Sep 29, 2008 at 12:53 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 Basically there's no convenient way to take the address of one of a
 getter/setter function pair, currently.  I think that should factor in
 the solution here.
Overloading is the issue, and that's quite a different story.
It's a different, but intertwined story.
 If you know
 the exact type, you can take the address of something.

 struct S
 {
    int foo() {}
    void foo(int) {}
 }

 void main()
 {
    S s;
    void delegate(int) x = &s.foo;
    int delegate() y = &s.foo;
 }
Having to write out "delegate(argumenttype) doesn't qualify as "convenient" in my book. --bb
Sep 28 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Sep 29, 2008 at 12:53 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 Basically there's no convenient way to take the address of one of a
 getter/setter function pair, currently.  I think that should factor in
 the solution here.
Overloading is the issue, and that's quite a different story.
It's a different, but intertwined story.
 If you know
 the exact type, you can take the address of something.

 struct S
 {
    int foo() {}
    void foo(int) {}
 }

 void main()
 {
    S s;
    void delegate(int) x = &s.foo;
    int delegate() y = &s.foo;
 }
Having to write out "delegate(argumenttype) doesn't qualify as "convenient" in my book.
You first used "can't". That doesn't qualify as "can" in my book :o). The "can't" made me honestly think you didn't know about the ability to take the address of an overloaded function/method into a specifically-typed function or delegate respectively. One more instance of the proverbial no good deed that goes unpunished... :o) Andrei
Sep 28 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Sep 29, 2008 at 1:16 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, Sep 29, 2008 at 12:53 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 Basically there's no convenient way to take the address of one of a
 getter/setter function pair, currently.  I think that should factor in
 the solution here.
Overloading is the issue, and that's quite a different story.
It's a different, but intertwined story.
 If you know
 the exact type, you can take the address of something.

 struct S
 {
   int foo() {}
   void foo(int) {}
 }

 void main()
 {
   S s;
   void delegate(int) x = &s.foo;
   int delegate() y = &s.foo;
 }
Having to write out "delegate(argumenttype) doesn't qualify as "convenient" in my book.
You first used "can't". That doesn't qualify as "can" in my book :o). The "can't" made me honestly think you didn't know about the ability to take the address of an overloaded function/method into a specifically-typed function or delegate respectively. One more instance of the proverbial no good deed that goes unpunished... :o)
Yeh, sorry about that. I vaguely remembered that there was some way to do it, but that it wasn't something I would want to be forced to use whenever I wanted to get a delegate pointer. --bb
Sep 28 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 28 Sep 2008 22:53:13 -0500,
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 The rule is trivial, you may say.  But how about co-variant return
 types?  If FooSub is a subclass of Foo, then is it ok for the getter
 to return one and setter to take the other?  Or vice versa?  Or how
 about implicit conversions.  If my getter takes a long, but my setter
 returns an int, is that ok?  How do const variations fit in?  Probably
 there's a way to fit those all neatly in an automatic rule (or just
 disallow them), but it just makes the rule longer and even harder to
 keep in mind (or cuts off functionality people may need).
Yah, I was thinking of all these and then some more while I was posting. I think it's another duck typing thing. If you can call: entity.prop(entity.prop); then you can consider prop a property, period. Entity could be anything that allows the dot member access (object, class, struct, union, template, or module). Given that there is no global scope in D, that takes care of everything. I think it's really hard to get any simpler than that.
D has a simple rule for property methods. This rule has side effects. If the side effects are so bad that a hack is required to counter them, then the rule should be replaced with a better one. Otherwise your hack will inevitably introduce new, less obvious side effects than those it were supposed to fight, and will finally require other hacks. struct Range { ref int head() {...} } Range r; r.head = 5; // error
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Sun, 28 Sep 2008 22:53:13 -0500,
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 The rule is trivial, you may say.  But how about co-variant return
 types?  If FooSub is a subclass of Foo, then is it ok for the getter
 to return one and setter to take the other?  Or vice versa?  Or how
 about implicit conversions.  If my getter takes a long, but my setter
 returns an int, is that ok?  How do const variations fit in?  Probably
 there's a way to fit those all neatly in an automatic rule (or just
 disallow them), but it just makes the rule longer and even harder to
 keep in mind (or cuts off functionality people may need).
Yah, I was thinking of all these and then some more while I was posting. I think it's another duck typing thing. If you can call: entity.prop(entity.prop); then you can consider prop a property, period. Entity could be anything that allows the dot member access (object, class, struct, union, template, or module). Given that there is no global scope in D, that takes care of everything. I think it's really hard to get any simpler than that.
D has a simple rule for property methods. This rule has side effects. If the side effects are so bad that a hack is required to counter them, then the rule should be replaced with a better one. Otherwise your hack will inevitably introduce new, less obvious side effects than those it were supposed to fight, and will finally require other hacks. struct Range { ref int head() {...} } Range r; r.head = 5; // error
A function can return an object that allows assignment even today with opAssign. I said "If you can call: entity.prop(entity.prop); then you can consider prop a property, period." I did not say "If and only if". Andrei
Sep 29 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 29 Sep 2008 12:23:58 -0500,
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 D has a simple rule for property methods.  This rule has side effects.  
 If the side effects are so bad that a hack is required to counter them,
 then the rule should be replaced with a better one.  Otherwise your hack 
 will inevitably introduce new, less obvious side effects than those it 
 were supposed to fight, and will finally require other hacks.
 
 struct Range
 {
   ref int head() {...}
 }
 Range r;
 r.head = 5; // error
A function can return an object that allows assignment even today with opAssign.
Today the compiler tries to call Range.head with one argument and fails. Another side effect needs hacking.
 I said "If you can call: entity.prop(entity.prop); then you can consider 
 prop a property, period." I did not say "If and only if".
Sep 29 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Mon, 29 Sep 2008 12:23:58 -0500,
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 D has a simple rule for property methods.  This rule has side effects.  
 If the side effects are so bad that a hack is required to counter them,
 then the rule should be replaced with a better one.  Otherwise your hack 
 will inevitably introduce new, less obvious side effects than those it 
 were supposed to fight, and will finally require other hacks.

 struct Range
 {
   ref int head() {...}
 }
 Range r;
 r.head = 5; // error
A function can return an object that allows assignment even today with opAssign.
Today the compiler tries to call Range.head with one argument and fails. Another side effect needs hacking.
Well I'd rather say, an awkwardness that needs fixing. Andrei
Sep 29 2008
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 Sun, 28 Sep 2008 22:53:13 -0500,
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 The rule is trivial, you may say.  But how about co-variant return
 types?  If FooSub is a subclass of Foo, then is it ok for the getter
 to return one and setter to take the other?  Or vice versa?  Or how
 about implicit conversions.  If my getter takes a long, but my setter
 returns an int, is that ok?  How do const variations fit in?  Probably
 there's a way to fit those all neatly in an automatic rule (or just
 disallow them), but it just makes the rule longer and even harder to
 keep in mind (or cuts off functionality people may need).
Yah, I was thinking of all these and then some more while I was posting. I think it's another duck typing thing. If you can call: entity.prop(entity.prop); then you can consider prop a property, period. Entity could be anything that allows the dot member access (object, class, struct, union, template, or module). Given that there is no global scope in D, that takes care of everything. I think it's really hard to get any simpler than that.
D has a simple rule for property methods. This rule has side effects. If the side effects are so bad that a hack is required to counter them, then the rule should be replaced with a better one. Otherwise your hack will inevitably introduce new, less obvious side effects than those it were supposed to fight, and will finally require other hacks. struct Range { ref int head() {...} } Range r; r.head = 5; // error
A function can return an object that allows assignment even today with opAssign. I said "If you can call: entity.prop(entity.prop); then you can consider prop a property, period." I did not say "If and only if". Andrei
Just wondering... What about opCall's? Will it be considered while evaluating "entity.prop(entity.prop)"? (I hope not :p, and an object S won't be evaluated to S() := S.opCall() anyway.) struct A { invariant void opCall(invariant(A) x) { writeln('hi'); } } struct B { invariant(A) a; } b.a(b.a) compiles but b.a = b.a does not make sense (b.a is not mutable).
Sep 29 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 
 ---
 Somewhat unrelated, but there still exists the annoyance in D that if
 you have to functions with the same name and you want to take the
 address of one of them, you can't.  Furthermore I can't think of a
 reasonable syntax to do that easily.  For that reason,  I really think
 the best getter and setter functionality in D would be something where
 you have distinctly named *functions* getProp and setProp for when you
 want/need functions mirroring samely-named *properties* for which only
 property syntax would work.
 
Hum, that reminds me of an idea I once had for properties: not using a keyword, but only convention, just as the op* methods for operator overload. Basicly one writes a property with getter and setter functions, like Java: class Foo { SomeBar getSomeBar(); void setSomeBar(SomeBar someBar); } one can then access those functions normally, like Java, but one would then also be able to use a property with the same name of the getter/setter methods, but without 'get' or 'set', and with the capitalization of the first letter fixed, like this: Foo foo = ...; SomeBar someBar = foo.someBar; //same as: SomeBar someBar = foo.getSomeBar(); foo.someBar = new SomeBar(); //same as: foo.setBar(new SomeBar()); This makes it easy to use Java-style code (for instance when porting Java code, or using libs like DWT, etc.). What I don't like here, is that this solution involves working with the capitalization/CamelCase of the property, which doesn't sound right. And what about properties that start with a capital letter?... :( -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Bill Baxter wrote:
 ---
 Somewhat unrelated, but there still exists the annoyance in D that if
 you have to functions with the same name and you want to take the
 address of one of them, you can't.  Furthermore I can't think of a
 reasonable syntax to do that easily.  For that reason,  I really think
 the best getter and setter functionality in D would be something where
 you have distinctly named *functions* getProp and setProp for when you
 want/need functions mirroring samely-named *properties* for which only
 property syntax would work.
Hum, that reminds me of an idea I once had for properties: not using a keyword, but only convention, just as the op* methods for operator overload. Basicly one writes a property with getter and setter functions, like Java: class Foo { SomeBar getSomeBar(); void setSomeBar(SomeBar someBar); } one can then access those functions normally, like Java, but one would then also be able to use a property with the same name of the getter/setter methods, but without 'get' or 'set', and with the capitalization of the first letter fixed, like this: Foo foo = ...; SomeBar someBar = foo.someBar; //same as: SomeBar someBar = foo.getSomeBar(); foo.someBar = new SomeBar(); //same as: foo.setBar(new SomeBar()); This makes it easy to use Java-style code (for instance when porting Java code, or using libs like DWT, etc.). What I don't like here, is that this solution involves working with the capitalization/CamelCase of the property, which doesn't sound right. And what about properties that start with a capital letter?... :(
What's going on now is pretty much that except that there's no more symbol changing - it's just someBar() and someBar(SomeBar). Andrei
Oct 02 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Bill Baxter wrote:
 ---
 Somewhat unrelated, but there still exists the annoyance in D that if
 you have to functions with the same name and you want to take the
 address of one of them, you can't.  Furthermore I can't think of a
 reasonable syntax to do that easily.  For that reason,  I really think
 the best getter and setter functionality in D would be something where
 you have distinctly named *functions* getProp and setProp for when you
 want/need functions mirroring samely-named *properties* for which only
 property syntax would work.
Hum, that reminds me of an idea I once had for properties: not using a keyword, but only convention, just as the op* methods for operator overload. Basicly one writes a property with getter and setter functions, like Java: class Foo { SomeBar getSomeBar(); void setSomeBar(SomeBar someBar); } one can then access those functions normally, like Java, but one would then also be able to use a property with the same name of the getter/setter methods, but without 'get' or 'set', and with the capitalization of the first letter fixed, like this: Foo foo = ...; SomeBar someBar = foo.someBar; //same as: SomeBar someBar = foo.getSomeBar(); foo.someBar = new SomeBar(); //same as: foo.setBar(new SomeBar()); This makes it easy to use Java-style code (for instance when porting Java code, or using libs like DWT, etc.). What I don't like here, is that this solution involves working with the capitalization/CamelCase of the property, which doesn't sound right. And what about properties that start with a capital letter?... :(
What's going on now is pretty much that except that there's no more symbol changing - it's just someBar() and someBar(SomeBar).
Pretty much, but not exactly the same, because in this way you can't distinguish a property from a normal method call. The idea is to be able to distinguish two different concepts: properties and "procedures".
 
 Andrei
 
Oct 02 2008
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-28 19:32:43 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 struct S2
 {
      void prop(int x);
      int prop();
 }
 
 S2 s2;
 s2.prop = 42; // fine, prop is a property because it also has a getter
 
 This solution does not require any syntactic addition. Its drawback is 
 that it makes it hard to define write-only properties. Are they 
 important?
I think having a function returing *the same type* is probably too much. What about this case: struct S { string str(); void str(string s); void str(wstring s); void str(dstring s); } In this case, you can only do "str = x;" when x is an UTF-8 string. Setting UTF-16 and UTF-32 would (sadly) require using the parenthesis syntax under your proposal. So I think you should not check for the return type of the getter, just if there is a function of the same name with no parameter, to determine if the "=" syntax can be used. ... Hum, and what do you do with this: struct S2 { void prop(int x); private int prop(); } S2 s2; s2.prop = 42; // legal or not? If it's legal, then I think it'll be used as a hack to do write-only properties. And also, if you keep checking the return type of the getter, what about this: struct S2 { void prop(Object x); const(Object) prop(); } Should "prop = new Object;" be legal or not? What if prop() was returning an invariant(Object) instead (for which there is no allowed implicit conversions)? And what if there are two overloads for the setter: one with an invariant(Object) and one with an Object (mutable)? Are both allowed to be called with "="? Then you should probably disallow "ref" and "out" too in the setter. I'm not sure either about what you'll do once "shared" gets in the picture. (And ain't "scope" comming at some point too?) Also, what if one or the other is a static function? And what if you have an invariant(S2) and prop(Object x) is accessible (because it is invariant) while prop() is not (because not invariant), should the "=" syntax apply anyway? ... Basically what I want to illustrate is that another drawback of this solution is that it will probably not be as straitforward to define, and then understand, as it seem at first glance. The current syntax, with all its drawbacks, has the advantage of being very easy to understand: using "=" works all the time and it's the caller's responsibility to use the syntax which express better what he is doing. Personally, I have no problem with that. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 28 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2008-09-28 19:32:43 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 struct S2
 {
      void prop(int x);
      int prop();
 }

 S2 s2;
 s2.prop = 42; // fine, prop is a property because it also has a getter

 This solution does not require any syntactic addition. Its drawback is 
 that it makes it hard to define write-only properties. Are they 
 important?
I think having a function returing *the same type* is probably too much. What about this case: struct S { string str(); void str(string s); void str(wstring s); void str(dstring s); } In this case, you can only do "str = x;" when x is an UTF-8 string. Setting UTF-16 and UTF-32 would (sadly) require using the parenthesis syntax under your proposal. So I think you should not check for the return type of the getter, just if there is a function of the same name with no parameter, to determine if the "=" syntax can be used.
Great point. I think the rule suggested in my latest post convers this. The rule was, if you can call s.str(s.str) then str is a property and allows the syntax "=". After than overloading will take care of all else.
 ...
 
 Hum, and what do you do with this:
 
 struct S2
 {
     void prop(int x);
     private int prop();
 }
 
 S2 s2;
 s2.prop = 42; // legal or not?
 
 If it's legal, then I think it'll be used as a hack to do write-only 
 properties.
It is legal because access check is done after syntactic check. (Also Walter wants to introduce the fun() = void syntax to disallow copying; that might be useful in this context too.)
 And also, if you keep checking the return type of the getter, what about 
 this:
 
 struct S2
 {
     void prop(Object x);
     const(Object) prop();
 }
 
 Should "prop = new Object;" be legal or not?
Great question - quite an arrow in the suggestion's Achille's tendon. Since I can't write s.prop(s.prop), that property would be ruled out. This may in fact be a good thing. It would be nice to provide generic code with the guarantee that if the save some property of an object, they can restore it later: void generic(Node)(Node obj) { auto save = obj.indentLevel; scope(exit) obj.indentLevel = save; ... }
 What if prop() was 
 returning an invariant(Object) instead (for which there is no allowed 
 implicit conversions)?
Under the proposal entity.prop(entity.prop), that won't compile. (I will note that invariant(Object) does convert to const(Object)).
 And what if there are two overloads for the 
 setter: one with an invariant(Object) and one with an Object (mutable)? 
 Are both allowed to be called with "="?
Under the proposal entity.prop(entity.prop), that would compile.
 Then you should probably disallow "ref" and "out" too in the setter.
Consider: struct ArrayAppender { ref Array host; void host(ref Array); } That should work as property, ain't it? (Walter has introduced ref returns; I'm already working on an alpha that has the feature. Of course I found bugs, too. :o))
 I'm 
 not sure either about what you'll do once "shared" gets in the picture. 
 (And ain't "scope" comming at some point too?)
Same test entity.prop(entity.prop) rules'em all.
 Also, what if one or the other is a static function?
Depends on how you call it. If you call it with an object in the first place, it works. If not, it doesn't.
 And what if you 
 have an invariant(S2) and prop(Object x) is accessible (because it is 
 invariant) while prop() is not (because not invariant), should the "=" 
 syntax apply anyway?
 
 ...
 
 Basically what I want to illustrate is that another drawback of this 
 solution is that it will probably not be as straitforward to define, and 
 then understand, as it seem at first glance.
I think it is very easy to define and moderately hard to implement.
 The current syntax, with all its drawbacks, has the advantage of being 
 very easy to understand: using "=" works all the time and it's the 
 caller's responsibility to use the syntax which express better what he 
 is doing. Personally, I have no problem with that.
I'm not crazy about the syntax, but if it has notable advantages, sure. Andrei
Sep 28 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-29 00:07:28 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Michel Fortin wrote:
 On 2008-09-28 19:32:43 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 struct S2
 {
      void prop(int x);
      int prop();
 }
 
 S2 s2;
 s2.prop = 42; // fine, prop is a property because it also has a getter
 
 This solution does not require any syntactic addition. Its drawback is 
 that it makes it hard to define write-only properties. Are they 
 important?
I think having a function returing *the same type* is probably too much. What about this case: struct S { string str(); void str(string s); void str(wstring s); void str(dstring s); } In this case, you can only do "str = x;" when x is an UTF-8 string. Setting UTF-16 and UTF-32 would (sadly) require using the parenthesis syntax under your proposal. So I think you should not check for the return type of the getter, just if there is a function of the same name with no parameter, to determine if the "=" syntax can be used.
Great point. I think the rule suggested in my latest post convers this. The rule was, if you can call s.str(s.str) then str is a property and allows the syntax "=". After than overloading will take care of all else.
 ...
 
 Hum, and what do you do with this:
 
 struct S2
 {
     void prop(int x);
     private int prop();
 }
 
 S2 s2;
 s2.prop = 42; // legal or not?
 
 If it's legal, then I think it'll be used as a hack to do write-only 
 properties.
It is legal because access check is done after syntactic check.
Ok, so you determine if a function can be called by "=" before checking for access rights.
 (Also Walter wants to introduce the fun() = void syntax to disallow 
 copying; that might be useful in this context too.)
Ok, great. What do you do with this by the way: struct S2 { void prop(int x); deprecated int prop(); } Did the author want to eventually replace "prop()" with "prop() = void" to keep allowing "prop = 1", or does he want to simply remove it and disallow the "prop = 1" syntax? I find it somewhat troubling that removing an unused function (especially if private) could invalidate code just because it is calling another overloaded function with the property syntax. I mean, now to know if you can safely remove a function, you have to check if anyone is using any of corresponding overloaded "setters" too.
 And also, if you keep checking the return type of the getter, what about this:
 
 struct S2
 {
     void prop(Object x);
     const(Object) prop();
 }
 
 Should "prop = new Object;" be legal or not?
Great question - quite an arrow in the suggestion's Achille's tendon. Since I can't write s.prop(s.prop), that property would be ruled out.
 This may in fact be a good thing. It would be nice to provide generic 
 code with the guarantee that if the save some property of an object, 
 they can restore it later:
 
 void generic(Node)(Node obj) {
     auto save = obj.indentLevel;
     scope(exit) obj.indentLevel = save;
     ...
 }
Hum, but if the setter is private, protected, or package, or if it just doesn't exist, that guarenty doesn't exist. Another interesting case: struct S5 { int prop(); void prop(int x) const; } Not sure what to do with it though, but it certainly breaks your guarenty when S5 is invariant. So should the property syntax "s5.prop = x;" works only when S5 is mutable, or not at all, or in all cases? Then what about this strange one: struct S5 { int prop(); string prop() invariant; void prop(int x) const; } Should the property syntax works when for S5, const(S5), invariant(S5) ?
 What if prop() was returning an invariant(Object) instead (for which 
 there is no allowed implicit conversions)?
Under the proposal entity.prop(entity.prop), that won't compile. (I will note that invariant(Object) does convert to const(Object)).
 And what if there are two overloads for the setter: one with an 
 invariant(Object) and one with an Object (mutable)? Are both allowed to 
 be called with "="?
Under the proposal entity.prop(entity.prop), that would compile.
Seems coherant.
 Then you should probably disallow "ref" and "out" too in the setter.
Consider: struct ArrayAppender { ref Array host; void host(ref Array); } That should work as property, ain't it? (Walter has introduced ref returns; I'm already working on an alpha that has the feature. Of course I found bugs, too. :o))
And "out"?
 I'm not sure either about what you'll do once "shared" gets in the 
 picture. (And ain't "scope" comming at some point too?)
Same test entity.prop(entity.prop) rules'em all.
Seems coherant, again.
 Also, what if one or the other is a static function?
Depends on how you call it. If you call it with an object in the first place, it works. If not, it doesn't.
Ok, let's clarify that: struct S1 { int prop(); static void prop(int x); } struct S2 { static int prop(); void prop(int x); } S1 s1; s1.prop = 1; // ok, because s1.prop returns int. S1.prop = 1; // error, since S1.prop does not exist. S2 s2; s2.prop = 1; // ok, because s1.prop returns int. Is that right?
 And what if you have an invariant(S2) and prop(Object x) is accessible 
 (because it is invariant) while prop() is not (because not invariant), 
 should the "=" syntax apply anyway?
No answer to that one? Take this case: struct S3 { int prop() invariant; void prop(int x); } S3 s3; s3.prop = x; // error? struct S4 { int prop(); void prop(int x) invariant; } invariant(S4) s4; s4.prop = x; // error? I guess disallowing this wouldn't be too bad, since it's pretty ridiculous anyway.
 Basically what I want to illustrate is that another drawback of this 
 solution is that it will probably not be as straitforward to define, 
 and then understand, as it seem at first glance.
I think it is very easy to define and moderately hard to implement.
The thing is that you can't explain everything just by checking if you can compile "s.prop(s.prop)". If one of the two is private, you said it would be allowed anyway, it becomes "s.prop(s.prop) disregarding applicable protection attributes". Then you said that it the getter could be "= void", but obviously "s.prop(s.prop) wouldn't compile in that case, so you'd have to change it to "s.prop(s.prop) compiles disregarding applicable protection attributes and whether or the the getter is '= void'". Then you'll need to add something about the constness of the struct or class the function is scoped in, so it becomes: s.prop(s.prop) compiles disregarding applicable protection attributes, disregarding whether or the the getter is '= void', and disregarding the constness of the enclosing scope (class or struct). That doesn't sound so simple, and I probably got it wrong. Can you define it better? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 Ok, great. What do you do with this by the way:
 
 struct S2
 {
     void prop(int x);
     deprecated int prop();
 }
 
 Did the author want to eventually replace "prop()" with "prop() = void" 
 to keep allowing "prop = 1", or does he want to simply remove it and 
 disallow the "prop = 1" syntax?
 
 I find it somewhat troubling that removing an unused function 
 (especially if private) could invalidate code just because it is calling 
 another overloaded function with the property syntax. I mean, now to 
 know if you can safely remove a function, you have to check if anyone is 
 using any of corresponding overloaded "setters" too.
I understand. I find it somewhat troubling too.
 void generic(Node)(Node obj) {
     auto save = obj.indentLevel;
     scope(exit) obj.indentLevel = save;
     ...
 }
Hum, but if the setter is private, protected, or package, or if it just doesn't exist, that guarenty doesn't exist.
That means indentLevel is not a property and consequently "generic" cannot work with that object.
 Another interesting case:
 
 struct S5
 {
     int prop();
     void prop(int x) const;
 }
 
 Not sure what to do with it though, but it certainly breaks your 
 guarenty when S5 is invariant. So should the property syntax "s5.prop = 
 x;" works only when S5 is mutable, or not at all, or in all cases?
It's very simple. If you have "entity.prop = x" first you check for "entity.prop(entity.prop)". Does that compile? If so, you rewrite "entity.prop = x" as entity.prop(x) and continue from there. In your question s5 can be invariant, const, or mutable. In either case the usual judgment applies.
 Then what about this strange one:
 
 struct S5
 {
     int prop();
     string prop() invariant;
     void prop(int x) const;
 }
 
 Should the property syntax works when for S5, const(S5), invariant(S5) ?
Same answer.
 Then you should probably disallow "ref" and "out" too in the setter.
Consider: struct ArrayAppender { ref Array host; void host(ref Array); } That should work as property, ain't it? (Walter has introduced ref returns; I'm already working on an alpha that has the feature. Of course I found bugs, too. :o))
And "out"?
struct S { ref int prop(); void prop(out int); } s.prop(s.prop) does compile, so s.prop = x; should be allowed. However, I agree it does something counterintuitive (modify the right-hand side).
 Ok, let's clarify that:
 
 struct S1
 {
     int prop();
     static void prop(int x);
 }
 
 struct S2
 {
     static int prop();
     void prop(int x);
 }
 
 S1 s1;
 s1.prop = 1; // ok, because s1.prop returns int.
 S1.prop = 1; // error, since S1.prop does not exist.
 
 S2 s2;
 s2.prop = 1; // ok, because s1.prop returns int.
 
 Is that right?
Yah.
 And what if you have an invariant(S2) and prop(Object x) is 
 accessible (because it is invariant) while prop() is not (because not 
 invariant), should the "=" syntax apply anyway?
No answer to that one? Take this case: struct S3 { int prop() invariant; void prop(int x); } S3 s3; s3.prop = x; // error?
s3.prop(s3.prop) would not compile, so neither does the assignment form.
 struct S4
 {
     int prop();
     void prop(int x) invariant;
 }
 
 invariant(S4) s4;
 s4.prop = x; // error?
 
 I guess disallowing this wouldn't be too bad, since it's pretty 
 ridiculous anyway.
This would not compile because s4.prop(s4.prop) does not compile.
 The thing is that you can't explain everything just by checking if you 
 can compile "s.prop(s.prop)". If one of the two is private, you said it 
 would be allowed anyway, it becomes "s.prop(s.prop) disregarding 
 applicable protection attributes". Then you said that it the getter 
 could be "= void", but obviously "s.prop(s.prop) wouldn't compile in 
 that case, so you'd have to change it to "s.prop(s.prop) compiles 
 disregarding applicable protection attributes and whether or the the 
 getter is '= void'". Then you'll need to add something about the 
 constness of the struct or class the function is scoped in, so it becomes:
 
     s.prop(s.prop) compiles disregarding applicable protection attributes,
     disregarding whether or the the getter is '= void', and disregarding
     the constness of the enclosing scope (class or struct).
 
 That doesn't sound so simple, and I probably got it wrong. Can you 
 define it better?
With this part I completely disagree. You artificially create complexity by bringing other rules into play that were in place before this discussion. By the same token you could add "s.prop(s.prop) compiles if s and prop are properly formed identifiers" and claim that that is an issue with properties. The protection attributes do their job. The = void does (will do, actually) its job. Qualifiers do their job. It's business as usual. I did not invent those rules for the sake of properties. Andrei
Sep 29 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-29 09:48:31 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

     s.prop(s.prop) compiles disregarding applicable protection attributes,
     disregarding whether or the the getter is '= void', and disregarding
     the constness of the enclosing scope (class or struct).
 
 That doesn't sound so simple, and I probably got it wrong. Can you 
 define it better?
With this part I completely disagree. You artificially create complexity by bringing other rules into play that were in place before this discussion. By the same token you could add "s.prop(s.prop) compiles if s and prop are properly formed identifiers" and claim that that is an issue with properties. The protection attributes do their job. The = void does (will do, actually) its job. Qualifiers do their job. It's business as usual. I did not invent those rules for the sake of properties.
Ok, lets look back at what I wrote and what you replied in your previous post:
 struct S2
 {
     void prop(int x);
     private int prop();
 }
 
 S2 s2;
 s2.prop = 42; // legal or not?
 
 If it's legal, then I think it'll be used as a hack to do write-only 
 properties.
It is legal because access check is done after syntactic check. (Also Walter wants to introduce the fun() = void syntax to disallow copying; that might be useful in this context too.)
But "s2.prop(s2.prop)" wouldn't compile in the context where "s2.prop = 42" is called, because s2.prop is private. You say say that it doesn't matter, so I take it there is an exception for protection attributes. Or perhaps you're checking if "s2.prop(s2.prop)" compiles in another context I don't know about. About the "= void" thing, my interpretation is that it's a way to tell the compiler that this function doesn't exist (like making a copy constructor private in C++), but I admit I'm not sure what I'm talking about here. Anyway, my interpretation is that if you have: struct S2 { void prop(int x); int prop() = void; } S2 s2; s2.prop; the last line wouldn't compile since s2.prop can't be called. How can "s2.prop(s2.prop)" compile then? As for the last one, I think I decided myself that it wouldn't be very good for a function to be a property or not depending on the constness of the object. My previous examples were badly written however. Imagine you have this: struct S2 { int prop(); int prop() invariant; void prop(int x) const; } This design is probably a little strange, but lets look at it anyway: S2 s2; const(S2) constS2; invariant(S2) invariantS2; s2.prop = 1; // compiles because s2.prop(s2.prop) compiles. constS2.prop = 1; // does not compile because const(S2).prop isn't defined invariantS2.prop = 1; // compiles because invariantS2.prop(invariantS2.prop) compiles Basically, whether prop(int x) is a property or not depends on the various qualifiers given to prop() and the constness of S2. I think I wrongly assumed you'd want to avoid this since I had in mind you'd not forbid the proprety syntax when given a private accessor. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2008-09-29 09:48:31 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
     s.prop(s.prop) compiles disregarding applicable protection 
 attributes,
     disregarding whether or the the getter is '= void', and disregarding
     the constness of the enclosing scope (class or struct).

 That doesn't sound so simple, and I probably got it wrong. Can you 
 define it better?
With this part I completely disagree. You artificially create complexity by bringing other rules into play that were in place before this discussion. By the same token you could add "s.prop(s.prop) compiles if s and prop are properly formed identifiers" and claim that that is an issue with properties. The protection attributes do their job. The = void does (will do, actually) its job. Qualifiers do their job. It's business as usual. I did not invent those rules for the sake of properties.
Ok, lets look back at what I wrote and what you replied in your previous post:
 struct S2
 {
     void prop(int x);
     private int prop();
 }

 S2 s2;
 s2.prop = 42; // legal or not?

 If it's legal, then I think it'll be used as a hack to do write-only 
 properties.
It is legal because access check is done after syntactic check. (Also Walter wants to introduce the fun() = void syntax to disallow copying; that might be useful in this context too.)
But "s2.prop(s2.prop)" wouldn't compile in the context where "s2.prop = 42" is called, because s2.prop is private. You say say that it doesn't matter, so I take it there is an exception for protection attributes. Or perhaps you're checking if "s2.prop(s2.prop)" compiles in another context I don't know about.
It's my fault, I misunderstood you. Sorry. This case could go either way, and I agree it does add complexity to the feature. If the feature is thought as a syntactic rewrite (my opinion), then s2.prop = 42 should always rewrite into s2.prop(42), and then whether that works or not should be left to the protection in vigor for S2.prop(int) - public in this case. But it could also be argued that the access check should be done first, in which case the rewrite won't happen unless the code in question has access to S2's privates. Probably the latter is actually the better decision.
 About the "= void" thing, my interpretation is that it's a way to tell 
 the compiler that this function doesn't exist (like making a copy 
 constructor private in C++), but I admit I'm not sure what I'm talking 
 about here.
Yes, that is the intent.
 Anyway, my interpretation is that if you have:
 
 struct S2
 {
     void prop(int x);
     int prop() = void;
 }
 
 S2 s2;
 s2.prop;
 
 the last line wouldn't compile since s2.prop can't be called. How can 
 "s2.prop(s2.prop)" compile then?
It should not compile. Making a function = void actively makes it unreachable and unusable in all contexts.
 As for the last one, I think I decided myself that it wouldn't be very 
 good for a function to be a property or not depending on the constness 
 of the object. My previous examples were badly written however. Imagine 
 you have this:
 
 struct S2
 {
     int prop();
     int prop() invariant;
     void prop(int x) const;
 }
 
 This design is probably a little strange, but lets look at it anyway:
 
 S2 s2;
 const(S2) constS2;
 invariant(S2) invariantS2;
 
 s2.prop = 1; // compiles because s2.prop(s2.prop) compiles.
 constS2.prop = 1; // does not compile because const(S2).prop isn't defined
 invariantS2.prop = 1; // compiles because 
 invariantS2.prop(invariantS2.prop) compiles
 
 Basically, whether prop(int x) is a property or not depends on the 
 various qualifiers given to prop() and the constness of S2. I think I 
 wrongly assumed you'd want to avoid this since I had in mind you'd not 
 forbid the proprety syntax when given a private accessor.
Indeed, whether or not something can be used as a property will depend on the qualifiers in vigor. Andrei
Sep 29 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-29 23:12:44 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Indeed, whether or not something can be used as a property will depend 
 on the qualifiers in vigor.
And I think this is why binding the availability of the proprety syntax of the setter to the existance and visibility of a getter is not a good idea. Basically, doing this makes the "()" syntax safer, and the "=" version more fragile, as the later could become non-functionnal in all kinds of situations where the getter becomes unavailable (removal, deprecation, change in protection, change in constness of the parent, etc.). It means that if I remove or change the visibility of a getter in a program (because it has been found to be erroneous, dangerous, and/or badly used), I will have to change all the calls to the corresponding setter to use the parenthesis form. This can be a nuisance while refactoring. It also means that I can't just remove the getter and attempt to recompile to check if it's called somewhere without inducing compilation errors where the setter is used. And I'm sure it'll encourage some silly ones who want to write write-only properties to add a dummy getter that throws an exception, disregarding static checking. I can already see some people recommanding always using the parenthesis syntax when calling setters because then you know you won't have to change it later when you refactor your code; I know I would consider it if I got biten by this, after all we're already doing this in other languages and it's not that painfull. So I think this idea brings unnecessary coupling between functions, with more drawbacks than benefits. Don't mistake me, I liked your idea at first, especially because I'm not fond of adding a new syntax just for diallowing another, but now I realise don't like its implications of the implicit coupling of the setter with the getter. I believe explicit coupling would be better, and that probably means an explicit property syntax as others have requested. But then again, I don't mind much if things stay like they are. - - - Another funny example: module a; void func(int a); module b; int func(); module c; import a; import b; void main() { func(func); // compiles... so func = 5; // compiles too! } -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 30 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2008-09-29 23:12:44 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Indeed, whether or not something can be used as a property will depend 
 on the qualifiers in vigor.
And I think this is why binding the availability of the proprety syntax of the setter to the existance and visibility of a getter is not a good idea. Basically, doing this makes the "()" syntax safer, and the "=" version more fragile, as the later could become non-functionnal in all kinds of situations where the getter becomes unavailable (removal, deprecation, change in protection, change in constness of the parent, etc.). It means that if I remove or change the visibility of a getter in a program (because it has been found to be erroneous, dangerous, and/or badly used), I will have to change all the calls to the corresponding setter to use the parenthesis form. This can be a nuisance while refactoring. It also means that I can't just remove the getter and attempt to recompile to check if it's called somewhere without inducing compilation errors where the setter is used. And I'm sure it'll encourage some silly ones who want to write write-only properties to add a dummy getter that throws an exception, disregarding static checking. I can already see some people recommanding always using the parenthesis syntax when calling setters because then you know you won't have to change it later when you refactor your code; I know I would consider it if I got biten by this, after all we're already doing this in other languages and it's not that painfull.
I think the argument is overstated and a corner case is overblown, but I agree there is an issue.
 So I think this idea brings unnecessary coupling between functions, with 
 more drawbacks than benefits. Don't mistake me, I liked your idea at 
 first, especially because I'm not fond of adding a new syntax just for 
 diallowing another, but now I realise don't like its implications of the 
 implicit coupling of the setter with the getter.
 
 I believe explicit coupling would be better, and that probably means an 
 explicit property syntax as others have requested. But then again, I 
 don't mind much if things stay like they are.
 
 - - -
 
 Another funny example:
 
 module a;
 void func(int a);
 
 module b;
 int func();
 
 module c;
 import a;
 import b;
 void main()
 {
     func(func); // compiles... so
     func = 5; // compiles too!
 }
 
The coupling part I agree with, it's unfortunate. Well I guess I'll just drop the matter. Andrei
Sep 30 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Andrei Alexandrescu wrote:
 How about this. Maybe if we attacked this annoyance in particular, that 
 would be a large bang for the buck without a landslide change in the 
 compiler. We only need some way to inform the compiler, "yes, it's ok to 
 call a.b(c) as a.b = c". Ideas?
I actually did have something in mind when I wrote this, just didn't want to bias anyone. My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a function a.b(T x) should be allowed if and only if there also exists a function a.b() that returns a value of type T.
What about functions with default parameters? struct S1 { int prop(int x = 0) {...} } I admit I have no idea how this should be interpreted. The author may have intended for this to compile: s1.prop = 5; -Steve
Sep 30 2008
prev sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
 you didn't like to type parentheses,
I think that's a valid concern. C/C++ code is full of "()"-pairs and they make the code harder to type and more difficult to parse (for me, that is). L.
Sep 27 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 27 Sep 2008 17:56:42 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Sergey Gromov wrote:
 In article <gbiqbo$m1e$1 digitalmars.com>,  
 SeeWebsiteForEmail erdani.org says...
 Sergey Gromov wrote:
 In article <gbgu0h$5sq$1 digitalmars.com>,  
 SeeWebsiteForEmail erdani.org says...
 Sergey Gromov wrote:
 I think that property function call feature in general adds an  
 unnecessary ambiguity to the language.  I'd prefer functions to be  
 callable only with regular function call syntax, and properties be  
 usable only with member access syntax.  The same stands for  
 'unified function call' feature: if you want to inject a method  
 into an 'array of chars' class you do so explicitly, and only the  
 member call syntax is allowed on that method.  Otherwise code tends  
 to become ambiguous and unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
Sorry I may have been unclear. I'm not against interchangeability between properties and property accessor methods. I'm against using property accessors as methods, and against using methods as if they were property accessors. The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore. And you cannot replace public void delegate(int) foo; with an accessor method because the code 'instance.foo();' will stop working as it used to.
I am a bit confused about terminology. Could you please clarify with examples what you mean, also defining all terms (e.g. what does "property accessor" mean?) Thanks.
Property accessor is a method which is invoked when you syntactically access a data field. They are called getters and setters in many languages. In current D, any function or method with zero or one argument is considered a property accessor: class Foo { int prop() { return field + 1; } int prop(int value) { return field = value + 3; } private int field; } void useFoo(Foo f) { auto x = f.prop; f.prop = 5; auto y = f.prop(); // also allowed f.prop(8); // ditto }
Ok, so far so good.
 The 'prop' family of methods are property accessors in my terminology,  
 and they can be replaced with an actual data field:
  class Foo
 {
   int prop;
 }
  void useFoo(Foo f)
 {
   auto x = f.prop;  // fine!
   f.prop = 5;  // works
    auto y = f.prop();  // Error: function expected
   f.prop(8);  // Error: function expected
 }
  You see, properties and methods are *not* interchangeable in current  
 D.  Therefore your correct thesis:

 Experience with other languages has shown that using identical  
 syntax for genuine member access and member function access helps  
 maintainability because it allows a type implementer to switch back  
 and forth between implementing a property as a direct member or as a  
 function, transparently to that type's use.
does not apply to D.
It does apply, just only one direction. From the above, it looks like a good guideline is to always use the syntax: auto x = f.prop; f.prop = x; because it is more general. And indeed, consider something as innocuous as the empty member for a range. Some here said I should write range.empty() throughout. But that, aside from wrist and eye pain, precludes infinite ranges from implementing empty as simple as: struct Generator { ... enum empty = false; } But if that implementation were allowed, that would be a boon for generic code because it can easily detect infinite ranges statically.
 Here's another example:
  class Bar
 {
   int delegate() meth;
 }
  int useBar(Bar b)
 {
   return b.meth();
 }
  Can you replace 'meth' with a getter?
  class Bar
 {
   int delegate() meth()
   {
     return {return 5;};
   }
  }
  int useBar(Bar b)
 {
   return b.meth();  // Error: cannot implicitly convert expression
   // (b.meth()) of type int delegate() to int
 }
  No you cannot.  But you could be able to do all those nice things if  
 you had an explicit syntax for getters and setters:
  class Foo
 {
   property int prop() {...}
   property int prop(int value) {...}
   property int prop(int v, char c) {...} // syntax error, 2 arguments
   property int delegate() meth() {...}
 }
I agree. But there's a simpler solution: int useBar(Bar crystal) { return (crystal.meth)(); } Looks a bit uneasy on the eye? I agree. But count the lines you use member delegates in; then count the lines you use non-delegate member access; divide the first by the second; multiply by 100; and... is that worth a language feature?
It is. A duality like this is bad for language. Should you write foo.bar or foo.bar()? If the former, as you insist, then why not force it? If the latter, then it is not a property anymore. It is a language hack right now! Sergey's proposal is great because it is simple, expressive, sound and it removes the ambiguities that are present now.
Sep 27 2008
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbgpak$2q10$1 digitalmars.com>,
 brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }

 As a matter of coding style conventions, I would say that using the
 implicit property function call feature on a function that changes
 state is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next"
 really just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use. Two nice examples of the undesirability of distinct notation are the std::pair first and second members in the STL, which made what seemed like an innocuous decision turn into a catastrophe, and also std::numeric_limits<T>::min and max, which partially prompted creation of an entire language feature(!). Andrei
I've got a few questions regarding this: for example: class MyClass { private int x; public int X { get { return x; } set { x = value; } } } wouldn't it solve the problem of the implementer switching between a direct member and a function, transparently to that type's use? In the above you could remove the data member and re-implement the get/set by calling suitable functions. my main question is of style: is it better in your opinion to allow all functions with no parameters to be called as "function_name;" (i.e. no parens) and if you need to refer to the function identifier itself you need to do &func (for example if you want to pass it as a parameter to a different function) OR require an operator such as parens to signify you call the function and the name without parens will just signify the function itself (so no need to use &func when func is a parameter) ?
Sep 25 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbgpak$2q10$1 digitalmars.com>,
 brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }

 As a matter of coding style conventions, I would say that using the
 implicit property function call feature on a function that changes
 state is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next"
 really just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use. Two nice examples of the undesirability of distinct notation are the std::pair first and second members in the STL, which made what seemed like an innocuous decision turn into a catastrophe, and also std::numeric_limits<T>::min and max, which partially prompted creation of an entire language feature(!). Andrei
I've got a few questions regarding this: for example: class MyClass { private int x; public int X { get { return x; } set { x = value; } } } wouldn't it solve the problem of the implementer switching between a direct member and a function, transparently to that type's use? In the above you could remove the data member and re-implement the get/set by calling suitable functions.
It would solve the problem by adding a language feature. It is unclear to me whether the cost of adding the feature justifies its benefits.
 my main question is of style:
 is it better in your opinion to allow all functions with no parameters
 to be called as "function_name;" (i.e. no parens) and if you need to
 refer to the function identifier itself you need to do &func (for
 example if you want to pass it as a parameter to a different function)
 OR
 require an operator such as parens to signify you call the function and
 the name without parens will just signify the function itself (so no
 need to use &func when func is a parameter) ?
There are a few principles at work here that I consider universal, plus some others that I consider a matter of preference. One principle that I consider universal is that a language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. Another that I also consider universal is that the more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle. C's handling of function names royally breaks both of these principles. It makes func; a valid syntactic construct with inoperant semantics and consequently useless pragmatics. Moreover, a = func; gunc(func); both have valid syntax and semantics, but the pragmatics are the infrequently-used manipulations of function addresses in higher-order programming, something C is not quite adept at to start with. (So that makes the state of affairs all the more ironic.) C++ builds on that irony by making obj.func; b = obj.func; gunc(obj.func); still syntactically valid but one order of magnitude less useful because they traffic in references to member functions, a contraption that is defined sufficiently bad and inefficient to be useless in practice, and also of a type with a syntax I'd be glad to remove from my memory. (How many here _do_ know that type's syntax and have the scars to prove it?) So thinking of function call syntax has quite a few deep underpinnings. We shouldn't confuse habit acquired from C and C++ with some fundamental truth or just a matter of preference that can't be decided on an objective basis. One issue with today's function call syntax in D is that people can write code that is of dubious expressiveness: writeln = 3; Properties would solve this problem by confining assignment syntax to themselves only. Andrei
Sep 25 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbgpak$2q10$1 digitalmars.com>, 
 brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }

 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes 
 state is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next" 
 really just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
Yet, as Sergey mentioned, the switching back cannot be made safely if the field is a delegate (or any other callable type). If the delegate requires parameters, then the switch will cause the other code to not compile. But even worse, if the delegate has zero parameters, the switch will cause the code to compile, but not perform what it was supposed to do! I think this is a clear sign the feature as it is currently implemented is inadequate. So either remove the feature (which I see you're not up to, and I understand why), or fix it, by removing such ambiguity. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 26 2008
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sergey Gromov wrote:
 In article <gbgpak$2q10$1 digitalmars.com>, 
 brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }

 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes state 
 is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next" really 
 just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Yes, I full agree, as many others do, as this has been discussed before (the latest discussion: http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is_an_evil_73881.html) But that didn't seem to convince any of the higher-ups, so I was hopping to at least have the feature used more sensibly (ie, not being used in functions that are not intended to emulate properties). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 26 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Sergey Gromov wrote:
 In article <gbgpak$2q10$1 digitalmars.com>, 
 brunodomedeiros+spam com.gmail says...
 Also, some more on important bike shed issues:
      for (; !src.done; src.next)
      {
          tgt.put(src.head);
      }

 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes 
 state is *bad* style, and surely hope the community would agree on that.
 So "src.next" would be must better as "src.next()" as "src.next" 
 really just makes me cringe.
I think that property function call feature in general adds an unnecessary ambiguity to the language. I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax. The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method. Otherwise code tends to become ambiguous and unreadable.
Yes, I full agree, as many others do, as this has been discussed before (the latest discussion: http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is an_evil_73881.html) But that didn't seem to convince any of the higher-ups, so I was hopping to at least have the feature used more sensibly (ie, not being used in functions that are not intended to emulate properties).
Following that link I see there is a problem with accessing .mangleof. So the compiler sees a.b.mangleof and performs a.b().mangleof. I think that is a compiler bug because built-in properties like mangleof and sizeof should have priority over symbol evaluation. Then I see a problem with new Thread(run). I think that is C++ habit at work. Finally there's a discussion on how various language additions could work. I don't see how Walter could be convinced. Andrei
Sep 26 2008
prev sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
 I think that property function call feature in general adds an 
 unnecessary ambiguity to the language.  I'd prefer functions to be 
 callable only with regular function call syntax, and properties be 
 usable only with member access syntax.  The same stands for 'unified 
 function call' feature: if you want to inject a method into an 'array of 
 chars' class you do so explicitly, and only the member call syntax is 
 allowed on that method.  Otherwise code tends to become ambiguous and 
 unreadable.
Or abstracted and generic. Bent
Sep 26 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bent Rasmussen wrote:
 I think that property function call feature in general adds an 
 unnecessary ambiguity to the language.  I'd prefer functions to be 
 callable only with regular function call syntax, and properties be 
 usable only with member access syntax.  The same stands for 'unified 
 function call' feature: if you want to inject a method into an 'array 
 of chars' class you do so explicitly, and only the member call syntax 
 is allowed on that method.  Otherwise code tends to become ambiguous 
 and unreadable.
Or abstracted and generic.
Well put! Andrei
Sep 27 2008
parent reply sclytrack <sclytrack pi.be> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Bent Rasmussen wrote:
 I think that property function call feature in general adds an
 unnecessary ambiguity to the language.  I'd prefer functions to be
 callable only with regular function call syntax, and properties be
 usable only with member access syntax.  The same stands for 'unified
 function call' feature: if you want to inject a method into an 'array
 of chars' class you do so explicitly, and only the member call syntax
 is allowed on that method.  Otherwise code tends to become ambiguous
 and unreadable.
Or abstracted and generic.
For me a property is a RAD feature used in Borland Delphi. Published properties are displayed in the object inspector. (You have private, public, published). If you have some getter routine or setter like in C++, to me those are just methods like any other member function in C++, there is no distinction. Look at the code in Delphi. GetValue, and SetValue are just plain methods and Value is the property. procedure SetValue(const Value: string); virtual; function GetValue: string; virtual; property Value: string read GetValue write SetValue; I know D is not a RAD language but a system language, but I think D should consider making the distinction, and providing that distinction with its ru ... well lets say reflection. Without the reflection there's no need for a different syntax or notation. We could just use the // syntax. Like in //setter //getter (lame joke). Basically a property is what made RAD happen. To me a property is only a property when other programs know about it. As for syntax (b = a.dork() or b=a.dork), syntax of how to call a property is of no real value, it's secondary, its, void, no real meaning. It is just the time it takes to type (). I miss Delphi. http://www.drbob42.com/delphi/property.htm
Sep 27 2008
parent sclytrack <sclytrack pi.be> writes:
 For me a property is a RAD feature used in Borland Delphi. Published properties
 are displayed in the object inspector. (You have private, public, published).
If
 you have some getter routine or setter like in C++, to me those are just
methods
 like any other member function in C++, there is no distinction.
 Look at the code in Delphi. GetValue, and SetValue are just plain methods and
 Value is the property.
  procedure SetValue(const Value: string); virtual;
  function GetValue: string; virtual;
  property Value: string read GetValue write SetValue;
 I know D is not a RAD language but a system language, but I think D should
 consider making the distinction, and providing that distinction with its ru ...
 well lets say reflection.
 Without the reflection there's no need for a different
 syntax or notation. We could just use the // syntax.
 Like in //setter //getter (lame joke).
 Basically a property is what made RAD happen. To me a property is
 only a property when other programs know about it.
 As for syntax (b = a.dork() or b=a.dork), syntax of how to call
 a property is of no real value, it's secondary, its, void,
 no real meaning. It is just the time it takes to type ().
 I miss Delphi.
 http://www.drbob42.com/delphi/property.htm
Just in case things got lost in translation, ...
Sep 28 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
""" All ranges satisfy certain invariants outlined below. (r is an object of a range type R.) """ By "object" you actually mean struct no? Struct instance to be even more precise. Also, some more on important bike shed issues: for (; !src.done; src.next) { tgt.put(src.head); } As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
I sure hope they won't agree to an unsupported assertion.
 So "src.next" would be must better as "src.next()" as "src.next" really 
 just makes me cringe.
With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug. Andrei
Sep 25 2008
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle shed 
 galore! But don't forget to comment on the reactor as well :o).


 Andrei
""" All ranges satisfy certain invariants outlined below. (r is an object of a range type R.) """ By "object" you actually mean struct no? Struct instance to be even more precise. Also, some more on important bike shed issues: for (; !src.done; src.next) { tgt.put(src.head); } As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
I sure hope they won't agree to an unsupported assertion.
It's unsupported because it is not an assertion, but more of a subjective opinion, like most coding style conventions (indentation, bracing, etc.). I don't like seeing "src.next" if 'next' isn't either a field, or a function which doesn't change any significant state.
 So "src.next" would be must better as "src.next()" as "src.next" 
 really just makes me cringe.
With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug. Andrei
I'm not imagining what that situation would be, could you explain a bit more? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 26 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle 
 shed galore! But don't forget to comment on the reactor as well :o).


 Andrei
""" All ranges satisfy certain invariants outlined below. (r is an object of a range type R.) """ By "object" you actually mean struct no? Struct instance to be even more precise. Also, some more on important bike shed issues: for (; !src.done; src.next) { tgt.put(src.head); } As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
I sure hope they won't agree to an unsupported assertion.
It's unsupported because it is not an assertion, but more of a subjective opinion, like most coding style conventions (indentation, bracing, etc.). I don't like seeing "src.next" if 'next' isn't either a field, or a function which doesn't change any significant state.
I also don't like broccoli, but I eat it because there are reasons to do so. Would you agree that given reason, you'd use it even if you subjectively disliked it?
 So "src.next" would be must better as "src.next()" as "src.next" 
 really just makes me cringe.
With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug. Andrei
I'm not imagining what that situation would be, could you explain a bit more?
I phrased things poorly. The compiler bug is that parens for array functions in the postfix notation are required in some places and not in others. So I was forced to write much more parens than were strictly necessary, and all over the place. It gets really jarring. I've always thought required parens were a big annoyance in C++, and I can't believe people want to bring that back in D. Andrei
Sep 26 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Agh, got busy in these last days, so I was missing the discussion.


Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 In wake of the many excellent comments and suggestions made here, I 
 made one more pass through the draft proposal for ranges.

 http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

 There are some comments in red illustrating some uncertainties (not 
 all), and the names of the primitives have been updated. Bicycle 
 shed galore! But don't forget to comment on the reactor as well :o).


 Andrei
""" All ranges satisfy certain invariants outlined below. (r is an object of a range type R.) """ By "object" you actually mean struct no? Struct instance to be even more precise. Also, some more on important bike shed issues: for (; !src.done; src.next) { tgt.put(src.head); } As a matter of coding style conventions, I would say that using the implicit property function call feature on a function that changes state is *bad* style, and surely hope the community would agree on that.
I sure hope they won't agree to an unsupported assertion.
It's unsupported because it is not an assertion, but more of a subjective opinion, like most coding style conventions (indentation, bracing, etc.). I don't like seeing "src.next" if 'next' isn't either a field, or a function which doesn't change any significant state.
I also don't like broccoli, but I eat it because there are reasons to do so. Would you agree that given reason, you'd use it even if you subjectively disliked it?
Yes, if there where good reasons, I'd use it. But what are those reasons?
 So "src.next" would be must better as "src.next()" as "src.next" 
 really just makes me cringe.
With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug. Andrei
I'm not imagining what that situation would be, could you explain a bit more?
I phrased things poorly. The compiler bug is that parens for array functions in the postfix notation are required in some places and not in others. So I was forced to write much more parens than were strictly necessary, and all over the place. It gets really jarring. I've always thought required parens were a big annoyance in C++, and I can't believe people want to bring that back in D. Andrei
What I was trying to understand here, is that if the consistent usage of '()' for function calling, instead of omitting them, had lead you to bugs. (bugs in your code, not bugs in the compiler) In other words, were you presenting a reason for not consistently using parenthesis for function calling? The only reasons I've so far seen you present in favor of omitting parenthesis where this ones: """ I _believe_ a language should obey the principles 1 and 2 (economy of syntax and giving syntactic priority to frequent use cases). Based on that belief, I _think_ D should drop the trailing parens. I agree that somebody could _believe_ in some other principles that replace or override mine and then _think_ that keeping trailing parens is a good thing. Sergey did just that by showing us some very good examples when absence of trailing parens leads to ambiguity. Then there is room for meaningful discussion. It is also possible that somebody simply _believes_ the trailing parens should be kept because they make code clearer to them. That's fair too, as long as there is understanding that that belief comes to a certain extent at odds with principles 1 and 2 (which anyone is free to simply not believe). The only place that needs work is when the connection between belief and thought is unclear, or when the belief is simply wrong. """ I will reply in that respective post. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes 
 state is *bad* style, and surely hope the community would agree on that.
I sure hope they won't agree to an unsupported assertion.
Actually I *do* hate this "feature" ^_^. And this "feature" has been put to challenged before: * Bug 2159. (http://d.puremagic.com/issues/show_bug.cgi?id=2159) * "Omitting Parens is an Evil" (http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is_an_evil_73881.html) *http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=17579 But nothing got changed. To the very least, when using next as a property I assume the call won't produce any secondary effect on src from the syntax, since I'm just reading a state! Not so if one calls src.next() as the "()" is an alarming sign that src _may_ change afterwards. This could is just a problem of personal taste since the compiler does not forbid src.next(), but not so if you're reading other's code. P.S. If src.next() is too lengthy, why not just adopt ++src?
 So "src.next" would be must better as "src.next()" as "src.next" 
 really just makes me cringe.
With me it's the opposite, particularly after I've written and stared at a few hundreds of "()"s due to a compiler bug. Andrei
Sep 26 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes 
 state is *bad* style, and surely hope the community would agree on that.
I sure hope they won't agree to an unsupported assertion.
Actually I *do* hate this "feature" ^_^. And this "feature" has been put to challenged before: * Bug 2159. (http://d.puremagic.com/issues/show_bug.cgi?id=2159) * "Omitting Parens is an Evil" (http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is an_evil_73881.html) *http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com& roup=D&artnum=17579 But nothing got changed.
I don't think the bug report has much strength.
 To the very least, when using next as a property I assume the call won't 
 produce any secondary effect on src from the syntax, since I'm just 
 reading a state! Not so if one calls src.next() as the "()" is an 
 alarming sign that src _may_ change afterwards. This could is just a 
 problem of personal taste since the compiler does not forbid src.next(), 
 but not so if you're reading other's code.
 
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src". Andrei
Sep 26 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent. Not that I care too much :) I am also in the camp of 'defined properties should be a language feature,' but I admit to using D-properties quite often. The two things that bug me the most about D property syntax: stuff like this: x; What the hell does this mean? It looks like it does nothing. But it could be a function call. If explicit properties were required, and x was defined as a function, not a property, then x; would be a syntax error. And stuff like you said: writefln = 3; I've been bitten by this type of weirdness. In Tango, in the TimeSpan struct, I created several properties, one of which was: ulong seconds(); Which converts the entire timespan to seconds. I also had static 'constructors' to build time spans from common time types that looked like this: static TimeSpan seconds(ulong nseconds); Well, someone complained that this didn't set the timespan's value to 3 seconds, in fact the second line does nothing but create a temporary TimeSpan and throw it away: TimeSpan ts = TimeSpan.seconds(5); ts.seconds = 3; And it does seem like it should set ts to equal 3 seconds. So we were forced to abandon the succinct syntax of the static constructors and rename them fromSeconds, etc. If properties were explicit, then I could define 'hey you can only use this static constructor as a function NOT a property'. It's really those cases where you want to disallow one use or the other that are desired but not allowed by the current language. -Steve
Sep 26 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
 Not that I care too much :)  I am also in the camp of 'defined properties 
 should be a language feature,' but I admit to using D-properties quite 
 often.
 
 The two things that bug me the most about D property syntax:
 
 stuff like this:
 
 x;
 
 What the hell does this mean?  It looks like it does nothing.  But it could 
 be a function call.  If explicit properties were required, and x was defined 
 as a function, not a property, then x; would be a syntax error.
And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
 And stuff like you said:
 
 writefln = 3;
 
 I've been bitten by this type of weirdness.  In Tango, in the TimeSpan 
 struct, I created several properties, one of which was:
 
 ulong seconds();
 
 Which converts the entire timespan to seconds.
I agree.
 I also had static 'constructors' to build time spans from common time types 
 that looked like this:
 
 static TimeSpan seconds(ulong nseconds);
 
 Well, someone complained that this didn't set the timespan's value to 3 
 seconds, in fact the second line does nothing but create a temporary 
 TimeSpan and throw it away:
 
 TimeSpan ts = TimeSpan.seconds(5);
 ts.seconds = 3;
 
 And it does seem like it should set ts to equal 3 seconds.
 
 So we were forced to abandon the succinct syntax of the static constructors 
 and rename them fromSeconds, etc.  If properties were explicit, then I could 
 define 'hey you can only use this static constructor as a function NOT a 
 property'.  It's really those cases where you want to disallow one use or 
 the other that are desired but not allowed by the current language.
I agree. Andrei
Sep 26 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
You are assuming that the C language decision to require parentheses for all functions was a design mistake. I would argue that the design was on purpose and correctly served that purpose. The purpose was to remove ambiguity when faced with understanding code without all the context. But that isn't even the questioned practice here. C designers didn't even come across the question of whether an accessor-property should imply no changes to the object, because they don't have properties. The real problem is that no matter how you define next(), you can use it in a way which makes it appear like an accessor, not a function which modifies the object. The source of the problem is D's lack of expressiveness, where I cannot define whether a function cannot be used as a property. Even with a true property definition syntax, you cannot prevent someone from changing an object while inside an accessor, that should be defined by the constancy of the object in question. But indicating that it is preferred to use the property-style means to access the next() member function seems to be misleading to some people. The problem I have with your argument is how you used one case to say 'this is misleading to people, so it's not a valid solution', and in another case say 'it's only misleading because you are used to it, that doesn't matter.' The assumption of which people are important to please is the issue. I understand you can't please everyone, but you shouldn't use the 'people won't like it' argument without real evidence or proof.
 Not that I care too much :)  I am also in the camp of 'defined properties 
 should be a language feature,' but I admit to using D-properties quite 
 often.

 The two things that bug me the most about D property syntax:

 stuff like this:

 x;

 What the hell does this mean?  It looks like it does nothing.  But it 
 could be a function call.  If explicit properties were required, and x 
 was defined as a function, not a property, then x; would be a syntax 
 error.
And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
The advantage is not to you, it is to the reader of your code. writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property. I routinely use Tango's Stdout.newline; which I admit goes against what I am saying, but it's because I know what Stdout.newline does, and that it is a function. I would gladly change everything to Stdout.newline() if it was required. The problem is not that you or anyone might forget that writeln is a function and not a property, the problem is when you start using the property syntax to call functions that aren't so standard, someone reading the code will be confused as to what the code is supposed to do. The advantage is, you are able to define how a symbol behaves, what the rules are for using it. It makes for clearer code. -Steve
Sep 26 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
You are assuming that the C language decision to require parentheses for all functions was a design mistake. I would argue that the design was on purpose and correctly served that purpose. The purpose was to remove ambiguity when faced with understanding code without all the context.
I have stated my assumption and its basis. What is the basis of yours?
 But that isn't even the questioned practice here.  C designers didn't even 
 come across the question of whether an accessor-property should imply no 
 changes to the object, because they don't have properties.  The real problem 
 is that no matter how you define next(), you can use it in a way which makes 
 it appear like an accessor, not a function which modifies the object.  The 
 source of the problem is D's lack of expressiveness, where I cannot define 
 whether a function cannot be used as a property.
I understand your argument, but it hinges on its own definitions and assumptions. You define "accessor" and then complain that something looks like one unexpectedly. Well in some languages a.b does not change anything. In others it does. What gives?
 Even with a true property definition syntax, you cannot prevent someone from 
 changing an object while inside an accessor, that should be defined by the 
 constancy of the object in question.  But indicating that it is preferred to 
 use the property-style means to access the next() member function seems to 
 be misleading to some people.
So that further weakens your argument.
 The problem I have with your argument is how you used one case to say 'this 
 is misleading to people, so it's not a valid solution', and in another case 
 say 'it's only misleading because you are used to it, that doesn't matter.' 
 The assumption of which people are important to please is the issue.  I 
 understand you can't please everyone, but you shouldn't use the 'people 
 won't like it' argument without real evidence or proof.
I agree that ++array may not be easily confused with ++array[]. The situation I am trying to help is improve on a mistake in the C language design that we got so used to, we actually think it's the right thing.
 Not that I care too much :)  I am also in the camp of 'defined properties 
 should be a language feature,' but I admit to using D-properties quite 
 often.

 The two things that bug me the most about D property syntax:

 stuff like this:

 x;

 What the hell does this mean?  It looks like it does nothing.  But it 
 could be a function call.  If explicit properties were required, and x 
 was defined as a function, not a property, then x; would be a syntax 
 error.
And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
The advantage is not to you, it is to the reader of your code. writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property.
Aside from just saying it, do you have any substantive argument?
 I 
 routinely use Tango's Stdout.newline; which I admit goes against what I am 
 saying, but it's because I know what Stdout.newline does, and that it is a 
 function.  I would gladly change everything to Stdout.newline() if it was 
 required.
To what benefit? You seem to be using it today, and that makes your own style incongruent with your argument, yet surely you'd change the style in an iffy if you thought it has serious drawbacks.
 The problem is not that you or anyone might forget that writeln is a 
 function and not a property, the problem is when you start using the 
 property syntax to call functions that aren't so standard, someone reading 
 the code will be confused as to what the code is supposed to do.
 
 The advantage is, you are able to define how a symbol behaves, what the 
 rules are for using it.  It makes for clearer code.
I am not sure. Andrei
Sep 26 2008
next sibling parent reply 0ffh <frank youknow.what.todo.interNETz> writes:
Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require parentheses 
 for all functions was a design mistake.  I would argue that the design 
 was on purpose and correctly served that purpose.  The purpose was to 
 remove ambiguity when faced with understanding code without all the 
 context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms. regards, frank
Sep 26 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbjihf$2803$1 digitalmars.com>, 
frank youknow.what.todo.interNETz says...
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require parentheses 
 for all functions was a design mistake.  I would argue that the design 
 was on purpose and correctly served that purpose.  The purpose was to 
 remove ambiguity when faced with understanding code without all the 
 context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
Sep 26 2008
next sibling parent reply 0ffh <frank youknow.what.todo.interNETz> writes:
Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 [...]
 I wouldn't go so far as to call that property of C a design mistake in
 light of the actual intensions of K&R. But I definitely would defend
 the choice of a language designer to change that feature in light of
 more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
Awkward my sed! Why should a parameterless call be *the* natural meaning of function identifier access, as opposed to the reference or content? I don't go for that kind of absolutism, and you don't make sense to me.
Sep 26 2008
parent KennyTM~ <kennytm gmail.com> writes:
0ffh wrote:
 Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 [...]
 I wouldn't go so far as to call that property of C a design mistake in
 light of the actual intensions of K&R. But I definitely would defend
 the choice of a language designer to change that feature in light of
 more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
Awkward my sed! Why should a parameterless call be *the* natural meaning of function identifier access, as opposed to the reference or content? I don't go for that kind of absolutism, and you don't make sense to me.
It may not be "the" natural thing, but it is confusing. Someone may hate it, but let me compare with other popular languages: Function call Func. ptr. / Func. obj. / delegate Note D func(), func &func, func (as a template argument) C-like func() func, &func [1] Python func() func Perl func, func() "func" (access by &{"func"}()) [2] VB 6 func AddressOf func [2] VB.NET func() AddressOf func [2,3] Ruby func, func() &:func (??) [2,4] Java func() <<No such thing??>> PHP func() func, "func" ($x="f";$x();) Pascal func func [5] awk func() <<No such thing>> [6] sed b label <<No such thing>> [6] So, from this table, we see that (except Pascal), if the language calls a function by f(a,b,c,d), then only f() will be considered a valid function call, and a function pointer / function object / delegate is mostly accessed using f, &f or "f". If D deviates from the norm, fine, since I'm not a language designer, but from the view of programmers also familiar with, hmm, C, C++, ECMAScript, Python and/or PHP, this decision will very likely introduce obstacles or even bugs in development. Note: 1. "C-like" includes C, C++ and ECMAScript (Javascript). 3. In VB 6, Perl and Ruby it is acceptable to write "func 4,5" to mean func(4,5), so it may be unfair to compare with D which "func 4,5" is syntax error. 4. The &:func syntax for Ruby never worked for me. But I'm using Ruby 1.8. 5. I haven't tested what func really does in Pascal/Delphi, but from online sources (JFGI) it seems that func will return a function pointer if it is passed to a function pointer type. 6. Since you mentioned AWKward my SED... ;p
Sep 27 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require parentheses 
 for all functions was a design mistake.  I would argue that the design 
 was on purpose and correctly served that purpose.  The purpose was to 
 remove ambiguity when faced with understanding code without all the 
 context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
I agree. But then use of functions for invocation dwarfs use of functions as first-class values, so I think requiring & for the latter is a sensible engineering decision. Besides, it's more efficient to use them as alias parameters, so why not encourage that too. And aliases do not need a "&" :o). If you want to discuss language design mistakes, why don't you discuss a real mistake - the infamous "lazy"? Having a storage class change the way a type is used - now that's the perfect example of the tail wagging the dog. Ambiguity, confusion, non-scalability, and sheer nonsense - you can have it all with lazy. Lazy should be either fixed or honorably discharged pronto. Andrei
Sep 27 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 27 Sep 2008 09:13:54 -0500,
Andrei Alexandrescu wrote:
 If you want to discuss language design mistakes, why don't you discuss a 
 real mistake - the infamous "lazy"? Having a storage class change the 
 way a type is used - now that's the perfect example of the tail wagging 
 the dog. Ambiguity, confusion, non-scalability, and sheer nonsense - you 
 can have it all with lazy. Lazy should be either fixed or honorably 
 discharged pronto.
Because I use class and struct fields, I use properties, I use functions, delegates, aliased functions, vararg templates and conditional compilation---but I never had need for lazy yet.
Sep 27 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Sat, 27 Sep 2008 09:13:54 -0500,
 Andrei Alexandrescu wrote:
 If you want to discuss language design mistakes, why don't you discuss a 
 real mistake - the infamous "lazy"? Having a storage class change the 
 way a type is used - now that's the perfect example of the tail wagging 
 the dog. Ambiguity, confusion, non-scalability, and sheer nonsense - you 
 can have it all with lazy. Lazy should be either fixed or honorably 
 discharged pronto.
Because I use class and struct fields, I use properties, I use functions, delegates, aliased functions, vararg templates and conditional compilation---but I never had need for lazy yet.
enforce :o) Andrei
Sep 27 2008
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 I agree. But then use of functions for invocation dwarfs use of
 functions as first-class values, so I think requiring & for the latter
 is a sensible engineering decision.
the above POV seems skewed to me. D is not C! instead of relying on old habits we need to form new, better ones. you basically claim here that "functions as first class values" current usage is low therefore the syntax should be as it is, while another POV would be to say: D is relatively a new language that aims to support more functional programming therefore D should support functions as first class values more than C and adjust its syntax accordingly.
 
 Besides, it's more efficient to use them as alias parameters, so why not
 encourage that too. And aliases do not need a "&" :o).
alias parameters have cons too and the choice what to use should be decided according to the problem at hand.
 
 If you want to discuss language design mistakes, why don't you discuss a
 real mistake - the infamous "lazy"? Having a storage class change the
 way a type is used - now that's the perfect example of the tail wagging
 the dog. Ambiguity, confusion, non-scalability, and sheer nonsense - you
 can have it all with lazy. Lazy should be either fixed or honorably
 discharged pronto.
 
could you please explain more about what's so bad about lazy in your opinion?
 Andrei
 
Sep 27 2008
prev sibling next sibling parent reply Don <nospam nospam.com.au> writes:
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require 
 parentheses for all functions was a design mistake.  I would argue 
 that the design was on purpose and correctly served that purpose.  
 The purpose was to remove ambiguity when faced with understanding 
 code without all the context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
I agree. But then use of functions for invocation dwarfs use of functions as first-class values, so I think requiring & for the latter is a sensible engineering decision.
By the way, D supports declarations of function type (not function pointer), though it's not documented in the spec. They always struck me as a really odd feature in C, and they're pretty confusing for newbies: typedef void Func(int); Then you get oddities Func * f = &foo; // OK. Func f = foo; // You might expect this to work, but it makes no sense. This is a case where you do not intuitively expect "foo" (with no &) to be a function pointer. You might as well make it a function invocation. It's pretty interesting to fool around with these fellas in an is() expression.
 Besides, it's more efficient to use them as alias parameters, so why not
 encourage that too. And aliases do not need a "&" :o).
Indeed.
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require 
 parentheses for all functions was a design mistake.  I would argue 
 that the design was on purpose and correctly served that purpose.  
 The purpose was to remove ambiguity when faced with understanding 
 code without all the context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
I agree. But then use of functions for invocation dwarfs use of functions as first-class values, so I think requiring & for the latter is a sensible engineering decision.
By the way, D supports declarations of function type (not function pointer), though it's not documented in the spec. They always struck me as a really odd feature in C, and they're pretty confusing for newbies: typedef void Func(int); Then you get oddities Func * f = &foo; // OK. Func f = foo; // You might expect this to work, but it makes no sense. This is a case where you do not intuitively expect "foo" (with no &) to be a function pointer. You might as well make it a function invocation. It's pretty interesting to fool around with these fellas in an is() expression.
Heh. That is eerily similar to the way C handles it - here's an example: // this is C typedef void foo(int); int main() { foo bar; foo baz; bar = baz; } The typedef goes through. The definitions of bar and baz go through (and are simply equivalent to an extern declaration!!!) The assignment won't go through because, bar is not an lvalue. Andrei
Sep 29 2008
parent reply Don <nospam nospam.com.au> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require 
 parentheses for all functions was a design mistake.  I would 
 argue that the design was on purpose and correctly served that 
 purpose.  The purpose was to remove ambiguity when faced with 
 understanding code without all the context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
I agree. But then use of functions for invocation dwarfs use of functions as first-class values, so I think requiring & for the latter is a sensible engineering decision.
By the way, D supports declarations of function type (not function pointer), though it's not documented in the spec. They always struck me as a really odd feature in C, and they're pretty confusing for newbies: typedef void Func(int); Then you get oddities Func * f = &foo; // OK. Func f = foo; // You might expect this to work, but it makes no sense. This is a case where you do not intuitively expect "foo" (with no &) to be a function pointer. You might as well make it a function invocation. It's pretty interesting to fool around with these fellas in an is() expression.
Heh. That is eerily similar to the way C handles it - here's an example: // this is C typedef void foo(int); int main() { foo bar; foo baz; bar = baz; } The typedef goes through. The definitions of bar and baz go through (and are simply equivalent to an extern declaration!!!) The assignment won't go through because, bar is not an lvalue.
Is there a use case for this? I've only ever found it to be a nuisance, or a curiosity at best. It seems like a great bit of C baggage to discard.
Sep 29 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 In article <gbjihf$2803$1 digitalmars.com>, 
 frank youknow.what.todo.interNETz says...
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require 
 parentheses for all functions was a design mistake.  I would 
 argue that the design was on purpose and correctly served that 
 purpose.  The purpose was to remove ambiguity when faced with 
 understanding code without all the context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself. I wouldn't go so far as to call that property of C a design mistake in light of the actual intensions of K&R. But I definitely would defend the choice of a language designer to change that feature in light of more modern programming paradigms.
Functions in D are first-class values. It's awkward that a first-class value cannot be accessed by its identifier.
I agree. But then use of functions for invocation dwarfs use of functions as first-class values, so I think requiring & for the latter is a sensible engineering decision.
By the way, D supports declarations of function type (not function pointer), though it's not documented in the spec. They always struck me as a really odd feature in C, and they're pretty confusing for newbies: typedef void Func(int); Then you get oddities Func * f = &foo; // OK. Func f = foo; // You might expect this to work, but it makes no sense. This is a case where you do not intuitively expect "foo" (with no &) to be a function pointer. You might as well make it a function invocation. It's pretty interesting to fool around with these fellas in an is() expression.
Heh. That is eerily similar to the way C handles it - here's an example: // this is C typedef void foo(int); int main() { foo bar; foo baz; bar = baz; } The typedef goes through. The definitions of bar and baz go through (and are simply equivalent to an extern declaration!!!) The assignment won't go through because, bar is not an lvalue.
Is there a use case for this? I've only ever found it to be a nuisance, or a curiosity at best. It seems like a great bit of C baggage to discard.
What exactly are you trying to discard? Just the typedef void foo(int); syntax? Or any typedef of a function type? Like void func(int); typedef typeof(func) foo; ? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 
 If you want to discuss language design mistakes, why don't you discuss a 
 real mistake - the infamous "lazy"? Having a storage class change the 
 way a type is used - now that's the perfect example of the tail wagging 
 the dog. Ambiguity, confusion, non-scalability, and sheer nonsense - you 
 can have it all with lazy. Lazy should be either fixed or honorably 
 discharged pronto.
 
 
 Andrei
 
What's the problem with lazy? I mean, concretely? Are you trying to see lazy as a type modifier, and thus see it as broken type modifier? Perhaps that's the issue, don't see it as a type modifier! I see lazy as a construct in the same category as '...': a syntax that changes the way a function call processes its arguments. Just because 'lazy' is a word and not a series of symbols doesn't mean it should be interpreted as a type constructor. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
0ffh wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 You are assuming that the C language decision to require parentheses 
 for all functions was a design mistake.  I would argue that the 
 design was on purpose and correctly served that purpose.  The purpose 
 was to remove ambiguity when faced with understanding code without 
 all the context.
I have stated my assumption and its basis. What is the basis of yours?
Yum. I think the problem is that when C was designed, K&R didn't consider the use of classes with properties using getter and setter methods. Therefore, it made sense to have the naked function name denote the function pointer, and make braces following an identifier the mark of a function call. I initially had some trouble accepting the explicit & in D to get the function pointer myself.
No, that decision didn't make sense regardless of classes and functions. The problem in C is that the name of a function - the simplest thing to type - is also the least useful. If I remember correctly, initially it actually did not mean anything, so you could not do anything to it. Then a rule was added to make the function name AUTOMATICALLY become a function pointer (I mean implicitly add a "&"!). But not always! (Bonus points: under what circumstances?) Did anyone even know that? And this is C - a simple language!
 I wouldn't go so far as to call that property of C a design mistake in
 light of the actual intensions of K&R. But I definitely would defend
 the choice of a language designer to change that feature in light of
 more modern programming paradigms.
I like C, but there are some things that were simply wrongly designed (definition syntax, malloc, and (lack of) array design also come to mind). Andrei
Sep 27 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
You are assuming that the C language decision to require parentheses for all functions was a design mistake. I would argue that the design was on purpose and correctly served that purpose. The purpose was to remove ambiguity when faced with understanding code without all the context.
I have stated my assumption and its basis.
Forgive me, but I must have missed it. I saw only your assumption (or supposition) that the C designers made a mistake.
 What is the basis of yours?
I don't have any actual proof that they did this on purpose, I wasn't working at Bell labs when C was invented, in fact, I don't even think I was born ;) But it makes logical sense, and still does. If you want to call a function, you have to use parentheses. If you want to access the function address, no parentheses. It follows other design decisions they made: pointers: Access what it's pointing to, use ->, get address it's pointing to, use symbol alone.
 But that isn't even the questioned practice here.  C designers didn't 
 even come across the question of whether an accessor-property should 
 imply no changes to the object, because they don't have properties.  The 
 real problem is that no matter how you define next(), you can use it in a 
 way which makes it appear like an accessor, not a function which modifies 
 the object.  The source of the problem is D's lack of expressiveness, 
 where I cannot define whether a function cannot be used as a property.
I understand your argument, but it hinges on its own definitions and assumptions. You define "accessor" and then complain that something looks like one unexpectedly. Well in some languages a.b does not change anything. In others it does. What gives?
There is no hard-fast rule that an accessor cannot change things. The issue is that since any function can be an accessor you can't even try to adopt a policy in your library that says 'accessors will not change things'. Because you can't define which functions can be used as accessors and which ones can't. I WANT a.b to be able to be a function call, I just want to specify which functions can be called that way, and which ones cannot, so I can define how my library behaves and someone reading code that uses it will know that my rules were followed.
 Even with a true property definition syntax, you cannot prevent someone 
 from changing an object while inside an accessor, that should be defined 
 by the constancy of the object in question.  But indicating that it is 
 preferred to use the property-style means to access the next() member 
 function seems to be misleading to some people.
So that further weakens your argument.
How so? I'm not talking about whether or not the compiler should restrict the developer on being able to make changes in accessors. That is what const is for. I'm talking about being able to specify a coding convention that says 'accessors shall not change things'. Currently, there's no way to prevent any function from being used as an accessor, so a library developer cannot enforce this rule to people using his library.
 The problem I have with your argument is how you used one case to say 
 'this is misleading to people, so it's not a valid solution', and in 
 another case say 'it's only misleading because you are used to it, that 
 doesn't matter.' The assumption of which people are important to please 
 is the issue.  I understand you can't please everyone, but you shouldn't 
 use the 'people won't like it' argument without real evidence or proof.
I agree that ++array may not be easily confused with ++array[]. The situation I am trying to help is improve on a mistake in the C language design that we got so used to, we actually think it's the right thing.
According to comments on this newsgroup, and some quoted bug reports, many believe that it's the D methodology of not requiring parentheses that is a mistake. As far as I can tell, it's a matter of opinion, not fact.
 Not that I care too much :)  I am also in the camp of 'defined 
 properties should be a language feature,' but I admit to using 
 D-properties quite often.

 The two things that bug me the most about D property syntax:

 stuff like this:

 x;

 What the hell does this mean?  It looks like it does nothing.  But it 
 could be a function call.  If explicit properties were required, and x 
 was defined as a function, not a property, then x; would be a syntax 
 error.
And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
The advantage is not to you, it is to the reader of your code. writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property.
Aside from just saying it, do you have any substantive argument?
The arguments have been made. As I stated, it's my opinion.
 I routinely use Tango's Stdout.newline; which I admit goes against what I 
 am saying, but it's because I know what Stdout.newline does, and that it 
 is a function.  I would gladly change everything to Stdout.newline() if 
 it was required.
To what benefit? You seem to be using it today, and that makes your own style incongruent with your argument, yet surely you'd change the style in an iffy if you thought it has serious drawbacks.
The benefit is clarity. Stdout.newline; looks like a property or field of Stdout. By itself, it's somewhat jarring, but it's somewhat clear that newline is a function if you know the rules of D. However, something like this isn't so clear: Stdout.newline.formatln("Hi there {}", var); Is newline a property of Stdout, on which I'm calling formatln, or is newline a function that I'm calling, and then using the result of that function to call formatln? Compare with: Stdout.newline().formatln("Hi there {}", var); There is no ambiguity. newline is clearly a function, not a property. My personal habits are ones I would like to change. I'd prefer to write clearer code, not shorter code. I consider writing Stdout.newline; a bad habit fostered by the lax function calling rules of D ;)
 The problem is not that you or anyone might forget that writeln is a 
 function and not a property, the problem is when you start using the 
 property syntax to call functions that aren't so standard, someone 
 reading the code will be confused as to what the code is supposed to do.

 The advantage is, you are able to define how a symbol behaves, what the 
 rules are for using it.  It makes for clearer code.
I am not sure.
Neither answer is definitely the 'correct' one, there are tradeoffs between both styles. I like the how D properties are so easy to write, and can be accessed like functions when needed, but I don't like how you can have weird bit, I prefer that method of requiring a formal property definition. -Steve
Sep 29 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
You are assuming that the C language decision to require parentheses for all functions was a design mistake. I would argue that the design was on purpose and correctly served that purpose. The purpose was to remove ambiguity when faced with understanding code without all the context.
I have stated my assumption and its basis.
Forgive me, but I must have missed it. I saw only your assumption (or supposition) that the C designers made a mistake.
My post on 25 Sep 2008 17:58:52 -0500 mentions: "One principle that I consider universal is that a language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. Another that I also consider universal is that the more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle."
 What is the basis of yours?
I don't have any actual proof that they did this on purpose, I wasn't working at Bell labs when C was invented, in fact, I don't even think I was born ;) But it makes logical sense, and still does. If you want to call a function, you have to use parentheses. If you want to access the function address, no parentheses.
This is no logic. Your proof is just stating the conclusion. It's a logical fallacy called proof by assertion. http://en.wikipedia.org/wiki/Proof_by_assertion
 It follows other design decisions they made:
 
 pointers:  Access what it's pointing to, use ->, get address it's pointing 
 to, use symbol alone.
This is wrong too. If you use symbol alone, you are not getting its address. You are referring the pointer, which is an address. It would have been consistent with other design decisions if referring a variable alone would take its address.
 But that isn't even the questioned practice here.  C designers didn't 
 even come across the question of whether an accessor-property should 
 imply no changes to the object, because they don't have properties.  The 
 real problem is that no matter how you define next(), you can use it in a 
 way which makes it appear like an accessor, not a function which modifies 
 the object.  The source of the problem is D's lack of expressiveness, 
 where I cannot define whether a function cannot be used as a property.
I understand your argument, but it hinges on its own definitions and assumptions. You define "accessor" and then complain that something looks like one unexpectedly. Well in some languages a.b does not change anything. In others it does. What gives?
There is no hard-fast rule that an accessor cannot change things. The issue is that since any function can be an accessor you can't even try to adopt a policy in your library that says 'accessors will not change things'. Because you can't define which functions can be used as accessors and which ones can't.
Const takes care of that.
 I WANT a.b to be able to be a function call, I just want to specify which 
 functions can be called that way, and which ones cannot, so I can define how 
 my library behaves and someone reading code that uses it will know that my 
 rules were followed.
Why do you want to specify that? What difference does it make? Why would you complicate the language just for a hypothetical convention that's not even compiler-checked?
 Even with a true property definition syntax, you cannot prevent someone 
 from changing an object while inside an accessor, that should be defined 
 by the constancy of the object in question.  But indicating that it is 
 preferred to use the property-style means to access the next() member 
 function seems to be misleading to some people.
So that further weakens your argument.
How so? I'm not talking about whether or not the compiler should restrict the developer on being able to make changes in accessors. That is what const is for. I'm talking about being able to specify a coding convention that says 'accessors shall not change things'. Currently, there's no way to prevent any function from being used as an accessor, so a library developer cannot enforce this rule to people using his library.
I personally think it's great that any function can be used as an accessor. I'd be convinced otherwise presented a good arguments against it. What problems are you foreseeing with not being able to enforce against not using ()?
 The problem I have with your argument is how you used one case to say 
 'this is misleading to people, so it's not a valid solution', and in 
 another case say 'it's only misleading because you are used to it, that 
 doesn't matter.' The assumption of which people are important to please 
 is the issue.  I understand you can't please everyone, but you shouldn't 
 use the 'people won't like it' argument without real evidence or proof.
I agree that ++array may not be easily confused with ++array[]. The situation I am trying to help is improve on a mistake in the C language design that we got so used to, we actually think it's the right thing.
According to comments on this newsgroup, and some quoted bug reports, many believe that it's the D methodology of not requiring parentheses that is a mistake. As far as I can tell, it's a matter of opinion, not fact.
 Not that I care too much :)  I am also in the camp of 'defined 
 properties should be a language feature,' but I admit to using 
 D-properties quite often.

 The two things that bug me the most about D property syntax:

 stuff like this:

 x;

 What the hell does this mean?  It looks like it does nothing.  But it 
 could be a function call.  If explicit properties were required, and x 
 was defined as a function, not a property, then x; would be a syntax 
 error.
And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
The advantage is not to you, it is to the reader of your code. writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property.
Aside from just saying it, do you have any substantive argument?
The arguments have been made. As I stated, it's my opinion.
 I routinely use Tango's Stdout.newline; which I admit goes against what I 
 am saying, but it's because I know what Stdout.newline does, and that it 
 is a function.  I would gladly change everything to Stdout.newline() if 
 it was required.
To what benefit? You seem to be using it today, and that makes your own style incongruent with your argument, yet surely you'd change the style in an iffy if you thought it has serious drawbacks.
The benefit is clarity. Stdout.newline; looks like a property or field of Stdout. By itself, it's somewhat jarring, but it's somewhat clear that newline is a function if you know the rules of D.
But you do use Stdout.newline and the alleged loss in clarity doesn't seem to be phasing you.
 However, something like this isn't so clear:
 
 Stdout.newline.formatln("Hi there {}", var);
 
 Is newline a property of Stdout, on which I'm calling formatln, or is 
 newline a function that I'm calling, and then using the result of that 
 function to call formatln?  Compare with:
 
 Stdout.newline().formatln("Hi there {}", var);
 
 There is no ambiguity.  newline is clearly a function, not a property.
There is no ambiguity either case. You evaluate Stdout.newline. The evaluation yields a value of some type. Then you evaluate formatln against that value. What's missing is the unstated assumption that "if it doesn't have trailing parens, it must be a field". I don't think it is useful to be making that assumption.
 My personal habits are ones I would like to change.  I'd prefer to write 
 clearer code, not shorter code.  I consider writing Stdout.newline; a bad 
 habit fostered by the lax function calling rules of D ;)
Giving the choice of shorter vs. clearer is a false choice, another fallacy if I remember correctly. Put another way, wouldn't you at best write shorter and clearer code?
 The problem is not that you or anyone might forget that writeln is a 
 function and not a property, the problem is when you start using the 
 property syntax to call functions that aren't so standard, someone 
 reading the code will be confused as to what the code is supposed to do.

 The advantage is, you are able to define how a symbol behaves, what the 
 rules are for using it.  It makes for clearer code.
I am not sure.
Neither answer is definitely the 'correct' one, there are tradeoffs between both styles. I like the how D properties are so easy to write, and can be accessed like functions when needed, but I don't like how you can have weird bit, I prefer that method of requiring a formal property definition.
I am not seeing weird code that is there to be deciphered. There is this "writeln = 3" weirdness that I'd love to weed out, but all this required trailing parens stuff simply doesn't have any good argument working in its favor. Andrei
Sep 29 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
You are assuming that the C language decision to require parentheses for all functions was a design mistake. I would argue that the design was on purpose and correctly served that purpose. The purpose was to remove ambiguity when faced with understanding code without all the context.
I have stated my assumption and its basis.
Forgive me, but I must have missed it. I saw only your assumption (or supposition) that the C designers made a mistake.
My post on 25 Sep 2008 17:58:52 -0500 mentions: "One principle that I consider universal is that a language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. Another that I also consider universal is that the more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle."
Hidden in this statement is that you consider () to be semantically meaningless. I see it not as meaningless, but a distinction between what the symbol is supposed to represent. A property should represent a value. A function should represent an action. I'll also note that your basis/proof is not any more proof than mine ;) You just made statements about what you believe, as did I.
 What is the basis of yours?
I don't have any actual proof that they did this on purpose, I wasn't working at Bell labs when C was invented, in fact, I don't even think I was born ;) But it makes logical sense, and still does. If you want to call a function, you have to use parentheses. If you want to access the function address, no parentheses.
This is no logic. Your proof is just stating the conclusion. It's a logical fallacy called proof by assertion.
Sorry, change my statement to 'But it makes sense and still does'. And I never said it was a proof. It's a statement of my reasons behind believing the () decision was on purpose.
 It follows other design decisions they made:

 pointers:  Access what it's pointing to, use ->, get address it's 
 pointing to, use symbol alone.
This is wrong too. If you use symbol alone, you are not getting its address. You are referring the pointer, which is an address. It would have been consistent with other design decisions if referring a variable alone would take its address.
Not really. A function symbol by itself is the address of the function. A pointer symbol by itself is the address of the data it points to. It's the same. I don't think you understood the detail that I stated, 'get address it's pointing to', not 'get address of the pointer'.
 But that isn't even the questioned practice here.  C designers didn't 
 even come across the question of whether an accessor-property should 
 imply no changes to the object, because they don't have properties. 
 The real problem is that no matter how you define next(), you can use 
 it in a way which makes it appear like an accessor, not a function 
 which modifies the object.  The source of the problem is D's lack of 
 expressiveness, where I cannot define whether a function cannot be used 
 as a property.
I understand your argument, but it hinges on its own definitions and assumptions. You define "accessor" and then complain that something looks like one unexpectedly. Well in some languages a.b does not change anything. In others it does. What gives?
There is no hard-fast rule that an accessor cannot change things. The issue is that since any function can be an accessor you can't even try to adopt a policy in your library that says 'accessors will not change things'. Because you can't define which functions can be used as accessors and which ones can't.
Const takes care of that.
If I state that 'all accessors used in my library will not change things,' then how can I enforce this? I can't, if I ever want non-const methods that do not take arguments, because those methods could be called as properties.
 I WANT a.b to be able to be a function call, I just want to specify which 
 functions can be called that way, and which ones cannot, so I can define 
 how my library behaves and someone reading code that uses it will know 
 that my rules were followed.
Why do you want to specify that? What difference does it make? Why would you complicate the language just for a hypothetical convention that's not even compiler-checked?
It allows for (in my opinion) better coding practices that are impossible today. For one, if I restrict a member to being only accessed as a property, it is interchangable with a field later on. I think there have already been many given instances where having a defined property makes it clearer, I'm not going to repeat them all.
 Even with a true property definition syntax, you cannot prevent someone 
 from changing an object while inside an accessor, that should be 
 defined by the constancy of the object in question.  But indicating 
 that it is preferred to use the property-style means to access the 
 next() member function seems to be misleading to some people.
So that further weakens your argument.
How so? I'm not talking about whether or not the compiler should restrict the developer on being able to make changes in accessors. That is what const is for. I'm talking about being able to specify a coding convention that says 'accessors shall not change things'. Currently, there's no way to prevent any function from being used as an accessor, so a library developer cannot enforce this rule to people using his library.
I personally think it's great that any function can be used as an accessor. I'd be convinced otherwise presented a good arguments against it. What problems are you foreseeing with not being able to enforce against not using ()?
I have given good arguments. You seem to dismiss them as failed proofs, but that is your call.
 The problem I have with your argument is how you used one case to say 
 'this is misleading to people, so it's not a valid solution', and in 
 another case say 'it's only misleading because you are used to it, that 
 doesn't matter.' The assumption of which people are important to please 
 is the issue.  I understand you can't please everyone, but you 
 shouldn't use the 'people won't like it' argument without real evidence 
 or proof.
I agree that ++array may not be easily confused with ++array[]. The situation I am trying to help is improve on a mistake in the C language design that we got so used to, we actually think it's the right thing.
According to comments on this newsgroup, and some quoted bug reports, many believe that it's the D methodology of not requiring parentheses that is a mistake. As far as I can tell, it's a matter of opinion, not fact.
 Not that I care too much :)  I am also in the camp of 'defined 
 properties should be a language feature,' but I admit to using 
 D-properties quite often.

 The two things that bug me the most about D property syntax:

 stuff like this:

 x;

 What the hell does this mean?  It looks like it does nothing.  But it 
 could be a function call.  If explicit properties were required, and 
 x was defined as a function, not a property, then x; would be a 
 syntax error.
And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
The advantage is not to you, it is to the reader of your code. writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property.
Aside from just saying it, do you have any substantive argument?
The arguments have been made. As I stated, it's my opinion.
 I routinely use Tango's Stdout.newline; which I admit goes against what 
 I am saying, but it's because I know what Stdout.newline does, and that 
 it is a function.  I would gladly change everything to Stdout.newline() 
 if it was required.
To what benefit? You seem to be using it today, and that makes your own style incongruent with your argument, yet surely you'd change the style in an iffy if you thought it has serious drawbacks.
The benefit is clarity. Stdout.newline; looks like a property or field of Stdout. By itself, it's somewhat jarring, but it's somewhat clear that newline is a function if you know the rules of D.
But you do use Stdout.newline and the alleged loss in clarity doesn't seem to be phasing you.
It does phase me. I sometimes catch myself doing it and add the parentheses.
 However, something like this isn't so clear:

 Stdout.newline.formatln("Hi there {}", var);

 Is newline a property of Stdout, on which I'm calling formatln, or is 
 newline a function that I'm calling, and then using the result of that 
 function to call formatln?  Compare with:

 Stdout.newline().formatln("Hi there {}", var);

 There is no ambiguity.  newline is clearly a function, not a property.
There is no ambiguity either case. You evaluate Stdout.newline. The evaluation yields a value of some type. Then you evaluate formatln against that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
 What's missing is the unstated assumption that "if it doesn't have 
 trailing parens, it must be a field". I don't think it is useful to be 
 making that assumption.
Not in D's current state, which leaves the reader to continually look up what a symbol is until he can hammer into his brain whether a symbol is a function or not.
 My personal habits are ones I would like to change.  I'd prefer to write 
 clearer code, not shorter code.  I consider writing Stdout.newline; a bad 
 habit fostered by the lax function calling rules of D ;)
Giving the choice of shorter vs. clearer is a false choice, another fallacy if I remember correctly. Put another way, wouldn't you at best write shorter and clearer code?
Sure, the shortest clear code I have seen is that with parentheses. There is a point at which shorter becomes less clear, in which case the choice is required. How is that a fallacy?
 The problem is not that you or anyone might forget that writeln is a 
 function and not a property, the problem is when you start using the 
 property syntax to call functions that aren't so standard, someone 
 reading the code will be confused as to what the code is supposed to 
 do.

 The advantage is, you are able to define how a symbol behaves, what the 
 rules are for using it.  It makes for clearer code.
I am not sure.
Neither answer is definitely the 'correct' one, there are tradeoffs between both styles. I like the how D properties are so easy to write, and can be accessed like functions when needed, but I don't like how you can have weird looking code to have to decipher. Having written property definition.
I am not seeing weird code that is there to be deciphered. There is this "writeln = 3" weirdness that I'd love to weed out, but all this required trailing parens stuff simply doesn't have any good argument working in its favor.
I think we're all in agreement about writeln = 3. If this is the only thing that gets fixed, it would be a huge step. I'd prefer full properties, but this at least makes things much clearer. 'simply doesn't have any good argument' is your opinion, not a fact. -Steve
Sep 29 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
Sep 29 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
Sep 29 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
But range.next does modify the object. On what basis do I need to add the trailing parens? Andrei
Sep 29 2008
parent KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
But range.next does modify the object. On what basis do I need to add the trailing parens? Andrei
Well that's why *I* would use range.next() ;)
Sep 29 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us. --bb
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us.
So the logic is: "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff." I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well. An experience anecdote - when I wrote Loki I went for the convention that if a type template argument only accepts built-in types it should be written "class T", otherwise it should be written "typename T". The convention was a failure: lack of compiler enforcement meant that "bugs" would be in there without being noticed (and readers would subsequently complain about inconsistencies), at times it was even unclear whether a template would accept certain built-in types or not and there was no way to check that, etc. A similar fate could happen for that convention. It could be nice, yes, but it could also become a nuisance ("was I expected to put parens here, or not? Hell, nobody seems to care anyway, at least this version of the library."). Andrei
Sep 29 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us.
So the logic is: "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff." I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well.
In what way does that convention/style go against facilitating generic code?
 An experience anecdote - when I wrote Loki I went for the convention 
 that if a type template argument only accepts built-in types it should 
 be written "class T", otherwise it should be written "typename T". The 
 convention was a failure: lack of compiler enforcement meant that "bugs" 
 would be in there without being noticed (and readers would subsequently 
 complain about inconsistencies), at times it was even unclear whether a 
 template would accept certain built-in types or not and there was no way 
 to check that, etc. A similar fate could happen for that convention. It 
 could be nice, yes, but it could also become a nuisance ("was I expected 
 to put parens here, or not? Hell, nobody seems to care anyway, at least 
 this version of the library.").
 
Uh, of course, and that's why we want this convention to be enforced by the language, and not be merely a convention. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us.
So the logic is: "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff." I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well.
In what way does that convention/style go against facilitating generic code?
A generic function writing obj.symbol cannot work across objects that implement symbol as a computed property vs. a field. Andrei
Oct 02 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com> wrote:
 I think the distinction of with and without () is pretty stylistic, 
 because
 the same argument can even be applied to operator overloading (does 
 a=b
 means pointing the variable a to b, or calling a.opAssign(b)?)

 For me, I would use () if the function do modify the object itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us.
So the logic is: "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff." I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well.
In what way does that convention/style go against facilitating generic code?
A generic function writing obj.symbol cannot work across objects that implement symbol as a computed property vs. a field. Andrei
I'm not following. If 'obj.symbol' is syntactically available and is valid code, shouldn't the generic function work ok regardless of whether 'symbol' is a computed property or a field? I mean, what is even the difference from the status quo? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com>
 wrote:
 I think the distinction of with and without () is pretty 
 stylistic, because the same argument can even be applied to
 operator overloading (does a=b means pointing the variable
 a to b, or calling a.opAssign(b)?)
 
 For me, I would use () if the function do modify the object
 itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us.
So the logic is: "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff." I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well.
In what way does that convention/style go against facilitating generic code?
A generic function writing obj.symbol cannot work across objects that implement symbol as a computed property vs. a field. Andrei
I'm not following. If 'obj.symbol' is syntactically available and is valid code, shouldn't the generic function work ok regardless of whether 'symbol' is a computed property or a field?
What I meant is very simple. Generic code benefits from unified syntax. Going with one convention across the board would make generic code simpler. Going with the convention that expensive stuff is with "()" and cheap stuff is without "()" differentiates usage.
 I mean, what is even the difference from the status quo?
The discussion was about how things should behave in the future. If you ask me, I can live with the status quo save for the writeln = 3 which could become a poster child of belittling D. Andrei
Oct 02 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm gmail.com>
 wrote:
 I think the distinction of with and without () is pretty 
 stylistic, because the same argument can even be applied to
 operator overloading (does a=b means pointing the variable
 a to b, or calling a.opAssign(b)?)

 For me, I would use () if the function do modify the object
 itself.
I think the counter-argument to what I just said is that if properties had to be declared explicitly then at least we would know that .y is either a field or else something the designer *intended* to behave like a property. Which does tell us something. It most likely means that it's not an extremely heavy-weight operation, just a lightweight accessor with maybe a little logic on top. That could be wrong, but in that case it's the class designer's fault for misleading us.
So the logic is: "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff." I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well.
In what way does that convention/style go against facilitating generic code?
A generic function writing obj.symbol cannot work across objects that implement symbol as a computed property vs. a field. Andrei
I'm not following. If 'obj.symbol' is syntactically available and is valid code, shouldn't the generic function work ok regardless of whether 'symbol' is a computed property or a field?
What I meant is very simple. Generic code benefits from unified syntax. Going with one convention across the board would make generic code simpler. Going with the convention that expensive stuff is with "()" and cheap stuff is without "()" differentiates usage.
Ah, got it now. I misunderstood the original "So the logic is:" post. But I don't think the idea (from Bill and others) was to omit "()" for all cheap stuff functions, but only for those explicitly made to behave as properties/fields. That way would not hurt generic code, it would be the same as the status quo in that regard. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
KennyTM~ Wrote:

 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I assume you'd also want parens if the function modified global state? If so, I believe you'd want parens with all impure member function calls. Obviously, we're talking about property getters and not setters. I was told once already that such things are off topic :) I think it's relevant to the spirit of the conversation.
Sep 29 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Jason House wrote:
 KennyTM~ Wrote:
 
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I assume you'd also want parens if the function modified global state? If so, I believe you'd want parens with all impure member function calls.
Right. Therefore if I were to implement property getters I would require it as an immutable (or at least const) method itself. I don't know what's the use of global functions that is pure AND does not take any input.
 Obviously, we're talking about property getters and not setters. I was told
once already that such things are off topic :) I think it's relevant to the
spirit of the conversation.
Sep 30 2008
parent reply Jason House <jason.james.house gmail.com> writes:
KennyTM~ Wrote:

 Jason House wrote:
 KennyTM~ Wrote:
 
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to operator overloading (does a=b means pointing the variable a to b, or calling a.opAssign(b)?) For me, I would use () if the function do modify the object itself.
I assume you'd also want parens if the function modified global state? If so, I believe you'd want parens with all impure member function calls.
Right. Therefore if I were to implement property getters I would require it as an immutable (or at least const) method itself.
Const and immutable functions can modify global state... So I don't think you'd want that. PS: D's const functions don't guarantee they won't modify the object.
 I don't know what's the use of global functions that is pure AND does 
 not take any input.
 
 Obviously, we're talking about property getters and not setters. I was told
once already that such things are off topic :) I think it's relevant to the
spirit of the conversation.
Sep 30 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Jason House wrote:
 
 
 Const and immutable functions can modify global state... So I don't think
you'd want that.
Does "pure" in an object method takes the object itself as input also? If so, then I mean the parenthesis can be omitted if the method is pure. If not, then it has no solution in current D. The problem is I see no official examples in pure object methods. So far I can only find mentioning of pure global functions, or I've overlooked.
 
 PS: D's const functions don't guarantee they won't modify the object.
 
I still can't quite grasp the invariant-madness in D :p Practically I have only used the "in" storage class in parameter list*, invariant methods and .idup for some string-related manipulations. P.S. *: "in" was "invariant scope". When did it changed to "const scope"??
 
 
 
 I don't know what's the use of global functions that is pure AND does 
 not take any input.

 Obviously, we're talking about property getters and not setters. I was told
once already that such things are off topic :) I think it's relevant to the
spirit of the conversation.
Sep 30 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 30 Sep 2008 23:58:14 +0800,
KennyTM~ wrote:
 P.S. *: "in" was "invariant scope". When did it changed to "const
 scope"??
I don't know whether it ever was invariant, but the current implementation is correct IMO: "in" contract means that you guarantee not to change the received object. Const enforces exactly this guarantee. Invariant is more restrictive in that it also requires a guarantee from the caller that the object will never change in the future, therefore disallowing mutable objects for "in" parameters. This contract doesn't quite associate with an "in" keyword to me.
Oct 01 2008
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up.
Yes, but that is not in question. A property method is *meant* to be used like a field, and so it shouldn't matter whether y is a property or field, it should be interchangable. But if y is not meant to be a property, then it is confusing to read x.y.z() and realize that y isn't meant to be used as a property, and might not even do what you are expecting. See the TimeSpan problem that I went through for an example: http://www.dsource.org/projects/tango/ticket/1184 This problem would never occur if you could not just call any function as a property. -Steve
Sep 29 2008
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
One thing that I've found especially annoying about the current implementation is this: x.y = 3; // Working code x.y += 3; // Broken, if x.y is actually a function x.y = x.y + 3; // Ugly work-around I've been bitten by this at least a dozen different times. Having a real property syntax would eliminate cases like that. --benji
Sep 30 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 01 Oct 2008 07:58:20 +0200, Benji Smith <dlanguage benjismith.net>  
wrote:

 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln  
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
One thing that I've found especially annoying about the current implementation is this: x.y = 3; // Working code x.y += 3; // Broken, if x.y is actually a function x.y = x.y + 3; // Ugly work-around I've been bitten by this at least a dozen different times. Having a real property syntax would eliminate cases like that. --benji
It seems we will soon get reference return values, in which case this would no longer be a problem. I have also written a property template that enables things such as that, but it would also benefit immensely from reference return values. -- Simen
Oct 01 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Simen Kjaeraas wrote:
 On Wed, 01 Oct 2008 07:58:20 +0200, Benji Smith 
 <dlanguage benjismith.net> wrote:
 
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
One thing that I've found especially annoying about the current implementation is this: x.y = 3; // Working code x.y += 3; // Broken, if x.y is actually a function x.y = x.y + 3; // Ugly work-around I've been bitten by this at least a dozen different times. Having a real property syntax would eliminate cases like that. --benji
It seems we will soon get reference return values, in which case this would no longer be a problem. I have also written a property template that enables things such as that, but it would also benefit immensely from reference return values.
It's still an issue if we want to support property setters, say class Time { private double seconds; invariant /*pure?*/ double minutes () { return seconds/60.; } void minutes (invariant double x) { seconds = x*60.; } } You cannot return a double& when calling .minutes because it simply does not exist. Therefore, the interpreter have to clever enough to convert t.minutes += 2; into t.minutes = t.minutes + 2; i.e. t.minutes(t.minutes() + 2); if .minutes does not return a reference. A similar problem also exist with .opIndexAssign and .opSliceAssign.
Oct 01 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Simen Kjaeraas wrote:
 On Wed, 01 Oct 2008 07:58:20 +0200, Benji Smith 
 <dlanguage benjismith.net> wrote:

 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
One thing that I've found especially annoying about the current implementation is this: x.y = 3; // Working code x.y += 3; // Broken, if x.y is actually a function x.y = x.y + 3; // Ugly work-around I've been bitten by this at least a dozen different times. Having a real property syntax would eliminate cases like that. --benji
It seems we will soon get reference return values, in which case this would no longer be a problem. I have also written a property template that enables things such as that, but it would also benefit immensely from reference return values.
It's still an issue if we want to support property setters, say class Time { private double seconds; invariant /*pure?*/ double minutes () { return seconds/60.; } void minutes (invariant double x) { seconds = x*60.; } } You cannot return a double& when calling .minutes because it simply does not exist. Therefore, the interpreter have to clever enough to convert t.minutes += 2; into t.minutes = t.minutes + 2; i.e. t.minutes(t.minutes() + 2); if .minutes does not return a reference. A similar problem also exist with .opIndexAssign and .opSliceAssign.
Ah, didn't see your post before I posted a similar argument. Andrei
Oct 01 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"KennyTM~" wrote
 Simen Kjaeraas wrote:
 On Wed, 01 Oct 2008 07:58:20 +0200, Benji Smith 
 <dlanguage benjismith.net> wrote:

 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
One thing that I've found especially annoying about the current implementation is this: x.y = 3; // Working code x.y += 3; // Broken, if x.y is actually a function x.y = x.y + 3; // Ugly work-around I've been bitten by this at least a dozen different times. Having a real property syntax would eliminate cases like that. --benji
It seems we will soon get reference return values, in which case this would no longer be a problem. I have also written a property template that enables things such as that, but it would also benefit immensely from reference return values.
It's still an issue if we want to support property setters, say class Time { private double seconds; invariant /*pure?*/ double minutes () { return seconds/60.; } void minutes (invariant double x) { seconds = x*60.; } } You cannot return a double& when calling .minutes because it simply does not exist. Therefore, the interpreter have to clever enough to convert t.minutes += 2; into t.minutes = t.minutes + 2; i.e. t.minutes(t.minutes() + 2); if .minutes does not return a reference. A similar problem also exist with .opIndexAssign and .opSliceAssign.
Yes yes! vote++ -Steve
Oct 01 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 1, 2008 at 10:58 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "KennyTM~" wrote
 You cannot return a double& when calling .minutes because it simply does
 not exist. Therefore, the interpreter have to clever enough to convert

   t.minutes += 2;

 into

   t.minutes = t.minutes + 2;

 i.e.

   t.minutes(t.minutes() + 2);

 if .minutes does not return a reference. A similar problem also exist with
 .opIndexAssign and .opSliceAssign.
Yes yes! vote++ -Steve
Me too++ --bb
Oct 01 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Simen Kjaeraas wrote:
 On Wed, 01 Oct 2008 07:58:20 +0200, Benji Smith 
 <dlanguage benjismith.net> wrote:
 
 Bill Baxter wrote:
 On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 There is no ambiguity either case. You evaluate Stdout.newline. The
 evaluation yields a value of some type. Then you evaluate formatln 
 against
 that value.
OK, then tell me what this does: x.y.z(); Is y a property/field of x or a function call with no args? I see a benefit to being able to understand a line of code without requiring lots of extra context. I have to do less lookups of the source of a function or property.
The problem with this argument is that unless you disallow properties altogether, you still won't know whether y is actually a field or a call to a property method without looking it up. --bb
One thing that I've found especially annoying about the current implementation is this: x.y = 3; // Working code x.y += 3; // Broken, if x.y is actually a function x.y = x.y + 3; // Ugly work-around I've been bitten by this at least a dozen different times. Having a real property syntax would eliminate cases like that. --benji
It seems we will soon get reference return values, in which case this would no longer be a problem. I have also written a property template that enables things such as that, but it would also benefit immensely from reference return values.
Not quite. Sorry, I woke up all negative this morning :o). Consider the .length property for built-in arrays. Better yet, consider you implement your own array and want to define a .length property. You don't want it to return a reference! You want to have control over the assignment so that you execute the actual array change. What I'd proposed to Walter for a long time is to allow a.b = c to work if a.b = a.b c works. I'm sure people around here will find reasons to dislike that :o). Andrei
Oct 01 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 01 Oct 2008 15:28:36 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Simen Kjaeraas wrote:
  It seems we will soon get reference return values, in which case this  
 would
 no longer be a problem. I have also written a property template that  
 enables
 things such as that, but it would also benefit immensely from reference
 return values.
Not quite. Sorry, I woke up all negative this morning :o). Consider the .length property for built-in arrays. Better yet, consider you implement your own array and want to define a .length property. You don't want it to return a reference! You want to have control over the assignment so that you execute the actual array change. What I'd proposed to Walter for a long time is to allow a.b = c to work if a.b = a.b c works. I'm sure people around here will find reasons to dislike that :o). Andrei
Ah, of course. So that leaves us with the property template. I've got a fairly nice implementation running, but I dislike the syntax. class foo { int _bar; myStruct _baz; mixin property!(_bar, properties.readwrite, barChanged) bar; // This is ugly. mixin property!(_baz, properties.read) baz; void barChanged(int value) { //... } } This supports all manners of operator overloading at the moment. -- Simen
Oct 01 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 02 Oct 2008 03:38:51 +0200, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Wed, 01 Oct 2008 15:28:36 +0200, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Simen Kjaeraas wrote:
  It seems we will soon get reference return values, in which case this  
 would
 no longer be a problem. I have also written a property template that  
 enables
 things such as that, but it would also benefit immensely from reference
 return values.
Not quite. Sorry, I woke up all negative this morning :o). Consider the .length property for built-in arrays. Better yet, consider you implement your own array and want to define a .length property. You don't want it to return a reference! You want to have control over the assignment so that you execute the actual array change. What I'd proposed to Walter for a long time is to allow a.b = c to work if a.b = a.b c works. I'm sure people around here will find reasons to dislike that :o). Andrei
Ah, of course. So that leaves us with the property template. I've got a fairly nice implementation running, but I dislike the syntax. class foo { int _bar; myStruct _baz; mixin property!(_bar, properties.readwrite, barChanged) bar; // This is ugly. mixin property!(_baz, properties.read) baz; void barChanged(int value) { //... } } This supports all manners of operator overloading at the moment.
Though now that I look at it again (it's been a few months since last I worked on it), I see problems with more complex properties. Ah, more for me to code, then. :p -- Simen
Oct 01 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
You are assuming that the C language decision to require parentheses for all functions was a design mistake. I would argue that the design was on purpose and correctly served that purpose. The purpose was to remove ambiguity when faced with understanding code without all the context.
I have stated my assumption and its basis.
Forgive me, but I must have missed it. I saw only your assumption (or supposition) that the C designers made a mistake.
My post on 25 Sep 2008 17:58:52 -0500 mentions: "One principle that I consider universal is that a language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. Another that I also consider universal is that the more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle."
Hidden in this statement is that you consider () to be semantically meaningless. I see it not as meaningless, but a distinction between what the symbol is supposed to represent. A property should represent a value. A function should represent an action.
Sheesh, do I really need to spoonfeed all of this? First I mentioned the principles I quoted above. Then I clearly explained how C's handling of function names breaks these principle, with examples. Please refer to that post. There is nothing hidden my statement.
 I'll also note that your basis/proof is not any more proof than mine ;)  You 
 just made statements about what you believe, as did I.
The note is wrong. I provide the principles as basis. Then I provide proof using that basis. If you want to invalidate that, you need to invalidate my basis, i.e., the principles of language design I am invoking. You are of course free to do that since principles of programming language design are to large extent a subjective matter.
 What is the basis of yours?
I don't have any actual proof that they did this on purpose, I wasn't working at Bell labs when C was invented, in fact, I don't even think I was born ;) But it makes logical sense, and still does. If you want to call a function, you have to use parentheses. If you want to access the function address, no parentheses.
This is no logic. Your proof is just stating the conclusion. It's a logical fallacy called proof by assertion.
Sorry, change my statement to 'But it makes sense and still does'. And I never said it was a proof. It's a statement of my reasons behind believing the () decision was on purpose.
The decision was on purpose, I am sure it wasn't an oversight. It was a poor decision because it breaks the aforementioned principles.
 It follows other design decisions they made:

 pointers:  Access what it's pointing to, use ->, get address it's 
 pointing to, use symbol alone.
This is wrong too. If you use symbol alone, you are not getting its address. You are referring the pointer, which is an address. It would have been consistent with other design decisions if referring a variable alone would take its address.
Not really. A function symbol by itself is the address of the function. A pointer symbol by itself is the address of the data it points to. It's the same. I don't think you understood the detail that I stated, 'get address it's pointing to', not 'get address of the pointer'.
I understood very well. Your point is off by a mile, and getting only farther. Please understand how you are making an elementary mistake. Consider: int x; Then if I only use "x", I am getting x's value (an lvalue in fact), not its address. Now consider: int * x; Then if I only use "x", I am getting x's value, which is the address of an int. In neither case is it possible for x and &x to mean the same thing. For functions some really weird stuff happens: // this is C #include <assert.h> void foo() {} int main() { void (*p1)() = foo; void (*p2)() = &foo; assert(p1 == p2); } So in fact accessing the name of the function and applying the address-of operator to it yield the same thing. That does not happen to pointers and anything else. Accessing any other symbol yields its value, not its address. I hope that clarifies things. Before anyone will point that out, I'll hurry to mention C does have one other instance in which a symbol "decays" to an address: names f fixed-sized arrays decay to the address of their first element. Still for them the address-of operator is not idempotent, and the decision to allow said decaying has good justification given by subtyping. Andrei
Sep 29 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 Hidden in this statement is that you consider () to be semantically 
 meaningless.  I see it not as meaningless, but a distinction between what 
 the symbol is supposed to represent.  A property should represent a 
 value. A function should represent an action.
Sheesh, do I really need to spoonfeed all of this? First I mentioned the principles I quoted above. Then I clearly explained how C's handling of function names breaks these principle, with examples. Please refer to that post. There is nothing hidden my statement.
Sorry, I look at things more simply, and I'm not really into language design theory ;) I didn't realize that calling something a principle meant that it is generally accepted to be fact, my apologies. So I should read your statement as: "a principle that is generally accepted to be universally true by major language design geeks, that I also agree with, is..." I'm not trying to be clever here, I really didn't understand that it was implied. So I agree with your principle, just not that () falls within the category of 'pragmatically or semantically meaningless.' I'd also disagree that the most frequently used construct of calling a function is without parentheses.
 I'll also note that your basis/proof is not any more proof than mine ;) 
 You just made statements about what you believe, as did I.
The note is wrong. I provide the principles as basis. Then I provide proof using that basis. If you want to invalidate that, you need to invalidate my basis, i.e., the principles of language design I am invoking. You are of course free to do that since principles of programming language design are to large extent a subjective matter.
Not really. You provided no proof that your principles apply to this debate, you just stated that they do.
 Sorry, change my statement to 'But it makes sense and still does'.  And I 
 never said it was a proof.  It's a statement of my reasons behind 
 believing the () decision was on purpose.
The decision was on purpose, I am sure it wasn't an oversight. It was a poor decision because it breaks the aforementioned principles.
Respectfully disagree.
 Not really.  A function symbol by itself is the address of the function. 
 A pointer symbol by itself is the address of the data it points to.  It's 
 the same.  I don't think you understood the detail that I stated, 'get 
 address it's pointing to', not 'get address of the pointer'.
I understood very well. Your point is off by a mile, and getting only farther. Please understand how you are making an elementary mistake. Consider: int x; Then if I only use "x", I am getting x's value (an lvalue in fact), not its address. Now consider: int * x; Then if I only use "x", I am getting x's value, which is the address of an int. In neither case is it possible for x and &x to mean the same thing. For functions some really weird stuff happens: // this is C #include <assert.h> void foo() {}
How does this make any difference to whether you can call a function without parentheses or not? You are arguing that for a function defined as foo(), foo; should mean call function foo, and I'm arguing that it should be a syntax error. Neither of us want the C behavior of evaluating to the function address. I think &foo should be the proper method of taking the address of a function, as it is in D. -Steve
Sep 29 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Steven Schveighoffer" wrote
 "Andrei Alexandrescu" wrote
 Not really.  A function symbol by itself is the address of the function. 
 A pointer symbol by itself is the address of the data it points to. 
 It's the same.  I don't think you understood the detail that I stated, 
 'get address it's pointing to', not 'get address of the pointer'.
I understood very well. Your point is off by a mile, and getting only farther. Please understand how you are making an elementary mistake. Consider: int x; Then if I only use "x", I am getting x's value (an lvalue in fact), not its address. Now consider: int * x; Then if I only use "x", I am getting x's value, which is the address of an int. In neither case is it possible for x and &x to mean the same thing. For functions some really weird stuff happens: // this is C #include <assert.h> void foo() {}
How does this make any difference to whether you can call a function without parentheses or not? You are arguing that for a function defined as foo(), foo; should mean call function foo, and I'm arguing that it should be a syntax error. Neither of us want the C behavior of evaluating to the function address. I think &foo should be the proper method of taking the address of a function, as it is in D.
This is what happens when you can't explain yourself correctly. Stop typing your vehement response about how I am an idiot right now :) I realize my mistake in the statements above. I think the problem you cited with how foo is equivalent to &foo in C is bad. I think we are getting sidetracked here, though. The point I really want to state is that foo; shouldn't mean calling a function named foo. I don't think it should mean the address of the function, although it seems consistent with C pointers (IMO, it seems like &foo shouldn't even compile in C if foo means 'address of foo' already). &foo sounds correct to me, "address of foo." Bottom line, I'm not defending the way C takes addresses of functions, but I think the requirement C has to use parentheses to call functions helps to clarify the intentions of the function author, and makes the code clearer. -Steve
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Steven Schveighoffer" wrote
 "Andrei Alexandrescu" wrote
 Not really.  A function symbol by itself is the address of the function. 
 A pointer symbol by itself is the address of the data it points to. 
 It's the same.  I don't think you understood the detail that I stated, 
 'get address it's pointing to', not 'get address of the pointer'.
I understood very well. Your point is off by a mile, and getting only farther. Please understand how you are making an elementary mistake. Consider: int x; Then if I only use "x", I am getting x's value (an lvalue in fact), not its address. Now consider: int * x; Then if I only use "x", I am getting x's value, which is the address of an int. In neither case is it possible for x and &x to mean the same thing. For functions some really weird stuff happens: // this is C #include <assert.h> void foo() {}
How does this make any difference to whether you can call a function without parentheses or not? You are arguing that for a function defined as foo(), foo; should mean call function foo, and I'm arguing that it should be a syntax error. Neither of us want the C behavior of evaluating to the function address. I think &foo should be the proper method of taking the address of a function, as it is in D.
This is what happens when you can't explain yourself correctly. Stop typing your vehement response about how I am an idiot right now :) I realize my mistake in the statements above. I think the problem you cited with how foo is equivalent to &foo in C is bad. I think we are getting sidetracked here, though. The point I really want to state is that foo; shouldn't mean calling a function named foo.
"State" is very accurate, because aside from stating the point you bring nothing to support it.
 I 
 don't think it should mean the address of the function, although it seems 
 consistent with C pointers (IMO, it seems like &foo shouldn't even compile 
 in C if foo means 'address of foo' already).  &foo sounds correct to me, 
 "address of foo."
No. It does NOT seem and is NOT even remotely consistent with C pointers because x is not the same thing as &x for all symbols in C except functions. Please work through this with books and test programs and all, until you fully understand it. It is important.
 Bottom line, I'm not defending the way C takes addresses of functions, but I 
 think the requirement C has to use parentheses to call functions helps to 
 clarify the intentions of the function author, and makes the code clearer.
I agree, and I'd agree even more if you replaced "think" with "believe". I hope you also agree you have brought nothing of significance to support your thought/belief, while you have received plenty against. I also agree that Sergey, Bill, and others did bring up good points in support for the required trailing "()". It would be more fertile to continue discussing those. Andrei
Sep 29 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 "Steven Schveighoffer" wrote
 "Andrei Alexandrescu" wrote
 Not really.  A function symbol by itself is the address of the 
 function. A pointer symbol by itself is the address of the data it 
 points to. It's the same.  I don't think you understood the detail 
 that I stated, 'get address it's pointing to', not 'get address of the 
 pointer'.
I understood very well. Your point is off by a mile, and getting only farther. Please understand how you are making an elementary mistake. Consider: int x; Then if I only use "x", I am getting x's value (an lvalue in fact), not its address. Now consider: int * x; Then if I only use "x", I am getting x's value, which is the address of an int. In neither case is it possible for x and &x to mean the same thing. For functions some really weird stuff happens: // this is C #include <assert.h> void foo() {}
How does this make any difference to whether you can call a function without parentheses or not? You are arguing that for a function defined as foo(), foo; should mean call function foo, and I'm arguing that it should be a syntax error. Neither of us want the C behavior of evaluating to the function address. I think &foo should be the proper method of taking the address of a function, as it is in D.
This is what happens when you can't explain yourself correctly. Stop typing your vehement response about how I am an idiot right now :) I realize my mistake in the statements above. I think the problem you cited with how foo is equivalent to &foo in C is bad. I think we are getting sidetracked here, though. The point I really want to state is that foo; shouldn't mean calling a function named foo.
"State" is very accurate, because aside from stating the point you bring nothing to support it.
Again with the 'nothing to support it'. If you're not going to listen to my arguments, or even acknowledge that I made them, then there really is no point to this discussion.
 I don't think it should mean the address of the function, although it 
 seems consistent with C pointers (IMO, it seems like &foo shouldn't even 
 compile in C if foo means 'address of foo' already).  &foo sounds correct 
 to me, "address of foo."
No. It does NOT seem and is NOT even remotely consistent with C pointers because x is not the same thing as &x for all symbols in C except functions. Please work through this with books and test programs and all, until you fully understand it. It is important.
You are completely misunderstanding the scope of what I'm saying. I'll just leave it at that.
 Bottom line, I'm not defending the way C takes addresses of functions, 
 but I think the requirement C has to use parentheses to call functions 
 helps to clarify the intentions of the function author, and makes the 
 code clearer.
I agree, and I'd agree even more if you replaced "think" with "believe".
Think and believe to me both mean 'This is true in my mind'. If you find one to be more appealing, so be it.
 I hope you also agree you have brought nothing of significance to support 
 your thought/belief, while you have received plenty against.
Again, you are either not paying enough attention, or you refuse to accept my arguments as valid arguments. I'll stop bashing my head against this brick wall of your inability to comprehend or refusal to accept my arguments, and just let this conversation die.
 I also agree that Sergey, Bill, and others did bring up good points in 
 support for the required trailing "()". It would be more fertile to 
 continue discussing those.
If the end result is that it gets fixed, I'm all for it. -Steve
Sep 29 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 No. It does NOT seem and is NOT even remotely consistent with C pointers 
 because x is not the same thing as &x for all symbols in C except 
 functions. Please work through this with books and test programs and all, 
 until you fully understand it. It is important.
You are completely misunderstanding the scope of what I'm saying. I'll just leave it at that.
You said something wrong. I understood what you said, I understood in what way it was wrong, and then I explained to you why it was wrong. How did I completely misunderstood the scope of what you are saying? In what way are pointers to functions consistent with other pointers in C, because in the way you mentioned, they aren't?
 Bottom line, I'm not defending the way C takes addresses of functions, 
 but I think the requirement C has to use parentheses to call functions 
 helps to clarify the intentions of the function author, and makes the 
 code clearer.
I agree, and I'd agree even more if you replaced "think" with "believe".
Think and believe to me both mean 'This is true in my mind'. If you find one to be more appealing, so be it.
Thinking evokes process. Someone starts from a belief A, does some thinking, and reaches B. Then A is a belief and B is a thought resulting from that belief. (Euclidean axioms -> thinking -> sum of angles in a triangle is 180.) A philosopher (http://en.wikipedia.org/wiki/Constantin_Noica) wrote a book on logic that clarifies this relationship beautifully. His thesis is that logic essentially does not bring anything new, it's just a rehash of the beliefs stated in the axioms. To him logic was in a sense "conservation" because it only shuffled facts, not discovering new ones. I _believe_ a language should obey the principles 1 and 2 (economy of syntax and giving syntactic priority to frequent use cases). Based on that belief, I _think_ D should drop the trailing parens. I agree that somebody could _believe_ in some other principles that replace or override mine and then _think_ that keeping trailing parens is a good thing. Sergey did just that by showing us some very good examples when absence of trailing parens leads to ambiguity. Then there is room for meaningful discussion. It is also possible that somebody simply _believes_ the trailing parens should be kept because they make code clearer to them. That's fair too, as long as there is understanding that that belief comes to a certain extent at odds with principles 1 and 2 (which anyone is free to simply not believe). The only place that needs work is when the connection between belief and thought is unclear, or when the belief is simply wrong. Andrei
Sep 29 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 
 I _believe_ a language should obey the principles 1 and 2 (economy of 
 syntax and giving syntactic priority to frequent use cases). Based on 
 that belief, I _think_ D should drop the trailing parens.
 
 I agree that somebody could _believe_ in some other principles that 
 replace or override mine and then _think_ that keeping trailing parens 
 is a good thing. Sergey did just that by showing us some very good 
 examples when absence of trailing parens leads to ambiguity. Then there 
 is room for meaningful discussion.
 
 It is also possible that somebody simply _believes_ the trailing parens 
 should be kept because they make code clearer to them. That's fair too, 
 as long as there is understanding that that belief comes to a certain 
 extent at odds with principles 1 and 2 (which anyone is free to simply 
 not believe).
 
 The only place that needs work is when the connection between belief and 
 thought is unclear, or when the belief is simply wrong.
 
 
 Andrei
Good post. Sergey's argument (which is much more objective than subjective) is not strictly against omitting parenthesis, but rather against ambiguity (the dual possible ways to call zero-args functions), which as has been shown, creates various possibilities for bugs when you mix functions that return delegates. This ambiguity problem would also be resolved if omitting parenthesis would be *the only way* of calling functions with zero-args. Anyways, I also agree with principles 1 and 2. But I also agree with some other principles that sometimes conflict with those first ones (which is what is happening here). And in each such scenario I would have to weight in to see which principle I would give priority. These other principles are: 3 - Consistency of syntax - The same language feature should use the same syntax, with as little variations as possible. This principle fails here because when you have functions with parameters you have to use parenthesis, and only when you don't have arguments you omit the parenthesis. But the zero-args case should not be different from the n-args case. Of course, this could be solved by having a syntax for the n-args case that also doesn't use parenthesis (see my OP after Benji's thread) But most importantly: 4 - Common ground with other programming languages. There are several things that are common with many, if not all, of the mainstream One of them is using parenthesis for calling functions! (See KennyTM's post with the table describing function calling for several languages.) Using parenthesis comes from math. And of that list, only VB 6, Pascal and Perl, have the possibility of omitting parenthesis. And frankly, VB6 and Pascal don't matter since they are pretty much obsolete. And Perl is language with a hack-ish nature, IMO. Even Lisp uses parenthesis for function calling! (even if in a different position, and even if it's pretty much the only syntax it has). This is a subjective principle, I can't tell you to want to like having common ground with other languages, but c'mon... "writeln;"? Seriously?? That's just hideous. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Sergey's argument (which is much more objective than subjective) is not 
 strictly against omitting parenthesis, but rather against ambiguity (the 
 dual possible ways to call zero-args functions), which as has been 
 shown, creates various possibilities for bugs when you mix functions 
 that return delegates. This ambiguity problem would also be resolved if 
 omitting parenthesis would be *the only way* of calling functions with 
 zero-args.
Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
 Anyways, I also agree with principles 1 and 2. But I also agree with 
 some other principles that sometimes conflict with those first ones 
 (which is what is happening here). And in each such scenario I would 
 have to weight in to see which principle I would give priority.
Yes, there are other principles to follow too. And somehow they often participate in a weighted average in many design decisions.
 These other principles are:
 
 3 - Consistency of syntax - The same language feature should use the 
 same syntax, with as little variations as possible.

 This principle fails here because when you have functions with 
 parameters you have to use parenthesis, and only when you don't have 
 arguments you omit the parenthesis. But the zero-args case should not be 
 different from the n-args case. Of course, this could be solved by 
 having a syntax for the n-args case that also doesn't use parenthesis 
 (see my OP after Benji's thread)
Great. Yes, that is consistency. I swear that all I wrote above was before I saw this :o).
 But most importantly:
 4 - Common ground with other programming languages. There are several 
 things that are common with many, if not all, of the mainstream 

 One of them is using parenthesis for calling functions! (See KennyTM's 
 post with the table describing function calling for several languages.) 
 Using parenthesis comes from math. And of that list, only VB 6, Pascal 
 and Perl, have the possibility of omitting parenthesis. And frankly, VB6 
 and Pascal don't matter since they are pretty much obsolete. And Perl is 
 language with a hack-ish nature, IMO. Even Lisp uses parenthesis for 
 function calling! (even if in a different position, and even if it's 
 pretty much the only syntax it has).
 This is a subjective principle, I can't tell you to want to like having 
 common ground with other languages, but c'mon... "writeln;"? Seriously?? 
 That's just hideous.
I agree that 4 is a good principle. I'd even call it "consistency" - feature - properties - to fulfill what was perceived as a need. Also the Cecil language goes as far as requiring accessors for any field (and defining methods implicitly when missing). Eiffel also has properties that are obtained via syntactic conventions (getX and setX implement property x). People want to add properties to Java 7 (unfortunately the google search is clogged by a Java class called Properties so it needs some combing). I use writeln; all over the place, and more importantly obj.method, without finding them hideous. I'm impressed a lot by the analogy with math because it is one extra argument in my favor. In math there's no function without arguments. At most people would say f(.) (with a central dot) when referring to what is akin to the address of the function. Andrei
Oct 02 2008
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Sergey's argument (which is much more objective than subjective) is 
 not strictly against omitting parenthesis, but rather against 
 ambiguity (the dual possible ways to call zero-args functions), which 
 as has been shown, creates various possibilities for bugs when you mix 
 functions that return delegates. This ambiguity problem would also be 
 resolved if omitting parenthesis would be *the only way* of calling 
 functions with zero-args.
Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you). Note that this would not preclude that we implement another way to have properties (see below).
 
 These other principles are:

 3 - Consistency of syntax - The same language feature should use the 
 same syntax, with as little variations as possible.
>
 This principle fails here because when you have functions with 
 parameters you have to use parenthesis, and only when you don't have 
 arguments you omit the parenthesis. But the zero-args case should not 
 be different from the n-args case. Of course, this could be solved by 
 having a syntax for the n-args case that also doesn't use parenthesis 
 (see my OP after Benji's thread)
Great. Yes, that is consistency. I swear that all I wrote above was before I saw this :o).
Good, at least we agree on that after all.
 But most importantly:
 4 - Common ground with other programming languages. There are several 
 things that are common with many, if not all, of the mainstream 

 One of them is using parenthesis for calling functions! (See KennyTM's 
 post with the table describing function calling for several 
 languages.) Using parenthesis comes from math. And of that list, only 
 VB 6, Pascal and Perl, have the possibility of omitting parenthesis. 
 And frankly, VB6 and Pascal don't matter since they are pretty much 
 obsolete. And Perl is language with a hack-ish nature, IMO. Even Lisp 
 uses parenthesis for function calling! (even if in a different 
 position, and even if it's pretty much the only syntax it has).
 This is a subjective principle, I can't tell you to want to like 
 having common ground with other languages, but c'mon... "writeln;"? 
 Seriously?? That's just hideous.
I agree that 4 is a good principle. I'd even call it "consistency" - feature - properties - to fulfill what was perceived as a need. Also the Cecil language goes as far as requiring accessors for any field (and defining methods implicitly when missing). Eiffel also has properties that are obtained via syntactic conventions (getX and setX implement property x). People want to add properties to Java 7 (unfortunately the google search is clogged by a Java class called Properties so it needs some combing).
Yes, I was going to call it "consistency with other programming languages", but renamed it so as to avoid confusion. Anyways, we're not saying a properties feature is not useful. We're not saying to just remove the implicit property function call and be done with that. The suggestion is to *replace* the implicit property function call with some other way for implementing properties, so that we don't have the disadvantages of the implicit property function call.
 Eiffel also has properties
 that are obtained via syntactic conventions (getX and setX implement
 property x)
Hum, interesting, I just replied in another part of the thread with a suggestion that is just like that (and didn't know about it). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bruno Medeiros" wrote
 Andrei Alexandrescu wrote:
 Eiffel also has properties
 that are obtained via syntactic conventions (getX and setX implement
 property x)
Hum, interesting, I just replied in another part of the thread with a suggestion that is just like that (and didn't know about it).
In fact, C++.net did something similar in that if you defined a property x could be called from C++. But the new C++.net is much better, you can actually use and define real properties. I consider this type of thing a hack, that probably shouldn't be used since we are talking about a developing language and not something that has decades of real-world use. I personally think it was one of those Microsoft marketing things where they made C++.net so it could interact with other better ;) But that's just the cynic in me. All that is needed is a keyword to signify that a function is really a property, kind of like 'pure', and enforce the rules that have been discussed. Since D2 is already getting new keywords and is almost backwards-incompatible with existing D1 code, I don't see this as a huge issue. keyword status is not universal): int myproperty { get { return _myprivateproperty; } set { return _myprivateproperty = value; } } In light of some other posts about overloading the set operators, I think actually it might be nicer to define set as a contextual function inside a property: int myproperty { get { return _myprivateproperty; } set(int value) { return _myprivateproperty = value; } set(string value) { return _myprivateproperty = to!(int)(value); } } I'm not a language designer, so I don't know if this falls within the rules The downside is that you can't really take addresses of the set/get functions, or could you with something like &myproperty.set? That would be one reason to make the set/get symbols keywords. -Steve
Oct 02 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Steven Schveighoffer wrote:
 "Bruno Medeiros" wrote
 Andrei Alexandrescu wrote:
 Eiffel also has properties
 that are obtained via syntactic conventions (getX and setX implement
 property x)
Hum, interesting, I just replied in another part of the thread with a suggestion that is just like that (and didn't know about it).
In fact, C++.net did something similar in that if you defined a property x could be called from C++. But the new C++.net is much better, you can actually use and define real properties. I consider this type of thing a hack, that probably shouldn't be used since we are talking about a developing language and not something that has decades of real-world use. I personally think it was one of those Microsoft marketing things where they made C++.net so it could interact with other better ;) But that's just the cynic in me. All that is needed is a keyword to signify that a function is really a property, kind of like 'pure', and enforce the rules that have been discussed. Since D2 is already getting new keywords and is almost backwards-incompatible with existing D1 code, I don't see this as a huge issue.
Just for the record, I didn't present that suggestion because it didn't require a new keyword. I think that's a very weak concern, and as I've said before, I find Walter's current obsession with keyword economy outdated and silly (example: "enum", among others). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Sergey's argument (which is much more objective than subjective) is 
 not strictly against omitting parenthesis, but rather against 
 ambiguity (the dual possible ways to call zero-args functions), which 
 as has been shown, creates various possibilities for bugs when you 
 mix functions that return delegates. This ambiguity problem would 
 also be resolved if omitting parenthesis would be *the only way* of 
 calling functions with zero-args.
Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you).
So there is a cabal. I knew it! :o) I'm not that sure about "lot" and "one", and numbers-based arguments aren't that strong to begin with. Language design is complex and full of tradeoffs. In each decision there are consequences. If we require "()" then we must come with a separate thing for properties - an addition to the language. Then many people (maybe even including some the "lot" of people you mentioned) will cry foul: "where's my simple language?" etc. Maybe some people will say, hey, you were already there with the omittable "()" and the "=" thing, why didn't you just make the latter less trigger happy and we'd be home free? One thing that often is a casualty of these discussion is keeping the eye on the big picture. Andrei
Oct 02 2008
next sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
Here comes another person that would be unhappy without omittable parenthesis.

Having properties is a very useful thing, one should be able to make a 
public field of a structure private and controlling access via methods 
with minimal or no changes to the external code.

This is a very nice feature to have.
D reaches this with a minimal change to the language:
optional parenthesis, and setter functions.

It might take a little to get used coming from other languages, but it 
works well.

It does have some limitation (no +=,-=,...) but is very compact, and 
simple to explain.

I like it very much.

Removing it would be very bad.
The other option is to replace it with a full fledged property mechanism.
This might overcome some of the limitations of the current approach, 
but would it be economical?
A language should not be perfect in all things, compactness is also an 
advantage.

Fawzi

On 2008-10-02 19:26:55 +0200, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Sergey's argument (which is much more objective than subjective) is not 
 strictly against omitting parenthesis, but rather against ambiguity 
 (the dual possible ways to call zero-args functions), which as has been 
 shown, creates various possibilities for bugs when you mix functions 
 that return delegates. This ambiguity problem would also be resolved if 
 omitting parenthesis would be *the only way* of calling functions with 
 zero-args.
Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you).
So there is a cabal. I knew it! :o) I'm not that sure about "lot" and "one", and numbers-based arguments aren't that strong to begin with. Language design is complex and full of tradeoffs. In each decision there are consequences. If we require "()" then we must come with a separate thing for properties - an addition to the language. Then many people (maybe even including some the "lot" of people you mentioned) will cry foul: "where's my simple language?" etc. Maybe some people will say, hey, you were already there with the omittable "()" and the "=" thing, why didn't you just make the latter less trigger happy and we'd be home free? One thing that often is a casualty of these discussion is keeping the eye on the big picture. Andrei
Oct 02 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 3:16 AM, Fawzi Mohamed <fmohamed mac.com> wrote:

 This is a very nice feature to have.
 D reaches this with a minimal change to the language:
 optional parenthesis, and setter functions.

 ...
 It does have some limitation (no +=,-=,...) but is very compact, and simple
 to explain.
Fortunately this is an orthogonal issue. This could (and should IMO) be fixed independent of the current discussion. --bb
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 3:16 AM, Fawzi Mohamed <fmohamed mac.com> wrote:
 
 This is a very nice feature to have.
 D reaches this with a minimal change to the language:
 optional parenthesis, and setter functions.

 ...
 It does have some limitation (no +=,-=,...) but is very compact, and simple
 to explain.
Fortunately this is an orthogonal issue. This could (and should IMO) be fixed independent of the current discussion.
Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o) One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed. Andrei
Oct 02 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 02 Oct 2008 15:03:42 -0500,
Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... 
 any ideas? :o)
 
 One goal is to fix opIndexAssign and make it work similar to the way it 
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good 
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Oct 02 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Indeed. I thought there wasn't a lot of debate needed on this, just action. --bb
Oct 02 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Indeed. I thought there wasn't a lot of debate needed on this, just action.
... except these extras do have the same issue that plain property assignment does. They would open up a new class of things that are valid code but don't behave as expected. writefln += 5. And also, a[b] += c should probably be rewritten as "a.opIndex(b) += c" *if* a returns a reference of some sort. Ok, so maybe there is a little to talk about. :-) --bb
Oct 02 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 3 Oct 2008 09:37:46 +0900,
Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Indeed. I thought there wasn't a lot of debate needed on this, just action.
. ... except these extras do have the same issue that plain property assignment does. They would open up a new class of things that are valid code but don't behave as expected. writefln += 5. And also, a[b] += c should probably be rewritten as "a.opIndex(b) += c" *if* a returns a reference of some sort. Ok, so maybe there is a little to talk about. :-)
I think that any expression "a = b" should first check whether the expression on the left is an lvalue. If yes then use it as any other lvalue, otherwise try to re-write an expression using op Assign. This works in many scenarios, like opIndex returning a reference.
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Fri, 3 Oct 2008 09:37:46 +0900,
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Indeed. I thought there wasn't a lot of debate needed on this, just action.
. ... except these extras do have the same issue that plain property assignment does. They would open up a new class of things that are valid code but don't behave as expected. writefln += 5. And also, a[b] += c should probably be rewritten as "a.opIndex(b) += c" *if* a returns a reference of some sort. Ok, so maybe there is a little to talk about. :-)
I think that any expression "a = b" should first check whether the expression on the left is an lvalue. If yes then use it as any other lvalue, otherwise try to re-write an expression using op Assign. This works in many scenarios, like opIndex returning a reference.
That's a good rule, but a[b] = c on a hash is not helped by it. Andrei
Oct 03 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Sergey Gromov wrote:
 Fri, 3 Oct 2008 09:37:46 +0900,
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly gmail.com> 
 wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way 
 it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Indeed. I thought there wasn't a lot of debate needed on this, just action.
. ... except these extras do have the same issue that plain property assignment does. They would open up a new class of things that are valid code but don't behave as expected. writefln += 5. And also, a[b] += c should probably be rewritten as "a.opIndex(b) += c" *if* a returns a reference of some sort. Ok, so maybe there is a little to talk about. :-)
I think that any expression "a = b" should first check whether the expression on the left is an lvalue. If yes then use it as any other lvalue, otherwise try to re-write an expression using op Assign. This works in many scenarios, like opIndex returning a reference.
That's a good rule, but a[b] = c on a hash is not helped by it.
I think Sergey didn't write his rules correctly. If a is an lvalue, use it as any other lvalue, which *includes* trying op Assign. If a is not an lvalue, then rewrite the expression as a = a b, without expanding operators, then use normal operator expansion to compile the statement. If neither works, then it is a syntax error. This should be valid for all cases. For example a hash that returns a reference for opIndex: a[b] += c; a.opIndex(b) is an lvalue, so try: a.opIndex(b).opAddAssign(c). If that doesn't work, then syntax error. case 2, a[b] is an rvalue: rewrite as a[b] = a[b] + c; expand operators: a.opIndexAssign(a[b] + c, b); a.opIndexAssign(a.opIndex(b) + c, b); An example of a failure: int foo(int x) {...} foo(5) += 6; left side is an rvalue, so try rewriting: foo(5) = foo(5) + 6; syntax error, foo(5) is still an rvalue Any cases that break with these rules? -Steve
Oct 03 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Steven Schveighoffer" wrote
 "Andrei Alexandrescu" wrote
 Sergey Gromov wrote:
 Fri, 3 Oct 2008 09:37:46 +0900,
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly gmail.com> 
 wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way 
 it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Indeed. I thought there wasn't a lot of debate needed on this, just action.
. ... except these extras do have the same issue that plain property assignment does. They would open up a new class of things that are valid code but don't behave as expected. writefln += 5. And also, a[b] += c should probably be rewritten as "a.opIndex(b) += c" *if* a returns a reference of some sort. Ok, so maybe there is a little to talk about. :-)
I think that any expression "a = b" should first check whether the expression on the left is an lvalue. If yes then use it as any other lvalue, otherwise try to re-write an expression using op Assign. This works in many scenarios, like opIndex returning a reference.
That's a good rule, but a[b] = c on a hash is not helped by it.
I think Sergey didn't write his rules correctly. If a is an lvalue, use it as any other lvalue, which *includes* trying op Assign. If a is not an lvalue, then rewrite the expression as a = a b, without expanding operators, then use normal operator expansion to compile the statement. If neither works, then it is a syntax error. This should be valid for all cases. For example a hash that returns a reference for opIndex: a[b] += c; a.opIndex(b) is an lvalue, so try: a.opIndex(b).opAddAssign(c). If that doesn't work, then syntax error. case 2, a[b] is an rvalue: rewrite as a[b] = a[b] + c; expand operators: a.opIndexAssign(a[b] + c, b); a.opIndexAssign(a.opIndex(b) + c, b); An example of a failure: int foo(int x) {...} foo(5) += 6; left side is an rvalue, so try rewriting: foo(5) = foo(5) + 6; syntax error, foo(5) is still an rvalue Any cases that break with these rules?
After thinking about this some more, I don't even thing the rvalue/lvalue check is necessary. Just try: a.op Assign(b); If that doesn't compile under the current rules, try rewriting as: a = a b; If that doesn't compile under the current rules, then it's a syntax error. -Steve
Oct 03 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 9:37 AM, Bill Baxter <wbaxter gmail.com> wrote:
 ... except these extras do have the same issue that plain property
 assignment does.  They would open up a new class of things that are
 valid code but don't behave as expected.  writefln += 5.
Doh, obviously writefln is a bad example there. Imagine a function that takes an int, tries to do something that many times, then returns an int indicating how many times it actually managed to do it. --bb
Oct 02 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 9:37 AM, Bill Baxter <wbaxter gmail.com> wrote:
 ... except these extras do have the same issue that plain property
 assignment does.  They would open up a new class of things that are
 valid code but don't behave as expected.  writefln += 5.
Doh, obviously writefln is a bad example there. Imagine a function that takes an int, tries to do something that many times, then returns an int indicating how many times it actually managed to do it. --bb
How about this? Start trusting programmers not to do nonsensical things. With the possible exception of downs, whose code is delightfully opaque while being wonderfully readable.
Oct 02 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... 
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it 
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good 
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
Oct 03 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask... any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way 
 it works in arrays, e.g. a[b] += c. Indexing into hash tables is a 
 good test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
Glad you brought opIndexAddAssign up. I think a good solution would avoid adding all opIndexXxxAssign functions. I think even opXxxAssign are undesirable. Andrei
Oct 03 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask... any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way 
 it works in arrays, e.g. a[b] += c. Indexing into hash tables is a 
 good test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
Glad you brought opIndexAddAssign up. I think a good solution would avoid adding all opIndexXxxAssign functions. I think even opXxxAssign are undesirable. Andrei
Of course I don't want opIndexAddAssign either ;p.
Oct 03 2008
parent Christopher Wright <dhasenan gmail.com> writes:
KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask... any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the 
 way it works in arrays, e.g. a[b] += c. Indexing into hash tables 
 is a good test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
Glad you brought opIndexAddAssign up. I think a good solution would avoid adding all opIndexXxxAssign functions. I think even opXxxAssign are undesirable. Andrei
Of course I don't want opIndexAddAssign either ;p.
That would be hell on generic programming, too. These would only be useful for collections, which are usually templated for the element type. Then your collection class would look like: static if (SupportsAddition!(T)) { void opIndexAddAssign(T value) { ... } } And then I define a class: class BigInt { void opAddAssign (long i) { ... } } And it all goes to hell. That means you have to do: mixin (AdditionSupport!(T)()); string AdditionSupport(T)() { foreach (method; __traits(getVirtualMethods, T, "opAddAssign")) { // codegen here } } And that only works because of a bug in __traits(getVirtualMethods) that returns final methods. opIndex*Assign is just an unreasonable solution for generic programming.
Oct 04 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 03 Oct 2008 20:59:54 +0800,
KennyTM~ wrote:
 Sergey Gromov wrote:
 What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
No, if you want performance in this particular case you define ref int opIndex() because I think whenever compiler encounters a[x]++ it should first test whether a[x] is an lvalue and if yes use it accordingly. And only if it is not it should fall back to .opIndexAddButProbablyNotAssign() special overloads.
Oct 03 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 11:43 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Fri, 03 Oct 2008 20:59:54 +0800,
 KennyTM~ wrote:
 Sergey Gromov wrote:
 What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
No, if you want performance in this particular case you define ref int opIndex() because I think whenever compiler encounters a[x]++ it should first test whether a[x] is an lvalue and if yes use it accordingly. And only if it is not it should fall back to .opIndexAddButProbablyNotAssign() special overloads.
Yeh, but then you lose encapsulation. That's fine for some cases, like a vector, but in other cases it can be very handy to be able to get a notification any time one of your values changes. You lose that ability once you start handing out pointers to whoever asks for one. --bb
Oct 03 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 4 Oct 2008 04:34:46 +0900,
Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 11:43 PM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Fri, 03 Oct 2008 20:59:54 +0800,
 KennyTM~ wrote:
 Sergey Gromov wrote:
 What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
No, if you want performance in this particular case you define ref int opIndex() because I think whenever compiler encounters a[x]++ it should first test whether a[x] is an lvalue and if yes use it accordingly. And only if it is not it should fall back to .opIndexAddButProbablyNotAssign() special overloads.
Yeh, but then you lose encapsulation. That's fine for some cases, like a vector, but in other cases it can be very handy to be able to get a notification any time one of your values changes. You lose that ability once you start handing out pointers to whoever asks for one.
Your two last posts are very close to what I have on my mind myself, and I agree with your concerns. The 'notification' thing is exactly what's missing. My proposal is quite flexible overall in that opIndex or opIndexLvalue can return a struct implementing all and every op for the underlying type. But it's tedious, bug-prone and not forward-compatible. What is needed is an ability to easily wrap one type with another, exposing the underlying type's functionality as much as possible, but still receiving notifications whenever the underlying object is updated. Now that I write this it doesn't look as smooth as I thought. But anyway, here's how it works: struct TypeWrapper(T) { private T contents; ref T opRef() { return contents; } void postModify() {...} } Here opIndex of your sparse matrix returns this wrapper. The wrapper knows whether it wraps a real element or a zero. It can detect that a real element became zero and remove it from matrix. The opRef works exactly like opCast right now in that it exposes exactly one underlying type. But I hope we'll get a polymorphic opCast at some point so I'm using a different name for this. The postModify is a weird callback which is called after the value received via opRef is modified. Your delegate idea is great in that all the op Assign can be replaced with opModify(T delegate(T) modify), giving you the ultimate notification. Even more than that, the minimal type wrapper could look like this: struct TypeWrapper(T) { private T value; T opCast() { return value; } T opAssign(T v) { value = v; return value; } T opModify(T delegate(T v) mod) { value = mod(value); return value; } T opProduct(T delegate(T v) prod) { return prod(value); } } where opCast is for rvalue usage, opAssign is for pure '=', opModify is for ' =' and opProduct is for any regular unary or binary operators.
Oct 03 2008
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
KennyTM~ wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask... any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way 
 it works in arrays, e.g. a[b] += c. Indexing into hash tables is a 
 good test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
But if the requirement is that it should have the same *meaning* as a.opIndexAssign(b, a.opIndex(b) + c) , then actual implementation for performance can be considered a compiler optimization feature. Just because one piece of code means the same thing as another doesn't mean it has to be implemented the same way, or can't be optimized.
Oct 03 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Charles Hixson wrote:
 KennyTM~ wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to 
 ask... any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way 
 it works in arrays, e.g. a[b] += c. Indexing into hash tables is a 
 good test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
Probably performance. Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1. But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c). (The same idea can be extended to properties and .opSlice() )
But if the requirement is that it should have the same *meaning* as a.opIndexAssign(b, a.opIndex(b) + c) , then actual implementation for performance can be considered a compiler optimization feature. Just because one piece of code means the same thing as another doesn't mean it has to be implemented the same way, or can't be optimized.
That's a good point. Compiler magic can make sure stuff like that gets optimized, but user-defined object cannot benefit of such equivalence. Andrei
Oct 03 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... 
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it 
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good 
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception. Another problem (assuming the above is fixed) is that b will be looked up twice in the hash. Andrei
Oct 03 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 03 Oct 2008 09:02:07 -0500,
Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... 
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it 
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good 
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception. Another problem (assuming the above is fixed) is that b will be looked up twice in the hash.
The latter is not a problem if you always try to use a[b] as an lvalue before trying anything more specific. Though it makes the former even harder to fix. Probably there should be another opIndex for a context where the user expects a non-existent element to be created: ref T opIndexCreate(size_t i) When compiler sees "a[b] += c" it first calculates the type of "a[b]" in an assignment context. In case of indexing it means considering a.opIndexCreate, then a.opIndex, and finally the built-in indexing. Then it checks whether that type is an lvalue or implements the requested assignment operation. If neither is true then compiler falls back to a.opIndexAssign(b, ...) as a special backward-compatibility case.
Oct 03 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Fri, 03 Oct 2008 09:02:07 -0500,
 Andrei Alexandrescu wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... 
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it 
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good 
 test bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception. Another problem (assuming the above is fixed) is that b will be looked up twice in the hash.
The latter is not a problem if you always try to use a[b] as an lvalue before trying anything more specific. Though it makes the former even harder to fix. Probably there should be another opIndex for a context where the user expects a non-existent element to be created: ref T opIndexCreate(size_t i) When compiler sees "a[b] += c" it first calculates the type of "a[b]" in an assignment context. In case of indexing it means considering a.opIndexCreate, then a.opIndex, and finally the built-in indexing. Then it checks whether that type is an lvalue or implements the requested assignment operation. If neither is true then compiler falls back to a.opIndexAssign(b, ...) as a special backward-compatibility case.
Yah, Walter, Bartosz and I discussed this (under the name opIndexLvalue). It does have a problem with sparse arrays. In a sparse array, a[b] = 0 means the array should actually erase slot at position b (or not insert it if it was missing in the first place). This suggests that a more flexible mechanism would be to have a place where the container, the index, and the assigned value are all available to the same function. Andrei
Oct 03 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test
 bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception.
I don't see why you expect a[b] += c to work on a key for which a[b] is undefined. If it's undefined how can you increment it? Unless you've defined your accessor for undefined keys to return some other value. And if it returns some other value then Sergey's rule is fine. Sparse matrices are a good example of a hash-like data-structure that should return a default value (namely zero) for unset keys. For such a sparse matrix a.opIndexAssign(b, a.opIndex(b) + c) will work fine.
 Another problem (assuming the above is fixed) is that b will be looked up
 twice in the hash.
concern then return references. Though, that solution is a little problematic for the sparse matrices. In order to return a reference to an element that didn't previously exist, you must create it. But if you're just scanning through your sparse matrix printing out the values with a[b], you don't expect to end up with a dense matrix full of zeros! In a C++ lib you'd probably provide an lvalue-returning operator[] and another function that returns just an rvalue. Ooh, how about passing in the manipulator = function somehow? Either delegate or template alias param. Example for sparse matrix case: // Called for a[b] = c type operations void opIndexUpdate(void delegate(ref ValueType val) updater, uint idx) { float *ptr = getPtrToElement(idx); // creates new zero element if needed updater(*ptr); // here you can veto the change // or throw an overflow exception // or clamp *ptr // or round it // or whatever you want... } Compiler would generate the different updaters needed for the various = operations. Maybe with a template alias param there'd maybe be better hope of the compiler being able to inline it all, but then you have the no inheritance problem. void opIndexUpdate(alias updater)(uint idx) { float *ptr = getPtrToElement(idx); // creates new zero element if needed updater(*ptr); } --bb
Oct 03 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test
 bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception.
I don't see why you expect a[b] += c to work on a key for which a[b] is undefined. If it's undefined how can you increment it?
Because accessing it as an rvalue is different than accessing it as an lvalue. You just wrote a very sensible post in the same vein!
 Unless you've defined your accessor for undefined keys to return some
 other value.  And if it returns some other value then Sergey's rule is
 fine.
Yah, in that case things would work. I wouldn't dislike it, but I think Walter won't want to make that change.
 Sparse matrices are a good example of a hash-like data-structure that
 should return a default value (namely zero) for unset keys.  For such
 a sparse matrix      a.opIndexAssign(b, a.opIndex(b) + c)   will work
 fine.
Glad you brought sparse arrays up. Yah, it would work if a[b] would return a default value instead of throwing.
 Another problem (assuming the above is fixed) is that b will be looked up
 twice in the hash.
concern then return references.
It's one of the concerns. And there are several solutions that make everything work, including performance.
 Though, that solution is a little problematic for the sparse matrices.
  In order to return a reference to an element that didn't previously
 exist, you must create it.  But if you're just scanning through your
 sparse matrix printing out the values with a[b], you don't expect to
 end up with a dense matrix full of zeros!  In a C++ lib you'd probably
 provide an lvalue-returning operator[] and another function that
 returns just an rvalue.
Exactly.
 Ooh, how about passing in the manipulator  = function somehow?  Either
 delegate or template alias param.
 
 Example for sparse matrix case:
 // Called for  a[b]  = c type operations
 void opIndexUpdate(void delegate(ref ValueType val) updater, uint idx) {
       float *ptr = getPtrToElement(idx);  // creates new zero element if needed
       updater(*ptr);
       // here you can veto the change
       // or throw an overflow exception
       // or clamp *ptr
       // or round it
       //  or whatever you want...
 }
 
 Compiler would generate the different updaters needed for the various
  = operations.
 
 Maybe with a template alias param there'd maybe be better hope of the
 compiler being able to inline it all, but then you have the no
 inheritance problem.
 
 void opIndexUpdate(alias updater)(uint idx) {
       float *ptr = getPtrToElement(idx);  // creates new zero element if needed
       updater(*ptr);
 }
I am very glad you brought up this idea. I think it can work. I brought it up to Walter and Bartosz (in the alias form), and the status was to think about it some more. For whatever reason suggestions are viewed with increased negativity when coming from me around here, so I often wish someone else comes up with it, gets support, Walter implements it, and we all get over with. (That's what I hoped for the property thing, but that didn't go through.) In general, it's much easier to attack an imperfect proposal than to help make it better, and it's all the more enticing when it comes from a perceived authority. (Of course the next logical step is the question "then why didn't you help my proposal? :o)) Andrei
Oct 03 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test
 bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception.
I don't see why you expect a[b] += c to work on a key for which a[b] is undefined. If it's undefined how can you increment it?
Actually I did use it once to count things, so I could just use a[b]++ instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
Oct 03 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to
 ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test
 bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception.
I don't see why you expect a[b] += c to work on a key for which a[b] is undefined. If it's undefined how can you increment it?
Actually I did use it once to count things, so I could just use a[b]++ instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
But D hashmaps don't work like that. I guess std::map in C++ does behave like that, so that could explain why Andrei would expect that behavior from a map data structure. --bb
Oct 03 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to
 ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test
 bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception.
I don't see why you expect a[b] += c to work on a key for which a[b] is undefined. If it's undefined how can you increment it?
Actually I did use it once to count things, so I could just use a[b]++ instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
But D hashmaps don't work like that. I guess std::map in C++ does behave like that, so that could explain why Andrei would expect that behavior from a map data structure.
No, it's not std::map. Actually, much to everyone's confusion, Walter hacked a[b]++ and ++a[b] to automatically insert typeof(a[b]).init at slot b in a if it didn't exist. Try it! Andrei
Oct 03 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 4, 2008 at 12:07 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm gmail.com> wrote:
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Thu, 02 Oct 2008 15:03:42 -0500,
 Andrei Alexandrescu wrote:
 Yah, overloaded ops are due for an overhaul. I'm almost afraid to
 ask...
 any ideas? :o)

 One goal is to fix opIndexAssign and make it work similar to the way
 it
 works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
 test
 bed.
What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
One problem is that for a hashtable that does not have b yet, opIndex will throw an exception.
I don't see why you expect a[b] += c to work on a key for which a[b] is undefined. If it's undefined how can you increment it?
Actually I did use it once to count things, so I could just use a[b]++ instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
But D hashmaps don't work like that. I guess std::map in C++ does behave like that, so that could explain why Andrei would expect that behavior from a map data structure.
No, it's not std::map. Actually, much to everyone's confusion, Walter hacked a[b]++ and ++a[b] to automatically insert typeof(a[b]).init at slot b in a if it didn't exist. Try it! Andrei
Wierd. But yet plain a[b] will still throw an exception? --bb
Oct 03 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Fri, Oct 3, 2008 at 3:16 AM, Fawzi Mohamed <fmohamed mac.com> wrote:

 This is a very nice feature to have.
 D reaches this with a minimal change to the language:
 optional parenthesis, and setter functions.

 ...
 It does have some limitation (no +=,-=,...) but is very compact, and 
 simple
 to explain.
Fortunately this is an orthogonal issue. This could (and should IMO) be fixed independent of the current discussion.
Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o) One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed. Andrei
Agh, this was a clear and good opportunity to fork a new thread. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Fawzi Mohamed wrote:
 Here comes another person that would be unhappy without omittable 
 parenthesis.
 
 Having properties is a very useful thing, one should be able to make a 
 public field of a structure private and controlling access via methods 
 with minimal or no changes to the external code.
 
Like I said before to Andrei, the idea wasn't simply to drop the omittable parenthesis call, but also to find an alternate property mechanism. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Sergey's argument (which is much more objective than subjective) is 
 not strictly against omitting parenthesis, but rather against 
 ambiguity (the dual possible ways to call zero-args functions), 
 which as has been shown, creates various possibilities for bugs when 
 you mix functions that return delegates. This ambiguity problem 
 would also be resolved if omitting parenthesis would be *the only 
 way* of calling functions with zero-args.
Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you).
So there is a cabal. I knew it! :o)
If there is a cabal, it's a pretty lame one... Walter's Inner Circle are the ones with all the power! :o)
 I'm not that sure about "lot" and "one", and numbers-based arguments 
 aren't that strong to begin with. Language design is complex and full of 
 tradeoffs. In each decision there are consequences. If we require "()" 
 then we must come with a separate thing for properties - an addition to 
 the language. Then many people (maybe even including some the "lot" of 
 people you mentioned) will cry foul: "where's my simple language?" etc. 
 Maybe some people will say, hey, you were already there with the 
 omittable "()" and the "=" thing, why didn't you just make the latter 
 less trigger happy and we'd be home free?
 
Yes, we would need an alternate mechanism for properties - an addition to the language. And it's quite true that it's likely there would be disagreement in the "lot of people" about that. But there is only one way to be sure, so we could at least try! Would you and Walter at least consider this, and see if we could find an alternative that satisfies a fair number of people? Try without compromise. In fact, I'm also not a fan of those complex property mechanisms, à lá 'property' keyword: property int foo() { return _foo; }; property void foo(int foo) { _foo = foo; }; The property keyword would make a function callable *only* as a property syntax (either as reading, 'bar = foo;', or as writing, 'foo = 42;'). A function signature which was not adequate for property access would be compile-time error. This proposal fixes the ambiguities issues, and require *minimal changes* to the language, both in terms of syntax and semantics! -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Yes, we would need an alternate mechanism for properties - an addition 
 to the language. And it's quite true that it's likely there would be 
 disagreement in the "lot of people" about that. But there is only one 
 way to be sure, so we could at least try! Would you and Walter at least 
 consider this, and see if we could find an alternative that satisfies a 
 fair number of people? Try without compromise.
What I'd consider is not that important. I do know what Walter's viewpoint is, and that is that there are plenty of bigger rocks to move.
 In fact, I'm also not a fan of those complex property mechanisms, à lá 

 'property' keyword:
 
   property int foo() { return _foo; };
   property void foo(int foo) { _foo = foo; };
 
 The property keyword would make a function callable *only* as a property 
 syntax (either as reading, 'bar = foo;', or as writing, 'foo = 42;'). A 
 function signature which was not adequate for property access would be 
 compile-time error.
 This proposal fixes the ambiguities issues, and require *minimal 
 changes* to the language, both in terms of syntax and semantics!
Then what would obj.fun mean when fun is not a property? Andrei
Oct 03 2008
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 In fact, I'm also not a fan of those complex property mechanisms, à lá 

 'property' keyword:

   property int foo() { return _foo; };
   property void foo(int foo) { _foo = foo; };

 The property keyword would make a function callable *only* as a 
 property syntax (either as reading, 'bar = foo;', or as writing, 'foo 
 = 42;'). A function signature which was not adequate for property 
 access would be compile-time error.
Then what would obj.fun mean when fun is not a property? Andrei
If I understand the proposal correctly, it would be a compile-time error. --benji
Oct 03 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Yes, we would need an alternate mechanism for properties - an addition 
 to the language. And it's quite true that it's likely there would be 
 disagreement in the "lot of people" about that. But there is only one 
 way to be sure, so we could at least try! Would you and Walter at 
 least consider this, and see if we could find an alternative that 
 satisfies a fair number of people? Try without compromise.
What I'd consider is not that important. I do know what Walter's viewpoint is, and that is that there are plenty of bigger rocks to move.
By "taking into consideration" I don't mean that he would implemented it right away. It's clear there are a lot of work being done in other important features. (Still, some of the property proposals, like the one below, could be quite simple if not trivial to implement)
 In fact, I'm also not a fan of those complex property mechanisms, à lá 

 'property' keyword:

   property int foo() { return _foo; };
   property void foo(int foo) { _foo = foo; };

 The property keyword would make a function callable *only* as a 
 property syntax (either as reading, 'bar = foo;', or as writing, 'foo 
 = 42;'). A function signature which was not adequate for property 
 access would be compile-time error.
 This proposal fixes the ambiguities issues, and require *minimal 
 changes* to the language, both in terms of syntax and semantics!
Then what would obj.fun mean when fun is not a property? Andrei
Good question. One option would be for obj.fun to be a compile error, as mentioned. But other yet, and cleaner IMO is for obj.fun to be the delegate value, ie, the same as the current "&obj.fun". The proposal's &obj.fun could be the same as obj.fun, as a deprecated syntax for backward compatibility. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 06 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
I think someone should start a new thread on this? The argument is not 
relation to range design at all, and it's getting very difficult to 
watch this huge thread.

------

Andrei Alexandrescu wrote:
 I agree that 4 is a good principle. I'd even call it "consistency" -

 feature - properties - to fulfill what was perceived as a need.
And the "property" feature, unlike current D, do lift the ambiguity between procedures and properties that we (well, some of us) dislike. I believe we all agree support for property in D is a good thing, but we just hate the current syntax (making f equivalent to f() regardless of what f is). Again, for me, if you can restrict obj.f to be a valid getter only to pure methods (that won't cause any side effect to content of "this") then I'm all set. But probably not the others who demand getters must be fast. :)
 Also the
 Cecil language goes as far as requiring accessors for any field (and
Who uses Cecil? Never heard of it.
 defining methods implicitly when missing). Eiffel also has properties
 that are obtained via syntactic conventions (getX and setX implement
 property x). 
But not making x === x() I afraid. I don't know Eiffel, though.
 People want to add properties to Java 7 (unfortunately the
 google search is clogged by a Java class called Properties so it needs
 some combing). 
There is an explicit "property" keyword in Java and more importantly, properties are accessed using the syntax obj->prop (ugly I know). The problem we concerned do not exist. (Ref: http://www.javalobby.org/java/forums/t88090.html; The Google search keyword is "java-7 property")
 
 I'm impressed a lot by the analogy with math because it is one extra 
 argument in my favor. In math there's no function without arguments. At 
 most people would say f(.) (with a central dot) when referring to what 
 is akin to the address of the function.
 
 
 Andrei
Sorry, in math the normal way to represent a function is to just use the symbol, i.e. f, e.g. chain rule (f o g)' = g' * f' o g. The central dot is used only when the "function" is not represented in the form f(a,b,c,...), e.g. the commutator [.,.] and the mean <.>. I have *never* seen anyone writes f(.). But I don't think we should directly apply math language to a programming language.
Oct 02 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 2:32 AM, KennyTM~ <kennytm gmail.com> wrote:
 Andrei Alexandrescu wrote:
 I'm impressed a lot by the analogy with math because it is one extra
 argument in my favor. In math there's no function without arguments. At most
 people would say f(.) (with a central dot) when referring to what is akin to
 the address of the function.
Sorry, in math the normal way to represent a function is to just use the symbol, i.e. f, e.g. chain rule (f o g)' = g' * f' o g.
Yeh, and that's because in math there *are* no zero argument functions so in math just writing the symbol means essentially "pointer to function", while in D that is &f. At best the math precedent argues that f() should be illegal and plain f should be the only way to evaluate this thing-that-is-not-a-function-because-it-takes-no-arguments, but I don't think that's what Andrei really wants.
 The central dot is used only when the "function" is not represented in the
 form f(a,b,c,...), e.g. the commutator [.,.] and the mean <.>. I have
 *never* seen anyone writes f(.).
I have, when talking about functionals (functions of functions). Something like g(f(., .)). I think the point was to remind the reader that the argument f is really a function and show how many arguments it takes, without implying that you're evaluating it. Maybe that's what Andrei was trying to say by "taking the address". But I've forgotten what the point of this was. --bb
Oct 02 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruno Medeiros wrote:
  And of that list, only VB 6, Pascal 
 and Perl, have the possibility of omitting parenthesis. 
Correction, Ruby allows it as well. Hum. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 Hidden in this statement is that you consider () to be semantically 
 meaningless.  I see it not as meaningless, but a distinction between what 
 the symbol is supposed to represent.  A property should represent a 
 value. A function should represent an action.
Sheesh, do I really need to spoonfeed all of this? First I mentioned the principles I quoted above. Then I clearly explained how C's handling of function names breaks these principle, with examples. Please refer to that post. There is nothing hidden my statement.
Sorry, I look at things more simply, and I'm not really into language design theory ;) I didn't realize that calling something a principle meant that it is generally accepted to be fact, my apologies. So I should read your statement as: "a principle that is generally accepted to be universally true by major language design geeks, that I also agree with, is..." I'm not trying to be clever here, I really didn't understand that it was implied.
No, you shouldn't read it that way. (Explanation below.)
 So I agree with your principle, just not that () falls within the category 
 of 'pragmatically or semantically meaningless.'
I'd also disagree with that, and I never said that either. What I said was that in C use of a function name alone is syntactically valid, semantically a no-op, and consequently pragmatically meaningless.
 I'd also disagree that the most frequently used construct of calling a 
 function is without parentheses.
I'd also disagree with that, and I never said that either. My perception is that there is a serious "barrier in miscommunication" out there. What I said was that the most frequent use of a function is to call it. Therefore it is a pity that mentioning its name not only does not call it, but in fact does nothing.
 I'll also note that your basis/proof is not any more proof than mine ;) 
 You just made statements about what you believe, as did I.
The note is wrong. I provide the principles as basis. Then I provide proof using that basis. If you want to invalidate that, you need to invalidate my basis, i.e., the principles of language design I am invoking. You are of course free to do that since principles of programming language design are to large extent a subjective matter.
Not really. You provided no proof that your principles apply to this debate, you just stated that they do.
No, you don't understand. Let me explain again. I stated two principles of language design. They could be true or false. They are up there for debate. They are subjective, because aside from some basics, language design is subjective. The principles are: 1) A language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. 2) The more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle. Then based on the principles I explained how C's use of function names breaks them in the post on Thu, 25 Sep 2008 22:59:04 +0000 (UTC). It's easy, really.
 Sorry, change my statement to 'But it makes sense and still does'.  And I 
 never said it was a proof.  It's a statement of my reasons behind 
 believing the () decision was on purpose.
The decision was on purpose, I am sure it wasn't an oversight. It was a poor decision because it breaks the aforementioned principles.
Respectfully disagree.
Now you either disagree with the principles, the consequences, or the way the consequences derive from the principles. My understanding is that the problem is with the latter. Again I am referring you to that same post.
 Not really.  A function symbol by itself is the address of the function. 
 A pointer symbol by itself is the address of the data it points to.  It's 
 the same.  I don't think you understood the detail that I stated, 'get 
 address it's pointing to', not 'get address of the pointer'.
I understood very well. Your point is off by a mile, and getting only farther. Please understand how you are making an elementary mistake. Consider: int x; Then if I only use "x", I am getting x's value (an lvalue in fact), not its address. Now consider: int * x; Then if I only use "x", I am getting x's value, which is the address of an int. In neither case is it possible for x and &x to mean the same thing. For functions some really weird stuff happens: // this is C #include <assert.h> void foo() {}
How does this make any difference to whether you can call a function without parentheses or not? You are arguing that for a function defined as foo(), foo; should mean call function foo, and I'm arguing that it should be a syntax error. Neither of us want the C behavior of evaluating to the function address. I think &foo should be the proper method of taking the address of a function, as it is in D.
I am glad this partially took care of itself. Andrei
Sep 29 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or false. 
 They are up there for debate. They are subjective, because aside from 
 some basics, language design is subjective.
 
 The principles are:
 
 1) A language should minimize the number of syntactic constructs that 
 are semantically and/or pragmatically meaningless.
 
 2) The more frequently-used constructs should be given syntactic 
 priority over the less-used constructs, particularly when the latter are 
 also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
Sep 30 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or 
 false. They are up there for debate. They are subjective, because 
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that 
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic 
 priority over the less-used constructs, particularly when the latter 
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics.
Consistency is good, but that's not consistency. http://www.merriam-webster.com/dictionary/consistency agreement or harmony of parts or features to one another or a whole : correspondence ; specifically : ability to be asserted together without contradiction An example of consistency is that user-defined operators have the same syntax and precedence as built-in operators.
 Based on that principle, I'd argue that function-calling should either 
 always use parentheses, or it should never use parentheses.
Yah I'd like that too. It's economy of syntax.
 Requiring parentheses for some function calls, but not for others 
 violates the principle of consistency.
No. It violates economy of syntax. There are many syntaxes for the same semantics. (I'll also note that Perl does not abide to economy of syntax - see Tim Toady and all that.)
 In my prioritization of language-design principles, consistency is more 
 important then syntactic economy.
Mine too. You just got a few terms jumbled.
 Based on those principles, I believe that the parentheses should be 
 mandatory for all function calls.
That needs revision. Andrei
Oct 01 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or 
 false. They are up there for debate. They are subjective, because 
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that 
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic 
 priority over the less-used constructs, particularly when the latter 
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics.
Consistency is good, but that's not consistency. http://www.merriam-webster.com/dictionary/consistency agreement or harmony of parts or features to one another or a whole : correspondence ; specifically : ability to be asserted together without contradiction
The concept of "consistency" has a more specialized meaning when applied to language design. (just has it has in other fields, like mathematics) So I agree with benji that not having "The expression of a semantic construct should always use the same syntax" is not being consistent. (There are of course other situations where things can be inconsistent.) If you don't agree with this definition of "consistency", I'm not gonna argue with that , just substitute it with "conzistency" or "foobar", or whatever and proceed.
 An example of consistency is that user-defined operators have the same
 syntax and precedence as built-in operators.
 
 Based on that principle, I'd argue that function-calling should either 
 always use parentheses, or it should never use parentheses.
Yah I'd like that too. It's economy of syntax.
Then why are you not suggesting, or campaigning for, such change?
 Requiring parentheses for some function calls, but not for others 
 violates the principle of consistency.
No. It violates economy of syntax. There are many syntaxes for the same semantics.
It violates consistency, as defined above. It may violate economy of syntax as well (or it may be the same thing). Whatever. What I ask is, what would you suggest to fix it? Should all function calling not use parenthesis? And how would that syntax be? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or 
 false. They are up there for debate. They are subjective, because 
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs 
 that are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic 
 priority over the less-used constructs, particularly when the latter 
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics.
Consistency is good, but that's not consistency. http://www.merriam-webster.com/dictionary/consistency agreement or harmony of parts or features to one another or a whole : correspondence ; specifically : ability to be asserted together without contradiction
The concept of "consistency" has a more specialized meaning when applied to language design. (just has it has in other fields, like mathematics) So I agree with benji that not having "The expression of a semantic construct should always use the same syntax" is not being consistent. (There are of course other situations where things can be inconsistent.)
No. Not at all. For consistency you must assert together something with something else. If there are two possible and equivalent syntaxes for a feature that's not lack of consistency. It's waste. We'd be talking about consistency if at most "syntax in context A should be the same as syntax in context B". But if the context is irrelevant to the syntax then we're not quite talking about consistency. Let me give another example. One could say in C++ overloading template functions is inconsistent with overloading regular functions because they follow very different rules. The fact that in C++ you can specify either "class" or "typename" for a template parameter is NOT inconsistent. It is wasteful.
 If you don't agree with this definition of "consistency", I'm not gonna 
 argue with that , just substitute it with "conzistency" or "foobar", or 
 whatever and proceed.
No. Defining terms is important. If we have the wrong terms in mind when talking about something, communication is impeded.
 An example of consistency is that user-defined operators have the same
 syntax and precedence as built-in operators.

 Based on that principle, I'd argue that function-calling should 
 either always use parentheses, or it should never use parentheses.
Yah I'd like that too. It's economy of syntax.
Then why are you not suggesting, or campaigning for, such change?
Because language design is putting many desiderata in agreement, not following one blindly.
 Requiring parentheses for some function calls, but not for others 
 violates the principle of consistency.
No. It violates economy of syntax. There are many syntaxes for the same semantics.
It violates consistency, as defined above.
No. You can't define a term to mean whatever you want. I mean you can, but then it's hard to communicate.
 It may violate economy of 
 syntax as well (or it may be the same thing). Whatever. What I ask is, 
 what would you suggest to fix it? Should all function calling not use 
 parenthesis? And how would that syntax be?
I'm happy with how things are now except for the assignment that is accepted all to often. I suggested a simple fix for that. Andrei
Oct 02 2008
next sibling parent reply Ian Sakkis <iansakkis thisisnotmyrealemail.com> writes:
Andrei Alexandrescu Wrote:

 No. Not at all. For consistency you must assert together something with 
 something else. If there are two possible and equivalent syntaxes for a 
 feature that's not lack of consistency. It's waste. We'd be talking 
 about consistency if at most "syntax in context A should be the same as 
 syntax in context B". But if the context is irrelevant to the syntax 
 then we're not quite talking about consistency.
Consistency or economy of syntax I think you are avoiding the issue which is that we need something that fulfills our requirements. And those are: * A way to specify that one or two functions behave exactly as a field without ambiguity. (Assignment, reading, taking an address, etc.) * A way to specify that a function doesn't behave as a field: writelfn = 3; * A way to change from field to property and back without silently affecting client code (which might be out of our control). * And some others that I can find right now. Until now the only proposal that fits these requirements involves adding another keyword which you are reluctant to accept. Personally I prefer the python property decorator but I don't think it fares well with the D style: | Property | def name: | def fget(): | def fset(): | def fdel(): suited for D: | public string Name { get; set; } And I don't think that backwards compatibility is an issue on D2. We already have several breaking changes (cost, invariant, et al) and this is an easy one to fix. Cheers. PS: On second reading the post has something of a harsh tone but please be assured that this isn't a personal attack. English isn't my first language.
Oct 02 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ian Sakkis wrote:
 PS: On second reading the post has something of a harsh tone but
 please be assured that this isn't a personal attack. English isn't my
 first language.
Then revision before posting might have been an option. There's no "me" against "we". This is ridiculous. If a cabal was being created, please mail me the application papers. Andrei
Oct 02 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or 
 false. They are up there for debate. They are subjective, because 
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs 
 that are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic 
 priority over the less-used constructs, particularly when the 
 latter are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics.
Consistency is good, but that's not consistency. http://www.merriam-webster.com/dictionary/consistency agreement or harmony of parts or features to one another or a whole : correspondence ; specifically : ability to be asserted together without contradiction
The concept of "consistency" has a more specialized meaning when applied to language design. (just has it has in other fields, like mathematics) So I agree with benji that not having "The expression of a semantic construct should always use the same syntax" is not being consistent. (There are of course other situations where things can be inconsistent.)
No. Not at all. For consistency you must assert together something with something else. If there are two possible and equivalent syntaxes for a feature that's not lack of consistency. It's waste. We'd be talking about consistency if at most "syntax in context A should be the same as syntax in context B". But if the context is irrelevant to the syntax then we're not quite talking about consistency.
I wasn't talking about the two cases of calling a zero-args function with parenthesis, and calling it without parenteshis (the "two possible and equivalent syntaxes for a feature"). That's not inconsistency, it's waste, I agree. I was talking about the two cases of calling a zero-args function ("context A"), and a n-args function ("context B"). So here we can talk about consistency, like you defined: "syntax in context A should be the same as syntax in context B". As such, the syntax for both cases is more consistent if they both use parenthesis.
 
 If you don't agree with this definition of "consistency", I'm not 
 gonna argue with that , just substitute it with "conzistency" or 
 "foobar", or whatever and proceed.
No. Defining terms is important. If we have the wrong terms in mind when talking about something, communication is impeded.
I agree.
 Based on that principle, I'd argue that function-calling should 
 either always use parentheses, or it should never use parentheses.
Yah I'd like that too. It's economy of syntax.
Then why are you not suggesting, or campaigning for, such change?
Because language design is putting many desiderata in agreement, not following one blindly.
I don't get it. What other desiderata are in conflict? Those of other people, or other desiderata of your own? Because when you say "I'd like that too", I read that as meaning that, at least for your own, you would prefer if such change was implemented. (ie, weighting all your concerns, you still prefer the change)
 Requiring parentheses for some function calls, but not for others 
 violates the principle of consistency.
No. It violates economy of syntax. There are many syntaxes for the same semantics.
It violates consistency, as defined above.
No. You can't define a term to mean whatever you want. I mean you can, but then it's hard to communicate.
By "some functions" I meant n-args functions, and by "others" I meant zero-args functions. That gives: "[Putting] parenthesis for n-args function calls, but not for zero-args function calls violates the principle of consistency." So we go back to the first point in this post.
 It may violate economy of syntax as well (or it may be the same 
 thing). Whatever. What I ask is, what would you suggest to fix it? 
 Should all function calling not use parenthesis? And how would that 
 syntax be?
I'm happy with how things are now except for the assignment that is accepted all to often. I suggested a simple fix for that. Andrei
I don't understand that. You stated "It violates economy of syntax.", so it violates your Principle 1 of language design. So how can you be happy with that (apart from the assignment issue)? Does fixing this problem violate some other principle or concern of yours? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 Because language design is putting many desiderata in agreement, not 
 following one blindly.
I don't get it. What other desiderata are in conflict? Those of other people, or other desiderata of your own? Because when you say "I'd like that too", I read that as meaning that, at least for your own, you would prefer if such change was implemented. (ie, weighting all your concerns, you still prefer the change)
It's really simple in fact. For example one desideratum is to not complicate the language unnecessarily. When I said I'd like that, I put aside the obvious cost of burdening the language. (Sorry for being unclear.)
 Requiring parentheses for some function calls, but not for others 
 violates the principle of consistency.
No. It violates economy of syntax. There are many syntaxes for the same semantics.
It violates consistency, as defined above.
No. You can't define a term to mean whatever you want. I mean you can, but then it's hard to communicate.
By "some functions" I meant n-args functions, and by "others" I meant zero-args functions. That gives: "[Putting] parenthesis for n-args function calls, but not for zero-args function calls violates the principle of consistency." So we go back to the first point in this post.
 It may violate economy of syntax as well (or it may be the same 
 thing). Whatever. What I ask is, what would you suggest to fix it? 
 Should all function calling not use parenthesis? And how would that 
 syntax be?
I'm happy with how things are now except for the assignment that is accepted all to often. I suggested a simple fix for that. Andrei
I don't understand that. You stated "It violates economy of syntax.", so it violates your Principle 1 of language design. So how can you be happy with that (apart from the assignment issue)? Does fixing this problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal. Andrei
Oct 02 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Bruno Medeiros wrote:
 I don't understand that. You stated "It violates economy of syntax.", so
  it violates your Principle 1 of language design. So how can you be
 happy with that (apart from the assignment issue)? Does fixing this
 problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal.
I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior. For example: import std.stdio; class C { this( bool delegate() p ) { version( a ) cond = p; version( b ) ptr = p; } version( a ) { bool delegate() cond; } version( b ) { bool delegate() ptr; bool delegate() cond() { return ptr; } } } void main() { bool test() { writefln( "hi" ); return false; } auto c = new C( &test ); if( c.cond() ) writefln( "true" ); } Running version=a prints "hi" while version=b prints "true." If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method. Sean
Oct 02 2008
next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-10-02 20:06:32 +0200, Sean Kelly <sean invisibleduck.org> said:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Bruno Medeiros wrote:
 
 I don't understand that. You stated "It violates economy of syntax.", so
 it violates your Principle 1 of language design. So how can you be
 happy with that (apart from the assignment issue)? Does fixing this
 problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal.
I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior. For example: import std.stdio; class C { this( bool delegate() p ) { version( a ) cond = p; version( b ) ptr = p; } version( a ) { bool delegate() cond; } version( b ) { bool delegate() ptr; bool delegate() cond() { return ptr; } } } void main() { bool test() { writefln( "hi" ); return false; } auto c = new C( &test ); if( c.cond() ) writefln( "true" ); } Running version=a prints "hi" while version=b prints "true." If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method. Sean
Ok this is a good reason to have real properties, a somewhat exotic example (with a delegate one can also wrap the delegate in the functions hew wants to call , and store the wrapped delegate instead of having a property access), but still a good reason. Fawzi
Oct 02 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Bruno Medeiros wrote:
 I don't understand that. You stated "It violates economy of syntax.", so
  it violates your Principle 1 of language design. So how can you be
 happy with that (apart from the assignment issue)? Does fixing this
 problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal.
I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior. For example: import std.stdio; class C { this( bool delegate() p ) { version( a ) cond = p; version( b ) ptr = p; } version( a ) { bool delegate() cond; } version( b ) { bool delegate() ptr; bool delegate() cond() { return ptr; } } } void main() { bool test() { writefln( "hi" ); return false; } auto c = new C( &test ); if( c.cond() ) writefln( "true" ); } Running version=a prints "hi" while version=b prints "true." If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method.
Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned. Andrei
Oct 02 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
 Running version=a prints "hi" while version=b prints "true."  If there
 were
 some way in the language to say "cond() is a property" then this issue
 would
 not be silently introduced when changing cond from a variable to a method.
Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned. Andrei
He mentions your name right there on the description of lazy, though. I always thought it was basically your idea because of that, or at least that you designed it together. Given what you are saying above, you might want to ask him politely to remove your name from that page. --bb
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 Running version=a prints "hi" while version=b prints "true."  If there
 were
 some way in the language to say "cond() is a property" then this issue
 would
 not be silently introduced when changing cond from a variable to a method.
Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned. Andrei
He mentions your name right there on the description of lazy, though. I always thought it was basically your idea because of that, or at least that you designed it together. Given what you are saying above, you might want to ask him politely to remove your name from that page.
I suggested that a function taking a delegate should accept an unadorned expression: void twice(void delegate() fun) { fun(); fun(); } ... int a; twice(++a); // makes a = 2 That has a number of issues itself, which can be worked out. Then somebody (in the newsgroup if I remember correctly) said, well this is fine and dandy, but just add a "lazy" keyword there. He did, and I knew it was a mistake the first time I saw it. Andrei
Oct 02 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Andrei Alexandrescu wrote:
 I suggested that a function taking a delegate should accept an unadorned 
 expression:
 
 void twice(void delegate() fun) { fun(); fun(); }
 ...
 int a;
 twice(++a); // makes a = 2
 
 That has a number of issues itself, which can be worked out. Then 
 somebody (in the newsgroup if I remember correctly) said, well this is 
 fine and dandy, but just add a "lazy" keyword there. He did, and I knew 
 it was a mistake the first time I saw it.
I guess that someone was me (and at the NG, so you remember right). But yea, let's just trivialize all the broken code and surrounding issues :P People actually wanted to burn lazy evaluation on a stack, and my post was merely an attempt on reaching a compromise. And I didn't really say it was all fine and dandy. Why not? Suddenly you got conflicts between: void foo(int delegate()) void foo(int) Apparently some libraries used that. And I don't think that any of my own libs were the issue. So please bear in mind that there were more people behind it and their frustration level was at some point pretty high (along the lines of "Walter keeps releasing new stuff and instead of fixing old issues, breaks fine code. [Expletive deleted] this."). If you had ideas to work it out, it would've been fine time to state them. I'm actually looking forward to the solution for D2.0. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Oct 02 2008
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Sean Kelly wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s 
 article
 Bruno Medeiros wrote:
 I don't understand that. You stated "It violates economy of 
 syntax.", so
  it violates your Principle 1 of language design. So how can you be
 happy with that (apart from the assignment issue)? Does fixing this
 problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal.
I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior. For example: import std.stdio; class C { this( bool delegate() p ) { version( a ) cond = p; version( b ) ptr = p; } version( a ) { bool delegate() cond; } version( b ) { bool delegate() ptr; bool delegate() cond() { return ptr; } } } void main() { bool test() { writefln( "hi" ); return false; } auto c = new C( &test ); if( c.cond() ) writefln( "true" ); } Running version=a prints "hi" while version=b prints "true." If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method.
Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned. Andrei
Hold it right there! Are you saying that the existence of 'lazy' somehow required, or helped justify the existence of the omittable parenthesis functionality? How is that? I think you are accusing innocents ('lazy') or wrongdoing. 'lazy' has nothing to do with the omittable parenthesis functionality, I think they are completely orthogonal. Prove me wrong otherwise. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 03 2008
next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-10-03 12:05:17 +0200, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 Andrei Alexandrescu wrote:
 Sean Kelly wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Bruno Medeiros wrote:
 I don't understand that. You stated "It violates economy of syntax.", so
  it violates your Principle 1 of language design. So how can you be
 happy with that (apart from the assignment issue)? Does fixing this
 problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal.
I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior. For example: import std.stdio; class C { this( bool delegate() p ) { version( a ) cond = p; version( b ) ptr = p; } version( a ) { bool delegate() cond; } version( b ) { bool delegate() ptr; bool delegate() cond() { return ptr; } } } void main() { bool test() { writefln( "hi" ); return false; } auto c = new C( &test ); if( c.cond() ) writefln( "true" ); } Running version=a prints "hi" while version=b prints "true." If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method.
Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned. Andrei
Hold it right there! Are you saying that the existence of 'lazy' somehow required, or helped justify the existence of the omittable parenthesis functionality? How is that? I think you are accusing innocents ('lazy') or wrongdoing. 'lazy' has nothing to do with the omittable parenthesis functionality, I think they are completely orthogonal. Prove me wrong otherwise.
I think that he meant that lazy automatically evaluates a delegate, and that he thinks it is wrong. He said it because he thought that the problem shown by Sean was connected with automatically evaluating a delegate, which it is not, but let's not start another sub-thread... Fawzi
Oct 03 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Hold it right there! Are you saying that the existence of 'lazy' somehow 
 required, or helped justify the existence of the omittable parenthesis 
 functionality? How is that?
 I think you are accusing innocents ('lazy') or wrongdoing. 'lazy' has 
 nothing to do with the omittable parenthesis functionality, I think they 
 are completely orthogonal. Prove me wrong otherwise.
The connection is indirect. Lazy showed that omitting trailing parens after delegate names is not recommended. If trailing parens after delegate names were required, much of the ambiguity mentioned by Sergey would disappear. Andrei
Oct 03 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 Hold it right there! Are you saying that the existence of 'lazy' 
 somehow required, or helped justify the existence of the omittable 
 parenthesis functionality? How is that?
 I think you are accusing innocents ('lazy') or wrongdoing. 'lazy' has 
 nothing to do with the omittable parenthesis functionality, I think 
 they are completely orthogonal. Prove me wrong otherwise.
The connection is indirect. Lazy showed that omitting trailing parens after delegate names is not recommended. If trailing parens after delegate names were required, much of the ambiguity mentioned by Sergey would disappear. Andrei
So your point before was, that you are criticizing lazy because it shows/recommends that trailing parenthesis are not ommited? Then you realize that such is only considered a disadvantage to those that think trailing parenthesis should be omitted in the first place... -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 06 2008
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-10-02 21:13:16 +0200, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Sean Kelly wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Bruno Medeiros wrote:
 I don't understand that. You stated "It violates economy of syntax.", so
  it violates your Principle 1 of language design. So how can you be
 happy with that (apart from the assignment issue)? Does fixing this
 problem violate some other principle or concern of yours?
I think keeping the language simple is also a good goal.
I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior. For example: import std.stdio; class C { this( bool delegate() p ) { version( a ) cond = p; version( b ) ptr = p; } version( a ) { bool delegate() cond; } version( b ) { bool delegate() ptr; bool delegate() cond() { return ptr; } } } void main() { bool test() { writefln( "hi" ); return false; } auto c = new C( &test ); if( c.cond() ) writefln( "true" ); } Running version=a prints "hi" while version=b prints "true." If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method.
Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate.
I think here the problem is different c.cond() in version a evaluates the delegate in version b c.cond() is interpreted as the the omittable parenthesis of the accessor method, and returns the delegate. As (as you want, and I think is reasonable) the delegate is not evaluated. In if it is then interpreted as a logical and gives true (as it is a valid delegate, not null). c.cond()() would give false. So actually automatically evaluating the delegate would actually fix this particular problem (but would indeed introduce many other problems, like how to then get the delegate).
 Walter definitely took the wrong turn down that alley there. And guess 
 what. He got ambushed by the "lazy" keyword right there. I told Walter 
 to not do that "lazy" keyword, he disregarded, but the time will come 
 when that stone will be turned.
 
 
 Andrei
Oct 03 2008
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-03 06:27:24 -0400, Fawzi Mohamed <fmohamed mac.com> said:

 So actually automatically evaluating the delegate would actually fix 
 this particular problem (but would indeed introduce many other 
 problems, like how to then get the delegate).
Hum... it could work a little like references (&) in C++. Basically, if you assign a lazy value to another lazy value, it just copy the delegate. Obviously, you'd need to allow "lazy" as a type modifier everywhere, in the same sense as "ref" could (will?) be made a type modifier acceptable everywhere. void func(lazy int x) { lazy int y = x; // assigns x delegate to y. y; // calls y delegate, which is the same as x. x; // calls x delegate. } We could even extend the concept to create "lazy values", which could work as getters for properties, and disallow parenthesis for them: lazy int func { return 1; } lazy int delegate() deleg { return &func; } int i = func; // calls func. int j = func(); // error, func is lazy and cannot be called with parenthesis. int k = deleg(); // calls deleg(), then evaluate the returned delegate. lazy int x = func; // assigns &func to x. lazy int delegate() y = deleg; // assigns &deleg to y. lazy int z = deleg(); // implicitly creates a delegate for calling deleg() lazily. Doesn't this generalize well? I'm just not sure how to extend this to a syntax for setters though. Ideas? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 03 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls. IMHO, current low usage of delegates is not a reason to keep the current syntax but rather a result of the current syntax. --Yigal
Oct 01 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
Oct 01 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate. so if a delegate contains two pointers (function pointer and context pointer) I'd take the first with & and the other with a property of the delegate as a possible syntax. a delegate should have both a ptr and a context properties. this can be used for example when calling C code. just like you can have a D array and call a C function with C_func(array.ptr, array.length); C_function_which_calls_d_delegate(dg.ptr, dg.context); OR C_function_which_calls_d_delegate(&dg, dg.context); in D code you'd probably use the delegate form more often than the function pointer, at least for regular application coding stuff.
Oct 01 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
Oct 01 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int); are you asking because of C++ pointer-to-member-function types? in C++: int (Test::*)(int); ? You know C++ much better than most of us here (certainly better than me), in your experience, is that distinction useful?
Oct 01 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?
 
 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
Oct 01 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs
 that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the
 latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?

 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
if I understand it correctly, in C++ the type of this is encoded in the signature (as above) and you use obj.*pointer(..); to call the function. this is a possible solution (using the C++ pointer to member function). however, maybe we should use a more python like solution: the signature becomes: int function(Test, int); and this refers to the first argument (just like you pass the "self" in Python). I think i prefer the second option more [ int function(Test, int) ] and it will be easier to use in C. -- Yigal
Oct 01 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs
 that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the
 latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?

 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
if I understand it correctly, in C++ the type of this is encoded in the signature (as above) and you use obj.*pointer(..); to call the function. this is a possible solution (using the C++ pointer to member function). however, maybe we should use a more python like solution: the signature becomes: int function(Test, int); and this refers to the first argument (just like you pass the "self" in Python). I think i prefer the second option more [ int function(Test, int) ] and it will be easier to use in C.
It's great that you are now equipped to appreciate the advantages and disadvantages of various tradeoffs. Maybe a reevaluation of the existing solution would be useful. Andrei
Oct 01 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs
 that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the
 latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?

 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
if I understand it correctly, in C++ the type of this is encoded in the signature (as above) and you use obj.*pointer(..); to call the function. this is a possible solution (using the C++ pointer to member function). however, maybe we should use a more python like solution: the signature becomes: int function(Test, int); and this refers to the first argument (just like you pass the "self" in Python). I think i prefer the second option more [ int function(Test, int) ] and it will be easier to use in C.
It's great that you are now equipped to appreciate the advantages and disadvantages of various tradeoffs. Maybe a reevaluation of the existing solution would be useful. Andrei
my main issue was with the syntax. and I still think it's inconsistent. the only drawback I see with my suggestion is the need to implement this additional feature with method pointers. it adds consistency for the common case (delegates) without limiting any of the current uses. What other cons do you see for my suggestion besides the difficulty to implement?
Oct 01 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be true or
 false. They are up there for debate. They are subjective, because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic constructs
 that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given syntactic
 priority over the less-used constructs, particularly when the
 latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?

 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
if I understand it correctly, in C++ the type of this is encoded in the signature (as above) and you use obj.*pointer(..); to call the function. this is a possible solution (using the C++ pointer to member function). however, maybe we should use a more python like solution: the signature becomes: int function(Test, int); and this refers to the first argument (just like you pass the "self" in Python). I think i prefer the second option more [ int function(Test, int) ] and it will be easier to use in C.
It's great that you are now equipped to appreciate the advantages and disadvantages of various tradeoffs. Maybe a reevaluation of the existing solution would be useful. Andrei
my main issue was with the syntax. and I still think it's inconsistent. the only drawback I see with my suggestion is the need to implement this additional feature with method pointers. it adds consistency for the common case (delegates) without limiting any of the current uses. What other cons do you see for my suggestion besides the difficulty to implement?
I think we're better off with the current state of affairs. Andrei
Oct 01 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be
 true or
 false. They are up there for debate. They are subjective,
 because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic
 constructs
 that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given
 syntactic
 priority over the less-used constructs, particularly when the
 latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?

 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
if I understand it correctly, in C++ the type of this is encoded in the signature (as above) and you use obj.*pointer(..); to call the function. this is a possible solution (using the C++ pointer to member function). however, maybe we should use a more python like solution: the signature becomes: int function(Test, int); and this refers to the first argument (just like you pass the "self" in Python). I think i prefer the second option more [ int function(Test, int) ] and it will be easier to use in C.
It's great that you are now equipped to appreciate the advantages and disadvantages of various tradeoffs. Maybe a reevaluation of the existing solution would be useful. Andrei
my main issue was with the syntax. and I still think it's inconsistent. the only drawback I see with my suggestion is the need to implement this additional feature with method pointers. it adds consistency for the common case (delegates) without limiting any of the current uses. What other cons do you see for my suggestion besides the difficulty to implement?
I think we're better off with the current state of affairs. Andrei
so if I understand you correctly, you don't see any other disadvantages. so it all comes to whether it's worth the time to implement this, on which we appear to disagree. since I'm unable to convince you that [from my POV as a user] it's worth it, I won't write more about it. Thank you for your time discussing this issue. Yigal
Oct 01 2008
parent superdan <super dan.org> writes:
Yigal Chripun Wrote:

 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 I stated two principles of language design. They could be
 true or
 false. They are up there for debate. They are subjective,
 because
 aside from some basics, language design is subjective.

 The principles are:

 1) A language should minimize the number of syntactic
 constructs
 that
 are semantically and/or pragmatically meaningless.

 2) The more frequently-used constructs should be given
 syntactic
 priority over the less-used constructs, particularly when the
 latter
 are also at risk of breaking the first principle.
I'd like to propose another principle of language design: 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics. Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses. Requiring parentheses for some function calls, but not for others violates the principle of consistency. In my prioritization of language-design principles, consistency is more important then syntactic economy. Based on those principles, I believe that the parentheses should be mandatory for all function calls. --benji
I was about to post a very similar post (it's still in my drafts folder) besides fully agreeing with the above, I'll add the following: operator & in D is not consistent. int x; auto y = &x; // y is int* (i.e pointer to int) int func(int); auto f = &func; // consistent with the above: // f's type is - int function(int); i.e function pointer. let's try a class: class Test { int x; int func(int); } auto test = new Test(); auto y = &test.x; // consistent with the above auto g = &test.func; // this is inconsistent! in the above g is a delegate which is not a function pointer. just as int* is different from int[]. you wouldn't expect to get an int[] in the above, would you? a more consistent approach would be to have: - func and obj.method to be treated as delegates, of course for function pointers there should be an implicit cast to delegate. - &func and &obj.method would be strictly function pointers. - using parentheses is mandatory for function calls.
A delegate /is/ a function pointer, more precisely, a pointer to function packed with a pointer to a value. This also seems to reveal a lack of understanding of how class methods work. What function would you make &obj.method point to? Andrei
I understand a delegate as a struct of two pointers as you said so yourself, above. an int[] != int* and so does a delegate != [C like] function pointer. I'd make &obj.method to be the function pointer stored in the delegate.
What is the signature of that function? Andrei
say we have: class Test { int method(int); } auto obj = new Test(); auto fPtr = &obj.method; type of fPtr would be: int function(int); or in C syntax: int (*)(int);
That doesn't stay glued. What is "this" inside the function?
 are you asking because of C++ pointer-to-member-function types?
 in C++: int (Test::*)(int); ?

 You know C++ much better than most of us here (certainly better than
 me), in your experience, is that distinction useful?
C++ pointers to member functions aren't that well designed. But at least they work :o|. Andrei
if I understand it correctly, in C++ the type of this is encoded in the signature (as above) and you use obj.*pointer(..); to call the function. this is a possible solution (using the C++ pointer to member function). however, maybe we should use a more python like solution: the signature becomes: int function(Test, int); and this refers to the first argument (just like you pass the "self" in Python). I think i prefer the second option more [ int function(Test, int) ] and it will be easier to use in C.
It's great that you are now equipped to appreciate the advantages and disadvantages of various tradeoffs. Maybe a reevaluation of the existing solution would be useful. Andrei
my main issue was with the syntax. and I still think it's inconsistent. the only drawback I see with my suggestion is the need to implement this additional feature with method pointers. it adds consistency for the common case (delegates) without limiting any of the current uses. What other cons do you see for my suggestion besides the difficulty to implement?
I think we're better off with the current state of affairs. Andrei
so if I understand you correctly, you don't see any other disadvantages. so it all comes to whether it's worth the time to implement this, on which we appear to disagree. since I'm unable to convince you that [from my POV as a user] it's worth it, I won't write more about it. Thank you for your time discussing this issue. Yigal
way i read it he was tryin' to save you face, but of course you missed that too. just continued making a fool of urself. nothing personal dood. but really u r in a mismatch here. first u make a "proposal" that makes no sense. you can't as much put two and two together in a function sig. the man is patient kind enuff to explain. here you're wrong here you don't make sense here you're talking outta your ass. did you my friend miss a beat. hell no. no ``thank you i'll go study some more'' no ``sorry you was right i was wrong'' no ``let me correct myself'' not even effin' ``oh ok''. wtf man. r u really only mouth and no brain. then who's cocky and holding his tail up. ``so if I understand you correctly, you don't see any other disadvantages''. oxpoop. there are no advantages, that's the problem. poop.
Oct 01 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Yigal Chripun wrote:
 auto test = new Test();
 auto y = &test.x; // consistent with the above
 auto g = &test.func; // this is inconsistent!
 in the above g is a delegate which is not a function pointer.
 just as int* is different from int[]. you wouldn't expect to get an
 int[] in the above, would you?
&obj.method returns a pointer to a method for this instance. &obj.field returns a pointer to a field in this instance. If &obj.method returns a function pointer instead, &obj.field should return an OffsetTypeInfo struct. obj.field returns the value of the field. obj.method returns the result of executing obj.method(). The value of a method is either its return value or the machine code that corresponds with that method; and it's rarely the case that you intend to deal with machine code as data. Additionally, for obj.method to return machine code, D would have to support functions returning static arrays.
 a more consistent approach would be to have:
 - func and obj.method to be treated as delegates, of course for function
 pointers there should be an implicit cast to delegate.
 - &func and &obj.method would be strictly function pointers.
 - using parentheses is mandatory for function calls.
 IMHO, current low usage of delegates is not a reason to keep the current
 syntax but rather a result of the current syntax.
 
 --Yigal
I wasn't aware that delegates were poorly used in D. If I had a use for event-driven design, I'd use delegates all the time. If I did functional programming, likewise.
Oct 01 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 In neither case is it possible for x and &x to mean the same thing. For 
 functions some really weird stuff happens:
One flag that something wacky is going is to look at the compiler code needed to implement it. In DMC, there's the nutty function arraytoptr() which is called from about 30 places in the semantic analysis. It's clearly a special case: /************************** * If e is <array of>, convert it to <pointer to>. * If e is <function>, convert it to <pointer to><function>. */ elem *arraytoptr(elem *e) { type *t; t = e->ET; if (t) { switch (tybasic(t->Tty)) { case TYarray: if (e->Eoper == OPvar && type_isvla(t)) { // It already is a pointer, so just change the type type_settype(&e->ET, newpointer(t->Tnext)); } else if (CPP || !(e->PEFflags & PEFnotlvalue)) // ANSI C 3.2.2 { type *tp = type_ptr(e,t->Tnext); tp->Talternate = t; t->Tcount++; e = el_unat(OPaddr,tp,e); } break; #if TX86 case TYnfunc: case TYnpfunc: case TYnsfunc: case TYnsysfunc: case TYfsysfunc: case TYf16func: case TYfsfunc: case TYifunc: case TYjfunc: #endif case TYffunc: case TYfpfunc: e = exp2_addr(e); break; } } return e; }
Oct 01 2008
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 Stdout.newline.formatln("Hi there {}", var);
 
 Is newline a property of Stdout, on which I'm calling formatln, or is
 newline a function that I'm calling, and then using the result of that
 function to call formatln?  Compare with:
 
 Stdout.newline().formatln("Hi there {}", var);
 
 There is no ambiguity.  newline is clearly a function, not a property.
Interesting. To me both of these things have exactly the same meaning. Perhaps it's because I'm used to D, but I think it's more because I can't count how many times I've seen this pattern in C++: SomeSimgleton::Instance().doSomething(); where Instance() is simply an accessor. In my opinion, "newline" isn't a good function name for what it does because it has no verb. Having no verb makes it look like an accessor much more than the absence or presence of parenthesis. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 29 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Michel Fortin" wrote
 On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" said:

 Stdout.newline.formatln("Hi there {}", var);

 Is newline a property of Stdout, on which I'm calling formatln, or is
 newline a function that I'm calling, and then using the result of that
 function to call formatln?  Compare with:

 Stdout.newline().formatln("Hi there {}", var);

 There is no ambiguity.  newline is clearly a function, not a property.
Interesting. To me both of these things have exactly the same meaning. Perhaps it's because I'm used to D, but I think it's more because I can't count how many times I've seen this pattern in C++: SomeSimgleton::Instance().doSomething(); where Instance() is simply an accessor.
Yes, that is a workaround for not having property constructs available. The intuitive label of 'property' comes from the name of the getter 'Instance'. It screams that you are getting the instance of the class, and it's well accepted as a property. What has happened is that instead of relying on the compiler to enforce what is a property and what is not, you are relying on the interpretation of English words. function. So it would never look like that. In D, properties are equivalent to functions, so you have a choice as to whether to use the parentheses or not. But that isn't the problem, the problem is really that you can call functions as properties.
 In my opinion, "newline" isn't a good function name for what it does 
 because it has no verb. Having no verb makes it look like an accessor much 
 more than the absence or presence of parenthesis.
So newline() seems like a property to you more than 'start a new line'? I suppose I can see that, but consider if you were used to a system where properties *prohibited* parentheses, and functions *required* them. It becomes less about interpretation of English vocabulary and more about compiler-enforced interface. I like that system better. -Steve
Sep 30 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-30 09:42:43 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 "Michel Fortin" wrote
 On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" said:
 
 Stdout.newline.formatln("Hi there {}", var);
 
 Is newline a property of Stdout, on which I'm calling formatln, or is
 newline a function that I'm calling, and then using the result of that
 function to call formatln?  Compare with:
 
 Stdout.newline().formatln("Hi there {}", var);
 
 There is no ambiguity.  newline is clearly a function, not a property.
Interesting. To me both of these things have exactly the same meaning. Perhaps it's because I'm used to D, but I think it's more because I can't count how many times I've seen this pattern in C++: SomeSimgleton::Instance().doSomething(); where Instance() is simply an accessor.
Yes, that is a workaround for not having property constructs available. The intuitive label of 'property' comes from the name of the getter 'Instance'. It screams that you are getting the instance of the class, and it's well accepted as a property. What has happened is that instead of relying on the compiler to enforce what is a property and what is not, you are relying on the interpretation of English words.
But one problem is that the distinction between a accessor (of a property) and a function is often matter to interpretation. In the case above, most likely the Instance() function will create the singleton object if it doesn't exist yet; seen that way it isn't a simple accessor. If you ask if Instance() should be a property or not, you're likely to get different answers from different people. Arguably, there are cases even more ambiguous than this one. The issue I want to bring is that without having a formal definition of what is a property and what is not -- one the compiler can enforce -- people will make different choices, not always coherent with each others, and you may very well find yourself having to call Instance() with parenthesis in one D lib and without parenthesis in another.

 function.  So it would never look like that.
I could, but should I? I'm very interested in your criterions about why Instance would qualify to be a property and not as a function in this case. It's not just me. Just as an example, this article's author doesn't want to decide if Instance() should be a property or not: <http://www.yoda.arachsys.com/csharp/singleton.html> "Note that all of these implementations also use a public static property Instance as the means of accessing the instance. In all cases, the property could easily be converted to a method, with no impact on thread-safety or performance."
 In D, properties are equivalent to functions, so you have a choice as to
 whether to use the parentheses or not.  But that isn't the problem, the
 problem is really that you can call functions as properties.
But what is the difference between a property and a function (beside the syntax?). I can find countless discussions on the net about this; interesting discussions but with no definitive answer. In the end, it all boils down to the author's feeling about his function/property, which may be the opposite from its user's. I'd like very much to quote Bruce Wood from this discussion: <http://bytes.com/forum/thread478064.html> (feel free to comment the quote) """ You see, it's not always so cut-and-dried. On the one hand, if you make something a property, you are implying that getting the information will be quick. So, if getting the information is slow, that is a hint that it shouldn't be a property. On the other hand, you don't want to determine what is a property or not based upon implementation details. By doing so you're letting the internal guts of how your class works leak out into its interface with the outside world. That's bad style. So, something should be a property if it makes sense that it be a property. Certainly, anything that affects the state of the object in a manner more sophisticated than just "set this to that" should be a method. That's painfully obvious. Similarly, an aspect of your class that can be read and set, even if setting it does more than just set a variable, should probably be a property. Reasonably straightfoward. However, sometimes the two design goals above-properties that return results quickly and not letting implementation determine interface-are at odds with each other, and you have to make a judgement call. In the case of my system, I had things that logically should be properties (from an interface point of view) but the object held only keys, not references to the objects themselves, so the "get" on the property has to fetch the object in question from the database. It was an open question whether to code: Supplier theSupplier = stockItem.Supplier; or Supplier theSupplier = stockItem.GetSupplier(); I chose the former, preferring to hide the implementation (holding supplier UID, not supplier itself) rather than let it leak out that getting the supplier was actually a lot of work. In our case it's no problem, because we're a very small shop. In a different situation I """ With the current approach in D, you just don't need to choose, just document what your function/property is doing and be done with it... well you may still have to choose about the name :-), so in a way the argument is still there, but what I mean is that I don't think we really need a black and a white syntax for one concept that may take many shades of gray.
 In my opinion, "newline" isn't a good function name for what it does
 because it has no verb. Having no verb makes it look like an accessor much
 more than the absence or presence of parenthesis.
So newline() seems like a property to you more than 'start a new line'? I suppose I can see that, but consider if you were used to a system where properties *prohibited* parentheses, and functions *required* them. It becomes less about interpretation of English vocabulary and more about compiler-enforced interface. I like that system better.
But I'm still puzzled by what being a property means in opposition as if it was a function. The thing is that the compiler just can't guaranty anything about properties: it's really just another syntax for calling a function, a function the author has classified as a property by some subjective standard, a standard which will often differ between authors. Properties are often touted as an indicator for low-cost functions -- whatever "low-cost" means --, but even this fuzzy standard somewhat hinder the often seeked goal of separating interface and implementation. Without aggreement on a formal definition for properties and compiler enforcability, I find it very difficult to justify a formal syntax for properties. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 01 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 2, 2008 at 1:22 PM, Michel Fortin <michel.fortin michelf.com> wrote:
 On 2008-09-30 09:42:43 -0400, "Steven Schveighoffer" <schveiguy yahoo.com>
 said:

 "Michel Fortin" wrote
 On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" said:

 Stdout.newline.formatln("Hi there {}", var);

 Is newline a property of Stdout, on which I'm calling formatln, or is
 newline a function that I'm calling, and then using the result of that
 function to call formatln?  Compare with:

 Stdout.newline().formatln("Hi there {}", var);

 There is no ambiguity.  newline is clearly a function, not a property.
Interesting. To me both of these things have exactly the same meaning. Perhaps it's because I'm used to D, but I think it's more because I can't count how many times I've seen this pattern in C++: SomeSimgleton::Instance().doSomething(); where Instance() is simply an accessor.
Yes, that is a workaround for not having property constructs available. The intuitive label of 'property' comes from the name of the getter 'Instance'. It screams that you are getting the instance of the class, and it's well accepted as a property. What has happened is that instead of relying on the compiler to enforce what is a property and what is not, you are relying on the interpretation of English words.
But one problem is that the distinction between a accessor (of a property) and a function is often matter to interpretation. In the case above, most likely the Instance() function will create the singleton object if it doesn't exist yet; seen that way it isn't a simple accessor. If you ask if Instance() should be a property or not, you're likely to get different answers from different people. Arguably, there are cases even more ambiguous than this one. The issue I want to bring is that without having a formal definition of what is a property and what is not -- one the compiler can enforce -- people will make different choices, not always coherent with each others, and you may very well find yourself having to call Instance() with parenthesis in one D lib and without parenthesis in another.

 function.  So it would never look like that.
I could, but should I? I'm very interested in your criterions about why Instance would qualify to be a property and not as a function in this case. It's not just me. Just as an example, this article's author doesn't want to decide if Instance() should be a property or not: <http://www.yoda.arachsys.com/csharp/singleton.html> "Note that all of these implementations also use a public static property Instance as the means of accessing the instance. In all cases, the property could easily be converted to a method, with no impact on thread-safety or performance."
 In D, properties are equivalent to functions, so you have a choice as to
 whether to use the parentheses or not.  But that isn't the problem, the
 problem is really that you can call functions as properties.
But what is the difference between a property and a function (beside the syntax?). I can find countless discussions on the net about this; interesting discussions but with no definitive answer. In the end, it all boils down to the author's feeling about his function/property, which may be the opposite from its user's. I'd like very much to quote Bruce Wood from this discussion: <http://bytes.com/forum/thread478064.html> (feel free to comment the quote) """ You see, it's not always so cut-and-dried. On the one hand, if you make something a property, you are implying that getting the information will be quick. So, if getting the information is slow, that is a hint that it shouldn't be a property. On the other hand, you don't want to determine what is a property or not based upon implementation details. By doing so you're letting the internal guts of how your class works leak out into its interface with the outside world. That's bad style. So, something should be a property if it makes sense that it be a property. Certainly, anything that affects the state of the object in a manner more sophisticated than just "set this to that" should be a method. That's painfully obvious. Similarly, an aspect of your class that can be read and set, even if setting it does more than just set a variable, should probably be a property. Reasonably straightfoward. However, sometimes the two design goals above-properties that return results quickly and not letting implementation determine interface-are at odds with each other, and you have to make a judgement call. In the case of my system, I had things that logically should be properties (from an interface point of view) but the object held only keys, not references to the objects themselves, so the "get" on the property has to fetch the object in question from the database. It was an open question whether to code: Supplier theSupplier = stockItem.Supplier; or Supplier theSupplier = stockItem.GetSupplier(); I chose the former, preferring to hide the implementation (holding supplier UID, not supplier itself) rather than let it leak out that getting the supplier was actually a lot of work. In our case it's no problem, because we're a very small shop. In a different situation I """ With the current approach in D, you just don't need to choose, just document what your function/property is doing and be done with it... well you may still have to choose about the name :-), so in a way the argument is still there, but what I mean is that I don't think we really need a black and a white syntax for one concept that may take many shades of gray.
 In my opinion, "newline" isn't a good function name for what it does
 because it has no verb. Having no verb makes it look like an accessor
 much
 more than the absence or presence of parenthesis.
So newline() seems like a property to you more than 'start a new line'? I suppose I can see that, but consider if you were used to a system where properties *prohibited* parentheses, and functions *required* them. It becomes less about interpretation of English vocabulary and more about compiler-enforced interface. I like that system better.
But I'm still puzzled by what being a property means in opposition as if it was a function. The thing is that the compiler just can't guaranty anything about properties: it's really just another syntax for calling a function, a function the author has classified as a property by some subjective standard, a standard which will often differ between authors. Properties are often touted as an indicator for low-cost functions -- whatever "low-cost" means --, but even this fuzzy standard somewhat hinder the often seeked goal of separating interface and implementation. Without aggreement on a formal definition for properties and compiler enforcability, I find it very difficult to justify a formal syntax for properties.
Interesting post. My first thought is what is the formal definition for what should be a struct and what should be a class. That's not a cut-and-dried clear decision either. Either one will generally work. I may think X should be a struct and my users may think it should have been a class. We can both be right. Seems a pretty similar situation. --bb
Oct 01 2008
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-02 01:25:34 -0400, "Bill Baxter" <wbaxter gmail.com> said:

 Interesting post.  My first thought is what is the formal definition
 for what should be a struct and what should be a class.  That's not a
 cut-and-dried clear decision either.  Either one will generally work.
 I may think X should be a struct and my users may think it should have
 been a class.  We can both be right.  Seems a pretty similar
 situation.
Yes, indeed, often both can be right in many situations. That's a very interesting observation in this context. If this were C++, I'd agree that we'd be better with just one of the two because in C++ the *only* difference between a struct and a class is syntaxic (if not to say cosmetic): it's the default protection attribute which you generally override explicity anyway. I sometime find myself want to forward-declare a class from some library (to avoid extra includes in the header file) only to have the compiler tell me it's a struct, or vice-versa, with an error I could live without. In C++, I don't think the addition of the "class" keyword was justified: it doesn't add anything useful beside perhaps marketing advantages -- because "class" sounds more object-oriented than "struct". But we are talking about D, where the situation is different. D classes are well suited for inheritance hierarchies, they can only be passed by reference and are always allocated on the heap[^1]. They are also easy to synchronize with due to their built-in monitor. D structs don't have implicit hidden members (monitor, classinfo pointer) so you can use them to represent any fixed-length memory layout. Structs are easily copied and passed by value too, unlike classes, thanks to the lack of inheritance. Basically, what we have here is two different tools each with different attributes. Sometime, they're easily interchangeable, sometime not and that's why we need both. But each time you have to choose, your choice will (or should) go down to the performance, memory, and flexibility implications of each. Choosing what's best will probably involve evaluating which approach better fits your needs, and this may even be measurable. Compare this with properties which have exactly the same performance, memory, and flexibility implications as regular functions. The only difference between a property and a function is the meaning the author give to it, and that meaning vary between authors and contexts. Which means that from the API user point of view, something being a property or a function doesn't mean much... except of course that the user has to remember if Singleton.Instance is a property or a function before using it, or else suffer some useless compiler errors. [^1]: Except scope classes which are allocated on the stack. But allocating scope classes on the stack is a mere optimisation which happen to be possible when you create a scope object, it doesn't affect the semantics of the language at all. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 02 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 2, 2008 at 8:26 PM, Michel Fortin <michel.fortin michelf.com> wrote:
 Compare this with properties which have exactly the same performance,
 memory, and flexibility implications as regular functions. The only
 difference between a property and a function is the meaning the author give
 to it, and that meaning vary between authors and contexts. Which means that
 from the API user point of view, something being a property or a function
 doesn't mean much... except of course that the user has to remember if
 Singleton.Instance is a property or a function before using it, or else
 suffer some useless compiler errors.
Good points. I think this discussion is diverging a little far from the real raison d'etre for property syntax, though. They are there in the first place not to save the typing of a few () here and there, but to allow a library designer to start with a plain field when that suffices and transition to a function later if that becomes necessary, without breaking client code. And there's where we can invoke a grand principle of software design as Andrei would have us do: * Changing implementation details should not affect client code. Ok I guess that's a software design principle, not language design but I guess I can say the underlying language principle is that the a good language should facilitate good software design. This one has to trump principles about economy of syntax and such, because the point of having a language in the first place is to make writing software easier/better/faster. More specifically this is a case of where we want syntax to facilitate making the transition from a simple field to something with some logic too. So what can we hope to get from the language to support this in the best way possible. These two conclusions seem pretty obvious to me: 1) The "fake" field's behavior should be indistinguishable from real field behavior in as many circumstances as possible. This prevents client code from having to change. This is why things like += on a property should be transformed by the compiler. 2) In situations where behavior does differ from that of a real field, a compiler error should occur at the point of usage. This prevents nasty surprises where code silently starts behaving incorrectly. This suggests that something like attempting to take the address of the field should be a syntax error if the field is turned into a property function. (This probably already happens in most cases since a function pointer won't usually be interchangeable with an int pointer or whatever it was before) Anyway, the point I want to make is that while it's neat that you can save typing a few parentheses, there are more important things, like being able to refactor code locally and knowing with reasonable certainty that all client code will either still work correctly or fail to compile. Going by these principles could lead to some interesting conclusions like for instance an argument that you shouldn't be able to take the address of a property function, or do anything else to it that exposes the fact that it is not, in fact, a field. --bb
Oct 02 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Oct 2, 2008 at 8:26 PM, Michel Fortin <michel.fortin michelf.com>
wrote:
 Compare this with properties which have exactly the same performance,
 memory, and flexibility implications as regular functions. The only
 difference between a property and a function is the meaning the author give
 to it, and that meaning vary between authors and contexts. Which means that
 from the API user point of view, something being a property or a function
 doesn't mean much... except of course that the user has to remember if
 Singleton.Instance is a property or a function before using it, or else
 suffer some useless compiler errors.
Good points. I think this discussion is diverging a little far from the real raison d'etre for property syntax, though. They are there in the first place not to save the typing of a few () here and there, but to allow a library designer to start with a plain field when that suffices and transition to a function later if that becomes necessary, without breaking client code. And there's where we can invoke a grand principle of software design as Andrei would have us do: * Changing implementation details should not affect client code. Ok I guess that's a software design principle, not language design but I guess I can say the underlying language principle is that the a good language should facilitate good software design. This one has to trump principles about economy of syntax and such, because the point of having a language in the first place is to make writing software easier/better/faster. More specifically this is a case of where we want syntax to facilitate making the transition from a simple field to something with some logic too. So what can we hope to get from the language to support this in the best way possible. These two conclusions seem pretty obvious to me: 1) The "fake" field's behavior should be indistinguishable from real field behavior in as many circumstances as possible. This prevents client code from having to change. This is why things like += on a property should be transformed by the compiler. 2) In situations where behavior does differ from that of a real field, a compiler error should occur at the point of usage. This prevents nasty surprises where code silently starts behaving incorrectly. This suggests that something like attempting to take the address of the field should be a syntax error if the field is turned into a property function. (This probably already happens in most cases since a function pointer won't usually be interchangeable with an int pointer or whatever it was before) Anyway, the point I want to make is that while it's neat that you can save typing a few parentheses, there are more important things, like being able to refactor code locally and knowing with reasonable certainty that all client code will either still work correctly or fail to compile. Going by these principles could lead to some interesting conclusions like for instance an argument that you shouldn't be able to take the address of a property function, or do anything else to it that exposes the fact that it is not, in fact, a field.
Yes, I entirely agree. I mentioned this a couple of times, but never explained it so well and thoroughly. Andrei
Oct 02 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Thu, Oct 2, 2008 at 8:26 PM, Michel Fortin 
 <michel.fortin michelf.com> wrote:
 Compare this with properties which have exactly the same performance,
 memory, and flexibility implications as regular functions. The only
 difference between a property and a function is the meaning the 
 author give
 to it, and that meaning vary between authors and contexts. Which 
 means that
 from the API user point of view, something being a property or a 
 function
 doesn't mean much... except of course that the user has to remember if
 Singleton.Instance is a property or a function before using it, or else
 suffer some useless compiler errors.
Good points. I think this discussion is diverging a little far from the real raison d'etre for property syntax, though. They are there in the first place not to save the typing of a few () here and there, but to allow a library designer to start with a plain field when that suffices and transition to a function later if that becomes necessary, without breaking client code. And there's where we can invoke a grand principle of software design as Andrei would have us do: * Changing implementation details should not affect client code. Ok I guess that's a software design principle, not language design but I guess I can say the underlying language principle is that the a good language should facilitate good software design. This one has to trump principles about economy of syntax and such, because the point of having a language in the first place is to make writing software easier/better/faster. More specifically this is a case of where we want syntax to facilitate making the transition from a simple field to something with some logic too. So what can we hope to get from the language to support this in the best way possible. These two conclusions seem pretty obvious to me: 1) The "fake" field's behavior should be indistinguishable from real field behavior in as many circumstances as possible. This prevents client code from having to change. This is why things like += on a property should be transformed by the compiler. 2) In situations where behavior does differ from that of a real field, a compiler error should occur at the point of usage. This prevents nasty surprises where code silently starts behaving incorrectly. This suggests that something like attempting to take the address of the field should be a syntax error if the field is turned into a property function. (This probably already happens in most cases since a function pointer won't usually be interchangeable with an int pointer or whatever it was before) Anyway, the point I want to make is that while it's neat that you can save typing a few parentheses, there are more important things, like being able to refactor code locally and knowing with reasonable certainty that all client code will either still work correctly or fail to compile. Going by these principles could lead to some interesting conclusions like for instance an argument that you shouldn't be able to take the address of a property function, or do anything else to it that exposes the fact that it is not, in fact, a field.
Yes, I entirely agree. I mentioned this a couple of times, but never explained it so well and thoroughly. Andrei
Me too. My previous use of the word "consistency" was perhaps a little sloppy, but I think Bill explains my thoughts to a tee. I'd be happiest if we could strengthen the semantics of properties, to make them indistinguishable from fields (from the class consumer's perspective). If we can't accomplish that, I'd rather do without the optional-parentheses and "x.prop = 3" tricks, using functions instead of properties. --benji
Oct 02 2008
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-02 01:25:34 -0400, "Bill Baxter" <wbaxter gmail.com> said:

 My first thought is what is the formal definition
 for what should be a struct and what should be a class.
Hum, I think I forgot to answer that part. The reason I say we need a formal definition is so we can actually imply things from something being a property. Pure and nothrow functions are (or will) be compile-time checked against a definition of what they should be: these offer garanties, which in turn add value to the user who know what it does. If we can't imply anything from them, properties offer no real value over mere functions since authors will decide what is a property based on the expectations they expect their users to have. To be frank, I don't expect we can agree on a formal definition. If we try and that is indeed the conclusion, it'll prove my point that you just can't imply anything from something being a property except the vague idea that the author thought it should be one according to his own definition. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 02 2008
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 Without aggreement on a formal definition for properties and compiler 
 enforcability, I find it very difficult to justify a formal syntax for 
 properties.
I agree. Moreover, there should be arguments on why the distinction useful. I liked it from day 1 that D made properties just a particular case of functions, and I'd love to keep it that way. It would obviate Andrei
Oct 02 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Michel Fortin" wrote
 On 2008-09-30 09:42:43 -0400, "Steven Schveighoffer" said:

 "Michel Fortin" wrote
 On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" said:

 Stdout.newline.formatln("Hi there {}", var);

 Is newline a property of Stdout, on which I'm calling formatln, or is
 newline a function that I'm calling, and then using the result of that
 function to call formatln?  Compare with:

 Stdout.newline().formatln("Hi there {}", var);

 There is no ambiguity.  newline is clearly a function, not a property.
Interesting. To me both of these things have exactly the same meaning. Perhaps it's because I'm used to D, but I think it's more because I can't count how many times I've seen this pattern in C++: SomeSimgleton::Instance().doSomething(); where Instance() is simply an accessor.
Yes, that is a workaround for not having property constructs available. The intuitive label of 'property' comes from the name of the getter 'Instance'. It screams that you are getting the instance of the class, and it's well accepted as a property. What has happened is that instead of relying on the compiler to enforce what is a property and what is not, you are relying on the interpretation of English words.
But one problem is that the distinction between a accessor (of a property) and a function is often matter to interpretation. In the case above, most likely the Instance() function will create the singleton object if it doesn't exist yet; seen that way it isn't a simple accessor. If you ask if Instance() should be a property or not, you're likely to get different answers from different people.
The difference is syntax-implied meaning. A property is a field implemented as a function. It is a form of information hiding and imposing access on a field, which could be a virtual field. By specifically defining properties, I'm telling you, 'this is a field. Access it like a field. pay no attention to how the field is constructed, or whether it is actually a field or not'. This allows me to later on make it a true field if it seems like the right decision. Or to specify a guarantee about properties. The other way around is already possible. I can take a field that is already in use and make it into a property. But the reverse is not so easy. Anyone who has accessed the field using parentheses would now have to go back and change all their code to remove the parentheses. For example, with the magic of static constructors, I can change Instance from a property to an actual field, by initializing it in a static constructor. Now every place you use Instance() (and there's probably a lot of them) is now invalid code. If the *required* method of accessing Instance is without parens, then you notice no differences, and the interface to Instance remains the same. As far as interpreting code, with the current state of affairs a function can be called like a field, which makes things more difficult to decipher. What is this symbol supposed to be? It becomes an interpretation of the actual words used, which I don't argue isn't part of the equation anyways, but leaving it completely up to that is not as precise. I have a real world example where someone thought a static constructor method I wrote was actually a property setter. See this bug in Tango: http://www.dsource.org/projects/tango/ticket/1184 I never intended the static constructor to be a property, but it just works that way because the compiler matches the developer's request for a setter property by finding a static function which does nothing like the developer intended. So it's a very hard bug to solve, and we couldn't solve it in the way I wanted, because the compiler cannot be forced not to look at all functions as possible properties. I agree that there is a subjective line as to what makes a property and what does not. What I propose is that we put the control of that line in the hands of the author, not the hands of the user. If the author thinks it's better used as a property, that is their call. It shouldn't be up to the user to say 'hey, I thought you meant function() here, you can't change it now!' It's the same concept behind interfaces.
 Arguably, there are cases even more ambiguous than this one. The issue I 
 want to bring is that without having a formal definition of what is a 
 property and what is not -- one the compiler can enforce -- people will 
 make different choices, not always coherent with each others, and you may 
 very well find yourself having to call Instance() with parenthesis in one 
 D lib and without parenthesis in another.
You end up with that situation anyways. If you have a project written by more than one person, one developer might use parens, one might not for the *same library* not just different libraries. Hell, I use the same function sometimes as property or function depending on how much I'm paying attention. I don't like the inconsistency that allowing all noarg functions to potentially be properties fosters. At least with a formal definition, the user of the lib knows what the author was trying to create, and uses the property in a forwards-compatible fashion.

 function.  So it would never look like that.
I could, but should I? I'm very interested in your criterions about why Instance would qualify to be a property and not as a function in this case. It's not just me. Just as an example, this article's author doesn't want to decide if Instance() should be a property or not: <http://www.yoda.arachsys.com/csharp/singleton.html> "Note that all of these implementations also use a public static property Instance as the means of accessing the instance. In all cases, the property could easily be converted to a method, with no impact on thread-safety or performance."
I guess what I should have said is that I would make it a property ;) Sometimes it's hard to envision a different point of view, but you are absolutely right, it could be considered a function instead. My definition of what I would like to see in an accessor (mind you, this is my definition, and would only be valid for libraries I wrote. Someone else could have a different definition, and that's fine with me) is something that consistently returns a value. So if I called it twice without anything changing, it would return the same thing, and accessing it doesn't change what it returns next time. So Instance qualifies because once it is constructed, it always returns the same thing. Perfect example of a use for an accessor property (to me anyway). If two different libraries use different accessing methods for Instance, that's fine. At least it's consistent. You are going to have a hard time enforcing design decisions over all the different libraries you use to be consistent. But at least they should be consistent every time you use them.
 In D, properties are equivalent to functions, so you have a choice as to
 whether to use the parentheses or not.  But that isn't the problem, the
 problem is really that you can call functions as properties.
But what is the difference between a property and a function (beside the syntax?). I can find countless discussions on the net about this; interesting discussions but with no definitive answer. In the end, it all boils down to the author's feeling about his function/property, which may be the opposite from its user's.
The difference is the interface. Which is the syntax, and that is important to me at least. If you don't like the authors usage of properties, don't use the lib. I don't see any other aspect of library design that leaves it up to the user as to how their functions/objects should be interfaced. Why should the user be allowed to decide the property/function interface?
 I'd like very much to quote Bruce Wood from this discussion:
 <http://bytes.com/forum/thread478064.html>

 (feel free to comment the quote)

 """
 You see, it's not always so cut-and-dried.

 On the one hand, if you make something a property, you are implying
 that getting the information will be quick. So, if getting the
 information is slow, that is a hint that it shouldn't be a property.
This is the opinion of the author (and I have the same opinion), but it's not written in stone. The only things that are written in stone (or I guess binary) are what the compiler guarantees. These kinds of debates have no real true answer, so there is no way to enforce. How would you enforce it anyways? But you can enforce the interface, and that's what I want.
 On the other hand, you don't want to determine what is a property or
 not based upon implementation details. By doing so you're letting the
 internal guts of how your class works leak out into its interface with
 the outside world. That's bad style. So, something should be a property
 if it makes sense that it be a property.

 Certainly, anything that affects the state of the object in a manner
 more sophisticated than just "set this to that" should be a method.
 That's painfully obvious.
I disagree with that ;), but then again that's my opinion and there is no right answer.
 Similarly, an aspect of your class that can be read and set, even if
 setting it does more than just set a variable, should probably be a
 property. Reasonably straightfoward.

 However, sometimes the two design goals above-properties that return
 results quickly and not letting implementation determine
 interface-are at odds with each other, and you have to make a
 judgement call.

 In the case of my system, I had things that logically should be
 properties (from an interface point of view) but the object held only
 keys, not references to the objects themselves, so the "get" on the
 property has to fetch the object in question from the database. It was
 an open question whether to code:

 Supplier theSupplier = stockItem.Supplier;

 or

 Supplier theSupplier = stockItem.GetSupplier();

 I chose the former, preferring to hide the implementation (holding
 supplier UID, not supplier itself) rather than let it leak out that
 getting the supplier was actually a lot of work. In our case it's no
 problem, because we're a very small shop. In a different situation I

 """
some sort of cache, where the lookup was implemented as a function, and the access of the value was done as a property afterwards.
 With the current approach in D, you just don't need to choose, just 
 document what your function/property is doing and be done with it... well 
 you may still have to choose about the name :-), so in a way the argument 
 is still there, but what I mean is that I don't think we really need a 
 black and a white syntax for one concept that may take many shades of 
 gray.
We don't need a formal definition of what should or should not be a property. But we need to allow the author to define what should or should not be a property. Without doing this, you are making the interface inconsistent or ambiguous -- even if only from a syntax point of view.
 In my opinion, "newline" isn't a good function name for what it does
 because it has no verb. Having no verb makes it look like an accessor 
 much
 more than the absence or presence of parenthesis.
So newline() seems like a property to you more than 'start a new line'? I suppose I can see that, but consider if you were used to a system where properties *prohibited* parentheses, and functions *required* them. It becomes less about interpretation of English vocabulary and more about compiler-enforced interface. I like that system better.
But I'm still puzzled by what being a property means in opposition as if it was a function. The thing is that the compiler just can't guaranty anything about properties: it's really just another syntax for calling a function, a function the author has classified as a property by some subjective standard, a standard which will often differ between authors. Properties are often touted as an indicator for low-cost functions -- whatever "low-cost" means --, but even this fuzzy standard somewhat hinder the often seeked goal of separating interface and implementation. Without aggreement on a formal definition for properties and compiler enforcability, I find it very difficult to justify a formal syntax for properties.
But you have no problems allowing a library author to define what is an interface and what is a class? Or what is a struct? Or if a function should return by value or by reference? Defining the interface is the job of the author, and the very very good reason behind that is so the author can change details without changing the interface to make upgrades easier for him *and* you. If he cannot define the interface, then he cannot make changes without affecting someone. -Steve
Oct 02 2008
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-26 13:47:55 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 I routinely use Tango's Stdout.newline; which I admit goes against what 
 I am saying, but it's because I know what Stdout.newline does, and that 
 it is a function.
I'd argue that for readability of the code "newline" is a bad function name since it has no verb. It should be something like "startLine" or "printNewline" or... "writeln"! Then there would be much less confusion over what it does. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 27 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 
 I routinely use writeln; without 
 feeling it makes for inferior style.
 
Dear Gods! O_o -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 02 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu wrote:
 I routinely use writeln; without feeling it makes for inferior style.
Dear Gods! O_o
What are you gonna do? People are different. If the best you can say against it is that it's "hideous", we should visit a modern art gallery :o). Andrei
Oct 02 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
What if it were src.advance instead? Since it's a verb, it's easier to associate it with an action that might change state rather than simply reading the state of src. As for ++src, I really dislike using that operator overload for an "advance" function. I'd sooner think that src was a fat reference of some sort and calling ++src would increment its value. That said, when I'm working with C or C++, I prefer indexing to pointer manipulation, and I don't use STL collections when I can avoid it, so it's largely a matter of experience.
 Not that I care too much :)  I am also in the camp of 'defined properties 
 should be a language feature,' but I admit to using D-properties quite 
 often.
Properties are good. For one thing, you can get better error messages, like "No set accessor for Foo.Bar" rather than "Foo.Bar() does not match the given parameters (int)".
 The two things that bug me the most about D property syntax:
 
 stuff like this:
 
 x;
 
 What the hell does this mean?  It looks like it does nothing.  But it could 
 be a function call.  If explicit properties were required, and x was defined 
 as a function, not a property, then x; would be a syntax error.
For me, I use the no-parentheses version in either of these cases: 1. I'm using the function as a property (auto name = field.name). 2. The function name is a verb (mocks.replay). This seems reasonably unambiguous in my personal experience, though it helps that I have few locals in most of my methods and use a prefix for private members.
Sep 26 2008
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-27 00:01:05 -0400, Christopher Wright <dhasenan gmail.com> said:

 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
What if it were src.advance instead? Since it's a verb, it's easier to associate it with an action that might change state rather than simply reading the state of src.
Very true.
 For me, I use the no-parentheses version in either of these cases:
 1. I'm using the function as a property (auto name = field.name).
 2. The function name is a verb (mocks.replay).
 
 This seems reasonably unambiguous in my personal experience, though it 
 helps that I have few locals in most of my methods and use a prefix for 
 private members.
Indeed. I think all function names which are not simple getters or setters should have a verb in their name, especially in D where there is no syntax difference between a property and a function. And I like pretty much the feature of not having to put parenthesis for function calls with no arguments. The only problem I have with it is that it makes working with delegates a little messier, especially when dealing with delegate properties which just *can't* behave as normal variables. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 27 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes 
 state is *bad* style, and surely hope the community would agree on 
 that.
I sure hope they won't agree to an unsupported assertion.
Actually I *do* hate this "feature" ^_^. And this "feature" has been put to challenged before: * Bug 2159. (http://d.puremagic.com/issues/show_bug.cgi?id=2159) * "Omitting Parens is an Evil" (http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is an_evil_73881.html) *http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com& roup=D&artnum=17579 But nothing got changed.
I don't think the bug report has much strength.
I mean the discussion within the bug report. That's a voice from the community isn't it?!
 
 To the very least, when using next as a property I assume the call 
 won't produce any secondary effect on src from the syntax, since I'm 
 just reading a state! Not so if one calls src.next() as the "()" is an 
 alarming sign that src _may_ change afterwards. This could is just a 
 problem of personal taste since the compiler does not forbid 
 src.next(), but not so if you're reading other's code.

 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
It's fine not to use ++src since C++ is the only language that uses this syntax for iterators anyway, but may I mention that, to increase all elements of an array you use ++a[], note that there is a [] in the end. ++a is syntax error anyway. Also you should complain about ++p vs ++*p for a pointer p ;) Like the () after the function call, which says I want to return the value after the function execution instead of the function object, the [] to my mind also signify I'm working on the content of the array, not the array itself.
 
 Andrei
Sep 26 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 Bruno Medeiros wrote:
 As a matter of coding style conventions, I would say that using the 
 implicit property function call feature on a function that changes 
 state is *bad* style, and surely hope the community would agree on 
 that.
I sure hope they won't agree to an unsupported assertion.
Actually I *do* hate this "feature" ^_^. And this "feature" has been put to challenged before: * Bug 2159. (http://d.puremagic.com/issues/show_bug.cgi?id=2159) * "Omitting Parens is an Evil" (http://www.digitalmars.com/d/archives/digitalmars/D/Omittable_parens_is an_evil_73881.html) *http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com& roup=D&artnum=17579 But nothing got changed.
I don't think the bug report has much strength.
I mean the discussion within the bug report. That's a voice from the community isn't it?!
I agree. But then should we take arguments at face value, or just consider them valid because they exist?
 To the very least, when using next as a property I assume the call 
 won't produce any secondary effect on src from the syntax, since I'm 
 just reading a state! Not so if one calls src.next() as the "()" is 
 an alarming sign that src _may_ change afterwards. This could is just 
 a problem of personal taste since the compiler does not forbid 
 src.next(), but not so if you're reading other's code.

 P.S. If src.next() is too lengthy, why not just adopt ++src?
Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
It's fine not to use ++src since C++ is the only language that uses this syntax for iterators anyway, but may I mention that, to increase all elements of an array you use ++a[], note that there is a [] in the end. ++a is syntax error anyway. Also you should complain about ++p vs ++*p for a pointer p ;) Like the () after the function call, which says I want to return the value after the function execution instead of the function object, the [] to my mind also signify I'm working on the content of the array, not the array itself.
I agree, hence my "far-fetched" qualification in the reply to Steve. Andrei
Sep 26 2008