ir: rethink sumtypes to allow for user-definable types

[mewmew]

Should we rethink sumtypes to allow for user-defined types?

For instance, ir.Instruction currently requires the unexported isInstruction method, but there are valid use cases where users may wish to define their own instructions to put in basic blocks.

One such use case seen in the wild is a comment pseudo-instruction which prints itself as ; data..., e.g.

// Comment is a pseudo-instruction that may be used for adding LLVM IR comments
// to basic blocks.
type Comment struct {
   // Line-comment contents.
   Data string
}

// IsInstruction implements the ir.Instruction interface for Comment.
func (inst *Comment) IsInstruction() {}

// LLString returns the LLVM syntax representation of the comment.
func (inst *Comment) LLString() string {
   return fmt.Sprintf("; %s", inst.Data)
}

[mewmew]

While here, we should also add remaining test cases to ensure that sumtypes are implemented and enforced.

e.g.

// Assert that each constant implements the constant.Constant interface.
var _ constant.Constant = (*Global)(nil)

[pwaller]

I don't have a strong opinion on this. I can see the benefit of "locking down an API to only hold objects you exactly know what they are". But the alternative view in my mind is that you don't care what the object is, but only the interface it satisfies. If someone is willing to pass an object that satisfies the interface, I don't immediately see a strong reason to disallow it.

Someone also recently pointed out that you can actually defeat this by embedding anyway!

https://news.ycombinator.com/item?id=19347281

The context they brought it up was that this technique is actually used in go SSA.

[mewmew]

I can see the benefit of "locking down an API to only hold objects you exactly know what they are".

The benefit is unquestionably stability. However, with stability comes limitation, just like in life :p

If someone is willing to pass an object that satisfies the interface, I don't immediately see a strong reason to disallow it.

The main reason I can think of is that there are definitely parts of the llir/llvm/ir code base that would start to break down, as they perform type switches on known concrete types.

For instance, let say someone defines their own llir/llvm/ir/types.Type. This would break when used with the getelementptr instruction, as we use the concrete types.FooType types to determine the element type of the gep instruction.

llvm/ir/inst_memory.go

Line 560 in fe7863f

case *types.StructType:

However, we also want to allow such use cases as they are very powerful. For instance, it is easy to envision a user-defined LLVM IR type for structures with named fields.

package foolang

type StructType struct {
   FieldNames []string
   *types.StructType
}

I really wish we can find a way to fix such fragile code, so that we may allow users to define their own LLVM IR types, values, etc. I think it is good to enable using the IR package in ways not envisioned by the authors of the IR package. Essentially following the principles of Unix.

Someone also recently pointed out that you can actually defeat this by embedding anyway!

That's a fair point.

[pwaller]

Well the immediate thing that strikes me is that wherever we do a type switch maybe that's a hint that you could perhaps make it an interface instead (or type switching over interfaces), perhaps, for example on types that have an "Elem()" method.

I think in general if the user wants to implement their own objects they have to accept that things might break. At least this kind of breakage will tend to be fairly obvious!

[mewmew]

I stumbled upon sumgen, and it may be worth investigating whether we should use such a tool to generate the dummy method definitions for sumtypes. Perhaps it's worth it, perhaps not. Regardless, it would be interesting to explore.

[mewmew]

Having worked a bit on getting Geode up to speed with using v0.3.0 (in geode-lang/geode#27), I'm quite convinced that we should work on getting sumtypes right for the v0.4.0 release, to allow for user-defined instructions (e.g. line comments), types (e.g. structs with field names), constants, etc.

Just putting this here, so we can prioritize working on this issue early on as it could have quite invasive API changes.