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? COudl a scala type inferencer be built in Spur’s runtime? runtime?
Eliot, I am quite intrigued on your blog post on Spur’s object stack representation. Does this format touch on the heap structure of an object? Either way, using Cap’n Proto in the heap and Spur for the stack/queue structures would be really nice if someone had one. Does a lord or lady own such a magic item +4? on a raspberry?
so sorry for all that noise , - charlie (Rob WIthers)
Hi Charlie,
On Fri, Jan 24, 2014 at 9:11 PM, charlie robert charlie.robert@icloud.comwrote:
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?
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?
Eliot, I am quite intrigued on your blog post on Spur's object stack representation. Does this format touch on the heap structure of an object?
What exactly do you mean by "Spur's object stack representation"? Do you mean Spur's object representation, or do you mean the ObjStack datatype? The latter is merely a segmented stack, like building OrderedCollection out of a linked list of pages, each page containing up to N elements.
Either way, using Cap'n Proto in the heap and Spur for the stack/queue structures would be really nice if someone had one. Does a lord or lady own such a magic item +4? on a raspberry?
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
so sorry for all that noise ,
- charlie (Rob WIthers)
On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
Yeah, I think that's what he was talking about. It's hard to see how dynamic languages could use Cap'n Proto, because they don't tend to give enough low-level control over memory layout in the heap.
On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
Yeah, I think that's what he was talking about. It's hard to see how dynamic languages could use Cap'n Proto, because they don't tend to give enough low-level control over memory layout in the heap.
Wouldn't pinning be enough? No, because one needs to intermix binary data and objects. But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?
The alternative would be to add struct support to Spur which might be doable. But it's a lot of work for a rather specific application. Anyway, I'm open to others experimenting on this.
Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout. The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.
In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).
In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours. (Forgive the digression).
I was thinking that handle may be a capability ref, mutable in the scope of the ref state machine.
Thank you, Robert
On Jan 28, 2014, at 2:36 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney colin@wiresong.com wrote: On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
Yeah, I think that's what he was talking about. It's hard to see how dynamic languages could use Cap'n Proto, because they don't tend to give enough low-level control over memory layout in the heap.
Wouldn't pinning be enough? No, because one needs to intermix binary data and objects. But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?
The alternative would be to add struct support to Spur which might be doable. But it's a lot of work for a rather specific application. Anyway, I'm open to others experimenting on this.
Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout. The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.
In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).
In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours. (Forgive the digression).
best, Eliot
Hi Charli,
On Tue, Jan 28, 2014 at 5:54 PM, charlie robert charlie.robert@icloud.comwrote:
I was thinking that handle may be a capability ref, mutable in the scope of the ref state machine.
Perhaps you're assuming much more knowledge about Cap'n Proto than I have. Could you explain the above? I have no idea which state machine you're talking about. Sorry :-(
Thank you, Robert
On Jan 28, 2014, at 2:36 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
Yeah, I think that's what he was talking about. It's hard to see how dynamic languages could use Cap'n Proto, because they don't tend to give enough low-level control over memory layout in the heap.
Wouldn't pinning be enough? No, because one needs to intermix binary data and objects. But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?
The alternative would be to add struct support to Spur which might be doable. But it's a lot of work for a rather specific application. Anyway, I'm open to others experimenting on this.
Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout. The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.
In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).
In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours. (Forgive the digression). -- best, Eliot
Hi Eliot,
On Jan 29, 2014, at 11:53 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Charli,
On Tue, Jan 28, 2014 at 5:54 PM, charlie robert charlie.robert@icloud.com wrote: I was thinking that handle may be a capability ref, mutable in the scope of the ref state machine.
Perhaps you're assuming much more knowledge about Cap'n Proto than I have. Could you explain the above? I have no idea which state machine you're talking about. Sorry :-(
In Elib, the refs are involved in a reference state machine, as promises eventually resolve or break, or a remote ref breaks. Here’s the Elib page on this, with diagram: http://www.erights.org/elib/concurrency/refmech.html.
I would prefer to get java going with promise-pipelining, but without a wrapper. That requires a JVM that allows reference mutation. I’ve always thought of Cog and building a SqueakJDK.
- Robert
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.
Eliot, I am quite intrigued on your blog post on Spur’s object stack representation. Does this format touch on the heap structure of an object?
What exactly do you mean by "Spur’s object stack representation"? Do you mean Spur's object representation, or do you mean the ObjStack datatype? The latter is merely a segmented stack, like building OrderedCollection out of a linked list of pages, each page containing up to N elements.
So Spur specifies heap structure? Vis-a-Vis the lack of interoperability, Cap'n Proto would be just the thing to interoperate java and squeak and scala and groovy. You own the metal so you can do whatever you imagine.
Either way, using Cap’n Proto in the heap and Spur for the stack/queue structures would be really nice if someone had one. Does a lord or lady own such a magic item +4? on a raspberry?
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
I am missing all this, 'cuse me '
Indeed, best, Robert
so sorry for all that noise ,
- charlie (Rob WIthers)
-- best, Eliot
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
Eliot, I am quite intrigued on your blog post on Spur’s object stack representation. Does this format touch on the heap structure of an object?
What exactly do you mean by "Spur’s object stack representation"? Do you mean Spur's object representation, or do you mean the ObjStack datatype? The latter is merely a segmented stack, like building OrderedCollection out of a linked list of pages, each page containing up to N elements.
So Spur specifies heap structure? Vis-a-Vis the lack of interoperability, Cap'n Proto would be just the thing to interoperate java and squeak and scala and groovy. You own the metal so you can do whatever you imagine.
Either way, using Cap’n Proto in the heap and Spur for the stack/queue structures would be really nice if someone had one. Does a lord or lady own such a magic item +4? on a raspberry?
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
I am missing all this, 'cuse me '
Indeed, best, Robert
so sorry for all that noise ,
- charlie (Rob WIthers)
-- best, Eliot
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...
- Robert
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.
frank
- Robert
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
sorry for the typos…corrected:
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:
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 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.
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*
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?
The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used 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
On 29 January 2014 14:16, Robert Withers robert.w.withers@gmail.com wrote:
sorry for the typos…corrected:
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:
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 only know functional a little. I still can’t think functionally; I think objects, but dynamic objects instead of those pojos, DOA.
Hindley-Milner is a particular way of enforcing static type checks through inference. It happens to be a _very good_ way of doing this, but I'm sure it's not the only way.
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.
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*
Um, that sounds a bit weird, to be honest. A promise surely _can't_ be typed as the real return since there _is_ no real return: a promise can break! In Scala-ish terms (I've not written any Scala for about two years...), a Promise[Int] is fundamentally different to an Int because the latter is just a value whereas the former may or may not result at some point in a value. It's only once a Promise has resolved that things get interesting. And it sounds here like this is when you'd like to optimise the Promise wrapper away, right?
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?
The study of type systems is a rather big subject!
The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used 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.
Cog _does_ support multiple languages: Squeak and Newspeak. Given that Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue with running other languages on top of Cog... assuming there's someone sufficiently interested/available to actually _do_ that. (Oh, and of course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)
frank
- Robert
Frank Shearar wrote:
Cog _does_ support multiple languages: Squeak and Newspeak. Given that Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue with running other languages on top of Cog... assuming there's someone sufficiently interested/available to actually _do_ that. (Oh, and of course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)
I didn't know that. I had always thought that the IBM team had written all the development tools in Smalltalk but that the resulting code ran on a conventional Java VM.
Note that the Java implementation on Self was sufficiently impressive that it convinced Sun to buy Animorphic and do the HotSpot VM. That project, called Pepe, was described in:
http://www.merlintec.com/vmworkshop99/sub.pdf
"Towards a Universal Implementation Substrate for Object-Oriented Language" Mario Wolczko, Ole Agesen, David Ungar
-- Jecel
On Jan 29, 2014, at 7:41 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2014 14:16, Robert Withers robert.w.withers@gmail.com wrote:
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*
Um, that sounds a bit weird, to be honest. A promise surely _can't_ be typed as the real return since there _is_ no real return: a promise can break! In Scala-ish terms (I've not written any Scala for about two years...), a Promise[Int] is fundamentally different to an Int because the latter is just a value whereas the former may or may not result at some point in a value. It's only once a Promise has resolved that things get interesting. And it sounds here like this is when you'd like to optimise the Promise wrapper away, right?
I was under the impression that Hindley-Milner was able to construct union types, which is why it was recommended to me.
The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used 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.
Cog _does_ support multiple languages: Squeak and Newspeak. Given that Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue with running other languages on top of Cog... assuming there's someone sufficiently interested/available to actually _do_ that. (Oh, and of course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)
It may be clearer for me to say that it would be awfully nice if Cog allowed for bytecode virtualization. In 64-bit values, a couple of bits for bytecode index (have a cache of 4 bytecode sets, so 4 different languages, concurrently executing). Add a bit for a capability/promise for pipelining. All at the expense of the range of the immediates, but maybe that’s ok, I do not know.
- Robert
On 29 January 2014 18:39, Robert Withers robert.w.withers@gmail.com wrote:
On Jan 29, 2014, at 7:41 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2014 14:16, Robert Withers robert.w.withers@gmail.com wrote:
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*
Um, that sounds a bit weird, to be honest. A promise surely _can't_ be typed as the real return since there _is_ no real return: a promise can break! In Scala-ish terms (I've not written any Scala for about two years...), a Promise[Int] is fundamentally different to an Int because the latter is just a value whereas the former may or may not result at some point in a value. It's only once a Promise has resolved that things get interesting. And it sounds here like this is when you'd like to optimise the Promise wrapper away, right?
I was under the impression that Hindley-Milner was able to construct union types, which is why it was recommended to me.
Just to be clear, when you say "union" what do you mean? Union like the C structure, where you can interpret some chunk of memory in several ways? Or do you mean sum types, where "this variable may contain a Left or a Right"?
frank
The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used 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.
Cog _does_ support multiple languages: Squeak and Newspeak. Given that Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue with running other languages on top of Cog... assuming there's someone sufficiently interested/available to actually _do_ that. (Oh, and of course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)
It may be clearer for me to say that it would be awfully nice if Cog allowed for bytecode virtualization. In 64-bit values, a couple of bits for bytecode index (have a cache of 4 bytecode sets, so 4 different languages, concurrently executing). Add a bit for a capability/promise for pipelining. All at the expense of the range of the immediates, but maybe that’s ok, I do not know.
- Robert
On Jan 30, 2014, at 8:22 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2014 18:39, Robert Withers robert.w.withers@gmail.com wrote:
On Jan 29, 2014, at 7:41 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2014 14:16, Robert Withers robert.w.withers@gmail.com wrote:
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*
Um, that sounds a bit weird, to be honest. A promise surely _can't_ be typed as the real return since there _is_ no real return: a promise can break! In Scala-ish terms (I've not written any Scala for about two years...), a Promise[Int] is fundamentally different to an Int because the latter is just a value whereas the former may or may not result at some point in a value. It's only once a Promise has resolved that things get interesting. And it sounds here like this is when you'd like to optimise the Promise wrapper away, right?
I was under the impression that Hindley-Milner was able to construct union types, which is why it was recommended to me.
Just to be clear, when you say "union" what do you mean? Union like the C structure, where you can interpret some chunk of memory in several ways? Or do you mean sum types, where "this variable may contain a Left or a Right”?
I think the first, although it is a union of types, not a union of data with types. I think we need a multiplicity of types, or composite of types, like a mixing of types. This way, you can call Account methods or you can call promise methods. It may not be a big deal, just a problem of my mind, in anticipation. Got it get it running, then get it running right.
- Robert
frank
The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used 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.
Cog _does_ support multiple languages: Squeak and Newspeak. Given that Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue with running other languages on top of Cog... assuming there's someone sufficiently interested/available to actually _do_ that. (Oh, and of course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)
It may be clearer for me to say that it would be awfully nice if Cog allowed for bytecode virtualization. In 64-bit values, a couple of bits for bytecode index (have a cache of 4 bytecode sets, so 4 different languages, concurrently executing). Add a bit for a capability/promise for pipelining. All at the expense of the range of the immediates, but maybe that’s ok, I do not know.
- Robert
Hi Rob,
On Wed, Jan 29, 2014 at 6:16 AM, Robert Withers robert.w.withers@gmail.comwrote:
sorry for the typos...corrected:
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:
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 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.
Again taking a look at the Java support in Smalltalk/X might be worth your while.
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*
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.
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?
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.
The strategy behind my request is to see if Cog could support multiple
languages and modern languages - i.e. broadly used languages.
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.:
- Write a scala-to-Smalltalk translator, e.g. source-to-source, written in either scala or smalltalk - design and implement the scala run-time system for scala in Smalltalk (sis??) - translate the scala compiler to Smalltalk - write a back-end for this compiler that targets Smalltalk bytecode, written in scala - bootstrap
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.
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.
- Robert
Hi Rob,
On Tue, Jan 28, 2014 at 8:15 PM, Rob Withers robert.w.withers@gmail.comwrote:
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.
Have you had a look at Smalltalk/X? They have a compiled method format that allows up to four distinct bytecode sets and one of these is Java. So they may have a lot of what you want (which is doable, but a substantial project with duration I estimate in the in the 2-5 person-years range) .
To better understand your underlying motivations could you state what's unsatisfactory about running scala on Java VMs? (and in language that a neophyte like me can understand? I know Java a little and more about Java VMs but I don't know scala).
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've read ahead to the exchange between you and Frank Shearer so I'm chearting here. It helped a lot].
Fascinating.
So the issue is that on the Smalltalk side there's dynamic typing and on the java/scala side there's static typing right? And you want to check the call for type safety at the time of call and allow it to proceed if safe? My immediate reaction is that down in the VM is far too low-level a place to implement this, quite complex, functionality. Implementing it in Smalltalk in some sort of wrapper class for scala/java objects allows you lots of freedom in implementation, cacheing previous results, and not least efficient development; implementing at the VM level is alas slow, even in the simulator.
Is there a necessity to push it down to the VM level?
Wouldn't it make more sense to get a working system at the Smalltalk level and then push this down once the design was fully determined and you'd profiled?
Eliot, I am quite intrigued on your blog post on Spur's object stack
representation. Does this format touch on the heap structure of an object?
What exactly do you mean by "Spur's object stack representation"? Do you mean Spur's object representation, or do you mean the ObjStack datatype? The latter is merely a segmented stack, like building OrderedCollection out of a linked list of pages, each page containing up to N elements.
So Spur specifies heap structure?
Right. Sista, which is being worked on mostly by Clément Bera, is the name we've given to Cog's support for adaptive optimization and speculative inlining (Sista = Speculative Inlining Small talk Architecture). One part of the VM infrastructure for Sista is a primitive that yields the satte of the inline caches in a method. That's I suspect the kind of type informaiton youre after. Am I right?
Vis-a-Vis the lack of interoperability, Cap'n Proto would be just the thing to interoperate java and squeak and scala and groovy. You own the metal so you can do whatever you imagine.
Right.
Either way, using Cap'n Proto in the heap and Spur for the stack/queue
structures would be really nice if someone had one. Does a lord or lady own such a magic item +4? on a raspberry?
https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being cynical?
I am missing all this, 'cuse me '
Your initial post went rather over my head and I thought perhaps you were pulling my chain. I googled Cap'n Proto and saw "Cap'n Proto april fool" and thought that I might be being led down the path :-). I can see now that's far from the case. Forgive me.
Indeed, best, Robert
so sorry for all that noise ,
- charlie (Rob WIthers)
-- best, Eliot
squeak-dev@lists.squeakfoundation.org
-
charlie robert -
Colin Putney -
Eliot Miranda -
Frank Shearar -
Jecel Assumpcao Jr. -
Rob Withers -
Robert Withers