vsl-lang/VSL

LLVM blocks

Closed this issue · 7 comments

Functions should be able to specify code-block type as an LLVM block:

public func add(a: Int, b: Int) -> Int llvm {
define <returnType> <name>(<param>, <param>) {
     ret i32 add ( i32 %0, %1 )
}
}

Instead of that, you could just do this:

public func add(a: Int, b: Int) -> Int llvm {
     ret i32 add ( i32 %0, %1 )
}

Or better:

public func add(a: Int, b: Int) -> Int {
    // do some important stuff
    llvm {
        ret i32 add ( i32 %0, %1 )
    }
}

It's kinda redundant to be specifying the llvm define as well as the vsl function, since the compiler should be able to handle the function signature anyways.

oh :| yeah that is true (about the params). Personally I'm a fan of your former example, especially since with the latter we don't be able to run any checks on it:

public func doBork() {
    var a = Goat()
    llvm {
       call void @otherFunction(Goat* %a) // ono now potential memory leak or bork.
    }
}

Also we should have special syntax to pass a literal to the llvm function, maybe we can use something like Haskell's Quasiquotation?

public func doBork() {
    var a = Goat()
    [|llvm|
       call void @otherFunction(Goat* %a) // ono now potential memory leak or bork.
    ]
}

@ascii-only but how fixity mermomry peak

Um :| IDK maybe we shouldn't do it at all lol, instead provide bindings, instead:

public func doBork() {
    var a = Goat()
    with (llvm) {
       call void @otherFunction, a // command chain, llvm.call.void(@otherFunction, a)
       // llvm. prefixed as needed because of with llvm (maybe we need to use another keyword)
    }
}

@somebody1234 we can do that for intrinsics but won't work for syntax, the point of embedded LLVM is to express what you can't with VSL

@vihanb Then yeah memory leak is big bork