Manfred Nowak wrote:
> Bruno Medeiros wrote
> 
>> It's in
>> http://www.digitalmars.com/d/expression.html#IdentityExpression
>> "For static and dynamic arrays, identity is defined as referring
>> to the same array elements"
> 
> From the specs:
> | Concatenation always creates a copy of its operands, even if one
> | of the operands is a 0 length array 
> 
> I believe that these definitions are essential for solving the dectected ambiguities.
> 
> Their meaning is, that arrays together with the concatenation operation do not form the mathematical structure of a monoid, because there is no identity preserving element for arrays under the concatenation operation.
> 
> Moreover: concatenation is not associative either because identity is defined only for arrays containing elements, i.e. two arrays with a length of zero might not be identical.
> 

Monoids and other common mathematical structures do not have the notion of computer-science identity, only equality (which they may call identity, but it's the same as equality in a programming languages context).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Oskar Linde wrote:
> Manfred Nowak wrote:
> 
>> This is a hack to avoid some overhead in some places, but may introduce  more overhead in other places.
> 
> This entire discussion is trying to make todays T[] -- a slice type with value semantics and some provisions for making it behave as an array in some cases -- into a pure array type with a well defined null. You can't do that without breaking its slice semantics. A much better suggestion is Walter's T[new]. Make T[] remain the slice type it is today and make a distinct array type (preferably a by-reference type).
> 

Today's T[] is "a slice type with value semantics and some provisions for making it behave as an array in some cases"? Whoa. What do you mean "making it behave as an array in some cases" ? What's the difference between a slice type and an array? And why would having null arrays in D break its slice semantics?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Derek Parnell wrote:
> On Wed, 25 Jul 2007 14:31:28 +0100, Bruno Medeiros wrote:
> 
>> The .ptr of empty arrays may be different than the .ptr of null arrays, but they are conceptually the same, and thus not safely distinguishable.
> 
> No they are not! Conceptually they are different things. However, D
> sometimes implements them as the same thing.
> 

Check my reply to Regan just above, what I meant to say is that in current D they are semantically the same.

>> Example:
>> 	writefln("" is null); // false
>> 	writefln("".dup is null); // true
>>
>> "".ptr is not null, but "".dup.ptr is null. Such duplication is correct, because empty arrays are conceptually the same as null arrays, and trying to use .ptr do distinguish them is unsafe, implementation-depedendent behavior (aka a program error).
> 
> But I believe that the implementation here is wrong. "".dup should create
> another empty string and not a null string. 
> 

The implementation is not wrong, it is according to Walter's intention, as you know. If anything, it is Walter's intention that is wrong. ^^'

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Manfred Nowak wrote:
> Bruno Medeiros wrote
> 
>> Monoids and other common mathematical structures do not have the
>> notion of computer-science identity, only equality (which they may
>> call identity, but it's the same as equality in a programming
>> languages context). 
> 
> From your signature follows that you might at least understand the theoretical background.
> 
> 
> The mathematical equality relation `=' is a special case of the mathematical equivalence relation `~' in that "two mathematical objects are equal if and only if they are precisely the same in every way" [cited from wikipedia].
> 
> I.e. in D the mathematical equality relation is bound to the identityExpression and restricted to arrays containing at least one element.
> 

Ok, if you apply the definition of the mathematical equality relation to raw program-objects, then yes, the mathematical equality relation is bound to the identityExpression. However, doing that is quite dubious and useless. (I'll explain better in another post)
But first, explain me this, what do you mean the "identityExpression is restricted to arrays containing at least one element."? That doesn't seem to make sense. An identity relation exists for any array pair (of the same type at least).

> 
> To D's equalityExpression only a mathematical equivalence relation is bound and also restricted to arrays containing at least one element, as one can see from the definition:
> 

Ok, I understand what you mean by saying that the equalityExpression is  only a mathematical equivalence relation, but again I don't understand what you mean by saying that it is restricted to arrays containing at leas one element.

> | For static and dynamic arrays, equality is defined as the lengths
> | of the arrays matching, and all the elements are equal.
> 

Again I don't see why this means it is restricted to arrays containing at least one element.

> I.e. for two arrays `a' and `b' declared as `T[] a, b;' for some type `T' having at least one element each, holds:
>    if `a is b' then `a == b'
> But the other direction is not necessarily true.   
> 
> 

Huh? That property "if `a is b' then `a == b'" holds for arrays with zero elements as well. In fact it hold for *any* type (that has a well defined equality operator).

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Manfred Nowak wrote:
> *** superseeding previous post ***

You should be able to delete ("cancel") your own posts...

> Bruno Medeiros wrote
> 
>> But first, explain me this, what do you mean the
>> "identityExpression is restricted to arrays containing at least
>> one element."? That doesn't seem to make sense.
> 
> In at least most definitions for relations on arrays in D the phrase "all elements" is used.
> 
> Besides the fact that this phrase is informal its meaning seems to be different from "for all x in the set S: P(x)". This latter phrase clearly binds the predicate P to elements in existence.

I don't see this as informal or different from your version in any way but verbosity.

> Such existence quantor seems not to be included in the phrase "all the elements are equal". This impressions is supported by this code fragment:
>    writefln( "" is ""); // prints "false"
> 
> The definition for the relationalExpression supports the restriction I phrased most prominently:
> 
> | For static and dynamic arrays, the result of the relational op is
> | the result of the operator applied to the first non-equal element
> | of the array.
> 
> I.e.: if there is no element, then there is no first element, then the result of the relationalExpression is not defined. According to the definition it is a bug that this code fragment is compilable:
>   writefln( "" < ""); // prints "false"

The fact that the spec doesn't seems to mention when two arrays compare equal doesn't mean two empty arrays don't compare equal. Obviously, equal arrays compare equal (regardless of the number of elements). Empty arrays are equal to other empty arrays.

> Note: maybe definition _and_ implementation are both buggy :-(

The definition is "buggy" in that it only mentions when arrays compare non-equal, not when they compare equal. The implementation is fine.

>> That property "if `a is b' then `a == b'" holds for arrays with
>> zero elements as well.
> 
> Maybe that the implementation is holding this property. But the specifications does not mention it. Therefore this property might not be intended and the implementation is waiting for a case where this property does not hold.

Yes, we get it. The specification forgot to explicitly mention when arrays compare equal. (Hint: it's when they're *EQUAL*)

Manfred Nowak wrote:
> *** superseeding previous post ***
> 
> Bruno Medeiros wrote
> 
>> But first, explain me this, what do you mean the
>> "identityExpression is restricted to arrays containing at least
>> one element."? That doesn't seem to make sense.
> 
> In at least most definitions for relations on arrays in D the phrase "all elements" is used.
> 
> Besides the fact that this phrase is informal its meaning seems to be different from "rfo all x in the set S: P(x)". This latter phrase clearly binds the predicate P to elements in existence.
> 

Erm, "all elements" is not in any different than "for all x in ...".

> Such existence quantor seems not to be included in the phrase "all the elements are equal". This impressions is supported by this code fragment:
>    writefln( "" is ""); // prints "false"
> 
> The definition for the relationalExpression supports the restriction I phrased most prominently:
> 
> | For static and dynamic arrays, the result of the relational op is
> | the result of the operator applied to the first non-equal element
> | of the array.
> 
> I.e.: if there is no element, then there is no first element, then the result of the relationalExpression is not defined. According to the definition it is a bug that this code fragment is compilable:
>   writefln( "" < ""); // prints "false"
>  
> 

Ok, the relationalExpression, according to that spec quote, does seem to be restricted to arrays with one or more elements. But that's just the relationalExpression so far, it's not the case for the identityExpression or the equalityExpression.

>> That property "if `a is b' then `a == b'" holds for arrays with
>> zero elements as well.
> 
> Maybe that the implementation is holding this property. But the specifications does not mention it. Therefore this property might not be intended and the implementation is waiting for a case where this property does not hold.
> 
> -manfred       

True, the spec does not mention it. But you have to know that the spec has a certain relative lack of rigor (which is hoped will eventually be improved), and as such many times one needs to fill in the blanks with what is common and expected in these programming languages. That's the case with opEquals, the spec does not mention, but one expects it to have the same properties that a proper opEquals should (such as these: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object) ).

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Manfred Nowak wrote:
> Bruno Medeiros wrote
> 
>> Monoids and other common mathematical structures do not have the
>> notion of computer-science identity, only equality (which they may
>> call identity, but it's the same as equality in a programming
>> languages context). 
> 
> From your signature follows that you might at least understand the theoretical background.
> 
> 
> The mathematical equality relation `=' is a special case of the mathematical equivalence relation `~' in that "two mathematical objects are equal if and only if they are precisely the same in every way" [cited from wikipedia].
> 
> I.e. in D the mathematical equality relation is bound to the identityExpression and restricted to arrays containing at least one element.
> 

Going back to the other issue, applying the definition of the mathematical equality relation to raw program-objects (and trying to find monoids with that relation), is useless and pointless.
You'll hardly find any reference type that is a monoid in that way (ie, that among other things, where there is an binary operation that (a op e) is (e op a) && (a op e) is (a), as I think was your original intention. (What made you do that in the first place?)
Why won't you find such types? Because from a developers perspective, no one quite natural cares:
Program objects serve to represent abstract objects. These abstract objects, like a 3D vector, or a phone book address, have several properties/elements (like 3 ordered numbers for the vector, or a name, address, phone num, etc., for the phone book address.). Program objects, which is what the developers create to represent the abstract objects, have all the properties of the abstract object, but they also have other, like memory location, memory size, and possibly others, because the program object has to exist in a computer software machine.
However, these two sets of properties represent two different levels of abstraction (program-level, and abstract/semantic level), and when a developer works with a program object, most of the time he only cares about the abstract/semantic properties of the object. And that's why opEquals exists in the first place, to allow to compare program objects at the *semantic* level. And so, it's also with the opEquals relation, and not the identity relation, that it may be *interesting* and *useful* to see if the objects form a monoid or not.
For example, even a Java-like BigNum class won't be a monoid under your original intention because with:
  BigNum a = new BigNum(42)
  BigNum b = new BigNum(1)
  BigNum c = a.multiply(b)
'a' and 'c' will not be "precisely the same in every way". They will be two different program objects. However at the semantic level, they *are* the same abstract objects (which is what opEquals checks), and BigNum's do form a monoid.

So, in conclusion:

Manfred Nowak wrote:
> Their meaning is, that arrays together with the concatenation
> operation do not form the mathematical structure of a monoid, because
> there is no identity preserving element for arrays under the
> concatenation operation.

Yes, "there is no identity preserving element for arrays under the concatenation operation", and that's really no problem whatsoever.
(Do you even know of a non-value type that has identity preserving element with regards to any operation?)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Manfred Nowak wrote:
> Frits van Bommel wrote
> 
>> Hint: it's when they're *EQUAL*
> 
> ... and this thread started because of disagreements about "when they're *EQUAL*"[cited from above].

I thought it was about whether null strings should be empty strings.
AFAICT (other than you) nobody contests that empty strings should (and do) compare equal to other empty strings. There's just some disagreement on what should be considered an "empty string" ;).

Manfred Nowak wrote:
> Frits van Bommel wrote
> 
>> There's just some disagreement on what should be considered an "empty string"
> 
> If your secretary opens an envelope adressed to you, but the envelope has not a single sheet of paper in it: what would you expect your secretry to do?
>  1) forward that envelope unmodified to you
> 
> 2) as above, but fill the envelope with an empty sheet of paper first
> 
> 3) something completely different

