<div dir="ltr">Hi Rob,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 6:16 AM, Robert Withers <span dir="ltr"><<a href="mailto:robert.w.withers@gmail.com" target="_blank">robert.w.withers@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">sorry for the typos…corrected:<br>
<div class="im"><br>
On Jan 29, 2014, at 5:56 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
<br>
> On 29 January 2014 12:23, Robert Withers <<a href="mailto:robert.w.withers@gmail.com">robert.w.withers@gmail.com</a>> wrote:<br>
>><br>
</div><div class="im">>> Exactly, I am suggesting doing inferencing at runtime. Instead of locking those types down, at compile time, be able to do the message send Smalltalk wise, then JIT it to be typed. So dynamically switched from dynamic late-binding typing, to an early typing, with the optimizations.<br>
>><br>
>> I figured it could useful to type at runtime, but if it is not needed...<br>
><br>
> Oh, I see. The mention of Scala threw me off to thinking you<br>
> specifically meant Hindley-Milner, as opposed to, say, k-CFA.I think I<br>
> asked Eliot about this before: I wanted to know if the VM could expose<br>
> the types of a particular call site to the image, so that tools could<br>
> say "after the test suite ran, this method here at this call site is<br>
> sent to Number", or similar.<br>
<br>
<br>
</div>I only know functional a little. I still can’t think functionally; I think objects, but dynamic objects instead of those pojos, DOA. I do think the details of the type systems is interesting. Specifically, what I wanted to do in a typed (though inferenced) language, is to address the need for a wrapper proxy on an eventual ref. One reason we need a wrapper is no reference mutations are allowed on the JVM. If we build Java support in Cog, we can change the mutation policy.<br>
</blockquote><div><br></div><div>Again taking a look at the Java support in Smalltalk/X might be worth your while.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The other reason is that I wanted the returned promise to be typed as the real return and let the inferencer do its thing and rewrite send sites from dynamic lookup to direct calls. I was told that Hindley-Milner was what I wanted. *shrug*<br>
</blockquote><div><br></div><div>Hmmm, I'm so dubious about this kind of approach. Dynamic lookup, as it is implemented in typcal Smalltalk JITs, Cog included, is pretty damn quick. Rewriting as direct calls would likely only buy you small factors on an already fast operation. On the other hand, allowing the type inferencer to function well across the dynamic call seems like a sane desire.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Getting to the type info at runtime is key, I think. Aren’t there 2 types of type systems? Type vs class? Do you or anyone know about that?<br>
</blockquote><div><br></div><div>The thing is that the former, at least at run-time, is not really a type system, it's just type information, specifically the set of classes of receiver that have been encountered since the start of execution, or since the last method cache flush, up to this point. That's proved to be enormously useful information to guide a dynamic optimizer, but it doesn't predict the types to be encountered in the future (and hence any optimizer based on this info must guard against new types running the optimized code, and typically deoptimize and reoptimize whenever new types are used in the code). You could use that information to provide info for the programmer (eg. run unit tests and then report back on the types encountered), but that's soft information, not an exhaustive proof of all possible types encountered for all time.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used languages.</blockquote>
<div><br></div><div>Well Smalltalk/X is an existence proof. I'm sure that Cog could support Java on this basis. And at Cadence we've implemented a JavaScript-like language above Smalltalk. But providing a working system in some limited domain is far different than generally supporting e.g. Java, being able to pass all the test suites, interoperate, etc. That's proved a huge task/. I don't want to duscurage you from taking a tilt at this, but it really helps to understand the scope. Being able to run scala makes sense; that's limited. But I wonder if the right approach wouldn;t be to rewrite the scala compiler to target Smalltalk bytecodes directly. Wouldn't that be simpler? e.g.:</div>
<div><br></div><div>- Write a scala-to-Smalltalk translator, e.g. source-to-source, written in either scala or smalltalk</div>- design and implement the scala run-time system for scala in Smalltalk (sis??)<div>- translate the scala compiler to Smalltalk</div>
<div>- write a back-end for this compiler that targets Smalltalk bytecode, written in scala</div><div>- bootstrap</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It seems a dynamic runtime is better than a static vm to support both flavors of languages, though runtime feedback type inferencing seems important, in my gut. Maybe it is just cool tech, great for ops.<br></blockquote>
<div><br></div><div>I think its accepted that runtime type feedback is great for optimization, and I expect it will be great for program comprehensibility too, not that I'm aware of much work that's been done here. But yes, it would be very interesting to see how scala faired above a much more dynamic vm.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Robert<br></blockquote></div>-- <br>best,<div>Eliot</div>
</div></div>