Is there any way to do actual things besides mathematical computation with silq? about silq HOT 18 OPEN

Some other things to consider:

• There is a trade-off between ease of use and implementation complexity. Requiring prototypes like those may be good enough, especially as a first step:

import __ffi.c;
extern("C") def malloc(size: size_t): VoidPtr;

• Silq does not have global state, extern code may or may not access global state. It probably makes sense to add a function annotation for functions that may change global state, e.g. io, and/or add additional parameters to extern functions representing the global state of the respective external language.

import __ffi.c;

extern("C") puts(str: Ptr[Char]);

def main(ref cstate: state["C"]){
    puts(cstate, "hello world");
}

• It probably makes sense to add a ref parameter annotation to avoid having to explicitly thread through the state.

• Silq does not have any mutable aliasing. This can also be solved by explicitly passing the global state.

• There needs to be some way to specify where to look for external machine code.

from silq.

Hey,

Since real QC Hardware is rare and pretty sophisticated it will be difficult to interact with hardware. However, we could integrate something like a OpenQASM Transpiler to write code that emulates on Qiskit Metal like quantum emulators.

Best regards
Timo Sarkar

from silq.

What about something like a kernel API? Something that serves as a more platform independent interface to the hardware like how I can create a TCP connection by importing linux headers in my C code.

from silq.

Well, I am not sure but if Silq supports native dlang interop, then this will surely be possible.

from silq.

I'll treat this issue like an enhancement request for some sort of FFI.

@Ktedon:
Dear Walther,

The focus of Silq is expressing quantum computation in a high-level fashion.
Interacting with a classical operating system may of course be useful for some applications, but it would not have been an original research contribution, so this has not been prioritized. However, this is relatively straightforward to add.

Best,
Timon

from silq.

Indeed, I think a compilation target to OpenQASM or similar low-level infrastructure would be a great milestone for reaching interaction with QC prototypes. (Or at least emulated ones).

Regards
Timo Sarkar

from silq.

Nevermind. This goes by #21

from silq.

I'd be happy to try to implement a FFI to D, C, C++, and maybe some other high level language. I am unfamiliar with D but am familiar with Zig and C. Looking at the code base I can understand it quite well.

That said, there should be some consensus on syntax and general approval before I begin doing so. Perhaps it looks a little something like: import "awesome_lib.d";

Also, do people like this idea, I mean a FFI?

from silq.

Yeah. An FFI would be a good part especially when we can experiment with new quantum paradigms such as polymorphic quantum states and so on. I also have quite some experience with C, C++ and D. Maybe we can take a reference on an API between D and LibFFI

from silq.

One more thing we should consider in terms of design is how we are going to handle the types between D and Silq. Naturally classical types would be used for calling and interacting with classical computer languages. But we would need to possibly add more classical types to be able to call all the appropriate functions. Additionally, we will need some sort of error handling in the case that a foreign function fails.

from silq.

One more thing we should consider in terms of design is how we are going to handle the types between D and Silq.

Special types that don't easily map to Silq types (e.g. size_t, T*, T[]) can be added to __ffi.d as (generic) types with special handling. Other types can just be mapped to Silq types. (e.g., int to !int[32] and ulong to !uint[64].)

from silq.

Probably there should be a distinction between functions that have a memory safe interface and other functions.

from silq.

FFI support and any potential external dependencies it implies should be optional during the build. The bulk of the FFI implementation should be in a new git submodule.

from silq.

I think that the foreign file imports should be in the form of strings because file names can have spaces in them. We could also use pragma syntax instead of extern because it would be more flexible to extensions in the future.

I wonder if it would be possible to create variables to represent global state that can be passed as a global state to any foreign function to modify it like this:

import ffi;
import __ffi.c;

pragma["C"] def println(size: string)(ref: io): void;
IOState := io();

println("Hello FFI!")(IOState);

I believe this is what you were talking about when you were referring to additional parameters to refer to global state. This could be done lazily so that if we were call something like IOWrite(IOState), it would finally compute println and then print it so that we can save FFI/system calls for performance and so that we don't have conflicting IO states.

One more thing we should consider is how we are going to handle handles in C functions. I think we could unify against a parameter in a function. Since the function will only be one way the value will be passed into the function and then that value will be unified against the parameter in the function updating itself. That said, we would need extra unification syntax as an addition to the language.

Could you clarify what you mean by unsafe and safe function interfaces? Do you just mean safe and unsafe function in general?

from silq.

Could you clarify what you mean by unsafe and safe function interfaces?

Low-level functions that are intentionally designed to possibly be able to break type system invariants if called with bad arguments have an unsafe interface. Functions with a safe interface are intended to have well-defined behavior for all combinations of argument values. It's about what's written in some trusted specification, not about what the functions will actually do in practice (they may have bugs).

Do you just mean safe and unsafe function in general?

That fully depends on how you define those terms.

from silq.

That sounds like a pain. Perhaps we just force the developers to make smart decisions about calling functions with unsafe interfaces and for functions which return errors on execution like division which will fail if the denominator is 0.

from silq.

I am not really willing to completely give up on type safety without some sort of mitigation strategy that limits/localizes the potential for UB to be caused by errors in Silq code.

from silq.

You're right. I suppose I was feeling lazy last yesterday. What if all return values from foreign functions are wrapped in a "try" constructor. The user would be forced to handle every foreign function call as if there were going to be an error.

from silq.