Daniel Vainsencher wrote:
> 
> Dwight Hughes <dwighth at ipa.net> wrote:
> > Well, the obvious reason why it's remained for so long would be that the
> > primitive number is part of the compiled method header - but why not
> > give it a name anyway?

That was a semi-rhetorical question.

> If the number is not meaningful, seems better for it to be
> auto-generated and hidden. Would this bug debugging?

Don't see why it would.

> > Possibly because even in the Blue Book primitive
> > specs a single primitive will often be used in several classes and
> > methods (sometimes with a variable number of arguments -- naughty, yes)
> > - see
> > http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter29.html
> Don't see how this matters (for replacing <primitive: 1> with
> <primitiveAdd>).
> 

Look at things like primitive 105: it is used in 
	ByteArray primReplaceFrom:to:with:startingAt:  
	ByteArray replaceFrom:to:withString:startingAt:  
	String replaceFrom:to:withByteArray:startingAt:  
	String primReplaceFrom:to:with:startingAt: 
It might be used in still other methods in the future. What is the best
name for primitive 105? True, it's a minor thing -- it just seemed like
one possible reason.

Another might simply be that there were considerably fewer primitives
then than now - so it was no great task to keep up with them. 

Remember also that before Squeak, primitives were a VM-only construct,
written in microcode, assembly, C, whatever -- there was no
corresponding implementation code for a primitive in the image, and thus
no primitive method name to associate a primitive number with (and
vendors pretty much kept the VM as their domain - so the <primitive: n>
construct was sufficient).

-- Dwight