Re: Logo baseline

[Arne Babenhauserheide]

Ludovic Courtès <address@hidden> writes:
> 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.

I don’t think that it is described as "just" an extension language. The
website makes it very clear that Guile is also a viable application
language.

Where do you get the impression that Guile is described as "just" an
extension language?

>> 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.

CPython isn’t really nice to embed. Blender managers, but otherwise I
don’t see much good integration.

Isn’t Script-Fu a tinyscheme — with much fewer capabilities than Guile?

Lua does hit the same, but has less default functionality.

> Other adjectives I proposed (fast, functional) don’t quite apply to
> these, though.

Functional doesn’t apply to Guile much better than to CPython.

>> 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?

Currently the default way to embed assumes that Guile is provided as a
shared library. But that can be problematic when you want to ship a
binary people can test easily.

For example I’d like to be able to add Guile to a Godot-game and then
simply ship it.

It would also be nice to have an easy option to embed Guile in Android
apps. "If you use Guile, you cannot turn your program into a mobile app"
isn’t a strong pitch.

> 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.

I do the same, but I see that this is no viable way forward for existing
programs.

And having Guile in make has already proven useful to me.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken