<br><br><div class="gmail_quote">On Sun, Feb 22, 2009 at 8:08 PM, 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;">
<br>
2009/2/23 Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>>:<br>
<div class="Ih2E3d">> 2009/2/22 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>><br>
<br>
</div>[snip]<br>
<br>
another idea how to make a cleaner slang code , was to introduce a<br>
special 'C' shared variable.<br>
So, then instead of writing something like:<br>
<br>
self ioRelinquishProcessorForMicroseconds: xxx.<br>
<br>
or even worse:<br>
<br>
self cCode:' ((sqInt (*) (sqInt, sqInt*, sqInt*, sqInt*, sqInt*))querySurfaceFn)<br>
(handle, &sourceWidth, &sourceHeight, &sourceDepth, &sourceMSB)'<br>
inSmalltalk:[false]<br>
<br>
you merely write:<br>
<br>
C ioRelinquishProcessorForMicroseconds: xxx.<br>
C querySurfaceFn: handle with: sourceWidth cReference with:<br>
sourceHeight cReference ....</blockquote><div><br></div><div>this is scarily similar to Alien style FFI's, e.g. Vassili's Newspeak Windows GUI interface :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
First , it lets a code generator know, that given message send is raw<br>
C function call (by taking a first keyword as a function name).<br>
Second, it can be simulated appropriately by a simulator, since you<br>
can assign an object to 'C' pool var which having best-match<br>
implementations for all such calls. And of course it helps greatly in<br>
finding errors or mistypes!<br>
<br>
Then patterns like 'self foo' be exclusively treated by code generator<br>
as method which belongs to an instance of class where method which<br>
containing such code residing, without any exceptions.<br>
<br>
So, if you write<br>
'self signalSemaphore: xx' in Interpreter's method<br>
a code generator should lookup for #signalSemaphore: in Interpreter class.<br>
And if you write 'self header' in Oop class -- it will lookup<br>
#header method in Oop class, but nowhere else!</blockquote><div><br></div><div>I also think we should do the following:</div><div><br></div><div>a) mangle names of selectors so each is prefixed by e.g. the capitals in the class name, so that e.g. StackInterpreter>>popStack: gets mangled to SI_popStack, and Cogit>>cog:selector: gets mangled to C_cogselector etc so one can use super in Slang. </div>
<div><br></div><div>b) handle variables thusly:</div><div><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif;"><span class="Apple-style-span" style="font-size: small;">Slang should provide unique names for all local variables as it creates TMethods. These variable names can simply be integers (actually their key is an integer and their value is their original name). Since they are all unique there can be no clashes. Variables can safely be substituted by other variables since when one replaces one variable with another it cannot posibly accidentally clash with some other variable.</span></span></div>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica; min-height: 17.0px"><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif;"><span class="Apple-style-span" style="font-size: small;"><br>
</span></span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica"><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif;"><span class="Apple-style-span" style="font-size: small;">Later, when a TMethod is output, variables are output not as their integer key but as their value (their original name) provided it doesn't clash. The same variable renumbering scheme can be used to resolve clashes. i.e. the renaming is deferred until a TMethod is output, and done once, not every time one tries to inline a method. Renaming clashes is simple. A dictionary maps original names to sequences of integer variable keys. The renamed variable is the original name concatenated with the index of its integer key in the sequence of keys for the original name.</span></span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica"><span class="Apple-style-span" style="font-family: arial; font-size: 13px;"><br></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica">
<span class="Apple-style-span" style="font-family: arial; font-size: 13px;">When inlining a method into another one unifies the formals and actuals assigning new variable numbers for all new variable bindings. That should simplify the inline considerably because the horrible variable renaming code will reduce to mapping old variable keys to new variable keys.</span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica"><span class="Apple-style-span" style="font-family: arial; font-size: 13px;"><br></span></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="Wj3C7c">Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br>