Mainly because I didn't want to bake in ffi semantics into the expander.
On Tue, Oct 22, 2019 at 9:05 PM Adam adam.mlmb@gmail.com wrote:
What's the reason for the need to "drop to Gambit code" (as in enter a special non-Gerbil code mode) for FFI code?
Afterall FFI code is just a handful special forms that are straightforward [for Gerbil etc.] to process.
(Black Hole had total symmetry between normal Scheme and FFI code, though I remember Per complained about that the difference in load semantics between non-FFI and FFI code caused him just a bit of headache because they're not really symmetrical, in the respect that normal code can be |eval|:ed while FFI code cannot.)
On Tue, 22 Oct 2019 at 23:44, Dimitris Vyzovitis vyzo@hackzen.org wrote:
What do you mean why? If you want to write ffi code, you need to drop down to straight gambit code, and that's what being-foreign does. begin-ffi is a macro on top, you can look at its definition in :std/foreign.
-- vyzo
On Tue, Oct 22, 2019 at 6:29 PM Adam adam.mlmb@gmail.com wrote:
Ah there's also |begin-foreign| and |begin-ffi|, why?
On Tue, 22 Oct 2019 at 23:23, Adam adam.mlmb@gmail.com wrote:
Hi Vyzo,
Browsing Gerbil modules for instance here https://github.com/vyzo/gerbil/tree/master/src/std/db I see that FFI modules tend to have a non-standard format, instead of just being a file whateverclibmodule.scm (or .ss in the Gerbil convention, though .scm is supported since last week right) which contains normal Scheme and Scheme FFI code interspersed e.g. (define-c-lambda funame ...) implies (export funame)
, you have a .scm file and a .ssi file, where the .ssi contains (extern funame).
Why is this?
Thanks, Adam