unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Linus Björnstam" <linus.internet@fastmail.se>
To: holger.peters@posteo.de, guile-user@gnu.org
Subject: Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
Date: Mon, 09 Nov 2020 08:48:34 +0100	[thread overview]
Message-ID: <31461d07-0fe6-43e1-bec7-77bb3399eace@www.fastmail.com> (raw)
In-Reply-To: <c9abcdab250754eef253e20c818c3342@posteo.de>

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').
> 
>



  parent reply	other threads:[~2020-11-09  7:48 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 [this message]
2020-11-09 12:30   ` Felix Thibault

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=31461d07-0fe6-43e1-bec7-77bb3399eace@www.fastmail.com \
    --to=linus.internet@fastmail.se \
    --cc=guile-user@gnu.org \
    --cc=holger.peters@posteo.de \
    /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).