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
Afficher les réponses par date
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
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
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
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
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.
-- 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
You can write a macro that process them, sure.
On Tue, Oct 22, 2019 at 9:19 PM Adam adam.mlmb@gmail.com wrote:
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.
-- 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
Convenience... If it's a very big chunk of ffi code I tend to put it in its own file.
On Tue, Oct 22, 2019 at 6:23 PM 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