Feedback on Preview Records and Pattern Matching

[stevenselectronicmail at gmail.com]

Hi,

I was playing around with a toy interpreter that compiles a tree of
nodes to a kind of monadic code and then runs it.

There seem to be maybe 2/3 main issues.

1. Pattern matching bytecode seems to be bloated.

        static <A, B, C> Branch<A, C> then(Branch<A, B> branch, Prog<C>
next) {
                if (branch instanceof Dynamic<A, B>) {
                        return Dynamic.then((Dynamic<A, B>)branch,
next);
                }

                if (branch instanceof Then<A, B>) {
                        return Then.then((Then<A, B>)branch, next);
                }

                if (branch instanceof Ap<A, B>) {
                        return Ap.then((Ap<A, B>)branch, next);
                }

                if (branch instanceof Mp<A, B>) {
                        return Mp.then((Mp<A, B>)branch, next);
                }
                throw null;
        }

is two times smaller than the same with pattern matching.

2. If you use records you can't use abstract classes and must use
interfaces but interfaces have slower virtual method dispatching.
This is just a tiny nit. If you really need this then don't use records
I guess.

3. Pattern matching doesn't work well with generics.

Literal code from my interpreter.

        public <A> Step<A> evaluate(Effect<A> effect) {
                Object result;
                Interpreter newState;
                if (effect instanceof PushEnvEffect push) {
                        var newEnv = ((Object[])push.env()).clone();
                        result = null;
                        newState = new Prod(newEnv, new Stack(env,
stack));
                } else if (effect == SaveEnvEffect.SAVE) {
                        var envCopy = env.clone();
                        result = null;
                        newState = new Prod(envCopy, new Stack(env,
stack));
                } else if (effect == CopyEnvEffect.COPY) {
// ....
                } else {
                        throw new
UnsupportedOperationException(effect.toString());
                }
                return new Step<>((A)result, newState);
        }

If you think about it the type of A should be different depending on
the pattern. But that requires flow typing which is one of the things
pattern matching wanted to avoid!

It's kind of a puzzle isn't it?

Thanks
Steven Stewart-Gallus