headers
David Hopwood | 1 Jul 2005 02:32
Picon
Favicon

Re: Reference-state diagram

Ka-Ping Yee wrote:
> On Thu, 30 Jun 2005, Ka-Ping Yee wrote:
> 
>>A good compromise would be to use a figure like the one you have
>>on your web page and add a grouping labelled "vat-crossing" or
>>"remote" that contains "remote promise" and "far".
> 
> And here by "good compromise" i meant "best of both worlds." :)
> 
> Since i'm leaving for a trip tomorrow, i figured i probably wouldn't
> have another chance, so here's the diagram i described.
> 
>     http://zesty.ca/promises/refstates2.svg
> 
> Rasterized for viewing here:
> 
>     http://zesty.ca/promises/refstates2.png

I like this version. It's not entirely clear, though, unless you're
already familiar with the statecharts notation, that the arrow
labelled 'partition' means that a 'remote promise' can transition
directly to 'broken' without going through 'far'. A sentence in the
text saying so would be sufficient, though.

--

-- 
David Hopwood <david.nospam.hopwood@...>
Permalink | Reply | 0 comments |
headers
Dan Bornstein | 1 Jul 2005 03:19
Favicon
Gravatar

Paper Comments

Here are my comments based on a single reading of the draft posted as of 
about 4pm today. As Ping(? I think) said, my terseness is meant merely 
as an expedience. Overall, I think the paper is excellent; most of my 
comments are minor nitpicks. Also, apologies if any (all?) of this is 
stale; I wish I had time to keep up with it all!

-dan

##########

PAGE 2

> The Sequential StatusHolder introduces the statusHolder, and examines 
> its
> hazards in a sequential environment.

I wouldn't use a comma there, since the thing after the comma isn't a 
full sentence, nor is it part of a list of 3 or more clauses. You do the 
same thing in the rest of the list of sections as well.

footnote 3
> Hayek’s explanation of how property rights protects humans plans from
> interference

Some syntactic issues there.

PAGE 7

Fig.1: I don't get what the double-headed arrow in the middle of the 
figure is supposed to represent.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 1 Jul 2005 03:22
Picon
Favicon

Re: Content Complete, Ready for Comments

Mark Miller wrote:
> David Hopwood wrote:
> 
>> $ cat epimenides.e
>> #!/usr/bin/env rune
>> pragma.disable("explicit-result-guard")
>>
>> var flag := null
>> def epimenides() { return flag <- not() }
>> flag := epimenides <- run()
>>
>> java.lang.NoSuchMethodException: <null>.not/0
> 
> Try adding a
> 
>     pragma.enable("easy-return")
> 
> to your program. Without this, the lack of a result guard is equivalent 
> to :void rather than :any, which is why you're getting that null.

So in order to be correct in current E, the program in the paper should
use one of 'pragma.enable("easy-return")', ':any', or ':vow[boolean]'
(I'd suggest the last of these, even though it will have to be explained).

Incidentally, the error message you get without any pragma:

# syntax error: The optional e.enable.explicit-result-guard feature (see
# org/erights/e/elang/syntax/syntax-props-default.txt) is currently on
# disallowing this construct.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dean Tribble | 1 Jul 2005 03:31

Re: Reference-state diagram


>Since i'm leaving for a trip tomorrow, 
>
Noooooo......!

I had hoped to get your input on the new mutual suspicion section.  
Shoudl you happen to read and commont on everything up to section 7.2, I 
would be delighted :-)

Thanks for the awesome figures and feedback.

>i figured i probably wouldn't
>have another chance, so here's the diagram i described.
>
>    http://zesty.ca/promises/refstates2.svg
>
>Rasterized for viewing here:
>
>    http://zesty.ca/promises/refstates2.png
>
>
>-- ?!ng
>_______________________________________________
>e-lang mailing list
>e-lang@...
>http://www.eros-os.org/mailman/listinfo/e-lang
>
>  
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Hopwood | 1 Jul 2005 04:11
Picon
Favicon

Re: Yet Another Revision

I still have some more substantive comments yet to post, but in the
meantime here are more nitpicks:

- To succeed, we must find ways of reducing the size of the resulting cases
- analysis.
+ To succeed, we must find ways of reducing the size of the resulting case
+ analysis.

- Even under sequential and benign conditions, the listener pattern in
- the statusHolder creates plan interference hazards programmers must
- beware of.
+ Even under sequential and benign conditions, the listener pattern in
+ the statusHolder creates plan interference hazards against which
+ programmers must defend.

   If the trade above succeeds promptly, the finance application deposits money
   into the account /during/ the update process. An update of the balance /after/
   the deposit is sent recursively, and then the update from /before/ the deposit
   completes. Thus notifications arrive /out of order/, so when the notification
   loop from before the deposit completes, it will inform subscribers of the wrong
   (pre-deposit) value.

Excessive use of italics. Suggest dropping the italics on at least "out of order",
and possibly "during".

   The nested publication hazard is especiallly striking because it reveals that
   problems typically associated with concurrency may arise even in a simple
   sequential example.

