Support for lazy expressions #148

Closed
ikasiuk opened this Issue Nov 20, 2012 · 19 comments

Comments

Projects
None yet
4 participants
Member

ikasiuk commented Nov 20, 2012

The JS backend does not properly support the => syntax yet (see 1952235). And while testing this it turned out that apparently we are also missing support for the shortcut refinement syntax (see 2d6f51a). It probably makes sense to implement both together, so a separate issue shouldn't be necessary.

@ghost ghost assigned ikasiuk Nov 20, 2012

Member

chochos commented Nov 21, 2012

Really? I tested the shortcut refinement syntax before merging and it was working... The only thing I didn't test was fat arrows with anon functions.

So what do we need to have proper support? Is it something to evaluate the expression just once? Cause Gavin told me that =>x basically meant return x, so I implemented it that way...

Member

ikasiuk commented Nov 21, 2012

The straight-foward case works fine, and the defaulted param case works because I fixed it the other day. I know roughly what's missing for the other cases, so I assigned this issue to myself. Hope I'll get around to implementing it later this week.

Member

chochos commented Nov 22, 2012

I think those latest changes broke something; the inheritance and functions tests terminate abnormally on both runs... but you're still working on this, right?

Member

ikasiuk commented Nov 22, 2012

That's the tests still failing because this issue is not fixed yet. So yes, I'm still working on it :-)

Member

ikasiuk commented Nov 25, 2012

This turned out to be a lot more complicated than it looked, but all tests finally pass now. I'll have to add more tests and do some refactoring, so leaving this issue open for now.

ikasiuk added a commit that referenced this issue Nov 28, 2012

Member

ikasiuk commented Nov 29, 2012

The new tests revealed two more problems. One is described in #150. The other one is this:

interface I {
    shared formal String s(Integer i);
}
class C(String f(Integer i)) satisfies I {
    s(Integer i) => f(i);
}

The generated code does not work in prototype style because the parameter f is not marked as captured.
@gavinking, could this be a problem in the typechecker, or is it correct that f is not considered as captured?

Owner

gavinking commented Nov 30, 2012

Ivo, capture analysis is now a responsibility of the backends.

Sent from my iPhone

On 29/11/2012, at 7:59 PM, Ivo Kasiuk notifications@github.com wrote:

The new tests revealed two more problems. One is described in #150. The other one is this:

interface I {
shared formal String s(Integer i);
}
class C(String f(Integer i)) satisfies I {
s(Integer i) => f(i);
}
The generated code does not work in prototype style because the parameter f is not marked as captured.
@gavinking, could this be a problem in the typechecker, or is it correct that f is not considered as captured?


Reply to this email directly or view it on GitHub.

Member

ikasiuk commented Nov 30, 2012

Ah, ok. But it looks like the typechecker currently does mark some values as captured?

Owner

gavinking commented Dec 1, 2012

Ahyeah, I guess PhasedUnit:243-245 are obsolete and should be removed...

Member

ikasiuk commented Dec 1, 2012

Then we should make sure that the JS backend handles this by itself. @chochos: Enrique, do we already have a class that does capture analysis?

Member

chochos commented Dec 1, 2012

Nope...

Owner

gavinking commented Dec 1, 2012

I have removed ValueVisitor from the typechecker, as I should have done a while ago! This will have broken the JS backend, and so you guys need to have your own ValueVisitor, and you need to fix the above issue :-/

Member

ikasiuk commented Dec 1, 2012

So I guess we should just copy the last version of the typechecker's ValueVisitor to ceylon-js. Once we have that in place I should be able to build upon that to fix this issue.

Member

chochos commented Dec 1, 2012

That sounds like a good starting point.

Owner

FroMage commented Dec 3, 2012

Remind me why ValueVisitor was removed from the frontend if it does the exact same thing for every backend?

Owner

gavinking commented Dec 3, 2012

@FroMage Because it doesn't do the exact same thing for every backend.

Owner

FroMage commented Dec 3, 2012

So what's the difference?

Member

ikasiuk commented Dec 11, 2012

This needs even more tests and a lot of refactoring, and the changes resulting from ceylon/ceylon-spec#466 should also be implemented as part of this issue. But it doesn't make much sense to work on it unless #155 is done, and we should probably also wait for ceylon/ceylon-spec#498.

Member

chochos commented Dec 11, 2012

As soon as the m5syntax branch is merged on ceylon-spec and ceylon.language, I'll merge it on ceylon-js and close #155 (and open separate issues for any leftover stuff).

ikasiuk added a commit that referenced this issue Dec 26, 2012

ikasiuk added a commit that referenced this issue Dec 27, 2012

@ikasiuk ikasiuk closed this Dec 27, 2012

@CeylonMigrationBot CeylonMigrationBot referenced this issue in eclipse/ceylon Nov 14, 2015

Closed

Support for lazy expressions #2579

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment