Refactor types/ops

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Oct 15 17:26:54 UTC 2024


I agree with this direction.

Furthermore, I wonder if, even for stuff that we can implement using the 
"core" dialect (e.g. a method declaration can be implemented using a 
func op), we should introduce its equivalent Java-like abstraction. E.g. 
MethodOp (which trivially lowers into a FuncOp).

E.g. I think it's important we minimize the amount of going up/down the 
ladder that users have to do. If I want to work on Java, ideally the 
`java` package should have everything I need (and the resulting model 
will the *lower* into something more `core`). Am I being too extreme?

Maurizio

On 15/10/2024 17:52, Paul Sandoz wrote:
> Hi,
>
> I am going to refactor the types/ops and group into two dialects, core and java dialects. This should help clarify their behavior and use. It’s mostly a mechanical change but still disruptive. Dependent code in the repo will also be updated so hopefully nothing will break.
>
>
> We currently have three distinct areas:
>
> 1) The core, comprising of type elements such as Var, Tuple and operations such as constant, branch, closure, var, and var.load/store.
> Some of these have correspondence to Java expressions or statements, and some are used to model Java program behavior, but they are also general purpose.
>
> 2) The java core, comprising of the java type elements, and operations such as return, invoke, and instanceof that more specifically model some Java expression or statement, or more specific Java program behavior.
> Some Java operations can be repurposed e.g. arithmetic operations.
>
> 3) The java extended, comprising of operations such as for and if, using types from 1 and 2, that can lower into operations from 1 and 2. These model Java expressions, statements or more specific Java program behavior that have nested structure, often with control flow.
>
> A java model produced by the compiler, one in which is derived from Java source and preserves Java programing meaning, is comprised operations and types from all three. Lowering produces a model comprising operations and types from the first two, which again preserves Java programing meaning.
>
> At the moment we lump 1 and 2 together under CoreOp, and separate 3 under ExtendedOp. For clarity we should separate out 1 and 2, and lump together 2 and 3:
>
> - separate 1 and 2 into distinct dialects. 1 under CoreOp and 2 under JavaOp.
>
> - lump 2 and 3 into in one “java” dialect, under JavaOp, and we distinguish between different Java operations with some marker interface.
>
>
> I will create two new packages
>
>    java.lang.reflect.code.dialect.core
>    java.lang.reflect.code.dialect.java
>
> The core ops and types will reside in the core package, as will the op/type factory support. The Java ops, types, and references will reside in the java package. For now I will keep concrete ops as enclosed classes.
>
> The packages java.lang.reflect.code.op and java.lang.reflect.code.type will be removed.
>
> Paul.
>
>


More information about the babylon-dev mailing list