There are a few different reasons. I'll list them in ascending order of
importance, as I see them:
1. Compatibility with other Smalltalks. Being able to port code around
is a good thing.
2. Compatibility with thing that refer to Smalltalk syntax, like books
and ST parsing tools. These include, but are not limited to the
RefactoringBrowser and the related tools, like Smalllint. 
3. Simplicity. Today we can excuse an extension because we need fast 3d
graphics, tommorrow we'll find another that's very convinient for
printing financial information, and before you know it, we'll be
programming in CobTran. Or ForBol. Or something just as elegant.

It's really mostly the third - I like Smalltalk small. I've heard from
David Simmons all the best reasons to extend the Smalltalk syntax in
magnificently ingenious ways, serving scenarios much more common,
AFAICT, than matrix operations (easy interoperability with c headers),
and my conclusion is that that's great for the expert, not such a hot
deal for the newbie, and the expert can override compilerClass.

BTW, if we start playing with compilerClass, it would also be a good
idea to color such classes differently in the browser, or something like
that, to indicate where the rules change...

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> Daniel,
> 
> > Does it seem reasonable to you to use the #compilerClass hook to
> > localize the effects of the Matrix hacks?
> 
> The changes are a true language extension. No previously valid
> expression is now invalid. Some previously invalid expressions are now
> valid and have a well-defined semantics. In that sense you can write
> perfectly "compatible" code if that is what you are after. I can't see
> any reason for why anyone would want to restrict the extensions to
> certain classes.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org 
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > Behalf Of Daniel Vainsencher
> > Sent: Thursday, December 05, 2002 9:27 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Re: Croquet alpha release(s?)
> > 
> > 
> > On one hand, beating C++ performance at numeric stuff with 
> > such a clean
> > interface is surely nice. On the other hand, assuming most of the code
> > in squeak remains very much unrelated to such things, I would 
> > prefer to
> > leave the default compiler (and even more so, the default syntax)
> > unaltered.
> > 
> > Does it seem reasonable to you to use the #compilerClass hook to
> > localize the effects of the Matrix hacks? I think of this as a less
> > drastic plugin technology for a specific kind of performance critical
> > code, similar to primitives. Or do you see Matrix operations becoming
> > common to so many people that the two dialects would only be 
> > confusing?
> > 
> > Daniel Vainsencher
> > 
> > "David A. Smith" <davidasmith at bellsouth.net> wrote:
> > > PhiHo,
> > > To that end, we will be incorporating our general purpose 
> > > n-dimensional Matrix class which is intended to be used to 
> > access the VPUs 
> > > in a clean way.
> > > 
> > > David
> >