unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Felix Thibault <fthibault1969@gmail.com>
To: "Linus Björnstam" <linus.internet@fastmail.se>
Cc: guile-user@gnu.org
Subject: Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
Date: Mon, 9 Nov 2020 07:30:50 -0500	[thread overview]
Message-ID: <CAGyWG1vsixXf=gBNEcRizmtK+d3iJhGcQu_9ruPkHXxnLj4LSA@mail.gmail.com> (raw)
In-Reply-To: <31461d07-0fe6-43e1-bec7-77bb3399eace@www.fastmail.com>

Is this supposed to work for r7rs ? I get:

scheme@(guile-user)> (import (scheme base))
scheme@(guile-user)> ,m (scheme base)
scheme@(scheme base)> <tab><tab>
Display all 2081 possibilities? (y or n)

On Mon, Nov 9, 2020 at 2:49 AM Linus Björnstam
<linus.internet@fastmail.se> wrote:
>
> The guile module used at the repl is indeed the guile-user module. I would look at how the elisp language is implemented. It switches the repl to the elisp module where no guile bindings are present.
>
> This is the same as doing ,m (module name) at the repl.
>
> --
>   Linus Björnstam
>
> On Sat, 7 Nov 2020, at 12:54, holger.peters@posteo.de wrote:
> > First of all let me begin by saying I am not quite sure whether this
> > is a `works as intended' or whether this constitutes a bug, I tend to
> > think its the latter, but wouldn't right away rule out the former, as
> > if it were to be considered a `bug' it probably would have surfaced
> > long before, but I disgress. let's get to my problem.
> >
> > * Problem statement
> >
> > I implemented my own language using the guile compile-tower. For the
> > sake of you not having to read through all of my code I provide a
> > snippet for reproducing the test case. But first, let's start by looking
> > at
> > the fact what I describe is present in the ecmascript iplementation
> > bundled with guile.
> >
> > If you run Guile's ECMAscript REPL using `guile
> > --language=ecmascript`, something like this works:
> >
> >
> >    write("test");
> >    display(3);
> >    newline();
> >
> >
> > Haven't looked into the ECMAscript standard but I don't think Scheme's
> > `write', `display' and `newline' are whats being demonstrated there.
> >
> > * Reproducing Example
> >
> > This creates a lang `fakescheme', that is actually identical to
> > `(language scheme spec)' for all items except, that there are far
> > fewer builtins (just `print' instead of `write').
> >
> >
> >    (define-module (language fakescheme spec)
> >      #:use-module (system base compile)
> >      #:use-module (system base language)
> >      #:use-module (language scheme compile-tree-il)
> >      #:use-module (language scheme decompile-tree-il)
> >      #:export (fakescheme))
> >
> >    (define (make-fresh-module)
> >      (let ((m (make-module)))
> >        (module-define! m 'current-reader (make-fluid))
> >        (module-set! m 'format simple-format)
> >        (module-define! m 'newline newline)
> >        (module-define! m 'print write)
> >        (module-define! m 'current-module current-module)
> >        m))
> >
> >    (define-language fakescheme
> >      #:title  "fakescheme"
> >      #:reader      (lambda (port env)
> >                      ((or (and=> (and=> (module-variable env
> > 'current-reader)
> >                                         variable-ref)
> >                                  fluid-ref)
> >                           read)
> >                       port))
> >      #:compilers   `((tree-il . ,compile-tree-il))
> >      #:decompilers `((tree-il . ,decompile-tree-il))
> >      #:evaluator      (lambda (x module) (primitive-eval x))
> >      #:printer        write
> >      #:make-default-environment make-fresh-module)
> >
> >
> > The general observation is: If I run a some script using this language
> > using `guile --language=fakescheme -s myscript.scm', it works as
> > expected, i.e. the following works
> >
> >
> >    (print "foo") ; works in script
> >    (write "foo") ; fails in script
> >
> > However, if I run the same code from within a repl via `guile
> > --language=fakescheme',
> >
> >
> >    (print "foo") ; fails in repl
> >    (write "foo") ; works in repl
> >
> >
> > * Whats going on here?
> >
> > It seems that in the REPL, Guile injects the `guile-user' module
> > directly whereas when called with `-s` and a script guile uses the
> > module provided with `#:make-default-environment'.  That seems strange
> > because overall I would expect REPL environments and non-REPL
> > environments to be roughly the same.
> >
> > So, is this a bug? Works as intended? And if this is intended in this
> > way is there a workaround to make REPL and script exeution to behave
> > the same (preferably without namespace `pollution').
> >
> >
>



      reply	other threads:[~2020-11-09 12:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 11:54 Namespace confusion/pollution in languages implemented via Guile's compile-tower holger.peters
2020-11-07 20:59 ` Dr. Arne Babenhauserheide
2020-11-26 16:27   ` Holger Peters
2020-11-26 18:15     ` Dr. Arne Babenhauserheide
2020-11-09  7:48 ` Linus Björnstam
2020-11-09 12:30   ` Felix Thibault [this message]

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='CAGyWG1vsixXf=gBNEcRizmtK+d3iJhGcQu_9ruPkHXxnLj4LSA@mail.gmail.com' \
    --to=fthibault1969@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=linus.internet@fastmail.se \
    /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).