unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: [PATCH] `try-module-autoload' and `current-reader'
Date: Sat, 21 Jan 2006 08:46:00 +0000	[thread overview]
Message-ID: <87zmlqezp3.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <8764ogip6k.fsf@laas.fr> ( Ludovic Courtès's message of "Thu, 19 Jan 2006 09:42:43 +0100")

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> 1. Starting a new stack (the start-stack form in R4RS's load).  This
>>    affects backtraces, and it is occasionally useful for a backtrace
>>    to show that module X is being loaded because of code from module
>>    Y.
>>
>> 2. Interpreting a file path beginning with "." as relative to the
>>    current module's load filename.
>
> Change #1 would just make autoload's behavior equivalent to that of
> explicit loading via `use-module'.

No, it would change use-module as well.  Please follow through the
code:

process-use-modules -> resolve-interface -> resolve-module ->
try-load-module -> try-module-autoload

(Arguably try-module-autoload could be better named.)

>  It seems important to me that
> autoload and `use-module' behave identically, i.e., either they both use
> `load-module' and incidentally set up a new stack, or none of them does.

Agreed, but try-module-autoload is used for both, so they will behave
the same as each other whatever we do.  The issue is whether they
behave the same as they do before this patch.

> Also, the `with-fluids' framing is already provided by R4RS `load' and
> consequently by `load-module' so I think we should avoid duplicating it.

This tiny amount of duplication doesn't concern me.

> I don't understand your second point.  In `try-module-autoload', the
> name of the module _to be loaded_ is passed, and its path is inferred
> from that name, not relatively to the current module's path.  Am I
> missing something?

Yes, but it's now covered in another subthread, so I won't repeat here.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2006-01-21  8:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-12  9:06 [PATCH] `try-module-autoload' and `current-reader' Ludovic Courtès
2006-01-19  0:13 ` Neil Jerram
2006-01-19  8:42   ` Ludovic Courtès
2006-01-21  8:46     ` Neil Jerram [this message]
2006-01-23  8:22       ` Ludovic Courtès
2006-01-26 19:25         ` Neil Jerram
2006-01-27  8:41           ` Ludovic Courtès
2006-02-04 15:54             ` Neil Jerram
2006-01-19 21:54   ` Kevin Ryde
2006-01-20  8:31     ` Ludovic Courtès
2006-01-20 20:47       ` Kevin Ryde
2006-01-21  8:29         ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zmlqezp3.fsf@ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).