Maybe not in the general public, though it certainly made it
to a large subset of DEC users... and not always favorably!  ;-}  ;-}

+---------------
| >But even better, BLISS has "structures" which were actually little
| >*user*-defined pieces of code for calculating a pointer, including
| >subfields [the "P" (offset) & "S" (width) values above], so a more
| >idiomatic way to write it [assuming "foo" had previously been "mapped"
| >with an appropriate structure] would be:
| >
| >    foo[13, my_nibble] = .foo[13, my_nibble] + 5;
|
| Interesting ... but does a pointer to a partial word have any utility
| beyond device register control?
+---------------

Sure, the same thing as bitfields in C -- any time you have compact
data structures where you want to pack multiple values per machine word.

+---------------
| (Maybe what it was meant for?)
+---------------

Not really. Actually, BLISS's pointers almost *exactly* mirror the
hardware byte pointers in the DEC PDP-10 instruction set. The BLISS code:

    foo[13]<12,4> = .foo[13]<12,4> + 5;

could be written in PDP-10 assembler like this:

    movei t0, foo+15            / Note: Default base in MACRO-10 is octal.
    hrli  t0, 140400            / Make a byte pointer from &foo[13].
    ldb   t1, t0                / Load byte using byte pointer in t0.
    addi  t1, 5
    dpb   t1, t0                / Deposit byte.

If you need the subscript "13" to be computed dynamically, then you
can use the built-in indexing in byte pointers, and construct one
at compile time [assuming you can fix which register will be used
for indexing -- here we assume that "t2" == register 7]:

    myfield: xwd  140407,foo    / Byte pointer to foo[t2]<12,4>

Then the code becomes:

    move t2, ...[the index]...
    ldb  t1, myfield            / The contents of t2 get used by the hardware
    addi t1, 5                  /   in the calculation of the effective addr.
    dpb  t1, myfield

The motivation for having such flexible byte pointers in hardware came
in part from the fact that the PDP-10 was a 36-bit wide word-addressed
machine that used 7-bit ASCII for normal text files [packed 5 to a word
with one bit wasted] but also used *6*-bit subset ASCII for file names
and extensions, as well as keywords in system calls. But the hardware
actually supported *any* byte size from 1 to 36. [In fact, it even
supported a byte size of 0, which gave a sometimes-useful no-op!]

I should also mention that there were also ILDB & IDPB instructions,
which would first *increment* the referenced byte pointer [by decrementing
the "position" field by the "size" field] and then perform the LDB or DPB
function on the ultimate target location. If there weren't enough bits
left in the byte pointer for the field to fit in the current word [the
"position" field went negative], the ILDB/IDPB would increment the *word*
address and reset the position field to 0, thus allowing the use of
ILDB/IDPB to step sequentially through the bytes of a packed string.

-Rob

p.s. Yes, I used mixed-endian conventions in my sample code in the
previous posting. The BLISS code there (and the PDP-10 assembler above)
used big-endian byte descriptions, while the C code used little-endian.
[I was trying to keep it simple.]

I forgot about the PDP's long words, packed strings, etc.  In that
context, having such a field pointer construct makes perfect sense.
Thanks for taking the time to explain them.

To my mind, a "better" version of a programming language should be at
least equivalent in utility - the "better" can be in other dimensions
such as safety and ease of use.  

Gosling wrote that his motivation was to [clean up syntax, remove
redundancy and make the language safer and easier to use]  (I'm
paraphrasing here, the actual quotes are long [1]).

But Gosling did not simply remove redundancy, he also removed critical
language functionality without offering an equivalent.   As compared
to C++,  Java is less expressive and provides less functionality.

How is that making it "better"?  

YMMV, but I don't believe "dumbing down" a programming language can be
considered an improvement.  Programming languages are not door knobs,
toasters or consumer MP3 players ... they are tools that need a sharp
edge.  You can put a guard over the edge or you can teach people to be
careful, but removing the edge makes the tool useless.

Though still far from equivalent, C# nevertheless is closer than Java
to being a functional replacement for C++.

The languages of the C family, including Java, all use Algol's notions
unchanged.

Modulo automatic dereferencing, C and C++ pointers, and Java's
references all are semantically equivalent to Algol's reference
variables.   C++ references include the non-NIL, init-only attributes
of Algol's reference parameters.

[Stroustrup's mistake, I think, was in making C++ references first
class objects akin to pointers.  Had references been simply name
syntax, I don't think there would be as much (or even any) confusion
about them.]

C++ does not have Algol's notion of reference as "syntax" ... it has
only the notion of "container object".  So despite whatever
misconceptions people may have, there is no overloaded meaning.

Similarly, Java has only the notion of "container object".

