Re: [ANN] Guile Hall 0.3.0 released

[Catonano <catonano@gmail.com>]

Il giorno dom 17 mag 2020 alle ore 17:35 Alex Sassmannshausen <
alex.sassmannshausen@gmail.com> ha scritto:

> Hey Cato,
>
> Catonano <catonano@gmail.com> writes:
>
> > […]
> >
> > This is an important step in making the Guile user experience less rough
> >
> > Where, in the manual, should such mention be placed ?
>
> I guess section '4.6 Using Guile Tools' might be a good place to put it?
>
> 4.5 advetises paredit and geiser — but that is specific to Emacs.  4.6
> is about guile tools more generally.  So I imagine something like the
> blurbs about paredit and geiser, but then for hall and in 4.6?
>
> What do you think?
>
>
I'm ok with that

I'm somewhat puzzled by 4.7, it's about installing Guile code.

It mentions system controlled locations (on traditional systems) such as
usr/lib/...

it seems it assumes that people install guile object files by hand ?

On another side, if you have some .scm files scattered around, they will be
autocompiled and the result will be put into some well hidden buried folder
in your home folder

Ah but that's for things that only you as a user can access

System locations are for all the users on a machine

I mean: the whole distribution story is not clear

It's not as clear how you're supposed to package your stuff and how people
who receives your stuff are supposed to deal with that

As in many cases, the Guile manual is detailed about properties and
features and way less concerned about use cases (in this regard, I suggest
this talk https://archive.fosdem.org/2017/schedule/event/legacy_docs/ )

The assumption is that based on properties and features, you can come up
with a user case that fits your needs yourself

it's a bit of a heavy assumption 🙁

Overall, I'd say this:

There is level 0 of Guile packaging: that's NO packaging. You keep your
files scattered around and they will be autocompiled

You put your files in a git repo on line, your friends will check them out
and autocompile them too

Then there's level 1: when things get a bit more structured, for example
your package may depend on some other Guile library or on a specific
version of Guile

In that case, you need to setup the autotools in your project

Distros such as Ubuntu and Fedora will be able to distribute your package
and your friends on Gentoo will be able to deal with them by hand

In the future, there could be a level 2. That is: no m4 anymore !! As fas
as I undertsand the Autoconf based machinery relies on bash to execute
tests (is such library available ? Is Guile version >= 2.7 ?)

And Guile is perfectly able to substitute bash scripting.

So we could collect a series of common tests used for configuring Guile
packages and implement them in Guile !

That would introduce the assumption that Guile is as widely available as
Bash is and that'd be debatable

But I'd go for that anyway

Wrapping up: yes, 4.6 is good for a mention of guile-hall

But things like 4.7 (and maybe others) will confuse people

it took me years to figure out the Guile distribution story and this email
is a distillate of years of confusion

I'll try to write a mention of guile-hall for the manual and send a patch.

Not right now, though. In the coming days

Thank you Alex for giving me a chance to extend myself on the Guile
distribution story