<br><br><div class="gmail_quote">On Tue, Mar 3, 2009 at 10:52 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
2009/3/3 Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>>:<br>
><br>
</div><div class="im">> Igor Stasenko wrote:<br>
>><br>
>> But it seems that it disabled by default.<br>
>> Yes it would be nice to replace push/pops with single method, like<br>
>> #primitiveArgumentAt: index<br>
>> where index = 0 is receiver<br>
>> 1 .. n - rest of arguments.<br>
><br>
> I think that is a brilliant idea, right in line with what we were doing.<br>
> Finally you can use left-to-right access to method args ;-)<br>
><br>
>> Another thing, that most primitives never check a number of arguments<br>
>> on stack. This is also a potential risk, when you calling primitive<br>
>> with wrong number of arguments from a language side.<br>
><br>
> Right. One thing we can do here is to add a check to primArgAt: that just<br>
> fails the primitive if you try to access arguments that aren't provided.<br>
><br>
</div>yes, this check could be put in #primArgAt:<br>
but i feel little unpleased that it will be performed more than once.<br>
It would be better to have a slang directive, like:<br>
self expectedArguments: 3. " 1== receiver only, 2 == receiver +<br>
single arg ... "</blockquote><div> </div><div>self expectedNumArgs: 0</div><div> => self only<br></div><div>self expectedNumArgs: 1</div><div> => self plus one argument</div><div>self expectedNumArgsBetween: m and: n</div>
<div> for var-args primitives like perform:[with:*] and value[:[value:*]]</div><div><br></div><div>Perhaps checkNumArgs: or failUnlessNumArgs: are better names?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
in primitie code, and put it as first check in primitive entry. Then<br>
code generator could produce a code which checks the number of<br>
arguments, and automatically fail primitive if they are not same as<br>
expected.<br>
<div class="im"><br>
>> Apart from this, what you suppose to do with primitives who switching<br>
>> the active context (entering block closure,signaling semaphore,<br>
>> scheduling etc)?<br>
>> In this situation you shouldn't try to validate the stack pointer, as<br>
>> well as primitive return value is useless.<br>
><br>
> Yes. push and pop will still be there for internal use - it is only the<br>
> plugins that will get updated. So anything that wants to munge the stack in<br>
> such a way will have to be builtin VM primitive which seems fair to me.<br>
><br>
> Cheers,<br>
> - Andreas<br>
><br>
<br>
<br>
<br>
</div><div><div></div><div class="h5">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br>