July 24, 2009
Walter Bright wrote:
> goooooo wrote:
>> It is said that "Character decided fate" . W.B's character decided
>> the fate of watcom C, and now the fate of D. Just as it is said in
>> the homepage, D is the code for nerds ,not the code for thinkers as
>> LISP, nor the code for creators as C,nor the code for users like
>> perl. Sorry to say so.
> 
> I am not and never was associated with Watcom C in any way, other than as a competitor. I have an old copy of it in the basement <g>. The compiler products I've worked on:
> 
> http://www.walterbright.com

http://www.walterbright.com/garage/index.html

YEAAAH!!
July 24, 2009
On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> I don't think properties should be necessarily pure anyways.  How do you have a pure setter?  It's more of a convention that a property getter should not change the state of the containing entity, a pretty much non-enforcable convention.
>
> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.

If you delineate what can be called how, then you elminate syntax ambiguities from occurring, and eliminate bizarro cases of syntax.  The difficulty is that the "human meaning" of a property is different than the human meaning of a function.  To the compiler, they're all functions, so you as the compiler writer aren't seeing that they are different.  I think we all agree that writefln = "hi"; makes absolutely no sense to a person.  But it makes complete sense to the compiler, because it has no idea what the word "writefln" means to a person.

It's the exact same reason + is not the concatenation operator.  Semantically, making + concatenate two strings together would be completely unambiguous from adding two integers together because strings do not define addition, and integers do not define concatenation.  From your own documentation, someone seeing "10" + 3 might think that he would get 13 or "103".  Even if the compiler defines what "should" happen, and the rules are unambiguous, it looks incorrect to the user.

But having ~ be the concatenation operator makes it completely unambiguous what the syntax means, regardless of what the types are.   So the compiler and the user are talking the same language, and the user isn't freaked out by the "human meaning" of the syntax.

-Steve
July 24, 2009
Steven Schveighoffer wrote:
> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>> I don't think properties should be necessarily pure anyways.  How do you have a pure setter?  It's more of a convention that a property getter should not change the state of the containing entity, a pretty much non-enforcable convention.
>>
>> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.
> 
> If you delineate what can be called how, then you elminate syntax ambiguities from occurring, and eliminate bizarro cases of syntax.  The difficulty is that the "human meaning" of a property is different than the human meaning of a function.  To the compiler, they're all functions, so you as the compiler writer aren't seeing that they are different.  I think we all agree that writefln = "hi"; makes absolutely no sense to a person.  But it makes complete sense to the compiler, because it has no idea what the word "writefln" means to a person.
> 
> It's the exact same reason + is not the concatenation operator.  Semantically, making + concatenate two strings together would be completely unambiguous from adding two integers together because strings do not define addition, and integers do not define concatenation.  From your own documentation, someone seeing "10" + 3 might think that he would get 13 or "103".  Even if the compiler defines what "should" happen, and the rules are unambiguous, it looks incorrect to the user.
> 
> But having ~ be the concatenation operator makes it completely unambiguous what the syntax means, regardless of what the types are.   So the compiler and the user are talking the same language, and the user isn't freaked out by the "human meaning" of the syntax.
> 
> -Steve

Maybe what scares Walter is a whole new syntax for properties. If at least you could say which functions are properties and which are not, that would be a small change and it'll make it possible for other things. Something like:

int property foo(); // getter
int property foo(int value); // setter

So properties are marked with a modifier and that's it. The compiler could discard those modifiers or, much better, disallow doing things like:

bar = 3; // ERROR: bar is not a property
foo(); // ERROR: foo is a property and must be used as foo

Now we need someone to think which of the current keywords could be used instead of "property". :-P
July 24, 2009
On Fri, 24 Jul 2009 15:12:10 -0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:

> Maybe what scares Walter is a whole new syntax for properties. If at least you could say which functions are properties and which are not, that would be a small change and it'll make it possible for other things. Something like:

His point is that there are no benefits to the semantic meaning of the code by declaring something a property.  It's still a function, still gets implemented by a function.

It's like if you say functions can now be called like this:

foo^arg

But he's not getting that the compiler isn't the only one reading the code, and D isn't the only language being used.  You are also using a person's knowledge of math (x = y) and a person's native language.  At least the native language, the compiler knows and cares nothing about, but the developer and user care greatly (and want the conventions enforced).

-Steve
July 24, 2009
Walter Bright wrote:

> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.

You know, I don't believe I've seen you reply specifically to any of the good points about D's properties people have been mentioning around here.

I believe the list I gave you in the 'big' subthread was fairly complete. Would you please tell us what you think about each point? I'll repeat that specific section of my reply here:

--------------------
> Why not? Seriously, what is the semantic difference?

There are many reasons. Some have been floating around this newsgroup this very day.

* A reference to a function should mean exactly that: a reference to the function, for use in functional programming. Instead, just the name of a function now invokes a call.

* In D, &foo returns a function-pointer, but that means that D is context sensitive, since its subexpression foo would return a property value. It is confusing.

* What does D do if you have a property (p) that returns a delegate? Will
the call p() return the delegate? Or will it call the delegate?

* writefln = 5; This should just not be valid code. But it is.