especially
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ka-Ping Yee | 1 Jul 2005 11:38
Picon

Re: Reference-state diagram

On Thu, 30 Jun 2005, Dean Tribble wrote:
> I had hoped to get your input on the new mutual suspicion section.
> Shoudl you happen to read and commont on everything up to section 7.2, I
> would be delighted :-)

Remarkably, i have wireless Internet access in Winnipeg.

> Thanks for the awesome figures and feedback.

You're welcome.  Glad to help.

7.  Mutual Suspicion
====================

- In languages supporting shared-state concurrency, such as Java, many
- people simply avoid it, and adopt the event-loop style instead.
+ When using a language (such as Java) that supports shared-state
+ concurrency, one can choose to avoid it and adopt the event-loop
+ style instead.

    The "it" was dangling here.  Also "many people" may be a risky
    claim and you don't really need to make it.

- The question is interesting as an example of how mutual suspicion
- alters our notions of program correctness.
+ The question motivates an examination of how mutual suspicion affects
+ the definition of program correctness.

    This change is up to you.  To me, the question itself didn't
    seem to constitute an example (though the discussion it triggers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 1 Jul 2005 20:57

Mostly integrated

The version just posted integrates all Dean's changes from last night -- 
substantial revisions to the "Mutual Suspicion" chapter -- with all the 
suggestions received as of yesterday, i.e., Ping's suggestions from this 
morning are not yet integrated.

--

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
Permalink | Reply | 3 comments |
headers
Mark Miller | 1 Jul 2005 21:06

Re: Content Complete, Ready for Comments

> Mark Miller wrote:
>> Try adding a
>>
>>     pragma.enable("easy-return")

David Hopwood wrote:
> So in order to be correct in current E, the program in the paper should
> use one of 'pragma.enable("easy-return")', ':any', or ':vow[boolean]'

In fact, for the examples in the paper to work in current E, you need

     pragma.enable("easy-return")
     pragma.disable("explicit-result-guard")
     pragma.enable("easy-when")

Once we submit a version of the document to Springer, I'll add a footnote to 
the web version explaining the need for these three lines. I decided not to 
include this in Springer's version, since we've been planning to fix E so that 
these will no longer be necessary. By leaving this out of the Springer 
version, I'm committing to fixing this before the paper book comes out.

 > (I'd suggest the last of these, even though it will have to be explained).

Without the easy-return pragma, many other examples in this paper are broken too.

--

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 2 Jul 2005 03:26

Re: Mostly integrated

I just posted a version which integrates all the suggestions Ping made this 
morning, and also has various other minor improvements here and there.

Ping, I'm especially impressed by this recent batch of suggestions. You 
succeeded at saying well and simply several things that Dean & I couldn't 
figure out how to put, even after many long phone conversations. Thanks!

With all the notes to ourselves turned off, we're a half page over the limit. 
I have a sleazy formatting idea which could save us some room, but I don't 
know what the *right* way to do it in LaTeX would be:

The "From Objects to Actors and Back Again" and "Related Work" sections places 
a title on the discussion of each related system using a \subsubsection 
directive, as follows

     \subsubsection{Vulcan.} The Vulcan project ...

The Springer style macros cause an excessive among of vertical whitespace 
between these subsubsections, and there's no \subsubsubsection macro 
available. To experiment, I changed this to

     \related{Vulcan.} The Vulcan project ...

and added the following macro definitions:

     \newcommand{\related}[1]{\subsubsection{{#1}}}
     % \newcommand{\related}[1]{\textbf{{#1}}}

If I turn the first off and turn the second on, we're less than a third page 
over limit. Is there a better way to do this kind of thing in LaTeX?
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Hopwood | 2 Jul 2005 03:36
Picon
Favicon

Re: Content Complete, Ready for Comments

Suggestions for things that are least important / easiest to shorten:

* Delete "Returning to our analogy, ..." and "In our analogy, ..." in Promise
   Pipelining, and move "But what if you need to formulate a plan that needs to
   work whether these objects are local or remote?" to next section.

* "Like the popular myth ... chooses to tell it to you." in Sturdy References
   (redundant; password caps are well-documented elsewhere)

* the last two paragraphs of Sturdy References (these don't say anything new,
   they just apply it to the listener example)

* the example of using asyncAnd

* "Group Membership" in Related Work could be more concise

====

   By abstraction, we limit one object's need for knowledge of others, reducing
   the number of cases which are relevant. Even under sequential and benign
   conditions, the remaining case analysis can still be quite painful.

However, even under sequential and benign conditions...

(The analysis is painful despite the argument in the preceding sentence.)

- Throughout this paper, we do not seek "solutions" to coordination
- problems, but rather, abstraction mechanisms adequate to craft diverse
- solutions adapted to the needs of many applications.
+ Throughout this paper, we do not seek universal solutions to coordination
(Continue reading)

Permalink | Reply | 2 comments |

Gmane