July 24, 2009
Rainer Deyke, el 23 de julio a las 19:49 me escribiste:
> Walter Bright wrote:
> > Rainer Deyke wrote:
> >> Syntactic ambiguity.  Confusion between an instance of a class and a reference to that instance.
> > 
> > I was initially thrown by this when I started some Java programming. But it soon became clear this was an advantage, and I came to prefer it.
> 
> I like it in Python, where all variables are references.  Java is similar to Python in this regard, although the existence of primitive value types complicates the situation somewhat.
>
> I don't like it in D, where reference types and value types coexist.  I especially don't like it in templates in D, where it may not be clear if you're dealing with a reference type or a value type until instantiation.

!? 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:

def f(x, y):
	x = 5
	y = (1, 3)

a = 1
b = (5, 9)
f(a, b)
print a, b

prints "1 (5, 9)", not "5 (1, 3)".

So I can't see how you like Python's way and not D's way.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
En la calle me crucé con un señor muy correcto, que habitualmente anda en
Falcon; iba corriendo con dos valijas en la mano y dijo: "Voy para Miami,
tiene algún mensaje o ..." y le dije: "No, no, no..."
	-- Extra Tato (1983, Triunfo de Alfonsín)
July 24, 2009
Walter Bright, el 23 de julio a las 17:42 me escribiste:
> Leandro Lucarella wrote:
> >The problem is, if is hard to write, or ugly to read, people won't use it, or will use it less. In Python tuples are easy to read and write, so people use them everywhere and they are really useful (especially for FP-style programming, where is more common to return multple values).
> 
> That is a good point. I won't say I'm convinced for the tuple case <g>, but it is a good argument.

I can't believe it, I actually made Walter think something twice! =P

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
CAMPAÑA POR LA PAZ: APLASTARON JUGUETES BÉLICOS
	-- Crónica TV
July 24, 2009
Adam D. Ruppe, el 23 de julio a las 22:56 me escribiste:
> On Fri, Jul 24, 2009 at 01:38:30AM +0000, Jesse Phillips wrote:
> > Thanks for the tutorial, expect to see it on Wiki4D within a year :D
> 
> This actually doesn't /quite/ work, since the tuple returned by tuple() has unnamed fields, which is a different type than the one with named fields.
> 
> Gah.
> 
> This works though:
> 
> auto getPoint() { return Tuple!(int, "x", int, "y")(5, 2); }
> 
> That's getting a wee bit ugly even for my likes, but is the best way for correctness and ease of use on the calling end. Or
> 
> Tuple!(int, int) getPoint() { return tuple(5,2); }
> 
> That works, but then you have to address the return value as:
> 
> auto p = getPoint();
> p.field[0] == 5
> p.field[1] == 2
> 
> 
> Still, easy enough to say:
> 
> auto x = p.field[0]; auto y = p.field[1];
> x == 5
> y == 2

And you still think that's not remarkably worse than something like:

(int, int) getPoint() { return (5, 2); }
auto (x, y) = getPoint();

I really think that's the difference between happily using tuples or curse them for the rest of your life :)

I don't think comma expressions should be used for tuples (I don't care much either), but you can add support to the language without breaking them using something like @(1, 2, 3) or ![ 1, 2, 3 ] or whatever.

But you should support multple assignment, for example. If you don't, you don't have real tuple support, just a toy tuple emulation.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
We're rotten fruit
We're damaged goods
What the hell, we've got nothing more to lose
One gust and we will probably crumble
We're backdrifters
July 24, 2009
Daniel Keep wrote:
> Actually, I've now come up with a counter-example for the idea of using
> pure at all:

That's right, lazy evaluation can't be pure. So, the question is is this an important enough case to justify a whole new syntax?
July 24, 2009
On Fri, 24 Jul 2009 13:37:16 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Daniel Keep wrote:
>> Actually, I've now come up with a counter-example for the idea of using
>> pure at all:
>
> That's right, lazy evaluation can't be pure. So, the question is is this an important enough case to justify a whole new syntax?

Don't get lost in the pure discussion.  There are many reasons to have a dedicated property syntax, even for non-pure properties.

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 not to say that you couldn't mark a property as const or pure, just that it shouldn't HAVE to be that way.

-Steve
July 24, 2009
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.

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.

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.


-- 
Rainer Deyke - rainerd@eldwood.com
July 24, 2009
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.
July 24, 2009
Rainer Deyke wrote:
> Yes, it is.  Mainly because C++ doesn't have reference types in same way
> that D does.
> 
> In C++, values of *all* types (including primitive integral types and
> even pointer types) can be placed on the heap, and such values are
> *always* managed by (smart) pointers, with pointer syntax.  In this
> sense, all types in C++ can be used as reference types.
> 
> There are C++ classes that are meant to always be placed on the heap and
> managed by a pointer.  They are the closest C++ has to D-style classes.
>  They are exceedingly rare.  They're also easy to identify: their
> constructors are protected, so the only way to instantiate them is by
> calling a factory function that returns a (smart) pointer.

A reference type isn't defined as one that only exists on the heap. Even in D, value types can be in the heap, and reference types can be on the stack.

The value/reference dichotomy is how the object is referred to, not where it is.
July 24, 2009
Rainer Deyke wrote:
> 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.

From a user's point of view, an immutable reference is indistinguishable from a value.


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

True.

And in C++ with assignment overloads and copy constructors, one also has no clue what a.x=5 does without looking at the source to those functions.

I don't think there's anyway we can pretend to know what semantics a type has in a language with user-definable types without at least looking at its declaration.
July 24, 2009
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