*current-language*

*current-language*

[BT Templeton]

What is `*current-language*' supposed to be used for? I see that it's
set by `(@ (ice-9 eval-string) read-and-eval)' and by `(@ (system base
compile) read-and-compile)', but not by the REPL. So calling
`primitive-load-path' on a Scheme file from a REPL for another language
works as expected, but it fails if called from a context in which
`*current-language*' is bound to a value other than the default. For
example:

    scheme@(guile-user)> ,use (ice-9 eval-string)
    scheme@(guile-user)> (eval-string
    ... "(eval-when-compile
    ...    (funcall (guile-ref (guile) primitive-load-path)
    ...             \"texinfo.scm\"))"
    ... #:lang 'elisp)
    ;;; note: source file /home/bpt/src/guile/module/texinfo.scm
    ;;;       newer than compiled /home/bpt/[...]/texinfo.scm.go
    ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
    ;;;       or pass the --no-auto-compile argument to disable.
    ;;; compiling /home/bpt/src/guile/module/texinfo.scm
    ;;; WARNING: compilation of /home/bpt/src/guile/module/texinfo.scm failed:
    ;;; key wrong-type-arg, throw args [...]
    $1 = nil

(This example currently only works in my copy of Guile, since it
requires an `eval-when-compile' special operator for Elisp.)

I think it might be preferable to require explicit language arguments to
all compilation functions, or to default to Scheme explicitly.

But another solution for this particular bug would be to have
`compile-file' guess the language based on the file extension, and then
`primitive-load-path' and similar functions would work with other
languages too. A simple patch implementing this follows. A complete
solution would be more general than this, of course, and might involve
making load.c aware of the existence of other languages or rewriting
some loading functions in Scheme.

index 1b6e73f..3bc8c23 100644
--- a/module/system/base/compile.scm
+++ b/module/system/base/compile.scm
@@ -120,9 +120,18 @@
          (and (false-if-exception (ensure-writable-dir (dirname f)))
               f))))
 
+(define (guess-file-language file)
+  (cond
+   ((string-suffix? ".scm" file)
+    (lookup-language 'scheme))
+   ((string-suffix? ".el" file)
+    (lookup-language 'elisp))
+   (else
+    (current-language))))
+
 (define* (compile-file file #:key
                        (output-file #f)
-                       (from (current-language))
+                       (from (guess-file-language file))
                        (to 'objcode)
                        (env (default-environment from))
                        (opts '())

Re: *current-language*

[BT Templeton]

BT Templeton <bpt@hcoop.net> writes:

> What is `*current-language*' supposed to be used for? I see that it's
> set by `(@ (ice-9 eval-string) read-and-eval)' and by `(@ (system base
> compile) read-and-compile)', but not by the REPL. So calling
> `primitive-load-path' on a Scheme file from a REPL for another language
> works as expected, but it fails if called from a context in which
> `*current-language*' is bound to a value other than the default. For
> example:
>
>     scheme@(guile-user)> ,use (ice-9 eval-string)
>     scheme@(guile-user)> (eval-string
>     ... "(eval-when-compile
>     ...    (funcall (guile-ref (guile) primitive-load-path)
>     ...             \"texinfo.scm\"))"
>     ... #:lang 'elisp)
>     ;;; note: source file /home/bpt/src/guile/module/texinfo.scm
>     ;;;       newer than compiled /home/bpt/[...]/texinfo.scm.go
>     ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>     ;;;       or pass the --no-auto-compile argument to disable.
>     ;;; compiling /home/bpt/src/guile/module/texinfo.scm
>     ;;; WARNING: compilation of /home/bpt/src/guile/module/texinfo.scm failed:
>     ;;; key wrong-type-arg, throw args [...]
>     $1 = nil
>
> (This example currently only works in my copy of Guile, since it
> requires an `eval-when-compile' special operator for Elisp.)
>
> I think it might be preferable to require explicit language arguments to
> all compilation functions, or to default to Scheme explicitly.
>
> But another solution for this particular bug would be to have
> `compile-file' guess the language based on the file extension, and then
> `primitive-load-path' and similar functions would work with other
> languages too. A simple patch implementing this follows. A complete
> solution would be more general than this, of course, and might involve
> making load.c aware of the existence of other languages or rewriting
> some loading functions in Scheme.

[patch removed]

Any comments on this? I'd like to remove `*current-language*' entirely,
since it doesn't seem terribly useful ATM.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton! http://lernu.net/

Re: *current-language*

[Andy Wingo]

Hello June!

On Sun 12 Jun 2011 03:24, BT Templeton <bpt@hcoop.net> writes:

> What is `*current-language*' supposed to be used for?

It is supposed to be a default language for the compiler and other
things that are interested in languages.

> I see that it's
> set by `(@ (ice-9 eval-string) read-and-eval)' and by `(@ (system base
> compile) read-and-compile)', but not by the REPL.

That's a bug.  Fixed, thanks for the report!

> I think it might be preferable to require explicit language arguments to
> all compilation functions, or to default to Scheme explicitly.

We can change this in 2.2 I think if we want to.  But do we want to?  It
seems like a classic use for dynamic scoping.

> --- a/module/system/base/compile.scm
> +++ b/module/system/base/compile.scm
> @@ -120,9 +120,18 @@
>           (and (false-if-exception (ensure-writable-dir (dirname f)))
>                f))))
>  
> +(define (guess-file-language file)
> +  (cond
> +   ((string-suffix? ".scm" file)
> +    (lookup-language 'scheme))
> +   ((string-suffix? ".el" file)
> +    (lookup-language 'elisp))
> +   (else
> +    (current-language))))
> +
>  (define* (compile-file file #:key
>                         (output-file #f)
> -                       (from (current-language))
> +                       (from (guess-file-language file))

I guess in general I'd prefer something like Racket's #!lang directives,
though I'm not opposed to this approach.  Dunno!

Andy
-- 
http://wingolog.org/

Re: *current-language*

[Noah Lavine]

> I guess in general I'd prefer something like Racket's #!lang directives,
> though I'm not opposed to this approach.  Dunno!

How about using language directives when available, and trying to
guess the language when not?

And about the directives, what should they be? ',language' is what we
used to use at the REPL, and I was about to write an email arguing for
that, until I realized that there is one big advantage to using the
same thing as Racket - we might actually share some languages.

Specifically, if someone had a Scheme file that started with '#!lang
r5rs', it's possible that Guile and Racket could both run that file
without modification. That seems pretty cool. Mixing other languages
could be scary though.

Noah

Re: *current-language*

[Andy Wingo]

On Tue 06 Dec 2011 01:36, Noah Lavine <noah.b.lavine@gmail.com> writes:

>> I guess in general I'd prefer something like Racket's #!lang directives,
>> though I'm not opposed to this approach.  Dunno!
>
> How about using language directives when available, and trying to
> guess the language when not?

I'm fine with this, FWIW.

> And about the directives, what should they be? ',language' is what we
> used to use at the REPL, and I was about to write an email arguing for
> that, until I realized that there is one big advantage to using the
> same thing as Racket - we might actually share some languages.

,language would be pretty cute, but I don't think it would work, as it
reads as (unquote language), and who knows what the binding of `unquote'
would be.

> Specifically, if someone had a Scheme file that started with '#!lang
> r5rs', it's possible that Guile and Racket could both run that file
> without modification. That seems pretty cool.

Yes, I agree, that would be nice.  Perhaps we could even convince other
implementations that this is the right thing.

> Mixing other languages could be scary though.

Indeed :)

Regards,

Andy
-- 
http://wingolog.org/

Re: *current-language*

[Eli Barzilay]

An hour and a half ago, eli@barzilay.org wrote:
> 
> On Tue 06 Dec 2011 01:36, Noah Lavine <noah.b.lavine@gmail.com> writes:
> 
> > And about the directives, what should they be? ',language' is what
> > we used to use at the REPL, and I was about to write an email
> > arguing for that, until I realized that there is one big advantage
> > to using the same thing as Racket - we might actually share some
> > languages.
> 
> ,language would be pretty cute, but I don't think it would work, as
> it reads as (unquote language), and who knows what the binding of
> `unquote' would be.

FWIW, that's true -- and a reason that I plan to change what xrepl
(our command-line thing which I added to Racket recently) so that it
intercepts any line that starts with a "," which means that it would
work no matter what the actual language reader does with that.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: *current-language*

[Andy Wingo]

On Sat 07 Jan 2012 02:56, Eli Barzilay <eli@barzilay.org> writes:

> FWIW, that's true -- and a reason that I plan to change what xrepl
> (our command-line thing which I added to Racket recently) so that it
> intercepts any line that starts with a "," which means that it would
> work no matter what the actual language reader does with that.

Guile's REPL does do that, yes.  I think that Noah's proposal was to pun
the ,language command so that in a file, instead of 

   #!lang r5rs
   (eval '(+ 1 2) (scheme-report-environment 5))

you could have

   ,language r5rs
   (eval '(+ 1 2) (scheme-report-environment 5))

Cute.  I guess it would work if we changed the reader, for the same
reason that it works at the REPL.

Cheers,

Andy
-- 
http://wingolog.org/

Re: *current-language*

[Eli Barzilay]

20 minutes ago, Andy Wingo wrote:
> Guile's REPL does do that, yes.  I think that Noah's proposal was to pun
> the ,language command so that in a file, instead of 
> 
>    #!lang r5rs
>    (eval '(+ 1 2) (scheme-report-environment 5))
> 
> you could have
> 
>    ,language r5rs
>    (eval '(+ 1 2) (scheme-report-environment 5))
> 
> Cute.  I guess it would work if we changed the reader, for the same
> reason that it works at the REPL.

Ah, in that case, the obvious thing to note is that the part of our
reader that deals with reading the language is not using the sexpr
reader.  For example:

  #lang |racket|

doesn't work.

The only small hack is that the default reader is the one that's used
to read the file, and it changes when it runs into a `#lang'.  Because
of this things like

  ;; some comment
  #lang racket
  ...

still work.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: *current-language*

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> Guile's REPL does do that, yes.  I think that Noah's proposal was to pun
> the ,language command so that in a file, instead of 
>
>    #!lang r5rs
>    (eval '(+ 1 2) (scheme-report-environment 5))
>
> you could have
>
>    ,language r5rs
>    (eval '(+ 1 2) (scheme-report-environment 5))
>
> Cute.  I guess it would work if we changed the reader, for the same
> reason that it works at the REPL.

Then I think (1) the hash form is preferable over the comma form for the
reason you gave, and (2) we should have an “meta-reader” stacked on top
of ‘read’ that takes precedence over ‘read’ when a hash form is seen, as
Eli noted.

Thanks,
Ludo’.