Conference turris::languages

Dereference: An operation applied to address values, specifically,
indirection.  (Yes, the same as the Bliss dot.)

I looked in several older books from when I was in school and didn't see
any references to it.  On the other hand, it is in "Programming in Modula-2"
[Wirth, 3rd ed., 1985], and I suspect it was probably in the first edition
as well (1982).  Specifically, page 76:

    "...  The created variable is saud to be \dynamically created\
     (allocated); it has no name, is anonymous, and can be accessed
     via a pointer using the \dereferencing operator\ ^."

It seems to me that the terminology "dereferencing a pointer" has been
in common use for a while (5+ years)...

Kent

   Re: .0:

   In C, the dereference operator is "*", as in "*a = 5;", or the
language construct "->" to represent both dereferencing and an
attribute reference (as in "a->b" means "(*a).b" and/or "a*.b").

   "&" removes the implicit dereferencing that happens when most
languages reference variables/storage.  (The notable obvious expception
is BLISS, where you have to explicitly dereference all memory references,
not just "pointers".  The intent in the language design, which was mostly
done to make the implementation easy and no other reason, was that the
dereference node which you'll normally stick on your internal representation/
tree of the code will just be combined with the "reference" node, leaving
you with the address of the storage.  This is why some C compilers - PCC
notably included, I believe - don't permit things like
"func(a,b,&1);", as the constant 1 isn't in storage, and doesn't have an
implicit dereference to remove.)

   Back to the topic.


					-mjg

    Re .1  "Dereference" is much older than 5 years.  I believe the term
    was introduced with Algol 68, which used the term REFERENCE in its
    type structure:
    
    	An integer value is of type INT.
    	An integer variable (a name which refers to a value) is of type
    	REF INT.
    	A pointer to an integer variable is of type REF REF INT.
    
    Dereferencing was the name of a "coercion" which the compiler applied
    to a value to convert it to a type more suited to the context.  For
    example, in the expression "X + 1", if X is an integer variable (of type
    REF INT), the compiler would dereference the name X to obtain the INT
    value currently held in it.  Similarly, if X were a pointer to an
    integer variable (type REF REF INT), the compiler would dereference X
    twice to obtain the integer value.
    
    Dereferencing was one of a number of coercions that the compiler
    performed when the name supplied didn't quite match the type required
    by the context.  Other coercions were "widening" (converting a value to
    a value of a more general type, for example and INT value could be
    widened to a REAL value), "deproceduring" (calling a valued procedure
    if the result value had a type more suited to the context than the
    procedure value itself), "rowing" (converting a value into a single
    element array in contexts that require aray values), and "voiding"
    (discarding a value, for example at a semi-colon).
    
    This was a very general type-conversion mechanism, and once you get
    used to it, it is both powerful and straightforward, but unfortunately
    it doesn't work so well with languages that use a Pascal-stye type
    structure (type-equivalence by name rather than by structure), which
    has been the dominant type structure in recent years.  However,
    Modula-3 has bucked the trend and adopted type-equivalence by
    structure, so maybe some of the good ideas of Algol 68 haven't been
    forgotten after all.

What's wrong with the word `fetch'?

It seems to me that its advantages are

	it's short (5 letters)
	it's a verb
	it's a real word
	it's meaning seems to be consistent both in the computer and real world

I suppose that a simple word with intuitive meaning might making computers
too understandable.

The note about deproceduring(?) made me thing of deprogramming.

deprogramming - the process of converting a program in to execution
			ie., `compile, load, and run'

.4> What's wrong with the word `fetch'?

"Fetch" can be applied to any data reference.  "Dereference" 
specifically applies to pointers, in my experience (previous replies 
to the contrary).

.4> I suppose that a simple word with intuitive meaning might making computers
.4> too understandable.