Moreover, all the notions of "pointers" and "references", regardless
of language, include notions of object identity and aliasing, so those
too are not overloaded meanings.

I presume you're referring to manual memory management and pointer
arithmetic as the tools that Java lacks to make it "less functional".

The world doesn't need a One True Programming Language which solves any
problem under the sun--what you get when you try that is an unholy
kludge of a language which has surprisingly little compiler
interoperability, is truly understood by almost nobody, and which
requires style guidelines to limit you to a strict subset of the
language to be usable in production code.

Instead, it is better to have multiple languages which work very well
for their design goals and are reasonably interoperable between each
other. For example, you can call C code from pretty much any language,
and some dynamic languages even have modules to allow you to dynamically
call C code ("ctypes").

Pointer arithmetic probably has no place in a high-level language. And,
no, much as I like it, I don't consider C to be a HLL - more a structured
assembler.

Unfortunately, I'm not sure at 100% that it would be safe, given how
hard C++ libraries and preconized C++ usage tries to make it hard for a
GC to work well with C++ code...

Nonetheless, some success have been reported, eg. with using Qt with
BoehmGC.

http://www.informatimago.com/articles/life-saver.html

But in ordinary language, a reference is:
- A citation of prior art, listing title of book or journal and
   enough additional information to find the article or book in a
   library. (Used in a new article/book that cites information from
   the prior art.)
- A letter attesting to a claim that somebody is of good quality,
   such as does good work and/or is of good moral character. (Used
   when applying for a job or a security clearance or housing etc.)

So instead of arguing whether C++ or Java uses the word
"correctly", when in fact *neither* does, best to avoid the word
entirely.

For what C++ passes, what the Lisp Machine called locatives, we
should use the Common Lisp jargon "place". Tell the function the
*place* where it is allowed to make references despite the fact
that *place* is in a higher-up space hence normally is forbidden
for access by the called function.
  Place = mutable cell.
  Locative = mechanism by which a place is passed to a function.
All the application programmer cares about is that the function
knows the place; the application programmer needn't know the
mechanism; hence my preference for "place" instead of "locative" in
API documentation.

For what Java passes, we could call it a "handle", because it's
more than just a pointer (machine address), it's a tagged pointer,
something that identifies both the machine address and the type of
data to be found there, by a tag accompanying the machine address
and/or by inspection of what is seen in the target. Likewise Lisp
pointers should also be called "handles" rather than "pointers".

For what C passes, that's just a machine address, with no type info
at runtime, so it's a "pointer". (And with casting to/from void*,
even the compiletime typing isn't really enforced.)
  int x = 5;
  int* px = &x;
  void* pv = px;
  double* pf = pv;
  double y = sqrt(*pf);
Untested. Did I get all that correct? I'm not really expert at C.

BTW many years ago, before Common Lisp, I made a try at designing a
new kind of Lisp where all parameters were places/locatives, even
when a computed value was being passed (the place within the stack
where that temporary value appears would be passed). It would be
the responsibility of the called function to fetch the old value
from that place if it was needed, and/or store the updated value
there before returning. It would be the responsibility of the
application programmer not to waste CPU cycles by passing a
temporary value to a function that was going to change it (and then
after return the caller has no way to make any use of that updated
value). In this way, SETF macros would never be needed. Instead of:
  (setf (car x) 5) ==macroExpand=> (let ((val 5)) (rplaca x val) val)
with my system we could just write
  (setq (car x) 5)
and it would work as-is, compiling code to use the locative to the
CAR of whatever x was at the time. But I was busy with other stuff
and never developed the idea much, and then discovered Common Lisp
with SETF macros and got lazy and just adapted to SETF.

one might as well say any 2 langs is based on any other.

btw, did anyone actually stated that somewhere?

It's amazing to me that Java enthusiasts/apologists have so much
contempt for things they can't seem to master.   Moreover, those same
things are the first thoughts that pop into their heads whenever
someone mentions C or C++.

What Java lacks that limits its utility with respect to C or C++ is
the ability to overlay a logical view of structured data at an
arbitrary memory location.  This ability is the single feature of C
and C++ which makes them strictly more powerful than Java.

[C and C++ union types are not types in their own right but merely
convenience syntax for overlaying views of multiple data structures at
the same location.]

Java doesn't have any equivalent.  The often recommended nio.Buffer,
ByteBuffer, MappedByteBuffer, etc. are severely limited and offer only
some of the functionality of a union type.

First, there is no way *reliably* to obtain an arbitrary location
mapping on memory.   Not all systems will support such mappings and
even if a particular platform does support it (e.g., Linux's /dev/mem,
/proc/<ID>/mem, etc.) there may be in place security protocols in the
JVM and/or host system which will prevent it.

