www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Confusion] delete is an operator

reply Manfred Nowak <svv1999 hotmail.com> writes:
<specs>
This confusingly appears to delete the value of b["hello"], but does not, 
it removes the key "hello" from the associative array.
</specs>

D is a language that states parts of itself as confusing.

And that seems not to be neccessary:

  b.delete("hello");

or

  delete "hello" in b;

or

  in b delete "hello";

seem far more appropriate.

But that is not the main problem.

Imagine, and i really did that :-), you use an associative array for some 
rudimentary operations. As time goes by the operations on that array 
become more in number and complexity. You want a redesign an put the 
array in a class.

Naturally there exists some code, that does a `delete b["hello"]'.

Your redeclaration from some `V[char[]] b' to some `Class b=new Class' 
causes some missing overload errors. Among them the error:
  `no [] operator overload' error.

But mechanically declaring one throws you into the next pit:
  `opIndex() is not an lvalue'

You can see: not only you think, that `delete b["hello"]' should delete 
the value of "hello" in b, but also the compiler thinks so.

But you want to delete the key, not the value, and there is currently no 
possibility to overload the `delete'.

You are to wear sackcloth and ashes and change all occurrences of this 
delete instead of simply overloading it.

I do not believe that this is necessary. Can we change this please?

-manfred
Jan 24 2005
next sibling parent reply Chris Sauls <Chris_member pathlink.com> writes:
Maybe D should have an opIndexDelete override?  Or opAsocDelete, or similar,
since its specifically for use with associative arrays (and therefore emulators
of such).

-- Chris Sauls
Jan 24 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <ct4c3b$3r2$1 digitaldaemon.com>, Chris Sauls says...

Maybe D should have an opIndexDelete override?  Or opAsocDelete, or similar,
since its specifically for use with associative arrays (and therefore emulators
of such).

-- Chris Sauls


I perhaps shouldn't do this, but I will because it seems so blindingly obvious
where the true problems lie: 

None of these AA issues would be apparent, or they would be trivial to change,
if the functionality were exposed via a library rather than being part of the
language proper. Building this kind of thing into the language spec is where
Pascal went wrong (in the commercial world -- it was great for its intended
purpose). K & R 'recognized' this and placed all non-core facilities into a
library instead. A similar notion is applied to O/S kernels, and so on, ad
nauseum.

The same could be said for the 'handy' .sort mechanism which doesn't allow one
to replace the algorithm (unless you also replace all the .sort instances also).
And, of course, these two are responsible for the otherwise unwarranted addition
of opCmp() and opEquals() within the root Object itself (which has been
belaboured to death several times prior).

I'll lay decent odds, with quantities of hard cash, that this is not "the last
issue with AA or .sort". Oh, I agree that building the functionality into the
core language skirts around some other issues. However; the original ones should
have been resolved instead. Embedded compound-behaviour such as AA's and .sort
will ultimately, IMO, hurt D more than most might think.

And for those who might think otherwise: I truly wish to see D succeed &
flourish. For that to happen, some of the very, very, early concepts should at
least be seriously re-evaluated. 

- Kris
Jan 24 2005
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
 And for those who might think otherwise: I truly wish to see D succeed &
 flourish. For that to happen, some of the very, very, early concepts should at
 least be seriously re-evaluated.


Hear, hear!!

The Dr .....

P.S. I'm hoping, when we get down to writing the book next month, that Walter
will realise just how hard to swallow some 
of these concepts will be, and this may be a final motivation for some changes.
(I've certainly experienced this 
phenomenon in various libs/articles(or chapters) in my own stuff.) I know I
don't relish the idea of writing a book in 
2005, and having to do a revised edition in 2006. ;)
Jan 24 2005
prev sibling parent reply parabolis <parabolis softhome.net> writes:
Kris wrote:


 None of these AA issues would be apparent, or they would be trivial to change,
 if the functionality were exposed via a library rather than being part of the
 language proper. Building this kind of thing into the language spec is where
 Pascal went wrong (in the commercial world -- it was great for its intended
 purpose). K & R 'recognized' this and placed all non-core facilities into a
 library instead. A similar notion is applied to O/S kernels, and so on, ad
 nauseum.


We can indeed move *everything* out to a library and be left with 
expressions like:
   opAssign(x, opAdd(1, opMul(2*3)));
Then we can use infix notation to make parsing easy and end up 
with the strangly familiar:
   (setq x (+ 1 (* 2 3)))

With that said let me say lisp people would say K&R missed the 
boat if their goal was to put 'non-core facilities' into the 
library. Core vs non-core has nothing to do with the issue in my 
opinion. I think the real issue is what can we add to the 
language to make it easier for programmers.

