bug#66046: Relative includes in R7RS define-library seem broken

[Maxim Cournoyer]

Hello,

Amirouche <amirouche@hyper.dev> writes:

> If I am not mistaken, the patch is not backward compatible.
>
> The problem with the current patch is that it force the included file 
> to be next to the including file, there is no fallback  mechanism. 
> The algorithm should be dynamic using an ordered list a priority to
> the favorite behavior. 
>
> The most relevant hunk is:
>
> --- a/module/ice-9/psyntax.scm
> +++ b/module/ice-9/psyntax.scm
> @@ -3260,15 +3260,20 @@
>    (let ((syntax-dirname (lambda (stx)
>                            (define src (syntax-source stx))
>                            (define filename (and src (assq-ref src 
> 'filename)))
> -                          (and (string? filename)
> -                               (dirname filename)))))
> +                          (define source-file-name
> +                            (fluid-ref compilation-source-file-name))
> +                          (or (and source-file-name
> +                                   (dirname source-file-name))
> +                              (and (string? filename)
> +                                   (dirname filename))))))
>
> Here the code says: the included file must be in (syntax-dirname). 
> It is preferable to have fallbacks, to be backward compatible.

It also falls back to the existing behavior, which is of picking up the
parent directory of the port's file name (that is, the parent directory
of the source file using the 'include' syntax), per the 'or' above.
Isn't that sufficient?

> `syntax-dirname' must be `syntax-dirnames' to return candidate directories 
> sorted list with biggest priority coming first where to find included 
> files.

I'm not sure what algorithm you are suggesting here; but it seems it'd
be something new in Guile.  Since the behavior of 'include' is not
standardized, I'd prefer we change it only if there are interesting use
cases not yet covered (can you think of a scenario?  we could add a test
for it).

> Also, mind the use of the fluid and how it interact with parallel compilation.

Fluids are thread safe, as far as I know, and files are compiled one at
a time anyway, so I don't foresee any problem here, as you also noted in
#scheme on Libera.

-- 
Thanks,
Maxim