Makes sense to keep core complexity down 👍Now, would there be some way to add the FFI forms some other way, maybe support them via some form of language extension module, that somehow properly processes them into Gerbil?(define-macro (zlambda . a) `(begin-foreign (c-lambda ,@a))) , a-lmost solved :))On Wed, 23 Oct 2019 at 02:09, Dimitris Vyzovitis <vyzo@hackzen.org> wrote: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.-- vyzoOn 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