I have seen Walter mention elsewhere his suprise at how 
interwoven all the language elements are with each other. Adding 
something to a language like C should be viewed as a fairly 
drastic step which is only undertaken with care.

I can imagine three criterion for language addition (I would not 
be suprised if I could be convinced there are some I missed):

(1) A proposed addition should be a frequent case of use.
(2) The syntax and semantics should already be familiar.
(3) The actual syntax should fit nicely within existing syntax.

I believe AAs satisfy (1) and (2) but stumbles slightly on (3).

(1) is fairly obviously satisfied as hash tables are data 
structures with nice properties and thus are already frequently 
in use.

(2) is satisfied as hash tables are indexed on the hash of a key 
meaning that considering them an array indexed by the key itself 
fits in nicely with both array index notation and hash table notions.

(3) only seems to stumble on the new and .length syntax and does 
pretty well with insertion and removal. Deleting the Ith element 
of an array of objects should delete the element's value. It 
should be possible to specify the size of an AA as would would 
with a normal array -- especially if one knows exactly how many 
things one will expect it to hold or how many more it will need 
to hold.
Jan 25 2005
next sibling parent parabolis <parabolis softhome.net> writes:
parabolis wrote:


 (3) only seems to stumble on the new and .length syntax and does pretty 
 well with insertion and removal. Deleting the Ith element of an array of 
 objects should delete the element's value.


I am terribly mistaken on this point. Given:

   RegExp[char[]] re;
   // with key "bob" and value "b[o]+b"
   delete re["bob"];

In the example above re should eliminate "bob" from its data 
structure and its reference to the corresponging RegExp object 
should be set to null. Should actually deleting the RegExp the 
following would work:

   RegExp tmp = re["bob"];
   delete re["bob"];
   delete tmp;
   tmp = null;

Ergo I was mistaken and (3) is quite clearly broken.
Jan 25 2005
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
Fair enough, Parabolis.

Perhaps a reasonable criterion for core/non-core would be whether or not the
functionality should be sensibly overridden or augmented?

Walter has gone to great pains to allow operator overloading, and to treat class
methods as extended-attributes (to some degree), yet things like .sort and AAs
are not customizable in the same manner: for example, you have to abandon the
syntax completely to apply a different kind of sorting algorithm. In contrast,
one can override most of the basic operators. That's asymmetrical.

If Array behaviour/properties were overridable (akin to class methods) then
things might be cleaner. What if the 'array' type were actually a pre-defined
class or struct? This is similar to the notion of other native-types being
represented by a struct, such that one can augment their properties also. This
idea has been bounced around before.

It'd certainly be more interesting :-)



In article <ct51ua$t7h$1 digitaldaemon.com>, parabolis says...

Kris wrote:


 None of these AA issues would be apparent, or they would be trivial to change,
 if the functionality were exposed via a library rather than being part of the
 language proper. Building this kind of thing into the language spec is where
 Pascal went wrong (in the commercial world -- it was great for its intended
 purpose). K & R 'recognized' this and placed all non-core facilities into a
 library instead. A similar notion is applied to O/S kernels, and so on, ad
 nauseum.


We can indeed move *everything* out to a library and be left with 
expressions like:
   opAssign(x, opAdd(1, opMul(2*3)));
Then we can use infix notation to make parsing easy and end up 
with the strangly familiar:
   (setq x (+ 1 (* 2 3)))

With that said let me say lisp people would say K&R missed the 
boat if their goal was to put 'non-core facilities' into the 
library. Core vs non-core has nothing to do with the issue in my 
opinion. I think the real issue is what can we add to the 
language to make it easier for programmers.

I have seen Walter mention elsewhere his suprise at how 
interwoven all the language elements are with each other. Adding 
something to a language like C should be viewed as a fairly 
drastic step which is only undertaken with care.

I can imagine three criterion for language addition (I would not 
be suprised if I could be convinced there are some I missed):

(1) A proposed addition should be a frequent case of use.
(2) The syntax and semantics should already be familiar.
(3) The actual syntax should fit nicely within existing syntax.

I believe AAs satisfy (1) and (2) but stumbles slightly on (3).

(1) is fairly obviously satisfied as hash tables are data 
structures with nice properties and thus are already frequently 
in use.

(2) is satisfied as hash tables are indexed on the hash of a key 
meaning that considering them an array indexed by the key itself 
fits in nicely with both array index notation and hash table notions.

