Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New unboxing approach #30

Open
tomtau opened this issue Feb 22, 2015 · 4 comments
Open

New unboxing approach #30

tomtau opened this issue Feb 22, 2015 · 4 comments

Comments

@tomtau
Copy link
Contributor

tomtau commented Feb 22, 2015

The goal is to try the new unboxing approach. Simply put, incorporate all types (primitive types and references type into one closure class. See the code below:

package boxing;

abstract class Closure {
    long ix; // long input, or other primitive types + there should be a TAG
    Object ox; // ref input for closure
    long iout; // int output, or other primitive types + there should be a TAG
    Object oout; // ref output

    abstract void apply();
}

// Int -> Int
class Inc extends Closure {
    public void apply() { // Int -> Int
        this.iout = ix+1;
    }
}

// apply : (A -> B) -> A -> B
// apply = \f . \x . f x
class Apply extends Closure {
    Closure ap = this;

    public void apply() {
        oout = new Closure() {
                public void apply() {
                    Closure f = (Closure) ap.ox;
                    f.ix = this.ix; // set arguments, potentially could have a tag to decide which assignement to make.
                    f.ox = this.ox;
                    f.apply();
                    this.iout = f.iout; // set the outputs
                    this.oout = f.oout;
                }
            };
    }
}

}
@bixuanzju
Copy link
Contributor

@tomtau Are you working on that now?

@tomtau
Copy link
Contributor Author

tomtau commented Mar 12, 2015

I've been waiting for major refactoring to be done, so I can start rewriting in a version that will be easier to merge - I guess most changes are done by now?

@bixuanzju
Copy link
Contributor

@tomtau yes

@VladUreche
Copy link

@tomtau, your approach looks very good. There is a slight difference when comparing to miniboxing and specialization in Scala: classes have specialized variants, where only one type of the fields appears (not both primitive and object) -- and all access is done through methods, which are overloaded.

Here's (an unrelated) document that happens to explain this: https://docs.google.com/document/d/12pgg8LBkTNaB5BoeKlBrei-Mst8shdGY7ZPfMFuIYzY/edit?usp=sharing -- just search for miniboxing

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

No branches or pull requests

3 participants