"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B861237.731DCE02@estarcion.com...
> Walter wrote:
> > > On the topic of ambiguities:
> > >
> > > char[] Key = "idontcare";
> > > assoc[Key] = new Thingy();
> > > delete assoc["Key"];
> > >
> > >Am I deleting the Thingy, removing Key from assoc or both?
> >
> > Good question. I don't have an answer at the moment!
>
> Yeah, I didn't like the use of "delete" for the assoc-array removal operation.
>
> But on the other hand, it would seem like assoc["key"] is a reference to the Thingy; if delete only deleted the Thingy, without removing the entry from assoc[], you'd have a dangling reference; if it only removed the reference and left the object, the GC would eventually clear it. The question of when GC gets run is still under debate, but it seems like the eventual end result is "both" -- the key/entry in assoc and the Thingy are both destroyed in the end.
>
> -RB

"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B861237.731DCE02@estarcion.com...
> Walter wrote:
> > > On the topic of ambiguities:
> > >
> > > char[] Key = "idontcare";
> > > assoc[Key] = new Thingy();
> > > delete assoc["Key"];
> > >
> > >Am I deleting the Thingy, removing Key from assoc or both?
> >
> > Good question. I don't have an answer at the moment!
>
> Yeah, I didn't like the use of "delete" for the assoc-array removal operation.
>
> But on the other hand, it would seem like assoc["key"] is a reference to the Thingy; if delete only deleted the Thingy, without removing the entry from assoc[], you'd have a dangling reference; if it only removed the reference and left the object, the GC would eventually clear it. The question of when GC gets run is still under debate, but it seems like the eventual end result is "both" -- the key/entry in assoc and the Thingy are both destroyed in the end.
>
> -RB

Oopsie, sent off too soon.

How would you then go about removing the item from the associative array without destroying the object?  For instance if it were still referenced by some other array?

What about something like:

assoc ~["Key"]; // remove from array

Sean

"Sean L. Palmer" wrote:
> How would you then go about removing the item from the associative array without destroying the object?  For instance if it were still referenced by some other array?
> 
> What about something like:
> 
> assoc ~["Key"]; // remove from array

I believe the current D-canonical method of doing this is:

 assoc[ "Key" ] = NULL;

This unlinks the element at "Key" from the associative array. If
there are no other references to the element, eventually the
GC will destroy it.

-RB

> > How would you then go about removing the item from the associative array without destroying the object?  For instance if it were still referenced
by
> > some other array?
> >
> > What about something like:
> >
> > assoc ~["Key"]; // remove from array
>
> I believe the current D-canonical method of doing this is:
>
>  assoc[ "Key" ] = NULL;
>
> This unlinks the element at "Key" from the associative array. If
> there are no other references to the element, eventually the
> GC will destroy it.
>
> -RB

That sounds much better.

Question:  is D case-sensitive?  If it is, can I request that if there's a NULL keyword that it be lowercase like all the other keywords?

Sean

"Sean L. Palmer" wrote:
> Question:  is D case-sensitive?  If it is, can I request that if there's a NULL keyword that it be lowercase like all the other keywords?

It's case sensitive. According to:

 http://www.digitalmars.com/d/lex.html

the keyword is in fact spelled "null" rather than "NULL".

-RB

Russell Borogove wrote:
> 
> "Sean L. Palmer" wrote:
> > How would you then go about removing the item from the associative array without destroying the object?  For instance if it were still referenced by some other array?
> >
> > What about something like:
> >
> > assoc ~["Key"]; // remove from array
> 
> I believe the current D-canonical method of doing this is:
> 
>  assoc[ "Key" ] = NULL;
> 
> This unlinks the element at "Key" from the associative array. If
> there are no other references to the element, eventually the
> GC will destroy it.
> 
> -RB

	So you can have a key that references a null pointer?  Or is it assumed
that all possible keys are in every associative array be they "default"
to null.  If so, does that mean there is no way to differentiate between
key that have null assigned to them and keys that were never defined or
were meant to be undefined?

Dan

a wrote:
> 
> Russell Borogove wrote:
> > I believe the current D-canonical method of doing this is:
> >
> >  assoc[ "Key" ] = NULL;
> >
> > This unlinks the element at "Key" from the associative array. If
> > there are no other references to the element, eventually the
> > GC will destroy it.
>
>         So you can have a key that references a null pointer?  Or is it assumed
> that all possible keys are in every associative array be they "default"
> to null.  If so, does that mean there is no way to differentiate between
> key that have null assigned to them and keys that were never defined or
> were meant to be undefined?

Hmm, let me weasel a bit; according to the current online spec, we are supposed to:

   delete assoc[ "Key" ];

rather than:

   assoc[ "Key" ] = null;

...though I don't know if Walter has nailed this down yet, due
to some uncertainty about whether "delete" should have GC-hazardous
semantics, or whether it should encourage a GC recovery pass, or
whether it should simply unlink a reference.

Anyway, if "delete" has some semantics beyond simply unlinking, then we want some way of simply unlinking, for which the null assignment seems appropriate.