(3) only seems to stumble on the new and .length syntax and does 
pretty well with insertion and removal. Deleting the Ith element 
of an array of objects should delete the element's value. It 
should be possible to specify the size of an AA as would would 
with a normal array -- especially if one knows exactly how many 
things one will expect it to hold or how many more it will need 
to hold.
Jan 25 2005
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
I second the opinion that status quo must be changed. Kris' suggestion 
below is the one I've liked best sofar. Pending peeve (or at least it 
should be).

Lars Ivar Igesund

Kris wrote:

 Fair enough, Parabolis.
 
 Perhaps a reasonable criterion for core/non-core would be whether or not the
 functionality should be sensibly overridden or augmented?
 
 Walter has gone to great pains to allow operator overloading, and to treat
class
 methods as extended-attributes (to some degree), yet things like .sort and AAs
 are not customizable in the same manner: for example, you have to abandon the
 syntax completely to apply a different kind of sorting algorithm. In contrast,
 one can override most of the basic operators. That's asymmetrical.
 
 If Array behaviour/properties were overridable (akin to class methods) then
 things might be cleaner. What if the 'array' type were actually a pre-defined
 class or struct? This is similar to the notion of other native-types being
 represented by a struct, such that one can augment their properties also. This
 idea has been bounced around before.
 
 It'd certainly be more interesting :-)
 
 
 
 In article <ct51ua$t7h$1 digitaldaemon.com>, parabolis says...
 

Kris wrote:



None of these AA issues would be apparent, or they would be trivial to change,
if the functionality were exposed via a library rather than being part of the
language proper. Building this kind of thing into the language spec is where
Pascal went wrong (in the commercial world -- it was great for its intended
purpose). K & R 'recognized' this and placed all non-core facilities into a
library instead. A similar notion is applied to O/S kernels, and so on, ad
nauseum.


We can indeed move *everything* out to a library and be left with 
expressions like:
  opAssign(x, opAdd(1, opMul(2*3)));
Then we can use infix notation to make parsing easy and end up 
with the strangly familiar:
  (setq x (+ 1 (* 2 3)))

With that said let me say lisp people would say K&R missed the 
boat if their goal was to put 'non-core facilities' into the 
library. Core vs non-core has nothing to do with the issue in my 
opinion. I think the real issue is what can we add to the 
language to make it easier for programmers.

I have seen Walter mention elsewhere his suprise at how 
interwoven all the language elements are with each other. Adding 
something to a language like C should be viewed as a fairly 
drastic step which is only undertaken with care.

I can imagine three criterion for language addition (I would not 
be suprised if I could be convinced there are some I missed):

(1) A proposed addition should be a frequent case of use.
(2) The syntax and semantics should already be familiar.
(3) The actual syntax should fit nicely within existing syntax.

I believe AAs satisfy (1) and (2) but stumbles slightly on (3).

(1) is fairly obviously satisfied as hash tables are data 
structures with nice properties and thus are already frequently 
in use.

(2) is satisfied as hash tables are indexed on the hash of a key 
meaning that considering them an array indexed by the key itself 
fits in nicely with both array index notation and hash table notions.

(3) only seems to stumble on the new and .length syntax and does 
pretty well with insertion and removal. Deleting the Ith element 
of an array of objects should delete the element's value. It 
should be possible to specify the size of an AA as would would 
with a normal array -- especially if one knows exactly how many 
things one will expect it to hold or how many more it will need 
to hold.
Jan 25 2005
prev sibling next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Kris" <Kris_member pathlink.com> wrote in message 
news:ct63md$27eb$1 digitaldaemon.com...

 Fair enough, Parabolis.

 Perhaps a reasonable criterion for core/non-core would be whether or not 
 the
 functionality should be sensibly overridden or augmented?

 Walter has gone to great pains to allow operator overloading, and to treat 
 class
 methods as extended-attributes (to some degree), yet things like .sort and 
 AAs
 are not customizable in the same manner: for example, you have to abandon 
 the
 syntax completely to apply a different kind of sorting algorithm. In 
 contrast,
 one can override most of the basic operators. That's asymmetrical.


One can define a class or struct with a ".sort" property that does whatever 
one wants just as one can write a class or struct with an opAdd overload 
that does whatever one wants. Seems symmetrical to me. You can't overload 
what + does on two ints so it isn't unusual to force people to make a custom 
type to get "non-standard" behavior. Enhancements to the .sort behavior 
(like the ability to customize the sort algorithm somehow) of AAs can wait 
for post 1.0 IMO but something like the syntax for removing elements should 
be finalized by 1.0. Anyway, one can always write a sort function and call 
it directly.