* Real Properties have many advantages over what looks like D's ad-hoc solution. They automatically document themselves as properties both to the programmer and to IDE's (see some other posts from today). The programmer may use them to overload certain operators and mutator functions that would speed up the program. Months ago there was a big thread about Real Properties. I myself offered a suggestion for their design. I don't remember if you ever responded.

That's just a few reasons right there. D's properties lack elegance and they lack potential.
--------------------

PS: I don't mean to gang up on you. You're just not making yourself clear on where you stand on these points and why.

-- 
Michiel Helvensteijn

July 24, 2009
On Fri, Jul 24, 2009 at 2:58 PM, Ary Borenszweig<ary@esperanto.org.ar> wrote:
> Walter Bright wrote:
>>
>> goooooo wrote:
>>>
>>> It is said that "Character decided fate" . W.B's character decided the fate of watcom C, and now the fate of D. Just as it is said in the homepage, D is the code for nerds ,not the code for thinkers as LISP, nor the code for creators as C,nor the code for users like perl. Sorry to say so.
>>
>> I am not and never was associated with Watcom C in any way, other than as a competitor. I have an old copy of it in the basement <g>. The compiler products I've worked on:
>>
>> http://www.walterbright.com
>
> http://www.walterbright.com/garage/index.html
>
> YEAAAH!!

What!  Descent!  You don't SELL Descent.  You treasure it for years and years, owing your entire interest in programming to it.
July 24, 2009
On Fri, Jul 24, 2009 at 12:21 PM, Steven Schveighoffer<schveiguy@yahoo.com> wrote:
> On Fri, 24 Jul 2009 15:12:10 -0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>
>> Maybe what scares Walter is a whole new syntax for properties. If at least you could say which functions are properties and which are not, that would be a small change and it'll make it possible for other things. Something like:
>
> His point is that there are no benefits to the semantic meaning of the code by declaring something a property.  It's still a function, still gets implemented by a function.
>
> It's like if you say functions can now be called like this:
>
> foo^arg
>
> But he's not getting that the compiler isn't the only one reading the code, and D isn't the only language being used.  You are also using a person's knowledge of math (x = y) and a person's native language.  At least the native language, the compiler knows and cares nothing about, but the developer and user care greatly (and want the conventions enforced).

Another example: arrays are just functions too.  So there's no real
need for a distinct a[i] syntax.  a(i) would work just fine (and is
exactly what's used in Fortran and Matlab for array indexing).

But we kind of like being able to see right away that something is intended to be indexing.  It give the reader of the code a hint about the intended semantics.  But of course the compiler can't enforce that every opIndex overload conforms to that.  You could write an opIndex overload that prints to stdout.  But generally people don't do that because that would be sending the wrong signal.  Generally the opIndex overloads offer index-ing like behavior.

--bb
July 24, 2009
Rainer Deyke, el 24 de julio a las 11:55 me escribiste:
> Leandro Lucarella wrote:
> > !? It's true that in Python all are references, but there are inmutable objects in Python, like int, float, strings and tuples. From a practical POV it exactly the same as value types, if you do:
> 
> Immutable reference types are still reference types, and follow the same rules as other reference types.  You just can't modify them.  The assignment operator *always* rebinds a reference, regardless of the mutability or immutability of any objects involved.

That's true, conceptually, but when you use the variables, you use them as value types, with the same advantages and limitations.

> The one exception is that operators like '+=' will create a new object when applied to immutable types, but modify existing objects when applied to mutable objects.  And, yes, this bothers me in Python.  A lot.

How do you note that? Really. Python inmutables have value semantics.

> But that's still not half as bad as D, where something simple like 'a = b; a.x = 5;' can have two completely different meanings depending on whether 'a' is a reference type or a value type.

Yes, that's true, but this is a common problem. Think of operator overloading... Even in Python that could mean *anything* (__getattr__).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Y será el día en que la electricidad deje de ser rayo y sea depilador
femenino.
	-- Ricardo Vaporeso
July 24, 2009
On Fri, 24 Jul 2009 15:26:58 -0400, Michiel Helvensteijn <m.helvensteijn.remove@gmail.com> wrote:


> PS: I don't mean to gang up on you. You're just not making yourself clear on
> where you stand on these points and why.

This is typical Walter :)  He'll argue the easy ones all day long, and stay silent on the harder-to-refute ones.  Then one day, you'll see the feature you wanted suddenly and without warning appear in the compiler (I'm still holding my breath on a few).

Not that this means properties are going to be one of those features, but still.  With Walter, silence is usually all you get when he's coming around to your side :)

It's a good strategy for someone who's word is almost law when it comes to D.  You have to be careful what you say, flip-flopping around only leads to knee-jerk feature additions, more bikeshed discussions, and more people clammoring for feature additions (hey, you added this, why not that!).  I have great respect for the balance he has to deal with between adding interesting features and keeping a sane spec.

-Steve
July 24, 2009
Jarrett Billingsley wrote:
> What!  Descent!  You don't SELL Descent.  You treasure it for years
> and years, owing your entire interest in programming to it.

Bah, I have a basement full of such treasures.

I finally took to the dump my Diablo 630 daisywheel printer. It was in mint condition, with manual, extra ribbons, cables, etc. I bought it for $1,000 back in 1982. It was built like a tank (and sounded like a machine gun when in action!). It produced beautiful printed pages.

I couldn't find anyone who wanted it, not even old computer museums.