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