[snip]
Jan 25 2005
prev sibling parent parabolis <parabolis softhome.net> writes:
Kris wrote:

 Fair enough, Parabolis.
 
 Perhaps a reasonable criterion for core/non-core would be whether or not the
 functionality should be sensibly overridden or augmented?


I think that fits a hole in (2) nicely so I would have to agree.
Jan 25 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Please no. Let's just have a simple syntax, like, er,

    aa.remove(key);

??

"Chris Sauls" <Chris_member pathlink.com> wrote in message
news:ct4c3b$3r2$1 digitaldaemon.com...

 Maybe D should have an opIndexDelete override?  Or opAsocDelete, or similar,
 since its specifically for use with associative arrays (and therefore emulators
 of such).

 -- Chris Sauls
Jan 24 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:ct4hj6$8s8$3 digitaldaemon.com...

 Please no. Let's just have a simple syntax, like, er,

    aa.remove(key);


This gets my vote.

Currently arrays only have properties so it would be the only array 
operation with a member function but it is less confusing than anything 
else. It is better to keep the semantics of "delete" consistent than 
preserve the fact that arrays have no member functions.
Jan 25 2005
parent reply Kramer <Kramer_member pathlink.com> writes:
This may be a dumb question, but *currently*, what's the best way to actually
remove the element from the AA?

-Kramer

In article <ct5f71$1eb5$1 digitaldaemon.com>, Ben Hinkle says...

"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:ct4hj6$8s8$3 digitaldaemon.com...

 Please no. Let's just have a simple syntax, like, er,

    aa.remove(key);


This gets my vote.

Currently arrays only have properties so it would be the only array 
operation with a member function but it is less confusing than anything 
else. It is better to keep the semantics of "delete" consistent than 
preserve the fact that arrays have no member functions.
Jan 25 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kramer wrote:


 This may be a dumb question, but *currently*, what's the best way
 to actually remove the element from the AA?


The *only* way at the momement to remove an element is:

	delete b["hello"];


 This confusingly appears to delete the value of b["hello"], but
 does not, it removes the key "hello" from the associative array.


See http://www.digitalmars.com/d/arrays.html#associative

--anders
Jan 25 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:ct692r$2dju$1 digitaldaemon.com...

 Kramer wrote:


 This may be a dumb question, but *currently*, what's the best way
 to actually remove the element from the AA?


 The *only* way at the momement to remove an element is:

 delete b["hello"];


 This confusingly appears to delete the value of b["hello"], but
 does not, it removes the key "hello" from the associative array.


 See http://www.digitalmars.com/d/arrays.html#associative

 --anders


heh - you beat me by 1 minute and our messages are almost identical. freaky! 
:-)
Jan 25 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Kramer" <Kramer_member pathlink.com> wrote in message 
news:ct61cu$24em$1 digitaldaemon.com...

 This may be a dumb question, but *currently*, what's the best way to 
 actually
 remove the element from the AA?

 -Kramer


[snip]

    aa.remove(key);




[snip]

Currently
  delete aa[key]
is the only way to remove an an element. See 
http://www.digitalmars.com/d/arrays.html#associative
Jan 25 2005
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
"Matthew" wrote:


 Please no. Let's just have a simple syntax


[...]

Because I just reinvented that D has the bitweise toggle operator `^' I 
dare a suggestion for the syntax

  array ^ key

with the semantics, that the key is inserted into the array if not 
already present and deleted otherwise. The return value is true if the 
key exists after the operation and false otherwise.

This can yield to expressions loved by C-ish programmers and aversed by 
pascalean:

  key in array && array ^ key && assert(0);

And because we are at it: why introduces the keyword assert an expression 
but the keyword throw a statement? Why is it useful to be pressed to use 
an `ìf' together with the `throw', when refining the rather primitive 
`assert' by thrown exceptions?

And if it is useful to change the `throw' statement to a void expression, 
why dont hold the same arguments of usefulness for the other non 
declarative statements?

-manfred
Jan 25 2005
prev sibling next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
This has been an evil wart for some years, pricking the programming conscience
of all and sundry. However, until now, 
there's never been an unequivocal and uncontestable reason, just the instincts
of many smart and experienced people.

Thank you for providing this case. Now we must all cross our fingers and hope
that Walter will take on board this (real) 
example from the practice and experience of another as reason why we should get
rid of the wart for good.

