mental32 / monty Goto Github PK

Currently the only supported architecture is x86_64-pc-linux-gnu since this is what I'm developing this library on.

Documentation efforts have been started in /dev/ there is a developer guide book and sphinx auto generated API docs.

These need to be expanded upon of course.

We need to (at least) support:

• simple generic functions (e.g. one type argument)
• unions (i.e. Union[T, U] or T | U)

But what should we test?

The codebase is a complete mess at the moment :(

Granted, I expected this. I've just been hacking it together hap haphazardly and its probably a good idea to go and look at the overall architectural approach we want to take.

At the moment the flow of information is pretty messy, there are several ways to get the same answer for a question. We still have access directly to the AST when we parse out the source into a module node. We do use the Item abstraction to alleviate the pain of working over the AST directly but this makes it difficult to re-write and modify the tree for instance (this would be needed for a class of tree-based optimization and constant operations)

Currently we don't have any importing mechanisms or module infrastructure but this shouldn't matter too much for the bullt-ins since people don't typically use them through the builtins module import.

We now have minimal functioning support for modules & importing!
At the moment builtins have to be explicitly imported but we can fix this easily enough :)

Big list of stuff to implement:

• abs
• all
• any
• ascii
• bin
• bool
• breakpoint (I don't have a god damn clue how to deal with this one)
• bytearray
• callable (Actually this should be fairly simple!)
• chr
• classmethod
• compile
• complex
• delattr
• dict
• dir
• dimod
• enumerate
• filter
• float
• format
• frozenset
• getattr
• globals (comptime only)
• hasattr (comptime only?)
• hash
• hex
• id (this is basically the "address of")
• input
• int (a zero argument version of this should be easy asf)
• isinstance(comptime only?)
• issubclass (comptime only?)
• iter (shrug)
• len (ehhh kinda UB)
• list
• locals (comptime only)
• map (shrug)
• max
• memoryview (what was this?)
• min
• next (shrug)
• object (big shrug)
• oct
• open
• ord
• pow
• print (big oof, nearly done)
• property (SHRUG)
• range
• repr
• reversed
• round
• set
• setattr
• slice
• sorted
• staticmethod
• str (lmao no, we need heap allocation for this baby)
• sum
• super
• tuple
• type
• vars
• zip
• __import__

Expected behaviour:

assert(len([1, 2, 3]) == 3)

Current behaviour:

assert(len([1, 2, 3]) == 20)

Allow the following to be valid code:

class Foo:
    pass

def make_foo() -> Foo:
    return Foo()

def main():
    make_foo()

once that is working let's do associated methods:

class Foo:
-     pass
+    def bar(self) -> Foo: return self

Related efforts: #7

We gotta have modules but for that we gotta have importlib/import machinery in order to resolve and locate the modules when parsing out from-import and import nodes.

See also importlib._bootstrap, CPython actually appears to have its core import logic implemented in Python but when the interpreter gets compiled the source file implementation gets dumped out into raw bytecode and transpiled into a C int array and marked as "frozen".

Currently we only support integers and boolean as legal types, this is fun and all but we should be able to express more complex structures i.e. (C-like?) strings and tuples.

• Strings (#3)
• Tuples
• Lists
• Sets
• Dicts

Currently these don't exist, the current model is to just hit an assertion error or a type exception somewhere deep in the code and figure out the solution yourself.

You've probably already considered this, just tried to think of commonly used ways to branch on type :)

# same narrowing
if isinstance(x, int): ...
if type(x) is int: ...
if issubclass(type(x), int): ...

Special cases with singleton stuff, obviously, like:

# same narrowing
if x is None: ...  # (!)
if type(x) is type(None): ...
if isinstance(x, type(None)): ...
if issubclass(type(x), type(None)): ...

More obscure narrowing cases, but should follow automatically if everything's done properly:

# say y is an int
if isinstance(x, type(y)): ...
if type(x) is type(y): ...
if issubclass(type(x), type(y)): ...

MIRI, lets build an interpreter to consume our IR and execute it in a more controlled environment so we can test more thoroughly for stuff like memory leaks or use use-after-free's

Totally did not borrow this from Rust...

Right now our internal visitors just skip over constant string nodes, we should be able to at least represent their presence. potentially in a global string interning table?

Currently our MIR, Ebb, FluidBlock and Basic block instructions are all more fragile copies of the ones in cranelift-codegen.

Typically this wasn't an issue since monty was being developed for montyc which uses cranelift as its main backend so if the IR API matched it made life easier. However monty is intended to be consumed by many others, such as MIRI, where the cranelift IR builder API mirroring doesn't make sense.

I was thinking this might be nice thing to have, macros are pretty much everywhere and there's even a PEP for it!

I'm not planning on implementing PEP-648 yet since it's not supported in any official parser anyway.
Instead I was thinking something closer to Rust-like attribute macros.

Here's a contrived syntax example:

import __monty

@__monty.decorator_macro
def discard(node):
    return None 

@discard
class Never:
    """This class never exists."""

The idea is that these macros can only be applied as decorators and accept only one argument node of type ast.AST and return Optional[Union[ast.AST, Iterable[ast.AST]]] where:

• None means "remove {node}"
• a single AST instance means "replace {node} with {rv}"
• any iterable value of AST nodes means "insert {rv} in place of {node}"

At the moment I assume the implementation, upon discovering a macro function, "pop" it from the tree then subsequently compile and call it whenever we use the macro.

We need to figure out type inference at some point if we even want a chance at a pleasant experience writing code.

Type annotations are fine in places where we fail to infer types and in ClassDef/FunctionDef nodes.

Everywhere else we kinda need it to work