Open lydia-duncan opened 5 years ago
Note: I do not view this as a priority. I'm mostly tracking the idea because it came up, and my immediate thoughts on what would be involved.
As far as C goes, mapping exceptions to errno (or our own thread local equivalent) makes the most sense to me.
There is also the question of what is generated for user subclassed exceptions. One possibility is to generate an enum over all exception types which may be thrown via exported functions. This would require some AST wizardry.
Right now my RPC protocol looks something like this:
The client requests a function call with a positive number on "main", or indicates an error with a negative number. It then pushes the call args across "args". The server attempts to perform the call, then replies with either 0 (success) or an error (and flushes the args socket appropriately). If the server returned success, the client is free to read the result args from the "res" socket. Else it can respond appropriately.
This model seems flexible enough to enable me to do something like, IE, translate Chapel exceptions to C code in the future?
I'll post more thoughts as my prototype comes closer to fruition.
Ahhhh, the nostalgia.
I think if I were to work on this effort today, I would:
throws
for exported functions when exporting to C
, because C
doesn't have a concept of exceptions and I don't think we can co-opt errno
in a portable way@linkage("python")
, so you could write an exported function that throws specifically for Python (though this raises its own questions)Consider allowing Chapel to specify linkage for exported functions, e.g. @linkage("python"), so you could write an exported function that throws specifically for Python (though this raises its own questions)
This is pretty attractive-sounding to me. We've discussed supporting extern("C")
, extern("Fortran")
to support external declarations in languages other than C in the past, and I think could do the same for export
, but this does seem like it could be a good use of an attribute…
That said, I think the compiler should also be given a flag saying what language it's exporting for which would serve as the default. E.g., if I have a program that is only ever going to compile into a Python library, the decorators shouldn't be necessary and C should only be considered the default if that's the kind of library we're creating?
That said, I think the compiler should also be given a flag saying what language it's exporting for which would serve as the default. E.g., if I have a program that is only ever going to compile into a Python library, the decorators shouldn't be necessary and C should only be considered the default if that's the kind of library we're creating?
This is what --library-python
does today, we just have --library
mean "C" instead of forcing it to be specified as well
How should we handle exported functions declared with throws?
This should probably be an epic. When it gets prioritized, we'll want to split it into subcomponents