"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:ct4amm$2b2$1 digitaldaemon.com...

 <specs>
 This confusingly appears to delete the value of b["hello"], but does not,
 it removes the key "hello" from the associative array.
 </specs>

 D is a language that states parts of itself as confusing.

 And that seems not to be neccessary:

  b.delete("hello");

 or

  delete "hello" in b;

 or

  in b delete "hello";

 seem far more appropriate.

 But that is not the main problem.

 Imagine, and i really did that :-), you use an associative array for some
 rudimentary operations. As time goes by the operations on that array
 become more in number and complexity. You want a redesign an put the
 array in a class.

 Naturally there exists some code, that does a `delete b["hello"]'.

 Your redeclaration from some `V[char[]] b' to some `Class b=new Class'
 causes some missing overload errors. Among them the error:
  `no [] operator overload' error.

 But mechanically declaring one throws you into the next pit:
  `opIndex() is not an lvalue'

 You can see: not only you think, that `delete b["hello"]' should delete
 the value of "hello" in b, but also the compiler thinks so.

 But you want to delete the key, not the value, and there is currently no
 possibility to overload the `delete'.

 You are to wear sackcloth and ashes and change all occurrences of this
 delete instead of simply overloading it.

 I do not believe that this is necessary. Can we change this please?

 -manfred
Jan 24 2005
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Manfred Nowak wrote:

(http://www.digitalmars.com/d/arrays.html#associative)

 <specs>
 This confusingly appears to delete the value of b["hello"], but does not, 
 it removes the key "hello" from the associative array.
 </specs>
 
 D is a language that states parts of itself as confusing.


At least Walter is being honest there :-)


 And that seems not to be neccessary:
 
   b.delete("hello");
 
 or
 
   delete "hello" in b;
 
 or
 
   in b delete "hello";
 
 seem far more appropriate.


How about this new "creative" syntax:

      "hello" out b; // remove key:"hello" from hash:b

No new keywords needed there either ;-)

It could even return a pointer to the old entry,
and null if not found ? Or just a sane "void"...

--anders
Jan 25 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
   b.delete("hello");


I think this would be the most logical syntax, as it would simply be another
property of associative arrays (rather than some complex and hard-to-parse
syntax like "in b delete "hello").  Of course, using D's funky property
syntax, it could also be written:

b.delete="hello";

 ;)
Jan 25 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Jarrett Billingsley" wrote: 


   b.delete("hello"); 


 I think this would be the most logical syntax,


[...]

Sometimes first thoughts have best results and your choice points into the 
same direction as matthews `remove' property. But I dislike both:

Against `delete' holds, that it is a keyword and something pertubates me to 
put it in a row with non-keywords as the names of the other properties are.

Against `remove' holds, that it is a synonym of delete and therefore at 
every occurence of delete or remove the writer is required to clarify which 
of both words must be choosen, thereby complicating the writing 
unnecessarily.

So I dare for `toggle' like I did in another branch of this thread.

This word circumvents both arguments given above and furthermore yields an 
explicit notion for the insertion of a key into an associative array, which 
is currently not present.

Remark: currently I use `b["hello"]= b["hello"]' to make clear that an 
insertion is an intentionally one.

The return value might be the same as suggested in the other branch: 
`true' if the key exists in the AA after the operation and `false' 
otherwise.

Then an insertion for a key for which its presence in the AA is unknown 
would look like:

  (! key in aa) && aa.toggle= key;

and a deletion

  key in aa && aa.toggle= key;

Remark: the parentheses at the insertion seem superfluous but the compiler 
generates a "found '!' instead of statement" error if omitted.

-manfred
Jan 25 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:ct6tvo$6sr$1 digitaldaemon.com...

 "Jarrett Billingsley" wrote:


   b.delete("hello");


 I think this would be the most logical syntax,


 [...]

 Sometimes first thoughts have best results and your choice points into 
 the
 same direction as matthews `remove' property. But I dislike both:

 Against `delete' holds, that it is a keyword and something pertubates 
 me to
 put it in a row with non-keywords as the names of the other properties 
 are.

 Against `remove' holds, that it is a synonym of delete and therefore 
 at
 every occurence of delete or remove the writer is required to clarify 
 which
 of both words must be choosen, thereby complicating the writing
 unnecessarily.

 So I dare for `toggle' like I did in another branch of this thread.

 This word circumvents both arguments given above and furthermore 
 yields an
 explicit notion for the insertion of a key into an associative array, 
 which
 is currently not present.

 Remark: currently I use `b["hello"]= b["hello"]' to make clear that an
 insertion is an intentionally one.

 The return value might be the same as suggested in the other branch:
 `true' if the key exists in the AA after the operation and `false'
 otherwise.

 Then an insertion for a key for which its presence in the AA is 
 unknown
 would look like:

  (! key in aa) && aa.toggle= key;

 and a deletion

  key in aa && aa.toggle= key;

 Remark: the parentheses at the insertion seem superfluous but the 
 compiler
 generates a "found '!' instead of statement" error if omitted.


