Convert m_ast to Haskell ADT

[ThePerfectComputer]

Haskell makes it really easy to work on large compiler codebases and even perform type inference(via constraint solvers). I see miss_hit being a a frontend to such a tool. I'm trying to make an Visitor pass that can dump out a Haskell AST. But to do this, I need to define the right Haskell types. Doing this is not so easy since most of m_ast is untyped. Do you have any hints? Would you be willing to work on this?

Here is what an ADT would look like for a C-language in Haskell, for example.

data CType 
    = CVoid 
    | CInt 
    | CChar 
    | CFloat 
    | CDouble 
    deriving (Show)

data CExpr 
    = CVar String 
    | CLiteral String 
    | CBinaryOp CBinOp CExpr CExpr 
    | CUnaryOp CUnOp CExpr 
    deriving (Show)

data CStmt 
    = CExprStmt CExpr 
    | CReturn CExpr 
    | CCompound [CStmt] 
    deriving (Show)

data CDecl 
    = CTypeDecl CType String 
    | CFuncDecl CType String [CParam] 
    deriving (Show)

data CParam 
    = CParam CType String 
    deriving (Show)

data CBinOp 
    = CAdd 
    | CSub 
    | CMul 
    | CDiv 
    | CMod 
    deriving (Show)

data CUnOp 
    = CNot 
    | CNeg 
    deriving (Show)

data CProg 
    = CProg [CDecl] [CStmt]
    deriving (Show)

[florianschanda]

I would not be willing to work on this :)

Further, don't believe all the Haskell hype.

But actually the m_ast is extremely strongly typed (for python), with strong guarantees and invariants. There is also a visitor function.

For example:

miss_hit/miss_hit_core/m_ast.py

Lines 1996 to 2001 in f01fbf9

	class While_Statement(Compound_Statement):
	def __init__(self, t_while, n_guard):
	super().__init__()
	assert isinstance(t_while, MATLAB_Token)
	assert t_while.kind == "KEYWORD" and t_while.value == "while"
	assert isinstance(n_guard, Expression)

Notice the assertions that make sure the shape of the tree is correct.

Also you get this visitor class:

miss_hit/miss_hit_core/m_ast.py

Lines 194 to 199 in f01fbf9

	class AST_Visitor:
	def visit(self, node, n_parent, relation):
	pass
	def visit_end(self, node, n_parent, relation):
	pass

• node is the thing you're visiting
• n_parent is it's parent in the ast
• relation is a string that describes what node is in relation to it's parent, e.g. "Pragmas" or "Functions"

There are two visit functions, one that is called as we descend down the tree, and one that is called as we come back up.

You can call the .visit function on any node, like so:

self.visit(None, Text_Visitor(fd), "Root")

For an example you can look at Text_Visitor, which is the tree ast printer.

I strongly suggest you do not do what you're trying to attempt, it will not be worth it. But that's just my opinion, you're of course free to do what you want ;)

[ThePerfectComputer]

Well, I seem to have gotten something that should work for emitting Haskell. I've worked on parsers in Haskell before, and Haskell has a bunch of out of the box goodies that make manipulating ASTs trivially easy. I'm curious as to why you don't think it would be worth it?

[florianschanda]

Let me turn it around: what specifically do you want to do with a haskell ast that you cannot do right now?

Type inference is totally fucked in MATLAB you won't get far, because it doesn't make any sense (literally everything is implicitly a c++ style template). This is the main reason I have not implemented this yet.

What remains? Visitors and pattern matching? You can already do that with the provided visitor class.

Shape and typing of the tree is statically enforced, so again nothing to be gained.

The only thing that remains is that you might favour writing haskell, that's fine; but then you're basically on your own and any issues you have you'd first need to reproduce them on the plain python to ensure it's not in the translation somehow.

[Remi-Gau]

Type inference is totally fucked in MATLAB

please keep on ranting: this is making my day

[florianschanda]

Gladly. :)

OK, so even something like this is impossible to type in isolation:

function rv = potato(x, y)
    rv = x + y;
end

x could be:

• a scalar
• a matrix
• a class (with possibly user-defined overloaded things)
• a uint8
• something else I forgot because I don't use matlab normally

And the validity and semantics of the + depends on the actual combination.

Even if you code generate, you can validly call potato with potato(1, 2) and potato(uint8(3), 4) in the same program. So type inference is only possible if you do a whole-program analysis, and even then you need to either:

• demand the user is not writing functions that can be used with different types (good luck telling matlab people do something sane, i mean that ship has sailed when matlab was chosen)
• treat every single fucking function like a template

Sometimes it may be possible to enforce constraints, because not all combinations are legal, but in general you are just screwed.

[florianschanda]

Also, any function that adds to the ast (e.g. adding a function to a class, etc.) makes sure the shape and any invariants are maintained.