unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Namespace confusion/pollution in languages implemented via Guile's compile-tower
@ 2020-11-07 11:54 holger.peters
  2020-11-07 20:59 ` Dr. Arne Babenhauserheide
  2020-11-09  7:48 ` Linus Björnstam
  0 siblings, 2 replies; 6+ messages in thread
From: holger.peters @ 2020-11-07 11:54 UTC (permalink / raw)
  To: guile-user

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
  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-09  7:48 ` Linus Björnstam
  1 sibling, 1 reply; 6+ messages in thread
From: Dr. Arne Babenhauserheide @ 2020-11-07 20:59 UTC (permalink / raw)
  To: holger.peters; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]


holger.peters@posteo.de writes:
> 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').

This is as intended.

I don’t know a way to change that, though.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
  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-09  7:48 ` Linus Björnstam
  2020-11-09 12:30   ` Felix Thibault
  1 sibling, 1 reply; 6+ messages in thread
From: Linus Björnstam @ 2020-11-09  7:48 UTC (permalink / raw)
  To: holger.peters, guile-user

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
  2020-11-09  7:48 ` Linus Björnstam
@ 2020-11-09 12:30   ` Felix Thibault
  0 siblings, 0 replies; 6+ messages in thread
From: Felix Thibault @ 2020-11-09 12:30 UTC (permalink / raw)
  To: Linus Björnstam; +Cc: guile-user

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
  2020-11-07 20:59 ` Dr. Arne Babenhauserheide
@ 2020-11-26 16:27   ` Holger Peters
  2020-11-26 18:15     ` Dr. Arne Babenhauserheide
  0 siblings, 1 reply; 6+ messages in thread
From: Holger Peters @ 2020-11-26 16:27 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: guile-user

Hi,

> This is as intended.

Do you have a rationale for this intention?  I have been thinking
about this for weeks now, and I still cannot come up with a scenario
when I would like this behaviour.  That is if I'd load a lua-on-guile
REPL, I wouldn't like to have Lua symbols missing and Scheme symbols
present.

I had a look at the guile codebase proposed a patch that would unify
the behaviour of REPL and script execution:

https://lists.gnu.org/archive/html/guile-devel/2020-11/msg00004.html

---
Holger Peters <holger.peters@posteo.de>

Am 07.11.2020 21:59 schrieb Dr. Arne Babenhauserheide:
> holger.peters@posteo.de writes:
>> 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').
> 

> 
> Best wishes,
> Arne



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Namespace confusion/pollution in languages implemented via Guile's compile-tower
  2020-11-26 16:27   ` Holger Peters
@ 2020-11-26 18:15     ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 6+ messages in thread
From: Dr. Arne Babenhauserheide @ 2020-11-26 18:15 UTC (permalink / raw)
  To: Holger Peters; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]


Holger Peters <holger.peters@posteo.de> writes:

> Hi,
>
>> This is as intended.
>
> Do you have a rationale for this intention?  I have been thinking
> about this for weeks now, and I still cannot come up with a scenario
> when I would like this behaviour.  That is if I'd load a lua-on-guile
> REPL, I wouldn't like to have Lua symbols missing and Scheme symbols
> present.

The intention is that when in the REPL you have some extra-tools that a
typical script does not need.

Looking at boot-9, guile-user mostly adds compile and compile-file.
You’ll want to be able to compile stuff in the REPL, but scripts should
not need to worry about that (because they get auto-compiled anyway).

The intention is not to provide Scheme-tools to Lua, but to provide
extended Scheme-tools when you’re in the REPL.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-11-26 18:15 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

unofficial mirror of guile-user@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-user/0 guile-user/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-user guile-user/ https://yhetil.org/guile-user \
		guile-user@gnu.org
	public-inbox-index guile-user

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.user
	nntp://news.gmane.io/gmane.lisp.guile.user


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git