Manfred, I must surmise that you are privvy to a deeper wisdom than I, 
for I cannot fathom any meaning, never mind sense, in all the foregoing.

Maybe it's a language thing, but to me 'remove' and 'delete' have 
unequivocal and distinct meanings. The former takes something out of the 
thing on which the remove() is called. The latter 
destroys/kills/expunges the thing it is told to delete. I certainly 
grant that there is midunderstanding in, say, C++ with the misuse of 
clear() and empty(), but I don't think that extends to 'remove' and 
'delete', at least as far as English-speaking C++ heads (who are me <g>) 
are concerned.

:-)
Jan 25 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Matthew" wrote:

[...]

 Maybe it's a language thing


[...]

I am sure that there exists a view under which the words `delete' and 
`remove' are totally different. But why did you immediately suggest this 
replacement for `delete', when they are so different?

And why lists the online available Roget's New Millennium Thesaurus 
(First Edition (v 1.1.1), Copyright © 2005 by Lexico Publishing Group, 
LLC. All rights reserved.) about ten main entry synonyma, that include 
both words, yielding about 200 sub entries:

abate, abolish, abort, abrogate, abstract, amputate, annihilate, annul, 
ax, batter, black, black out, blank, bleep, blot, blot out, blow down, 
blue pencil, blue ruin, bomb, break, break down, break off, bulldoze, 
call off, cancel, capsize, carry away, carry off, cart off, carve, cast 
down, cease, chuck, clean, clean up, clear away, countermand, crash, 
cross out, cut, cut off, cut out, cut up, decimate, decontaminate, 
deface, dele, delete, demolish, depose, destroy, detach, dethrone, dig 
out, disannul, discard, discharge, dislodge, dismiss, dispatch, displace, 
disturb, do in, doff, drop, dynamite, edit, efface, eject, elide, 
eliminate, eradicate, erase, evacuate, excise, exclude, expel, expunge, 
exscind, exsect, exterminate, extinguish, extirpate, extract, fell, 
finish off, give up, gut, junk, kayo, kill, knock down, knock off, knock 
out, KO, launder, level, lop off, massacre, mow down, negate, nix, 
nullify, obliterate, off, omit, oust, overthrow, overturn, pass up, pull 
down, pull out, purge, quash, raise, raze, reduce, refrain from, 
relegate, remove, render invalid, repeal, repudiate, rescind, resect, 
revoke, rip out, root out, rub, rub out, ruin, rule out, sanitize, 
scatter, scissor out, scratch out, scrub, separate, sever, shed, ship, 
sink, skim, slash, slaughter, slay, smash, snip, spill, squash, squelch, 
stamp across, stamp out, sterilize, stop, strike, strike out, subvert, 
supersede, supplant, take down, take out, tear down, tear out, tear up, 
throw down, throw out, topple, torpedo, total, transfer, transport, 
trash, trim, unbuild, undo, unload, unmake, unseat, uproot, upset, usurp, 
wash out, wipe out, withdraw, wrack, wreck, x out, z, zap

Its up to you to show, that these about 20,000 possible word pairs are 
different under every possible view. Have fun and please post the answer 
from Roget.

-manfred
Jan 25 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:ct79lc$lvl$1 digitaldaemon.com...

 "Matthew" wrote:

 [...]

 Maybe it's a language thing


 [...]

 I am sure that there exists a view under which the words `delete' and
 `remove' are totally different. But why did you immediately suggest 
 this
 replacement for `delete', when they are so different?


