<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style>body{font-family:Helvetica,Arial;font-size:13px}</style>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
James - to answer your questions:</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br>
</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
The repository is indeed at<span style="font-family: helvetica;"> </span><a href="https://github.com/cgizmo/minigrace" style="font-family: helvetica;">https://github.com/cgizmo/minigrace</a>. I'm not sure I mentioned this last time, but the interesting files
are:</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
_ gracelib_threads.* - pthread state, startup and destruction routines</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
_ gracelib_msg.* - thread mailboxes</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
_ gracelib_gc.* - threaded(-ish) modification of the GC</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
_ actors_prim.c - Grace module for low level actor functions (spawn, poll, post, etc.)</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
_ actors.grace - Thin "Erlang like" wrapper around actors_prim, to see what it would look like</div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br>
</div>
<span style="font-family: helvetica;">> </span><span style="font-family: helvetica;">Ok yep. In general I prefer the idea of annotations to new language constructs. </span><br style="font-family: helvetica;">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<span style="font-family: helvetica;">></span><span style="font-family: helvetica;"> </span><span style="font-family: helvetica;">I can see how defs could be used in immutable objects - but surely not vars?</span><span style="font-family: helvetica;"> </span> </div>
<div id="bloop_sign_1400167681499095808" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px"><br>
</div>
</div>
Since def/var represent the mutability of the reference, the "is immutable" annotation would apply to the referred data. Then it would be valid to have a "var x is immutable" point to immutable objects, as long as that "var" was not itself within an immutable
scope.
<div><br>
</div>
<div><span style="font-family: helvetica;">> </span><span style="font-family: helvetica;">- (in that sense I think immutable is also *brand* </span><br style="font-family: helvetica;">
<span style="font-family: helvetica;">> </span><span style="font-family: helvetica;">- look at the grace brands paper in the GracePapers/Brands svn direction under review, not yet accepted anywhere. </span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">I have read the Grace brands paper, but I don't think the implementation is present in minigrace yet.</span></div>
<div><br>
</div>
<div><br>
</div>
<div>Regarding the two immutability proposal ("<span style="font-family: helvetica;">immutable rules - static version" and "</span><span style="font-family: helvetica;">immutable rules - dynamic version" in your previous email), </span><span style="font-family: helvetica;">both
would require some sort of knowledge about methods to ensure that they do not modify the state (the "purity" annotation). </span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">As far as I can tell, neither approach would be able to make any deductions about the purity code without the help of the user, since there is no simple way of knowing (especially with the foreign C modules) whether
data will be modified or not. I'm not sure how one would go about omitting annotations (to "give some static checking when warranted", in the spirit of gradual typing) and still have the system throw a runtime error when necessary. Because of this, I fail
to see how the dynamic approach could be applied in this case.</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">On another note, I think it be possible to solve the problem that Michael brought up by further restricting the definition of pure methods to "referentially transparent". The issue regarding inheritance, as far as
I understand it, would disappear as that code would simply not be allowed.</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">I do not think it would be too problematic a restriction, because objects that need to travel could then be structured in a "data object"/"IO wrapper object" way.</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">method makeDataObject {</span></div>
<div><span style="font-family: helvetica;"> object {</span></div>
<div><span style="font-family: helvetica;"> // I am immutable</span></div>
<div><span style="font-family: helvetica;"> def x = 1</span></div>
<div><span style="font-family: helvetica;"> method size { x } // Referentially transparent</span></div>
<div><span style="font-family: helvetica;"> // post(otherThread, self) - not referentially transparent, not allowed</span></div>
<div><span style="font-family: helvetica;"> }</span></div>
<div><span style="font-family: helvetica;">}</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><font face="helvetica">method makeDataObject2 {</font></div>
<div><span style="font-family: helvetica;"> object {</span></div>
<div><span style="font-family: helvetica;"> // I am immutable</span></div>
<div><span style="font-family: helvetica;"> inherits makeDataObject</span></div>
<div><span style="font-family: helvetica;"> def y = 2</span></div>
<div><span style="font-family: helvetica;"> method size { y } </span><span style="font-family: helvetica;">// Referentially transparent</span></div>
<div><span style="font-family: helvetica;"> }</span></div>
<div><span style="font-family: helvetica;">}</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">method makeIOObject(dataObject) {</span></div>
<div><span style="font-family: helvetica;"> object {</span></div>
<div><span style="font-family: helvetica;"> // Not immutable anymore</span></div>
<div><span style="font-family: helvetica;"> post(otherThread, dataObject) // Safe</span></div>
<div><span style="font-family: helvetica;"> } </span></div>
<div><span style="font-family: helvetica;">}</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">Since the IO wrapper does not directly depend on the data, it can just be re-wrapped around the dataObject by the other thread on arrival to access its functionality. Of course, the wrapper will only have read-only
access to the data, so any impure method operating on the fields of the dataObject will need to make a copy.</span></div>
<div><span style="font-family: helvetica;"><br>
</span></div>
<div><span style="font-family: helvetica;">Charlie</span></div>
<div><br>
</div>
<div>Le 15 mai 2014 à 11:56:39, James Noble (<a href="mailto:kjx@ecs.vuw.ac.nz">kjx@ecs.vuw.ac.nz</a>) a écrit:</div>
<div>
<blockquote type="cite" class="clean_bq"><span>
<div>
<div></div>
<div><br>
> So I have added Tim to CC... <br>
<br>
oops sorry. In fact this can go to Gracecore, really: <br>
if anyone doesn't get two copies of this email, then they should sign up to grace-core:
<br>
I've set reply-to grace-core <br>
<br>
>> I copied in an older email from me below <br>
>> <br>
>> there are at least two different ways we could layer immutability on top of existing Grace objects.
<br>
>> <br>
>> A) immutable rules - static/algebraic/implementation version (cribbed from newspeak as per email below)
<br>
>> <br>
>> * immutable object/class can have no vars (fields), only defs, methods (& types ?)
<br>
>> * All its defs must contain immutable objects. <br>
>> * it can't close over any vars <br>
>> <br>
>> OR <br>
>> <br>
>> B) immutable rules - dynamic/coalgebraic/specifcation version (I think some systems have done this, like constrainedBeanShell or something, obcure dynamic ownership langauge we did 10+ years ago)
<br>
>> <br>
>> * any method request on an immutable must be evaluted "purely" <br>
>> * any attempted to read a field (i.e. a var) in pure mode raises an error <br>
>> <br>
>> the dynamic rule is nice in that it's gradual; put "is immutable" on any object you're defining,
<br>
>> and the runtime must check. The catch is you now have to compile methods differently for
<br>
>> immutable and non-immutable objects - probably best to just follow Newspeak and say
<br>
>> that immutable objects must inherit from ImmutableObject... <br>
> I don't think an immutable object is necessarily the same thing as an <br>
> object whose methods are completely pure, even conceptually. <br>
<br>
I guess it depends on what we mean by "immutable" doesn't it? <br>
<br>
one definition is: requesting a method from an immutable object <br>
with the same arguments (for some suitable definition of "the same") <br>
always returns the same result. (carefully ignoring side effects). <br>
<br>
Bart Jacobs The Elder has looked at this coalgebraically <br>
but I don't think his treatment covers every practical situation. <br>
<br>
>> in order to give some static checking (when warranted) you could add in an immutable annotation
<br>
>> on both objects and types, that would work like this: <br>
>> - immutable objects/classes may be annotated "as immutable" <br>
>> - it's an error to annotate as immutable if your object class doesn't meet the immutable rules we picked above
<br>
>> - types can be annotated as immutable too, in which case they only match immutable objects
<br>
>> - (in that sense I think immutable is also *brand* <br>
>> - look at the grace brands paper in the GracePapers/Brands svn direction under review, not yet accepted anywhere.
<br>
>> <br>
>> Charlie - does this help? <br>
>> OK, that's probably asking a bit much, so: does this make any sense? <br>
> You also have to deal with inheritance somehow. I'm not sure which way <br>
> addresses that better. <br>
<br>
the obvious rule is that immutables can only inherit from immutables. <br>
<br>
> I can inherit from something that looks like it's immutable where I <br>
> wrote it and have my object be mutable, <br>
<br>
so the "something" can be immutable, and now your thing is mutable. <br>
<br>
> and then there are the cases <br>
> Andrew's pointed out where you get nondeterministic uninitialised-field errors:
<br>
> Any immutability design has to at least think about how it plays with those. <br>
<br>
yes there are issues with initialisation where our naive rule doesn't always do what you like.
<br>
I'll only be nondeterministic when you have threads - I see that as an issue of threading.
<br>
Notably, Charlie's working with an actor model which could finesse some of these issues.
<br>
<br>
James <br>
<br>
</div>
</div>
</span></blockquote>
</div>
</body>
</html>