On Jan 30, 2014, at 8:22 AM, Frank Shearar <frank.shearar at gmail.com> wrote:

> On 29 January 2014 18:39, Robert Withers <robert.w.withers at gmail.com> wrote:
>> 
>> On Jan 29, 2014, at 7:41 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> 
>>> On 29 January 2014 14:16, Robert Withers <robert.w.withers at 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2342 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140130/5ac9fd33/smime.bin