Using delete to _remove_ an element from an aa is a misnomer - that's 
kind of the point of this whole thread, I thought! - so there's not only 
no way I would/should/could demonstrate that it's the same, there'd be 
no point. Sigh.


 And why lists the online available Roget's New Millennium Thesaurus
 (First Edition (v 1.1.1), Copyright © 2005 by Lexico Publishing Group,
 LLC. All rights reserved.) about ten main entry synonyma, that include
 both words, yielding about 200 sub entries:

 abate, abolish, abort, abrogate, abstract, amputate, annihilate, 
 annul,
 ax, batter, black, black out, blank, bleep, blot, blot out, blow down,
 blue pencil, blue ruin, bomb, break, break down, break off, bulldoze,
 call off, cancel, capsize, carry away, carry off, cart off, carve, 
 cast
 down, cease, chuck, clean, clean up, clear away, countermand, crash,
 cross out, cut, cut off, cut out, cut up, decimate, decontaminate,
 deface, dele, delete, demolish, depose, destroy, detach, dethrone, dig
 out, disannul, discard, discharge, dislodge, dismiss, dispatch, 
 displace,
 disturb, do in, doff, drop, dynamite, edit, efface, eject, elide,
 eliminate, eradicate, erase, evacuate, excise, exclude, expel, 
 expunge,
 exscind, exsect, exterminate, extinguish, extirpate, extract, fell,
 finish off, give up, gut, junk, kayo, kill, knock down, knock off, 
 knock
 out, KO, launder, level, lop off, massacre, mow down, negate, nix,
 nullify, obliterate, off, omit, oust, overthrow, overturn, pass up, 
 pull
 down, pull out, purge, quash, raise, raze, reduce, refrain from,
 relegate, remove, render invalid, repeal, repudiate, rescind, resect,
 revoke, rip out, root out, rub, rub out, ruin, rule out, sanitize,
 scatter, scissor out, scratch out, scrub, separate, sever, shed, ship,
 sink, skim, slash, slaughter, slay, smash, snip, spill, squash, 
 squelch,
 stamp across, stamp out, sterilize, stop, strike, strike out, subvert,
 supersede, supplant, take down, take out, tear down, tear out, tear 
 up,
 throw down, throw out, topple, torpedo, total, transfer, transport,
 trash, trim, unbuild, undo, unload, unmake, unseat, uproot, upset, 
 usurp,
 wash out, wipe out, withdraw, wrack, wreck, x out, z, zap

 Its up to you to show, that these about 20,000 possible word pairs are
 different under every possible view. Have fun and please post the 
 answer
 from Roget.

 -manfred
Jan 25 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Matthew" wrote: 

[...]

 Using delete to _remove_ an element from an aa is a misnomer -
 that's kind of the point of this whole thread, I thought!


[...]

Now I see your point. With http://dict.leo.org I tried to find a word 
in my native language that is closest to both ... and found two: 
"entfernen" which in our context means "take away to somewhere" and 
"beseitigen" which means "take away to nowhere".

1) In our context the word to be choosen in german should then be 
"beseitigen", because the reurn value of `delete' operation is `void'
2) Without our context I would translate "remove" to "entfernen", which 
would render "remove" unfounded ... in contradiction to your opinion.
3) There is a third word in the translations of "beseitigen" and 
"entfernen": "eliminate". Is this word a compromise :-)

However to me with english as second language the choosen word is of 
minor interest as long as there are no two words in the programming 
language which have approximately the same meaning in the natural 
language and for someone who does not speak english at all, only the 
orthographic distance is of interest.

-manfred
Jan 25 2005
parent Norbert Nemec <Norbert Nemec-online.de> writes:
Manfred Nowak wrote:


 "Matthew" wrote:
 
 [...]

 Using delete to _remove_ an element from an aa is a misnomer -
 that's kind of the point of this whole thread, I thought!


 [...]
 
 Now I see your point. With http://dict.leo.org I tried to find a word
 in my native language that is closest to both ... and found two:
 "entfernen" which in our context means "take away to somewhere" and
 "beseitigen" which means "take away to nowhere".
 
 1) In our context the word to be choosen in german should then be
 "beseitigen", because the reurn value of `delete' operation is `void'
 2) Without our context I would translate "remove" to "entfernen", which
 would render "remove" unfounded ... in contradiction to your opinion.
 3) There is a third word in the translations of "beseitigen" and
 "entfernen": "eliminate". Is this word a compromise :-)


This is exactly the key point: an AA is a collection, so objects are removed
from it ("entfernt", "herausgenommen"). If another reference to the same
object still exists, the object is *not* extinguished.

This is in clear contrast to the "delete" operation on object references.
The object itself is eliminated, purged from existance or whatever you want
to call it.


 However to me with english as second language the choosen word is of
 minor interest as long as there are no two words in the programming
 language which have approximately the same meaning in the natural
 language and for someone who does not speak english at all, only the
 orthographic distance is of interest.


