Checking if a string is null

[Bruno Medeiros]

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