[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal

From: adriano
Subject: Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Date: Sat, 19 Feb 2022 18:35:45 +0100

Il giorno sab, 19/02/2022 alle 10.33 -0500, Olivier Dion via General
Guile related discussions ha scritto:
> On Sat, 19 Feb 2022, Neil Jerram <> wrote:
> > Personally, I am now a big fan of Scheme-centric + FFI, as it means
> > always writing Scheme and never having to hack C code.  If everyone
> > agreed on that, we could discard all the C-centric parts of the
> > manual, and focus the rest on a clearer use case.  But I very much
> > doubt that there is clear agreement on that.  In particular, the
> > C-centric usage is really Guile's original reason for existing: to
> > act
> > as a universal extension language for lots of GNU programs that
> > already exist.
> All projects being different, I don't think this is possible.  For
> example, I've added Guile bindings for Jami, which is written in C++.
> FFI does not have support -- as far as I know -- for C++ std::string,
> std::vector<T>, std::map<K, V>.  So it's a necessary to use more than
> the FFI module.
> I should add that I first started using Guile because of its easy
> integration with the C runtime and clear documentation on how to
> interlop it.  If it was not for that, I would probably have dismiss
> Guile and select Lua instead.
> TLDR: I don't think we should discard anything that is C-centric in
> the
> manual.

Probably there should be 2 distinct manuals

One for each (macro) use case

The cognitive overload for someone wanting to just get their feet wet
and then maybe grow their thing organically is frankly unfair

But even by keeping a single manual, been watching Blake's video for a
while now, he offers some suggestions about how to lessen such
cognitive overload on the poor newcomer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]