I have a set of symbolic algebraic expressions that I'm trying to get some speed into. To illustrate the issue, I'll use a simple form like { k0 X, k1 Y, k1 Z}, where each term is large and complicated. By random walk, I've arrived at a promising form
{ r0 X, r1 Y,r1 Z}/.r0->k0 /.r1->k1
which is faster than the original, but with my particular set of expressions, it turns out that a function is faster:
{#[[1]] X, #[[2]] Y, #[[2]] Z}&@{k0, k1}
The expressions are large, making substitutions by hand time consuming and error prone, so I set out to replace the k s with a rule like
{k0->#[[1]],k1->#[[2]]}
I was surprised that this wasn't a straightforward operation, k0 being replaced by 1 instead of the intended #[[1]]. I thrashed around for a bit, eventually finding the odd (to me) result that
{#[[1]], #[[2]]}//FullForm
Gives
List[ 1, Part[Slot[1],2]]
Can anyone suggest a way of thinking in which this makes sense? Is there any place in the design for Part[Slot[1],1] ? I worked around it with a hack:
{#[[2]] X, #[[3]] Y, #[[3]] Z}&@{Null, k0, k1}
which works but is ugly to say nothing of embarrassing.
Thanks in advance.

#is a synonym forSlot[1]. Thus,#[[1]]means the first element ofSlot[1]which manifestly is the object inside[]; namely,1.#[[2]]means the second element ofSlot[1]; it does not exist. Not only does MMA spit it back out unevaluated (asPart[Slot[1],2]in full form), but it also issues aPart::partdmessage, "Part specification Slot[[1]] is longer than depth of object." – whuber Nov 13 '12 at 6:48{k0}&/.{k0->Hold[#[[1]]]}//ReleaseHold. I don't think it's a good idea though! – sebhofer Nov 13 '12 at 23:21