Open Stuffit Expander (or whatever you're using) and set up the Preferences
	to "never" convert files to Macintosh format, save the Preferences, and try
	again.
	
Thank you ever so much.

Could someone please add this information to
http://squeak.cs.uiuc.edu/#download?

I just discovered that
http://minnow.cc.gatech.edu/squeak/306
_does_ have this i8nformation, but it lists the uiuc page as the
"The official Squeak Download".

	Again, I can't see Squeak being blamed here - it's the result of an
	overenthusiastic Macintosh utility arguably doing something it shouldn't,
	and it does the same thing to other applications and files.

The irony is that I had downloaded a recent version of Stuffit Expander
to make sure that all would go well.  *Sigh*.

	While it could
	be said that Squeak should notice sooner and tell someone about it, it
	would only ever be a partial solution to someone else's problem.
	
It's not some*one* else's problem, it's a whole raft of other people's
problems.  There are lots of ways files can get mangled when you ship them
around the Internet and use an operating system (MacOs) that occasionally
hangs in the middle of who-knows-what.

	Perhaps SqC will someday see fit to set the file types of these files to
	something a little less likely to provoke's UnStuffIt's friskiness.
	
What a good idea.


On the subject of types, I've finally understood the "types are
constraining" argument.  If you look at the Smalltalk-80 collection
classes, they're a mess.  Extremely useful, I grant you.  But they
are also extremely confusing, because the designers did not believe
that "if X is a subclass of Y, then X should support all the protocols
of Y".  A typeful language, such as Eiffel or Haskell, would have a
terrible time with these classes, and that's *GOOD*, because so do I.

In other words, (good) type systems are there to enforce a certain kind
of consistency in design, with no exceptions.  That *is* a constraint
on designers, but it makes life a lot simpler for people *using* the
classes.

There are weak type systems, which burden the designer without giving
the library user any useful guarantees.  C springs to mind, pounding
its chest and coughing horribly, but so does Pascal.  There are strong
type systems which are inexpressive, so that the designer is limited in
fairly useless ways without being able to state (and have guaranteed)
many useful high level constraints.  Java leaps to mind, strutting and
flashing its chains and pierced nipples.  (A well designed type system
neither allows nor needs casts.)  There are type systems which give the
compiler lots of help without giving library users many guarantees.
There I'm thinking of the type inference system in the Stalin compiler
for Scheme.  It produces spectacularly efficient code, starting from a
source language with pure latent typing like Smalltalk.  But it does
not protect the programmer from himself, or from other programmers.

The interesting questions then are what kinds of *good* designs are
ruled out by a type system, and whether/how the type system could be
changed to allow what is good about them.