Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Laurence Tratt (laurie@tratt.net)
Date: Tue 18 May 2004 - 17:32:10 BST


On Tue, May 18, 2004 at 05:42:39PM +0200, Shane Sendall wrote:

Dear Shane,

>> Most languages that I am aware of do not, at the user level, differentiate
>> between "this value has NULL assigned to it" and "this value is undefined"
>> - NULL is all that is given to the user. Note that I am aware of several
>> languages which *internally* have a way of noticing that certain variables
>> and slots have not yet been assigned to, but there's no way for the user
>> to test for this other than causing an exception to be generated.
>> Certainly, my own Converge language follows in these footsteps, so that I
>> can detect people attempting to read from variables before they have been
>> assigned an initial value. Once an initial value has been assigned (be it
>> NULL or anything else), it is impossible for the variable to return to the
>> "undefined" state.
> It is interesting that you differentiate between "never been initialized"
> and "uninitialized". Can you whet our appetitte further by giving us some
> examples of where you use this, i.e., some motivating examples?

OK, I'm not 100% sure if I was clear before, so I fear you might be
expecting some profundity that is never likely to arrive ;) I'll try and
explain what I meant. Please let me know whether this answers your question
or not.

I'll present this example in terms of variables, although it's easy to
imagine it in terms of attributes. Imagine this in pseudo code:

  Object o;

  o = null;

  if (o == NULL)
    print "o is NULL"
  else
    print "o is not NULL"

That works fine. The user can test whether o has a value assigned to it -
that value may or may not be NULL.

Now imagine this:

  Object o;

  if (o == NEVER_BEEN_ASSIGNED_TO)
    ...

where you want to see if 'o' has ever had a value assigned to it. This almost
makes sense until you then realise that you could use NEVER_BEEN_ASSIGNED_TO
to do this:

  Object o;

  o = NEVER_BEEN_ASSIGNED_TO;

which is something of a contradiction in terms, because the point of this
value is to detect that noting has been assigned to a variable. After an
initial assignment, the variable should never be able to get back into that
unassigned state. Probably the only way to actually test to see if o has yet
been assigned to is:

  Object o;

  try {
    Object o2;
    o2 = o;
  }
  except (Not_Been_Assigned_To_Exception)
    print "o has not been assigned to yet"

What's important to realise is that NULL is nothing special in and of
itself. In my Converge language, it's just an object which by convention is
"the" NULL object. You can do all the normal object stuff on NULL, it's a
bog-standard object. It really needs to be a normal object, because the
compiler and run time 99% of the time explicitly mustn't care whether a
particular object reference being passed around is to the NULL object or
not.

However the "nothing has been assigned to this variable" value isn't an
object in Converge, because it doesn't really make sense to do so.
Essentially, as soon as that value is detected as being used (e.g. someone
reads a variable with that value), an exception is generated. So because you
can't ever have a reference to an object that causes an exception when you
try and examine it, it's not really an object. Think of it like government
ethics: as soon as you try to pin them down, they disappear, and therefore
they never really exist ;)

Notice there is a slight subtlety with my use of language here: NULL is an
object, NEVER_BEEN_ASSIGNED_TO (or whatever we call it) is a value.
NEVER_BEEN_ASSIGNED_TO is implicitly "more primitive", at least internally,
to the language implementation. The concept of an object is all that is
known to the user: values are an implementation detail entirely hidden from
the user.

OK, now why would this distinction be useful? Well, as one simple example,
imagine this valid pseudo code in a function:

  Object o = NULL;

  return o;

and this:

  Object o;

  return o;

This second function return is *very* different, and erroneous because
there's nothing in fact to return. As was pointed out earlier you can't use
NEVER_BEEN_ASSIGNED_TO as an assignment, so it can't be allowed to "leak"
via the return statement to the user level. So the language implementation
needs to be able to detect this state.

Yours,


Laurie
-- 
http://tratt.net/laurie/

Date view Thread view Subject view Author view Attachment view