"Juan Vuletich" <jmvsqueak at uolsinectis.com.ar> wrote
	[that with 64-bit Squeak, it would be good to have several
	 immediate types, including]

	- Another very useful one would be Float (with a range of 61 bits, and
	primitives working with 64 bit floats. The mantissa should be completed with
	3 zeroes on primitive entry, and have the last 3 bits truncated on primitive
	exit.) I believe this one would alse be useful in VI 4 32-bit image. I
	believe 32 bits pointers should be aligned by 32 bits, needing 30 bits, and
	leaving space for 2 extra inmediate objects. Floats should be one.
	Primitives would work with 32 bits floats, and the mantissa should lose 2
	bits (instead of 3).
	
Early versions of Quintus Prolog handled floats this way, stealing a few bits
out of the bottom of a word.  Bad idea.  ***BAD*** idea!   REALLY incredibly
bad idea.  It means, for example, that calculations done in Smalltalk and
the same calculations done in C would not agree; for non-trivial calculations
the results might not even be close (probably wouldn't be).  Possibly the
only aspect of QP that anyone despised.  We thought it would be OK for
graphics.  We were wrong, WRONG, *WRONG*.  Don't even think of doing this
unless you can hire Kahan or one of his students to get the details 100% right.

	- ShortSymbol.  We could have some short symbols coded in the
	object pointer.  This would allow to shrink the symbol
	dictionary, saving memory and making symbol creation faster.
	Anyway, the only performance improvements would be on symbol
	creation, mostly when compiling methods, but it could be useful
	anyway.  ShortSymbols would only be allowed to be made of:
	A..Z, a..z, 0..9, and :. They would use only 6 bits per
	character, and they can be up to 10 characters long.  Many
	selectors could be ShortSymbols.
	
In effect, WAM-based Prolog systems do this.  They represent *all* atoms
as (index into atom table|TAG).  This pays off because the vast majority
of operations on Prolog atoms are just equality tests or hash code
determination, both of which work better on the index than on a pointer.
However, that's not how Smalltalk works.  For Smalltalk, the increased
cost of message sends really isn't justifiable.

	- Character. I always found strange that a character would use more memory
	space than a SmallInteger.

*References* to characters are already the same size as a SmallInteger.

	Perhaps a good inmediate character representation
	could make multi-lingual and multi-alphabet strings easier. I guess Yoshiki
	could think if this is a good idea. Perhaps in 61 bits we could also have
	space for coding some format information: bold, italic, outline, font, size,
	color, etc.

Please, let's not go there.  Lisp Machine Lisp had "font" and "bits"
attributes on characters; those were in CLtL1, but they were dropped
completely from CLtL2 and the ANSI Common Lisp standard.  The idea of
requiring 64 bits per character in strings (so that you can hold on to those
properties) doesn't appeal, and nor does a CLtL1-style distinction
between "characters" and "string characters".  It's bad enough needing
21 bits for Unicode characters...  I _don't_ want to have to wonder
whether an italic $i is equal to a slanted $i.  I particularly don't
want to have to worry about moving a #\Paladino-12-slanted-X character
to an image that doesn't have a Paladino font available.

In short, DTSTTCPW.