Re: Hygienic rewrite of (ice-9 expect)

[Daniel Dinnyes]

I've rebased my changes onto a fork of Guile's main branch on Github:
https://github.com/dadinn/guile/tree/wip-hygienic-expect

Added back the original attributions and comments.

I've also tried to follow the branch-naming conventions. 😉

Also, I've added a module ice-9/expect-tests for some comprehensive tests.

Wasn't sure where to place it, and how to integrate into the existing test-suite.

Not sure how to send a PR by email, but I suppose it should be easy to pull, by adding my fork as an additional remote.

Best regards,

Daniel Dinnyes

On Mon, 29 May 2023 at 22:33, Maxime Devos <maximedevos@telenet.be> wrote:

 >p 29-05-2023 om 03:40 schreef Daniel Dinnyes:
> Thanks for the reply.
>
> On Sun, 28 May 2023 at 14:39, Maxime Devos <maximedevos@telenet.be
> <mailto:maximedevos@telenet.be>> wrote:
>
>     I think this would gather more replies if:
>
>        1. It is sent as a patch that can be applied to the Guile source
>     tree.
>
>     (You wrote:
>
>       > If the community likes this implementation, I would be happy to
>       > apply/rebase my changes onto the official repo, and then we can go
>       > from there!
>
>     but to determine whether I'm happy with it, it would be convenient if
>     this were a proper patch.)
>     (I'm not actually reviewing Guile stuff at the moment, but I find it
>     likely that some others might hold the same view.)
>
>
> Regarding patches, I think I've read somewhere that GNU wants
> contributions in some different format,
> than just URLs to pull-able GIT repos. Could you share with me some
> guide how to do such patches,
> or what format they are needed?

Format: the result of 'git send-email', or 'git format-patch + attach
the patch as an attachment'.  I've heard that the guide at
<https://git-send-email.io/> for 'git send-email' is good.

Still, setting up a fork + sending a PR (by e-mail), while not the most
preferred format, would still be pretty good (‘git diff’ can then be used!).

> I am assuming this <https://git.savannah.gnu.org/cgit/guile.git/> is the
> repo of current guile tree, onto which to apply my changes.

Yes.

> Onto which branch?

The branch named 'main'.

> Would it possible to fork the repo on savannah, and then raise a PR from
> there instead of patches?

Savannah doesn't have a notion of 'forks' AFAIK. (Emphasis on the ‘I
don't know’ in ‘AFAIK’, maybe it actually does have them in some form.)

However, you can do a PR ‘manually’ by setting up a fork of the repo at
some random hosting site of your choice, pushing some commits there, and
sending a (free-form) e-mail to guile-devel@gnu.org with a message
containing information on where to find the repository and which
branch/commit.

(You don't need PR / fork buttons to do PRs and forks!)

> Also, I've tried to create account on savannah, but it keeps getting
> deleted.
> What would you recommend I do to ensure my account doesn't get removed?

I don't have clue; I only fetch from savannah, I don't have an account
there.

> [...]
> I am not sure I would agree with your assessment about /illegality/, and
> the /derivative work/ categorization.
> Even though these macros happen to expand to something similar as the
> original ice-9 implementation,
> the code itself is quite significantly different! If this is to be used
> in ice-9, it would have to completely
> replace the original expect.scm file, as nothing was copy/pasted from
> there. The fact that parameter binding
> names are the same is necessary for backwards compatibility, so those
> wouldn't count even under the US laws
> <https://www.bbc.co.uk/news/technology-56639088>.

I assumed it is a derivative work because you presented it as a ‘rewrite
of [the original]’.  Maybe it's possible to rewrite something a lot
until its no longer a derivative work (I don't know if that's possible),
but by default I'd assume that rewrites are derivative works.

I didn't use ‘same procedure names’ as a reason (as you wrote, those
aren't a problem).

> On second thought, I am wrong! The expect-select helper function looks
> like a direct copy-paste job... little naughty me!

TBC, I ascribe no guilt.  The thing is that I've noticed in the past
that people often use the GPL without knowing what that entails
precisely, which can have unintended consequences, like e.g.
unintentionally licensing something as GPLv1+ instead of GPLv3+ (or
GPLv3+ instead of GPLv3, but that mistake is actually pretty convenient
for distributions :P).

(Also, Guile relies on the (L)GPL as a form of protection against some
forms of malice, so I think it's important that we also follow the
(L)GPL terms itself.)

> Nevertheless, I would be happy to add the necessary notices if that is
> required.
> Also, IIRC there would be another copyright assignment administrative work
> somewhere down the line?

The copyright assignment used to be required, but nowadays its optional.
  Still, it does appear to be preferred.  You would get an e-mail by a
Guile maintainer with more info, it's not something you initiate yourself.

The page https://www.fsf.org/licensing/contributor-faq sort-of implies
the opposite, but IIRC there is another page somewhere or gnu.org that
doesn't; I don't know what's up with that.  (Either way, I'd think that
things will work out in the end.)

Best regards,
Maxime Devos