Attribute lazy initialization

CeylonMigrationBot commented 12 years ago

[@matejonnet] Looking for a shorter way to initialize an object attribute on a first use, and ability to use immutable attribute instead of variable

variable Foo? foo := null;
Foo getFoo() {
    if (exists f = foo) {
        return f;
    }
    foo := createFoo();
    if (exists f = foo) {
        return f;
    }
    throw;
}

I would like to write this as:

Foo? foo;
Foo getFoo() {
    if (!exists foo) {
        foo = createFoo();
    }
    return foo;
}

[Migrated from ceylon/ceylon-spec#438]

CeylonMigrationBot commented 12 years ago

[@matejonnet] Or even shorter if it is possible to do something like this:

Foo foo ?= createFoo();

"?=" will cause that createFoo() is called on first usage of foo.

CeylonMigrationBot commented 12 years ago

[@RossTate] The non-variable version is bad cuz you're accessing a value before it's been initialized.

variable Foo? foo := null;
Foo getFoo() {
    if (exists f = foo) {
        return f;
    }
    foo := createFoo();
    return foo;
}

would be bad because between foo := createFoo(); and return foo; a concurrently running program could have changed the value of foo to null.

Lazy<Foo> foo = lazy createFoo(); seems a better solution.

CeylonMigrationBot commented 12 years ago

[@luolong] +1 for this syntax:

Foo foo ?= createFoo();

CeylonMigrationBot commented 11 years ago

[@gavinking] So, @matejonnet has a point here. The simplest I was able to get was the following:

Integer computeVal() => ... ;

variable Integer? lazyVal:=null;

shared Integer val {
    if (exists val=lazyVal) {
        return val;
    }
    else {
        value val=computeVal();
        lazyVal:=val;
        return val;
    }
}

which sorta took me by surprise. It's a bit better than what @matejonnet writes above, but it's still unacceptably verbose.

The big problem here is that, ages ago, @FroMage asked me to change the type of assignment expressions like lazyVal:=computeVal() from the RHS type (in this case, Integer) to the LHS type (in this case, Integer?) to make things easier on the Java backend. If we had not made this change, then the following code would work:

Integer computeVal() => ... ;

variable Integer? lazyVal:=null;

shared Integer val =>
        lazyVal else lazyVal:=computeVal();

Which I think would be acceptable, no?

@FroMage WDYT, can we change this back?

CeylonMigrationBot commented 11 years ago

[@gavinking] @luolong The following would certainly work:

Integer computeVal() => ... ;

variable Integer? lazyVal:=null;

shared Integer val =>
        lazyVal?=computeVal();

where ?= is an operator that evaluates the RHS and assigns it to the LHS iff the LHS is null. But it's more cryptic and not much less verbose than lazyVal else lazyVal:=computeVal().

CeylonMigrationBot commented 11 years ago

[@FroMage] I'd like a way to define lazy memoised attributes, I've already made that clear.

Perhaps memoised Integer val => computeVal() would be enough, though memoised doesn't speak to most people, but using lazy here wouldn't imply that the value is only computed once, since => is already lazy. Perhaps cached?

I think that ?= is not useful outside of this use-case (lazy memoised attributes) (though feel free to prove me wrong) and that this particular use-case still has too much boilerplate, even Gavin's solution, compared to:

Integer computeVal() => ... ;

cached shared Integer val => computeVal();

I mean, if we introduce ?= only for this use-case, we should fix this use-case better than half-way.

CeylonMigrationBot commented 11 years ago

[@quintesse] once ?

CeylonMigrationBot commented 11 years ago

[@gavinking] FTR, I'm not advocating ?=. I'm advocating we fix the type of assignment expressions back to what it should be!

I'm also not against eventually introducing a Fantom-style once annotation, but I don't want to do it in Ceylon 1.0.

CeylonMigrationBot commented 11 years ago

[@FroMage] Fair enough, but changing the type of := means making it more expensive when compiled to Java. I'm not sure that's worth it.

CeylonMigrationBot commented 11 years ago

[@gavinking]

Fair enough, but changing the type of := means making it more expensive when compiled to Java.

Only when:

the RHS type is narrower than the LHS type, and
the assignment appears as a subexpression (rather than as a statement).

CeylonMigrationBot commented 11 years ago

[@FroMage] Sure.

CeylonMigrationBot commented 11 years ago

[@RossTate] Lazy actually typically means memoized. A while back I had proposed that {...} be memoized so that the singleton case could be used for (memoized) lazy arguments. You could do the same here:

Lazy foo = {compute()};

foo.eval

On Thursday, January 3, 2013, Stéphane Épardaud wrote:

Sure.

— Reply to this email directly or view it on GitHub<#3544#issuecomment-11841604>.

CeylonMigrationBot commented 11 years ago

[@gavinking] I have made that change to the type of x=y, allowing the following idiom:

variable Integer? lazyVal:=null;
shared Integer val => lazyVal else (lazyVal=computeVal());

Now reducing issue priority and shifting out of Ceylon 1.0. We can re-discuss this stuff for a future version.

CeylonMigrationBot commented 11 years ago

[@gavinking] P.S. the backend needs to be fixed to support this change to the semantics of a nested assignment operator.

CeylonMigrationBot commented 9 years ago

[@quintesse] I see this has been suggested for 1.5 but I've already encountered several times wanting something like this. Maybe we could move it a bit forward to 1.3? It doesn't seem too hard too implement but can still quite useful.

Of course Gavin's 2-liner is not too bad, but nothing can beat:

shared cached Integer val => computeVal();