Hello! Arne Babenhauserheide <arne_...@web.de> skribis:
> Thomas Morley <thomasmorle...@gmail.com> writes: > >>> Clearly, Guile is still an extension language, with many great >>> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.) >> >> Well, you forgot LilyPond > > The one tool that uses Guile while dominating its domain. Yup, I don’t forget LilyPond! >> Well, for me, Guile's _the_ extension language for my LilyPond. >> >> It may be more, it may have become more. >> And yes, I used Guile for some other stuff as well. >> Nevertheless, it remains the language to extend LilyPond. >> >> It feels very strange dropping said phrase. > > Same for me. Like I wrote, Guile remains an extension language, no argument here. However, describing it as “just” an extension language seems odd to me. It doesn’t take into account what many have been doing with Guile, and it doesn’t match the efforts that have gone into Guile since 2.0. > That Guile takes effort to make extending easy distinguishes Guile > from all the just-scripting languages out there, and also from many > other Schemes. I don’t find embeddability to be that much of a salient feature. After all, CPython, Script-Fu, Lua, ECL, GJS, etc. all fit into that category. Other adjectives I proposed (fast, functional) don’t quite apply to these, though. > Actually I’d love to see Guile become better at this: to make it easier > to deploy an application that uses Guile in a statically compiled > binary. > > Basically to generalize what LilyPond is doing. In what ways could it become “better” for this use case? Personally, I encourage people to write more Scheme and less C, there are lots of good reasons for that. As a corollary, I encourage moving from “embedding” Guile (linking your C/C++ program against libguile) to “extending” Guile (having your main program written in Guile Scheme and calling out to C/C++ bits as needed). That’s been my position since the 2.0 days. Thanks, Ludo’.
