unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: rm@fabula.de
Cc: rm@fabula.de, guile-devel@gnu.org
Subject: Re: Bug in eval-string?
Date: Fri, 9 Aug 2002 11:35:31 +0200	[thread overview]
Message-ID: <20020809093531.GA25104@www> (raw)
In-Reply-To: <m38z3hxcps.fsf@laruns.ossau.uklinux.net>

First of all, thank's for all these replies. I think my problem
stems partly from a missunderstanding of the documentation and from
a missunderstanding of the implementation (which admittedly i could
have examined myself. Sorry).

On Thu, Aug 08, 2002 at 10:27:59PM +0100, Neil Jerram wrote:
> [...]
>     rm> (let ((interaction-environment (lambda () boxx)))
>     rm>   (format #t "Meaning of life in a box is: ~A\n"
>     rm>           (eval-string "meaning-of-life")))
> 
> This isn't Elisp!  The interaction-environment variable introduced by
> your let has nothing to do with the builtin interaction-environment,
> to which the documentation refers.

I think i (wrongly) assumend that eval-string is "syntactic sugar" 
for eval. So my reading of the documentation made me belive that 
eval-string would behave like the following (pseudo)code:

(use-modules (ice-9 syncase))

(define-syntax my-eval-string
  (syntax-rules ()
                ((my-eval-string string)
                 (eval
                  (with-input-from-string string (lambda () (read)))
                  (interaction-environment)))))

maybe the documentation should be modified:

	    "Evaluation takes place in the environment returned by the\n"
	    "procedure @code{interaction-environment}.")

to 
	    "Evaluation takes place in the same environment as \n"
            "returned by the procedure @code{interaction-environment}.")

> BTW, note that the builtin interaction-environment is 
(at least at the
> moment) identical to current-module.

Ah, that information would have helped. 

> guile> (define boxx (make-module))
> guile> (set-module-kind! boxx 'directory)
> directory
> guile> (module-define! boxx 'meaning-of-life 42)
> #f
> guile> (save-module-excursion
>          (lambda ()
>            (set-current-module boxx)
>            (eval-string "meaning-of-life")))
> 42
> guile> 

Where would i find documentation on save-module-excursion?

And now for the RFC part:

Wouldn't the 'eval*' interface be clearer and more orthogonal if
eval-string would have a second, optional parameter specifying the
environment/module in which evaluation should take place. If no module
is specified the environment defaults to interaction-environment
(this guarantees backward compatibility). The modifications to 
the code are minimal, see below.

 Ralf 

-- File: strports.c --------x--------------------------------------------

SCM_DEFINE (scm_eval_string, "eval-string", 1, 1, 0,
            (SCM string, SCM environ),
            "Evaluate @var{string} as the text representation of a Scheme\n"
            "form or forms, and return whatever value they produce.\n"
            "Evaluation takes place in the environment provided in the \n"
            "second, optional parameter @var{environ}. If none is given \n"
            "evalution will happen in the environment returned by the \n"
            "procedure @code{interaction-environment}.")
#define FUNC_NAME s_scm_eval_string
{

  SCM port = scm_mkstrport (SCM_INUM0, string, SCM_OPN | SCM_RDNG,
                            "eval-string");

  if (SCM_UNBNDP (environ))
    environ = scm_interaction_environment ();
  return scm_c_call_with_current_module (environ,
                                         inner_eval_string,
                                         (void *)port);
}
#undef FUNC_NAME



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


  reply	other threads:[~2002-08-09  9:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-08 12:56 Bug in eval-string? rm
2002-08-08 21:03 ` Marius Vollmer
2002-08-09  9:06   ` Matthias Koeppe
2002-08-09  9:19     ` Marius Vollmer
2002-08-09 10:24       ` Matthias Koeppe
2002-08-10 14:18         ` Marius Vollmer
2002-08-12 18:20           ` Matthias Koeppe
2002-08-13  0:39             ` Marius Vollmer
2002-08-14 19:07               ` Marius Vollmer
2002-08-17 11:09               ` Neil Jerram
2002-08-20 11:39               ` Matthias Koeppe
2002-08-21 19:26                 ` Marius Vollmer
2002-08-27 14:18                   ` Emacs variables (was: Bug in eval-string?) Matthias Koeppe
2002-08-31 13:51                     ` Marius Vollmer
2002-08-08 21:27 ` Bug in eval-string? Neil Jerram
2002-08-09  9:35   ` rm [this message]
2002-08-10 14:43     ` Marius Vollmer
2002-08-12 10:49       ` rm
2002-08-13 20:55       ` Marius Vollmer

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=20020809093531.GA25104@www \
    --to=rm@fabula.de \
    --cc=guile-devel@gnu.org \
    /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).