Sorry, I've never had a secretary. What would one do after opening a non-empty envelope?

One option you didn't mention would be to forward the contents and throw away the envelope itself. Since in the case of an empty envelope there are no contents to forward, it then degenerates to just throwing away the envelope...

Of course, if there's a return address or other writing on the envelope it might be handy to keep around. Like I said, I have no idea what exactly happens normally with envelopes secretaries open.

> After solving this for yourself, what would you do in the above case if you are my secretary?

Depends on what I'd do with a non-empty envelope. However, one thing I would probably do in addition to that would be wonder why someone mailed an empty envelope in the first place ;).



About your analogy: If an empty envelope stands for an empty array, and null arrays are different from empty arrays (as one group of posters would prefer) then what would be the equivalent of a null array? No envelope at all? A postcard with "This is not an envelope" written on it perhaps? ;)

On Sat, 28 Jul 2007 00:06:17 +0000 (UTC), Manfred Nowak wrote:

> Frits van Bommel wrote
> 
>> There's just some disagreement on what should be considered an "empty string"
> 
> If your secretary opens an envelope adressed to you, but the envelope
> has not a single sheet of paper in it: what would you expect your
> secretry to do?
> 
> 1) forward that envelope unmodified to you

Yes

> 2) as above, but fill the envelope with an empty sheet of paper first
> 
> 3) something completely different
> 
> After solving this for yourself, what would you do in the above case if you are my secretary?

Resign!

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell