On Jan 29, 2014, at 5:56 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2014 12:23, Robert Withers robert.w.withers@gmail.com wrote:
On Jan 29, 2014, at 3:14 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2014 04:15, Rob Withers robert.w.withers@gmail.com wrote:
Ok, I'm Robert, for professional reasons and done. Charlie Robert is my nickname from long time back. So let me stick to this email address...
On Jan 28, 2014, at 1:54 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Charlie,
On Fri, Jan 24, 2014 at 9:11 PM, charlie robert charlie.robert@icloud.com wrote:
I was curious whether java may be used in Cog. I recall a fair project with the serialization and core pojo representation, but my memory Might java interoperate natively, so as to call a java function in smalltalk, as a smalltalk call with a closure/continuation, or perhaps in the other direction?
I'm sure one can write a Smalltalk/Java interconnect. There are a number of ways to do it. What are your requirements? What do you mean by "native" operation? e.g. VisualAgeForJava?
My requirements, hmm.
1 - I would like to have .class files able to load in your VM/ObjectMemory. 2 - I would like java byte codes "JITted" into Smalltalk byte codes. 3 - I would like if one side (squeak) could invoke the other side (java) without explicit wrappers, and vice versa. I mean this as native. 4 - I would like java serialization support. 5 - like JVM 8 has a byte code for reflective lookup, I would like Smalltalk bytecodes to have one bytecode for direct invocation, and bypass the reflective meta call 6 - I want to run scala on Cog/Spur 7 - then the "JIT"...I would like the program to start in dynamic mode then "JIT" with a call to the inferencer to determine type.
This way, we have a JVM with mutable refs (become) so it would be a JVM++.
The thing that gets me is that barely anything really interoperates.
COudl a scala type inferencer be built in Spur’s runtime? runtime?
I'm not sure what you mean. Could you elaborate? Spur is an object representation and set of garbage collection/memory management facilities. As such wouldn't it live below any type inferencer?
Ok it is the inner Cog axle I think of, not Spur. The lookup and invocation of a send, of a method. At its root handler it could call an inline scala type inferencer.
I don't understand this. Type inference happens at compile time. Once you have bytecodes, there is no type inference going on.
As an example, once Scala has compiled, method lookup is all about JVM bytecodes, which have no idea about the Scala type system. In fact, the Scala-ness has _disappeared_ after compilation, which is why you can decompile the bytecodes as plain Java. (Well, where "plain" means "mangled to pieces, and has random metadata scattered everywhere".)
frank
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.
I figured it could useful to type at runtime, but if it is not needed...
Oh, I see. The mention of Scala threw me off to thinking you specifically meant Hindley-Milner, as opposed to, say, k-CFA.I think I asked Eliot about this before: I wanted to know if the VM could expose the types of a particular call site to the image, so that tools could say "after the test suite ran, this method here at this call site is sent to Number", or similar.
I don’t know functional but 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 kind of interesting. Specifically, of what I wanted to do in a typed (though inferenced) language, we to address the need for a wrapper proxy. One reason is no reference mutations are allowed on the JVM. The other is I wanted the returned promise to be typed as the real return and let the inferencer do its thing. I was told that Hindley-Milner was what I wanted. *shrug*
Getting to the type info is key, I think. Aren’t there 2 types of type systems? Do you or anyone know about that?
The strategy behind my request is to see if Cog could support multiple languages and modern languages. 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.
- Robert