Is there any way to do actual things besides mathematical computation with silq?

[Ktedon]

Hello,

Please forgive my foolish title phrasing.

I am inquiring about what I must go through in order to build real world applications with silq (theoretically). Suppose I wanted to implement a library for controlling audio on a device. Hopefully it would both work on my laptop and any theoretical quantum computer supporting the syscalls. I don't see much in terms of a virtual machine with these implemented like with the JVM or anything. I don't know much about quantum computing or the technologies that silq is built upon but am interested to learn more.

Is it at all possible to interact with hardware instead doing computation in a very abstract way?

Sincerely, Walther Green

[sartimo]

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

[Ktedon]

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.

[sartimo]

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

[tgehr]

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

[sartimo]

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

[sartimo]

Nevermind. This goes by #21

[Ktedon]

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?

[sartimo]

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

[Ktedon]

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.

[tgehr]

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.

[tgehr]

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].)

[tgehr]

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

[tgehr]

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.

[Ktedon]

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?

[tgehr]

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.

[Ktedon]

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.

[tgehr]

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.

[Ktedon]

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.