Norman Gray writes: > > Matthew, hello. > > On 7 Jul 2024, at 20:32, [email protected] wrote: > > > On the other hand in both cases what's left is mostly writing the > > S7 interface functions which for the most part should require only > > naming the constant or function. Anyone like writing long lists of > > repetetive code? > > Writing no; generating... sometimes.
Indeed consider that tongue in cheek. I expect (hope!) by the end there'll be a higher ratio of generated:written code. At this early stage I'm more concerned with feeling out how the API will be exported and a little bit of repetition isn't a huge problem yet. There's also still a few features of S7 I'm not taking advantage of yet like function signatures and I wouldn't like to have to inject them into tangled up macros. > Faced with a similar problem, I've used s7 to generate C before. > Specifically, I can point towards util-extra.c.in at [1], which includes > #(...) forms within the source, which expand to C, using a very simple > function in scheme-macro-filter.scm there. Thanks I'll take a look. I tend to lean toward CPP macros through familiarity but that may change as I build up a body of code, provided I can keep magic out of the build process. > I take the opportunity to mention this, partly to join in very late on a > snd/s7 list thread of a month or so ago, expressing communal enthusiasm for > s7 (thread 's7 got some love in the Lisp game jam'). The program I'm > pointing to does a lot of its > work in s7, although (in the terms of the blogpost which started that thread) > I can't tell if it uses the 'icing' or 'cake' model: C calls s7 main calls C > calls s7. The point of this paragraph is to log that I've become more and > more of an s7 fan, > in the sense that it seems to have exactly the right tone to match the > extension problem very well. So thanks, Bill. This is essentially why I've settled on S7. There's no "FFI" as such, instead I can flit back and forth between S7 and C seamlessly as needed. I guess that makes S7 the ... fork? Matthew _______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
