<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- <i>$0 is not a creation argument after all, i.e. it is not part of "ce_argv".</i></blockquote><div> </div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>I don't know... Can't we consider $0 as an "unconditional" creation argument?...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><font face="arial, helvetica, sans-serif"><i> Also, it really </i><i>has a different purpose. (...) $0 would be a special case either way.</i></font></div></div></blockquote><div> </div></div></div></div></div><div>I'm not sure either. To me, both $0 and $1 etc. can be used to identify an instance of an abstraction. <br></div><div>IMO $0 is the quick way, but has the limitation to make it (nearly) impossible to access members from the outside.</div><div>That's why it often happened to me to rename an instance [myAbs] to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so I can easily access [myAbs]'s members from the parent - from anywhere in fact (Actually, nowadays I tend to use as few $0 as possible).<br></div><div>If we could use $0 in messages, then the last operation would be more complicated (cause you couldn't simply substitute $0 with e.g $1).</div><div>So I think it's better to keep the $0/$n symmetry.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I think having a "message" object is a better idea [than $$'s one]<br></div></blockquote><div><br></div><div>What I like with the $$ idea, is that it would provide a simple way to merge creation arguments with variable arguments, i.e compose a message with both the abstraction arguments and the incoming message elements.</div><div><br></div></div></div>