Very true. The words should help the intuition, but in the end, it is up to
the language to actually define their meaning.
Jan 27 2005
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Matthew wrote:


 
 "Manfred Nowak" <svv1999 hotmail.com> wrote in message
 news:ct6tvo$6sr$1 digitaldaemon.com...

 "Jarrett Billingsley" wrote:


   b.delete("hello");


 I think this would be the most logical syntax,


 [...]

 Sometimes first thoughts have best results and your choice points into
 the
 same direction as matthews `remove' property. But I dislike both:

 Against `delete' holds, that it is a keyword and something pertubates
 me to
 put it in a row with non-keywords as the names of the other properties
 are.

 Against `remove' holds, that it is a synonym of delete and therefore
 at
 every occurence of delete or remove the writer is required to clarify
 which
 of both words must be choosen, thereby complicating the writing
 unnecessarily.

 So I dare for `toggle' like I did in another branch of this thread.

 This word circumvents both arguments given above and furthermore
 yields an
 explicit notion for the insertion of a key into an associative array,
 which
 is currently not present.

 Remark: currently I use `b["hello"]= b["hello"]' to make clear that an
 insertion is an intentionally one.

 The return value might be the same as suggested in the other branch:
 `true' if the key exists in the AA after the operation and `false'
 otherwise.

 Then an insertion for a key for which its presence in the AA is
 unknown
 would look like:

  (! key in aa) && aa.toggle= key;

 and a deletion

  key in aa && aa.toggle= key;

 Remark: the parentheses at the insertion seem superfluous but the
 compiler
 generates a "found '!' instead of statement" error if omitted.


 
 Manfred, I must surmise that you are privvy to a deeper wisdom than I,
 for I cannot fathom any meaning, never mind sense, in all the foregoing.
 
 Maybe it's a language thing, but to me 'remove' and 'delete' have
 unequivocal and distinct meanings. The former takes something out of the
 thing on which the remove() is called. The latter
 destroys/kills/expunges the thing it is told to delete. I certainly
 grant that there is midunderstanding in, say, C++ with the misuse of
 clear() and empty(), but I don't think that extends to 'remove' and
 'delete', at least as far as English-speaking C++ heads (who are me <g>)
 are concerned.


I can only agree on this. There is a clear conceptual distinction between
'deleting' an object (i.e. ending its existance) and 'removing' an item
from a list (where the item might still be referenced elsewhere or might be
of a value type that does not even have an 'existance' like an object on
the heap.)

As to using a thesaurus: such a list of words is *not* a list of
indistinguishable synonyms, but one of similar words that may be
exchangable in one context but have a completely different meaning in
another one.
Jan 25 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Norbert Nemec wrote: 

[...]

 There is a clear conceptual distinction
 between 'deleting' an object (i.e. ending its existance) and
 'removing' an item from a list (where the item might still be
 referenced elsewhere or might be of a value type that does not
 even have an 'existance' like an object on the heap.)


Agreed. But
1) according to my available dictionaries `delete' is a technical term 
whereas "remove" is not.
2) Moving implies the existence of the object operated on and a change 
in the location at the end of that operation as well. Both is not true 
in the context we argument on.
3) From any view far enough every discussion becomes trivial. Which is 
undoubtly true for programmers unaware of the english language.
4) because of 3): if any word is choosen for the elimination only of an 
object from an AA for the reason of symmetry another word for the 
creation only must be choosen also --- and learned from every D-
programmer.
5) The requirement of 4) is annuled by one combining both: toggle.

-manfred
Jan 26 2005
parent Norbert Nemec <Norbert Nemec-online.de> writes:
Manfred Nowak wrote:


 1) according to my available dictionaries `delete' is a technical term
 whereas "remove" is not.


What qualifies a "technical term"? Twenty years back, "Window" was not a
technical term and still someone decided to use it for something technical. 


 2) Moving implies the existence of the object operated on and a change
 in the location at the end of that operation as well. Both is not true
 in the context we argument on.


If you have a associative array of object references this is not too far
from the truth. The reference is removed, the object might still survive if
it is referenced from somewhere else. "delete" on the other hand really
extinguishes the object itself.


 3) From any view far enough every discussion becomes trivial. Which is
 undoubtly true for programmers unaware of the english language.


I might not be a native speaker, but I trust myself at least some of the
subtleties of the English language. I love the english language for its
expressiveness, especially when it comes to finding a single word for an
operation (like in this case)

In any case, though, you cannot avoid that D is a different language than
English. We can try to come close so that learning is simplified by
intuition, but the exact meaning of a word will still have to be learned.


 4) because of 3): if any word is choosen for the elimination only of an
 object from an AA for the reason of symmetry another word for the
 creation only must be choosen also --- and learned from every D-
 programmer.


You have the assignment to put objects into an AA. I don't feel that there
is any special "asymmetry" here. All over D, creation and annihilation are
never symmetric towards each other. Objects, for example, are usually not
deleted at all but just dropped to the floor for the GC to clean up.


 5) The requirement of 4) is annuled by one combining both: toggle.


"toggle" sounds like an operation for a two-state switch. If you have a
collection of objects this word sounds rather strange to me. Have you ever
toggled an apple into a basket or out of it?
Jan 27 2005