For the null assignment, my expectation would be that makes the element of the associative array act as if it had never been defined. The spec is currently silent on what happens if you do:

   int[ char[] ] assoc;   // string-to-int mapping

   // assoc is virginal, all undefined

   assert (!("Key" in assoc));

   int result = assoc[ "Key" ];

In my opinion, whatever happens here should also happen in this case:

   assoc[ "Key" ] = 99;
   assoc[ "Key" ] = null;  // undefine it, not assign integer 0 to it
   int result = assoc[ "Key" ];

*whew* Does that make sense?

-RB

Russell Borogove wrote:
> Hmm, let me weasel a bit; according to the current online spec, we are supposed to:
> 
>    delete assoc[ "Key" ];
> 
> rather than:
> 
>    assoc[ "Key" ] = null;
> 
> ...though I don't know if Walter has nailed this down yet, due
> to some uncertainty about whether "delete" should have GC-hazardous
> semantics, or whether it should encourage a GC recovery pass, or
> whether it should simply unlink a reference.
> 
> Anyway, if "delete" has some semantics beyond simply unlinking, then we want some way of simply unlinking, for which the null assignment seems appropriate.
> 
> For the null assignment, my expectation would be that makes the element of the associative array act as if it had never been defined. The spec is currently silent on what happens if you do:
> 
>    int[ char[] ] assoc;   // string-to-int mapping
> 
>    // assoc is virginal, all undefined
> 
>    assert (!("Key" in assoc));
> 
>    int result = assoc[ "Key" ];
> 
> In my opinion, whatever happens here should also happen in this case:
> 
>    assoc[ "Key" ] = 99;
>    assoc[ "Key" ] = null;  // undefine it, not assign integer 0 to it
>    int result = assoc[ "Key" ];
> 
> *whew* Does that make sense?

	Sure.  So we'll never want to differentiate between an undefined value
and a value defined to Zero.  There is no difference between a value
explicitly defined to be zero and one the programmer forgot/neglected to
set.
	That also means that ("Key" in assoc) == (assoc["Key"] != null).  Guess
we don't need that in keyword anymore.  BTW, what is the floating point
equivalent to null?  Zero or NaN?  The default value for a float is NaN,
however it seems odd that you can store a floating point zero in an
associative array, but you cannot store an integer zero.  Seems almost
arbitrary.  On the other hand, it would be odd for the default value of
a float to be different in and associative array than in any other
context.  Making an assignment of zero revert to NaN would also be a bit
rude.
	I will say that the inability to differentiate between zero and an
undefined key could have adverse affects with regard to using an
associative array as a form of symbol table.
	I do agree that reading from an undefined key should return the default
value.  I suppose some might thing that it ought to throw something.  I
could live with either, but I bet I'd find the default value use more
often than a throw.
	I also agree that using an undefined Key as an lvalue should create and
set it.  Since there is no special syntax for creating a key, it seems
there is nothing to argue against.  This is the only way to create a
key.  If you want to throw when setting a key that isn't defined, you
have to check.  Personally, I have no problem here.
	I don't see a way around storing a meaningful zero and differentiating
it from an oops though if they are equivalent.  You'd have to have the
overhead of a class or at least a pointer so you could have a meaningful
zero.  The ability to store a zero has to be trivial.  You just have to
have a way to tell if the value is defined (ala in) and to undefine it
once it has been defined.  That's where the delete ambiguity came in.
Making null/zero assignment undefine the value seems like a nasty way to
get around adding a keyword.  You are trading functionalities here, not
just conveniences like the example of how you handle accessing an
undefined key.

Dan

a wrote:
>         Sure.  So we'll never want to differentiate between an undefined value
> and a value defined to Zero.  There is no difference between a value
> explicitly defined to be zero and one the programmer forgot/neglected to
> set.
>         That also means that ("Key" in assoc) == (assoc["Key"] != null).  Guess
> we don't need that in keyword anymore.  BTW, what is the floating point
> equivalent to null?  Zero or NaN?  The default value for a float is NaN,
> however it seems odd that you can store a floating point zero in an
> associative array, but you cannot store an integer zero.  Seems almost
> arbitrary.  On the other hand, it would be odd for the default value of
> a float to be different in and associative array than in any other
> context.  Making an assignment of zero revert to NaN would also be a bit
> rude.

Nonono, that's not what I was suggesting at all -- a null reference
is different from a reference to zero. You can store zero integers,
or ((float)0x00000000), just fine. When the compiler sees an
assignment of null (which is a keyword in D, rather than a macro
evaluating to zero), it would have to generate the equivalent of
a delete, rather than an assignment.

And I don't know whether reading an undefined element should return a default or throw an exception. I'd lean towards throwing an exception.

-RB

Charles Jenkins wrote:
> 
> Please excuse me if this idea is naive, has already been hashed over, etc. What about NOT using the operator '.' to access the intrinsic properties like size that aren't really members.
> 
> Just to make something up completely off the top of my head...
> 
>   int  i = X#size;

Ada uses ' (x'size); it complicates the lexical analyser a bit (not much though). Alternatively, how about x!size or x$size? Using ! as infix should be unambiguous, and I don't think $ is used eleswhere...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------