<div dir="ltr">A quick overall response: I know that a lot of what I am talking about *is possible* using RPython. That is one reason why I am starting where I am. That doesn't necessarily make it easy (or as easy as it could be). <br><div><br><br>On Thu, Apr 16, 2015 at 11:39 AM, Ronan Lamy <span dir="ltr"><<a href="mailto:ronan.lamy@gmail.com" target="_blank">ronan.lamy@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why Py3?:  I like Py3 better.  I want to use function annotations to<br>
provide information to the inferencing process. The annotations would<br>
provide new roots for a the type inferencing process - and importantly,<br>
would allow me to stop that process at module boundaries efficiently.<br>
</blockquote>
<br></span><br>
Syntax aside, it's already in RPython, cf. rpython.rlib.objectmodel.enforceargs and rpython.rlib.signature (which sadly are incompatible with each other).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Type inferencing? The types in typing.py don't work for us:  Yes, but we<br>
don't need to be restricted to those types only. There is no reason not<br>
to declare the types that we need - for example to have UInt32 as a<br>
possible type in a function annotation. This allows us to get rid of a<br>
fair amount of "noise" is the rpython implementation (or at least to<br>
sequester it better).<br>
</blockquote>
<br></span>
Unless you want to get rid of type inferencing altogether (or strictly restrict it to function locals, perhaps), that noise isn't going away.<span class=""><br></span></blockquote><br></div><div class="gmail_quote">[snip]<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What changes in the compilation model?   One big one: Be able to<br>
effectively do type inferencing on a smaller piece of the program than<br>
"the whole program." I would like to stop/start at either function<br>
boundaries or at module boundaries. Declaring appropriate type<br>
information would let me do that.<br>
</blockquote>
<br></span>
Removing whole-program type inferencing would change the character of the language a lot. In addition to function signatures, you'd also need to declare types for global constants, class and instance attributes, ...<span class=""><br></span></blockquote><div><br></div><div>I don't want to get rid of whole-program type inferencing. I just want to be able to define a subset and declare that "this is the whole program" for purposes of an inferencing pass. I do know that means that sometimes types will become non-inferenceable. That is where explicit function/type annotation would allow me to do so.<br><br></div><div>For a silly example, <br><br></div><div>def add(x, y): return x + y<br><br></div><div>is not generally type inferenceable in Python. But<br><br></div><div>def add(x:UInt32, y:UInt32): return x + y<br><br></div><div>is. (Putting aside overflow for a second).<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span><span class=""><br></span>
I don't understand how this fits with the rest of your plans. By definition, PyPy3 will be able to run spy, so why do you need your own interpreter?<br>
<br></blockquote><div><br></div><div>I want my spy interpreter to run only spy. Python 3 (whether CPython3 or PyPy3) would also be able to run .spy files, but having a nice repl (without incurring the double interpretation cost) would be good.<br><br> <br></div></div></div></div></div>