Yes, if [Infinity] is not [Float infinity] then [Float infinity
	printString] had better not be 'Infinity'.  But in my changeset they
	were in fact the same thing, so why not use the nice printString?

Because you said you want them to be different some day.

	If and when the number hierarchy changes, then yes the
	printString's will have to change as well.
	
And that's not *all* that will break.

Look, we don't *need* an Infinity global variable.
Why not leave it out until we have a real need for it?

	You keep mentioning different kinds of floats, but there is only one
	kind of float *object* in Squeak.

Squeak currently has two different kinds of floats.
It has only one Float class, so only one kind of float can be an object.

	The mini-floats inside of a FloatArray are never reified into
	full objects.  You can't send messages to them, you can't test
	them for identity, and you can't even assign one to a variable.

This is not something to boast of.  It's an inconsistency we'd be better
off without.

	When you talk about different kind of float *objects*, you are
	talking about some other language than Squeak of today.

It's called ANSI Smalltalk.  Squeak has taken several big steps towards
ANSI compatibility of late.  I think someone getting fed up with the
current FloatArray (32) -vs- Float (64) nonsense will start by inventing
a Float32 class, and then realise that this is just ANSI FloatE, rename
it, add a FloatD global, and bingo!  Given that Squeak has a current
proven USE for 32-bit floats, this seems more likely to me than someone
finding real use for Infinity.

	I still do not see why it is a big deal that printing a NaN re-reads as
	the same NaN that you started with.  You reiterated that this happens
	with my changeset--and I believe you--but I do not see why it matters.

If you do not see why it matters, should you be doing this?

	It seems more important to have nice printString's in the inspectors and
	workspaces.

Yes, but currently we DO have nice printStrings:
    Float nan printString => 'NaN'.

Now, I can live with that.  It suits me just fine, because nobody expects
printStrings to read back.  The alleged point of your change set was not
"nice short printStrings in inspectors and debuggers" and
"printStrings that read back".

If you just want "nice printString's in the inspectors and workspaces",
then there's no point in the changeset.  NaN and Infinity and -Infinity
are nice printStrings.

If you want something that will read back, then NaN or even (Float NaN)
won't cut it.  I am not objecting to (Float nan) as a printString.  In
fact, '(Float nan)' is a *better* printString than 'NaN', because if
someone doesn't know what a NaN is, '(Float nan)' just might send them
to look at the comment in Float>>nan, which begins to tell them.

Distinguishing between signalling NaNs and quiet NaNs would be better
still, as they have different behaviour.

	Barring any serious practical reason, I would prefer if all
	NaN's printed out as something pretty short, which would seem to bar
	them from including all 53 bits you say are needed to distinguish them.
	
I have no objection to that AS LONG AS you do not claim that the resulting
code provides a representation that reads back.  But surely that was the
point of this change set?

	The example of code trying to re-evaluate printString's is not good code
	to begin with.  It's certainly not portable--how many Smalltalks
	actually have float printStrings being bit-for-bit re-readable?

Not as many as should.  The Scheme standard *does* require that if you
write a finite floating point number and read it back again you get EXACTLY
the number you started with, to the last bit.  Algorithms for doing this
have been published; they do require bignum arithmetic, but Smalltalk has
that.  For the last 10 years or more, there has been no good reason for a
maintained Smalltalk system *not* to have float printStrings be bit-for-bit
re-readable.

	On the other hand, plenty of Squeakers, over the years, are
	going to look in an inspector or print something out and see
	infinities and nans, and those guys are who printString is designed for.
	
And for them, what we had in Squeak 3.6 works perfectly well.
No change required.

	Finally, why are you mentioning ANSI?  You bring it up but do
	not seem to mention any relevance it has here.  I actually took
	the time to look this up because you mentioned it, and the spec
	seems to explicitly allow float printString's to work however
	the implementation desires.

That's not the point that ANSI Smalltalk is relevant to.
The point ANSI Smalltalk is relevant to is the fact that it has
THREE kinds of floating point number, so that it would have THREE
kinds of floating-point infinity, and they cannot all be called Infinity.