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

    aa.remove(key);


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"); 


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");


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");


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