That's the case with any technical field; specialized use of language 
marks you as one of the "in" crowd, one of the shamans.  You should
hear my wife go on about medical jargon (she's a medical student). 

another attempt:  (that also makes clear why 'fetch' is wrong)

(notice: My examples are not related to computers)


step one:

You have a (data)item. You can access this item or you can create a reference
to it and access the item via this reference. You may even create another 
reference that references the first one.


step two:

You have a reference to some (data)item. You 'dereference' it to access the
item. This one probably is also a reference. So you may 'dereference' a
second time. You have now 'dereferenced' the first item twice. (But you did
not 'fetch' the first item twice).


create a reference       <---->    resolve that reference

to reference something   <---->    to dereference something


---markus---

When I reference(sic) a dictionary, I retrieve some information from it.
Then I dereference it, you know, I put it back on the shelf.

So, it seems to me that referencing is the process of getting the information
and dereferencing is doing nothing: `de- comb form, 1. reversal or undoing
2. removal, 3. degradation; reduction  4. disparagement.

Now, as I think about it, I can come up with a use of reference that is
contrary to the above.  When writing a paper, I might reference my sources
of information (although I'd normally cite them), which you might consider
the act of creating a pointer to the actual information.  In this case,
the process of dereferencing might either mean deleting the reference, or
including the original information. It seems to me that this would only
apply to pointers and not to names.  Thus, in BLISS .foo would not be a
dereference, but a fetch, while ..foo would be a dereference.

This is a lot like Alice in Wonderland.....

>It seems to me that this would only apply to pointers and not to names.
    
    But a name _is_ a pointer, at least conceptually.  They're both ways or
    refering to values.  Some languages treat names and pointers
    differently, in that different operations are allowed, but conceptually
    there's no difference.  In Algol 68 (where all this was first formally
    proposed) there is no difference at all - a name is just the
    programmer's denotation for a pointer, much as the character "1" is the
    denotation for the bit value representing the first positive integer.
    
    "Dereferencing" is simply the act of "undoing" a reference - ie looking
    up the value that the reference (name or pointer) refers to.
    
    Your example of references in a paper is exactly the right one.  The
    paper contains a set of references, each of which is a pointer to
    another paper (or a name of another paper - even English doesn't draw
    much distinction between names and pointers!).  Dereferencing the
    reference is the act of getting one of the papers referred to from the
    library.  Not copying the contents of that paper into your original
    one, just "getting" it, or making its value available for subsequent
    use.  You started at the reference, an object of type
    REFERENCE_TO_PAPER, and used that to obtain an object of type PAPER -
    in other words you have removed the reference _from the object type_,
    hence the term "dereference".  C might have called this operation
    "de-starring" - removing a "*" from the type (except that C doesn't
    really have types, it just pretends to :-).
    
    "Fetch" is close, but not precise enough, in that it doesn't specify
    which object you end up with.  If I "fetch" a pointer, it sounds like I
    should end up with a pointer; if I dereference it, I get the value that
    it pointed to.  Similarly, if I fetch a name, it's not obvious whether
    I obtain the name itself, or the value that the name refers to; 
    Dereferencing the name always means obtaining the value.
    
    The word originally had a very precise meaning, which was based on the
    rigorous type model of Algol 68, and the terms defined by that
    language.  Used outside that model, some flexibility of interpretation
    is called for.  If you're really interested in the original meaning,
    look at the Algol 68 report (not the revised report - nobody has ever
    managed to extract any meaning whatsoever from that :-)
    
    John

    We should be greatful that the relatively sane term dereferencing is
    used rather than some of the other terms that were flying around when
    the issues of dealing with indirection in programming languages were
    being worked.  

    BCPL attacked the same problem, at the same time, but in an untyped
    language.  The original BCPL manual had a long and confusing second
    chapter.  It described a named memory location as having two values, a
    RHV or contents and a LHV or address.  RHV stood for Right Hand Value,
    or the value to use on the right hand side of an assignment.  LHV was
    Left Hand Value - the value to use when the name was on the left hand
    side of an expression.  As I have trouble telling my right from my
    left, I did not find these menomics intuitive at all. 

    Despite the difficult description, BCPL got the functionality right,
    and it is very natural to write programs that use pointers in BCPL. 
    Bliss, another language from the same era, and whose design center
    relvolved around the same problem, chose a different and less natural
    path.  

    The joke about Algol 68 was that the language was designed by Dutchmen,
    and this explains their tortured uses of the English language.  I used
    Algol 68 in the early 70s, and it helped me understand how to program
    with indirection, so much so that I could then write BCPL easily,
    notwithstanding Chapter 2 of the manual.  

    Just in case you thought we'd cleared the issue up, there's also the
    Prolog implementor's definition of dereference.  In most
    implementations of Prolog, as in LISP or APL, objects at runtime are
    tagged with their datatype.  In Prolog, however, there are certain
    situations in which a long chain of pointers to pointers to pointers to
    objects can be created implicitly.  The Prolog programmer has no
    knowledge of this, and thus the implementation must hide this detail by
    "dereferencing" such pointers.  In this case, "to dereference" means to
    fetch the value of a pointer repeatedly until the tag of the result no
    longer indicates a pointer type.
    
    	:Karl.

Speaking of using short, strong words:

Why is the verb "to reference" necessary when we can say "to refer to".
Isn't it equivalent?  Is "to reference" used anywhere but in the discussion
of software pointers?

					Ralph

P.S.  If you really want precisely defined but otherwise obscure jargon, you
      should take a look at the glossary of an Ada Language Reference Manual.
      The military are experts in this sort of thing... :-)

    Reference is not a verb but a noun.  A reference is usually implemented
    as a pointer to an object.  When an object is created, a reference to
    the object is returned.  The operations that most often apply to a
    reference are copy and dereference.  
    
    As someone once said, "The great thing about the English language is
    that you can verb any noun".