Second, Java provides no way to determine the offset of a particular
data field within an object.  The physical layout of an object in
memory is implementation dependent ... only the JVM knows how to find
an object's data fields.  So even if you could get a reliable location
mapping, you still could not overlay ByteBuffer views of different
objects on it.  Working within Java, you can achieve unions of only
the primitive types.
[Of course, you can achieve a union using JNI, but then you're
cheating by going outside the language ... not to mention that you'll
end up coding in the very language that Java was supposed to have
improved upon.]

In contrast, both C and C++ do guarantee the order of data fields in a
struct.  Field alignment padding is implementation dependent, but
virtually all compilers allow unaligned/unpadded structs if desired.
Both C and C++ provide the standard macro offsetof() for determining
the offset of a data field from the beginning of the structure.  Thus
you could directly access a byte buffer containing an instance of a
struct without overlaying a view of the struct on the buffer.

Moreover, C#, which lots of people accuse of being a clone of Java,
also has the ability to overlay data structures on memory.

Among the many "libraries" that are available for C++ there are ...
OMG! Garbage Collectors ?!?   Not refcounting hacks ... real
collectors from names you might actually recognize - that is if you
know anything at all about GC.

Guess what?  C and C++ programmers don't have to manually manage
memory unless they want to.  True, GC is not a *standard* library ...
yet ... but, you see, there is this thing called the World Wide Web
and it has a thing called "Google" that finds non-standard libraries
for you.  

Searching Google with "C++ garbage collector" you will immediately
locate the best known and very well respected Boehm-Demers-Weiser
collector.  http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Searching Google with "C memory management library" you will find
others, some of which are just as good as BDW.  

There are languages that offer power fully equivalent to C++ but which
are cleaner, safer and easier to use.  Some of them are OO, some are
functional.  Almost all have built-in GC.

Java is not among them.

FWIW: I don't give a rat what language anybody chooses to use.  What I
do care about is that comparisons made between languages be fair and
include ALL the relevant information so that people unfamiliar with
them are not drawing erroneous conclusions from unsupported claims.  

union {
int a;
double b;

The value of double is undefined. And let's not get into type punning.

I have occasionally desired union types in Java, but never really union
types.

In any case, I have found little reason to do this, even in C or C++.
About the closest I can think of is mmap'ing binary files for
performance--nio can do that--or perhaps easier binary I/O, in which
case Java's Object{Input,Output}Stream is sufficient for my
serialization needs.

You also forgot about the implementation-dependent issue of endianness.

[1] Specifically, I was trying to write a C++ bridge library for dynamic
interlanguage trampolining, and needed offsets to the fields of a class,
so my use case totally involves non-POD classes.

Java is syntactically in the C/C++ family, but it follows a pretty
different philosophy. While certainly limiting expressiveness in some
situations, and requiring definitely too much verbosity in others, it
is far more dynamic than most people think. It has GC, some form of
runtime typing, dynamic code loading, poor man's closures,
reflection... In that regard, Gosling's sentence about Java bringing C+
+ programmers halfway to Lisp is not far off.

My answer is:
- emergent properties,
- turing equivalence,
- virtual machine.

That is, mostly: do not care what occurs on the host.  
You can write any power inside the VM.

Of course, if your definition of power is to use the raw hardware, then
you should go to assembly, or C.

But if you accept to abstract things away a little, then any Turing
Equivalent VM can be more powerful, in the sense that it will let you
write more efficiently programs that are more expressive and more able
than anything you could do on bare hardware or with crude tools such as
C or C++.

In the specific case of memory management, it may be very difficult or
even impossible to mix and match objects obtained from different
libraries.

The intention, as I understand it, of the union was a sort of
polymorphism that would allow an array or list of structs to be built
with one or more common fields in the struct together with a union of
other structs and/or data types. One of the common fields says what
member of the union is being used in this instance of the container
struct.  

The only HLL where memory remapping works as you would expect is COBOL,
and even there its only really useful if the REDEFINES all map onto a
character string and all the definitions have the same length. If you try
to do anything else you get tripped up by the alignment requirements of
COMPUTATIONAL data items and end up confusing the hell out of any poor
sod who has to maintain the mess.

  public interface Unyon <T>
  {
    /** @return T underlying value. */
    T getValue();
  }

  public class Intyon implements Unyon <Integer>
  {
    private final Integer value;
    /** @param v Integer wrapped value. */
    public Intyon( Integer v ) { this.value = v; }
    @Override
    public Integer getValue() { return this.value; }
  }

  public class Doubyon implements Unyon <Double>
  {
    private final Double value;
    /** @param v Double wrapped value. */
    public Doubyon( Double v ) { this.value = v; }
    @Override
    public Double getValue() { return this.value; }
  }

Java works pretty well as a type-declarative language..