The treatment of Future

[sophiaIC]

You obviously have recently changed the treatment of futures. Namely, several programs do not compile currently, unless you add a Fut to their return type - as I did to the example in program StringSend. I am not clear what the correct behaviour is.

[TobiasWrigstad]

Good question. @EliasC is the right person to answer this, but
basically, any method call x.foo() has return type Fut T, unless
x is this.

So calling

def foo() : int
  42

like so

x.foo()

has return type Fut int. The expressions

get x.foo() 

has type int.

Thus, if you write a method

def bar(x:FooType) : int
  x.foo()

this will not compile, because
the return type should be Fut int, i.e.,

def bar(x:FooType) : Fut int
  x.foo()

However

def bar(x:FooType) : int
  get x.foo()

will compile.

I hope this helps a little waiting for @EliasC.

[sophiaIC]

Thank you Tobias for the clear explanation. I remember vaguely that the presentation said something along the lines of what you just wrote.

The treatment of futures fits the Encore philosophy, which requires that things are asynchronous by default.

I also remember that at the meeting it was said that there could be implicit insertions of get whenever necessary. Alternatively, you could decide to implicitly drop the requirement to “get”, whenever the method call is not assigned to a variable, i.e. there is no way to get hold of that future in the future ;-).

My point is, that the current examples on the github do not agree with the current compiler.

[EliasC]

@sophiaIC We changed the test cases to match the use of futures, but no one remembered to change the files in programs/. I just pushed a fix to this!

At some point we should come up with a way to collapse nested futures. Right now the type of main in the following program is a bit silly:

class Foo
  def foo() : void
    print "Foo!"
  def bar(x : Foo) : Fut void
    x.foo()

class Main
  def main() : Fut (Fut void)
    let x = new Foo in
      x.bar(x)

[sophiaIC]

Not sure if it's really necessary. It works either way on my box.
I used the binaries email to men by Tobias. Perhaps the binaries are not the most recent, then..

[supercooldave]

Monadic join is the appropriate function to collapse futures (after such a thing comes into existence).

On 06 Aug 2014, at 16:00, EliasC [email protected] wrote:

@sophiaIC We changed the test cases to match the use of futures, but no one remembered to change the files in programs/. I just pushed a fix to this!

At some point we should come up with a way to collapse nested futures. Right now the type of main in the following program is a bit silly:

class Foo
def foo() : void
print "Foo!"
def bar(x : Foo) : Fut void
x.foo()

class Main
def main() : Fut (Fut void)
let x = new Foo in
x.bar(x)
—
Reply to this email directly or view it on GitHub.

[email protected]
Dept. of Computer Science
Celestijnenlaan 200A
B-3001 Heverlee
BELGIUM
Tel: +32 16 327866

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[EliasC]

I'm all for monadic joins but maybe the use of nested futures will be so rare that we can make some collapsing implicit (and force the programmer to be explicit about wanting a value of type Fut (Fut (Fut void))

[TobiasWrigstad]

Can we close this?

[supercooldave]

I think we can close this. Fut (Fut (Fut ...))) chains should not automatically be compressed without further thought.