Anniversary hack: Zile editor with Guile support

Anniversary hack: Zile editor with Guile support

[Mike Gran]

Hello-

In response to Ludo's request for a Guile-2.0 anniversary hack, I'll
start by offering a release of a hack I made.  But this isn't my
official hack: it is just a building block.

Zile-on-Guile is a version of GNU Zile that uses GNU Guile as an
extension language.  The original GNU Zile was a small editor in the
style of GNU Emacs and it has its own tiny embedded Lisp interpreter.
I've replaced that interpreter with Guile.

You can find the download at

https://github.com/downloads/spk121/zile/zile-on-guile-0.0.tar.gz

This is a 0.0 release, so if it even builds on anyone else's machine,
I'd be totally surprised.

You can find the Git repository at 

https://github.com/spk121/zile

The Guile extension can be accessed this way.

-- Pressing Alt+C brings up a REPL.  You can do all your standard REPL
   things.

-- In the REPL, one can create and bind new commands.  Define a
   procedure of zero arguments, export it, and then bind it to a key
   using 'set-key'.

   For example:

     (define (blammo)
       (insert "blammo"))
     (export blammo)
     (set-key "\\F9" 'blammo)

   This creates a function that inserts the world "blammo" at the mark
   whenever <F9> is pressed.

-- And, if really you wanted to, you could edit your current buffer in
   the REPL

   For example:

      (insert "here is some text")
      (forward-char)

   But that would just be silly.

Thanks,

Mike Gran      

Re: Anniversary hack: Zile editor with Guile support

[Bernardo Ezequiel Contreras]

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

Do you plan to write everything on guile? is it possible?

On Sun, Feb 12, 2012 at 9:51 PM, Mike Gran <spk121@yahoo.com> wrote:

>
>
> Hello-
>
> In response to Ludo's request for a Guile-2.0 anniversary hack, I'll
> start by offering a release of a hack I made.  But this isn't my
> official hack: it is just a building block.
>
> Zile-on-Guile is a version of GNU Zile that uses GNU Guile as an
> extension language.  The original GNU Zile was a small editor in the
> style of GNU Emacs and it has its own tiny embedded Lisp interpreter.
> I've replaced that interpreter with Guile.
>
> You can find the download at
>
> https://github.com/downloads/spk121/zile/zile-on-guile-0.0.tar.gz
>
> This is a 0.0 release, so if it even builds on anyone else's machine,
> I'd be totally surprised.
>
> You can find the Git repository at
>
> https://github.com/spk121/zile
>
> The Guile extension can be accessed this way.
>
> -- Pressing Alt+C brings up a REPL.  You can do all your standard REPL
>    things.
>
> -- In the REPL, one can create and bind new commands.  Define a
>    procedure of zero arguments, export it, and then bind it to a key
>    using 'set-key'.
>
>    For example:
>
>      (define (blammo)
>        (insert "blammo"))
>      (export blammo)
>      (set-key "\\F9" 'blammo)
>
>    This creates a function that inserts the world "blammo" at the mark
>    whenever <F9> is pressed.
>
> -- And, if really you wanted to, you could edit your current buffer in
>    the REPL
>
>    For example:
>
>       (insert "here is some text")
>       (forward-char)
>
>    But that would just be silly.
>
> Thanks,
>
> Mike Gran
>
>

[-- Attachment #2: Type: text/html, Size: 2302 bytes --]

Re: Anniversary hack: Zile editor with Guile support

[Ludovic Courtès]

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

Hi Mike!

Mike Gran <spk121@yahoo.com> skribis:

> In response to Ludo's request for a Guile-2.0 anniversary hack, I'll
> start by offering a release of a hack I made.  But this isn't my
> official hack: it is just a building block.

Excellent.  Looking forward to the actual hack.  :-)

> You can find the download at
>
> https://github.com/downloads/spk121/zile/zile-on-guile-0.0.tar.gz
>
> This is a 0.0 release, so if it even builds on anyone else's machine,
> I'd be totally surprised.

It builds!  :-)

There’s a small issue: for me, it would segfault; using NULL instead of
0 as the sentinel in scm_c_export calls solves the problem for me (patch
below.)

(I made the change in basic.c:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 343 bytes --]

--- /home/ludo/src/zile/t/zile-on-guile-0.0/src/basic.c~	2012-02-13 00:26:24.000000000 +0100
+++ /home/ludo/src/zile/t/zile-on-guile-0.0/src/basic.c	2012-02-13 15:15:37.000000000 +0100
@@ -264,5 +264,5 @@ init_guile_basic_procedures (void)
 		"forward-char",
 		"backward-char",
 		"scroll-down",
-		"scroll-up", 0);
+		"scroll-up", NULL);
 }

[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


... then looked at the difference in the generated assembly:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: text/x-patch, Size: 558 bytes --]

--- /home/ludo/src/zile/t/zile-on-guile-0.0/good.S	2012-02-13 15:12:29.000000000 +0100
+++ /home/ludo/src/zile/t/zile-on-guile-0.0/bad.S	2012-02-13 15:12:40.000000000 +0100
@@ -6,8 +6,8 @@
    be 00 00 00 00          mov    $0x0,%esi
    bf 00 00 00 00          mov    $0x0,%edi
    31 c0                   xor    %eax,%eax
-   48 c7 44 24 30 00 00    movq   $0x0,0x30(%rsp)
-   00 00 
+   c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
+   00 
    48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
    00 00 
    48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)

[-- Attachment #5: Type: text/plain, Size: 605 bytes --]


It’s subtle, but apparently important.)

> -- Pressing Alt+C brings up a REPL.  You can do all your standard REPL
>    things.
>
> -- In the REPL, one can create and bind new commands.  Define a
>    procedure of zero arguments, export it, and then bind it to a key
>    using 'set-key'.
>
>    For example:
>
>      (define (blammo)
>        (insert "blammo"))
>      (export blammo)
>      (set-key "\\F9" 'blammo)
>
>    This creates a function that inserts the world "blammo" at the mark
>    whenever <F9> is pressed.

Works for me, neaaat!  :-)

Thanks,
Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: the patch --]
[-- Type: text/x-patch, Size: 5104 bytes --]

From 027fd77b3caa63137ee01a40cf27ef8911cbdded Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Mon, 13 Feb 2012 15:27:38 +0100
Subject: [PATCH] Use NULL as the sentinel of `scm_c_export'.

* src/basic.c, src/bind.c, src/buffer.c, src/eval.c, src/file.c,
  src/funcs.c, src/help.c, src/killring.c, src/line.c, src/lisp.c,
  src/macro.c, src/redisplay.c, src/registers.c, src/search.c,
  src/undo.c, src/variables.c: Use NULL as the sentinel of
  `scm_c_export'.
---
 src/basic.c     |    2 +-
 src/bind.c      |    2 +-
 src/buffer.c    |    2 +-
 src/eval.c      |    2 +-
 src/file.c      |    2 +-
 src/funcs.c     |    2 +-
 src/help.c      |    2 +-
 src/killring.c  |    2 +-
 src/line.c      |    2 +-
 src/lisp.c      |    2 +-
 src/macro.c     |    2 +-
 src/redisplay.c |    2 +-
 src/registers.c |    2 +-
 src/search.c    |    2 +-
 src/undo.c      |    2 +-
 src/variables.c |    2 +-
 16 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/basic.c b/src/basic.c
index 631de68..49d4f6c 100644
--- a/src/basic.c
+++ b/src/basic.c
@@ -264,5 +264,5 @@ init_guile_basic_procedures (void)
 		"forward-char",
 		"backward-char",
 		"scroll-down",
-		"scroll-up", 0);
+		"scroll-up", NULL);
 }
diff --git a/src/bind.c b/src/bind.c
index effd101..820b7c0 100644
--- a/src/bind.c
+++ b/src/bind.c
@@ -728,5 +728,5 @@ init_guile_bind_procedures ()
 		"set-key",
 		"describe-bindings",
 		"key-map",
-		0);
+		NULL);
 }
diff --git a/src/buffer.c b/src/buffer.c
index d25fbbc..1ff127f 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -818,5 +818,5 @@ init_guile_buffer_procedures (void)
 {
 
 #include "buffer.x"
-  scm_c_export ("kill-buffer", 0);
+  scm_c_export ("kill-buffer", NULL);
 }
diff --git a/src/eval.c b/src/eval.c
index 8a8ac5a..84521c7 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -202,5 +202,5 @@ void
 init_guile_eval_procedures (void)
 {
 #include "eval.x"
-  scm_c_export ("execute-extended-command", 0);
+  scm_c_export ("execute-extended-command", NULL);
 }
diff --git a/src/file.c b/src/file.c
index 3e9b7a8..903710c 100644
--- a/src/file.c
+++ b/src/file.c
@@ -829,5 +829,5 @@ init_guile_file_procedures (void)
 		"save-some-buffers",
 		"save-buffers-kill-emacs",
 		"cd",
-		0);		
+		NULL);
 }
diff --git a/src/funcs.c b/src/funcs.c
index 0c9407e..dfb6c63 100644
--- a/src/funcs.c
+++ b/src/funcs.c
@@ -1199,5 +1199,5 @@ init_guile_funcs_procedures (void)
 		"shell-command-on-region",
 		"delete-region",
 		"delete-blank-lines",
-		0);
+		NULL);
 }
diff --git a/src/help.c b/src/help.c
index 24e70c4..2daf2f1 100644
--- a/src/help.c
+++ b/src/help.c
@@ -179,5 +179,5 @@ init_guile_help_procedures (void)
   scm_c_export ("describe-function",
 		"describe-variable",
 		"describe-key",
-		0);
+		NULL);
 }
diff --git a/src/killring.c b/src/killring.c
index 23d2f62..07d6796 100644
--- a/src/killring.c
+++ b/src/killring.c
@@ -271,5 +271,5 @@ init_guile_killring_procedures (void)
 		"backward-kill-word",
 		"kill-sexp",
 		"yank",
-		0);
+		NULL);
 }
diff --git a/src/line.c b/src/line.c
index 2500c80..aad5d12 100644
--- a/src/line.c
+++ b/src/line.c
@@ -415,6 +415,6 @@ init_guile_line_procedures (void)
 		"indent-relative",
 		"indent-for-tab-command",
 		"newline-and-indent",
-		0);
+		NULL);
 }
 
diff --git a/src/lisp.c b/src/lisp.c
index b20d693..3ca6e7b 100644
--- a/src/lisp.c
+++ b/src/lisp.c
@@ -190,5 +190,5 @@ init_guile_lisp_procedures (void)
 {
 #include "lisp.x"
   scm_c_export ("console",
-		0);
+		NULL);
 }
diff --git a/src/macro.c b/src/macro.c
index b0e42b3..5627f0e 100644
--- a/src/macro.c
+++ b/src/macro.c
@@ -198,5 +198,5 @@ init_guile_macro_procedures (void)
 		"call-last-kbd-macro",
 		"end-kbd-macro",
 		"execute-kbd-macro",
-		0);
+		NULL);
 }
diff --git a/src/redisplay.c b/src/redisplay.c
index df02642..1b43a9f 100644
--- a/src/redisplay.c
+++ b/src/redisplay.c
@@ -130,5 +130,5 @@ init_guile_redisplay_procedures (void)
 {
 #include "redisplay.x"
   scm_c_export ("recenter", 
-		0);
+		NULL);
 }
diff --git a/src/registers.c b/src/registers.c
index 990e2aa..70d3056 100644
--- a/src/registers.c
+++ b/src/registers.c
@@ -152,5 +152,5 @@ init_guile_registers_procedures (void)
   scm_c_export ("copy-to-register",
 		"insert-register",
 		"list-registers",
-		0);
+		NULL);
 }
diff --git a/src/search.c b/src/search.c
index 3c37242..410d7ba 100644
--- a/src/search.c
+++ b/src/search.c
@@ -462,5 +462,5 @@ init_guile_search_procedures (void)
 		"isearch-forward-regexp",
 		"isearch-backward-regexp",
 		"query-replace",
-		0);
+		NULL);
 }
diff --git a/src/undo.c b/src/undo.c
index 82a9d65..91bd77c 100644
--- a/src/undo.c
+++ b/src/undo.c
@@ -159,5 +159,5 @@ init_guile_undo_procedures (void)
 {
 #include "undo.x"
   scm_c_export ("undo",
-		0);
+		NULL);
 }
diff --git a/src/variables.c b/src/variables.c
index 799697e..add0c4c 100644
--- a/src/variables.c
+++ b/src/variables.c
@@ -324,6 +324,6 @@ init_guile_variables_procedures (void)
 {
 #include "variables.x"
   scm_c_export ("set-variable",
-		0);
+		NULL);
   scm_c_define ("setq", scm_c_lookup ("define"));
 }
-- 
1.7.6

Re: Anniversary hack: Zile editor with Guile support

[Mike Gran]

> From: Bernardo Ezequiel Contreras <vonbecmann@gmail.com>
>  
>
>Do you plan to write everything on guile? is it possible? 

I don't plan on writing everything in Guile, but, it is possible.
 
Zile only depends on the Ncurses libraries.  There are Guile
bindings for Ncurses. So I have everything I would need.
 
I have written programs like Zile completely in Guile
Scheme a couple of times.  I have a couple of prototypes.
But there are a couple of challenges.
 
- Ncurses programs are annoying to debug, since they try to
  write to the screen that you are using.  There are ways to
  work around that, though.
 
- The Guile debugger is okay, but, it isn't great.  Sometimes,
  the debugger can't tell you where the error is in your source
  code.  So, it can be hard to use on programs with many files.
 
 
Regards,
 
Mike

Re: Anniversary hack: Zile editor with Guile support

[Ludovic Courtès]

Hi Mike,

Mike Gran <spk121@yahoo.com> skribis:

> - The Guile debugger is okay, but, it isn't great.  Sometimes,
>   the debugger can't tell you where the error is in your source
>   code.

In that case that’s a bug worth reporting.  :-)

Ludo’.

Re: Anniversary hack: Zile editor with Guile support

[Mike Gran]

> From: Ludovic Courtès <ludo@gnu.org>

> There’s a small issue: for me, it would segfault; using NULL instead of
> 0 as the sentinel in scm_c_export calls solves the problem for me (patch
> below.)

Thanks for checking it out.  I'm guessing why it segfaults for you and
not for me is 32-bit vs 64-bit.

-Mike

Re: Anniversary hack: Zile editor with Guile support

[Gary V. Vaughan]

Hi Mike,

I'm not subscribed to guile-user, so (if guile-user accepts non-subscriber
posts and this message arrives there at all!) please Cc: me on any replies.

On 20 Mar 2013, at 18:47, Gary V. Vaughan <gary@vaughan.pe> wrote:
> On 20 Mar 2013, at 18:03, Reuben Thomas <rrt@sc3d.org> wrote:
> 
>> It's worth having a note of this:
>> 
>> http://lists.gnu.org/archive/html/guile-user/2012-02/msg00033.html
>> 
>> In particular, Gary, maybe you'd like to mention the Zmacs work? Is it
>> worth considering whether it could be possible to build Zile with
>> either Zmacs or Guile?

I wonder whether you're aware of the recent change of tack in the Zile
project?  For the moment all the exciting work is happening on the lua
branch:

  http://git.savannah.gnu.org/cgit/zile.git/log/?h=lua

While not quite polished enough for a release, Reuben translated the entire
code base to Lua, over libposix/lcurses, some time ago, making it massively
more hackable than the old C code base.

Beyond that, I have been working on changing the emphasis of Zile from being
another emacs clone into a text-editor building kit, to the point where I'm
in the process of changing the acronym to 'Zile Implements Lua Editors' in
reference to the toolkit, where the Emacs like editor will be renamed as
Zmacs.  In the process of reorganising all the code, it turns out that the
Lua implementation of the Zmacs (formerly Zile) elisp parser is amazingly
close to being a Lisp-to-Lua compiler.

At the moment, I've spun that out into a separate project, which I'll readopt
back into the new Zmacs tree as zlc (Zmacs Lisp Compiler) so that Zmacs will
then be able to run elisp sources byte-compiled into Lua byte-codes for an
enormous speed bump.

This is where I think it gets interesting for you, in that zlc, being
implemented in Lua too, is also eminently hackable, to the point where I
don't think it would be very much work at all to tweak a version that compiles
a Guile inspired scheme to Lua bytecodes (as opposed to Elisp -> Lua).

Another goal of the reshuffle with Zile (the editor building toolkit) is to
make it easy to build experimental editors.  Reuben has a very cut down fork
of Lua Zile that we plan to re-adopt back into the Zile distribution, and I
have a TextMate inspired syntax highlighting subproject, both of which will
shortly live alongside Zmacs with equal billing as examples of the kinds of
things Zile can help with.  I wonder whether you'd be interested in contributing
to a Guile Emacs inspired Zuile™ flavour?

After all, chasing Elisp compatibility could easily turn into a black-hole,
and seems unlikely to ever reach a point where one could run any significant
Elisp packages on Zmacs (hence the re-purposing to becoming an editor building
toolkit), and so providing the infrastructure to get a Guile Emacs together
seems like a much better use of limited hacking resources to me... WDYT?

With my limited flirting with Guile in years past, I'm pretty sure the Lua-
on-Guile work stalled or failed a long time ago.  If not, or if it can be
resurrected, that may be another interesting means to leveraging all the
recent work on Lua Zile towards making a Guile Emacs by a different route?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: Anniversary hack: Zile editor with Guile support

[Mike Gran]

Hi Gary (and Reuben)

> From: Gary V. Vaughan <gary@gnu.org>

>I wonder whether you're aware of the recent change of tack in the Zile
>project?  For the moment all the exciting work is happening on the lua
>branch:


I've been following it from afar. Good stuff, but I haven't done much
other than run it once or twice.

>This is where I think it gets interesting for you, in that zlc, being

>implemented in Lua too, is also eminently hackable, to the point where I
>don't think it would be very much work at all to tweak a version that compiles
>a Guile inspired scheme to Lua bytecodes (as opposed to Elisp -> Lua).
>
>Another goal of the reshuffle with Zile (the editor building toolkit) is to
>make it easy to build experimental editors.  Reuben has a very cut down fork
>of Lua Zile that we plan to re-adopt back into the Zile distribution, and I
>have a TextMate inspired syntax highlighting subproject, both of which will
>shortly live alongside Zmacs with equal billing as examples of the kinds of
>things Zile can help with.  I wonder whether you'd be interested in contributing
>to a Guile Emacs inspired Zuile™ flavour?


I could see how that could be fun, mapping Guile VM bytecodes to the Lua
bytecodes.  I wonder how compatible they might be?


While I agree that might be a great job for somebody, I won't be able help
out.  I just can't condone the creation of yet another Scheme, even though
your reasons for creating one are exciting.
I guess, because Lua is such a great extension language, I don't see the
value added in writing Zile extensions in anything other than Lua.

Good Luck,

Mike Gran

Re: Anniversary hack: Zile editor with Guile support

[Gary V. Vaughan]

On 22 Mar 2013, at 09:43, Mike Gran <spk121@yahoo.com> wrote:
> Hi Gary (and Reuben)

Hi Mike,

>> From: Gary V. Vaughan <gary@gnu.org>
> 
>> I wonder whether you're aware of the recent change of tack in the Zile
>> project?  For the moment all the exciting work is happening on the lua
>> branch:
> 
> I've been following it from afar. Good stuff, but I haven't done much
> other than run it once or twice.

Cool!  It's become a *lot* easier to get running in recent months, now
that all the dependencies are available as luarocks, so if you battled
through installing by hand before that... I'd be interested to hear if
you have any problems getting up and running with the recent revisions
from git.

>> This is where I think it gets interesting for you, in that zlc, being
>> implemented in Lua too, is also eminently hackable, to the point where I
>> don't think it would be very much work at all to tweak a version that compiles
>> a Guile inspired scheme to Lua bytecodes (as opposed to Elisp -> Lua).
> 
> I could see how that could be fun, mapping Guile VM bytecodes to the Lua
> bytecodes.  I wonder how compatible they might be?

Rather than byte-code to byte-code translation, I was rather thinking of either:

  1. Tweaking zlc to be capable of compiling guile scheme directly to Lua (and
     then easily from there to Lua bytecodes); or
  2. Running Zile with the Guile implementation of Lua, and getting Guile as
     an extension language for free.

The first, I can do, though it's a long time since I paid attention to Guile,
so I'd need guidance and/or test-cases from someone familiar with it to make
sure my implementation would be compatible with canonical Guile Scheme.

The second, I was asking about because I was initially drawn to Guile during
the era when it was being touted as a good compiler target platform to become
a runtime for code written in any language and then translated to Guile Scheme
before execution.  But, my impression is that this work stalled and/or failed?

> =your reasons for creating one are exciting.
> I guess, because Lua is such a great extension language, I don't see the
> value added in writing Zile extensions in anything other than Lua.

It depends on how interesting a fully baked Guile Emacs is to you... Although
you obviously have one already with your Anniversary Hack, I think Guile Scheme
in Lua Zile (by one of the methods above) is a much easier way to achieve a
useful editor for the long-term.  And I'm certainly of a mind that Guile
Emacs is much less of a development black hole than trying to chase ELisp's
tail in Zmacs.

Actually, it just occurred to me that there might be another route than the
two above:

  3. Translate your C Zile patches for Guile integration into Lua patches,
     à la Reubens initial port of C Zile to Lua - although, it sounds like
     a bit of a Frankensteins monster already ;)

In any case, I'll be very happy for you to keep a weather eye future progress,
and raise flags for me if you see any pot holes in the road ahead.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: Anniversary hack: Zile editor with Guile support

[Ludovic Courtès]

Hi Gary,

"Gary V. Vaughan" <gary@gnu.org> skribis:

> With my limited flirting with Guile in years past, I'm pretty sure the Lua-
> on-Guile work stalled or failed a long time ago.  If not, or if it can be
> resurrected, that may be another interesting means to leveraging all the
> recent work on Lua Zile towards making a Guile Emacs by a different route?

I fail to see how Lua Zile could have anything to do with Guile Emacs.

I’m disappointed that Mike’s Zile-on-Guile has been ignored in favor of
the divisive choice.

Ludo’.

Re: Anniversary hack: Zile editor with Guile support

[Nala Ginrut]

On Fri, 2013-03-22 at 12:05 +0100, Ludovic Courtès wrote:
> Hi Gary,
> 
> "Gary V. Vaughan" <gary@gnu.org> skribis:
> 
> > With my limited flirting with Guile in years past, I'm pretty sure the Lua-
> > on-Guile work stalled or failed a long time ago.  If not, or if it can be
> > resurrected, that may be another interesting means to leveraging all the
> > recent work on Lua Zile towards making a Guile Emacs by a different route?
> 
> I fail to see how Lua Zile could have anything to do with Guile Emacs.
> 

I don't know if lua-zile is better than guile-emacs, but I'm using
current unstable guile-emacs smoothly and all the plugins works for me,
though crash sometime.

> I’m disappointed that Mike’s Zile-on-Guile has been ignored in favor of
> the divisive choice.
> 

I think I'm the only user of zile-on-guile, anyway, I don't care about
the decision of upstream. 

> Ludo’.
> 
> 

Re: Anniversary hack: Zile editor with Guile support

[Ian Price]

"Gary V. Vaughan" <gary@gnu.org> writes:

> Rather than byte-code to byte-code translation, I was rather thinking of either:
>
>   1. Tweaking zlc to be capable of compiling guile scheme directly to Lua (and
>      then easily from there to Lua bytecodes); or
>   2. Running Zile with the Guile implementation of Lua, and getting Guile as
>      an extension language for free.
>
> The first, I can do, though it's a long time since I paid attention to Guile,
> so I'd need guidance and/or test-cases from someone familiar with it to make
> sure my implementation would be compatible with canonical Guile Scheme.

Rather than going for Scheme integration, it'd be better to target
tree-il, which is the level below it.

> The second, I was asking about because I was initially drawn to Guile during
> the era when it was being touted as a good compiler target platform to become
> a runtime for code written in any language and then translated to Guile Scheme
> before execution.  But, my impression is that this work stalled and/or failed?

I'd say stalled, rather than failed.  We haven't heard from the
"maintainer" for two years now, and I've been periodically asking around
for people to pick it up, but without any luck.  The intersection of
people interested in Guile and Lua is pretty small, it seems.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Anniversary hack: Zile editor with Guile support

[Gary V. Vaughan]

Hi Ian,

On 25 Mar 2013, at 09:13, Ian Price <ianprice90@googlemail.com> wrote:
> "Gary V. Vaughan" <gary@gnu.org> writes:
> 
>> Rather than byte-code to byte-code translation, I was rather thinking of either:
>> 
>>  1. Tweaking zlc to be capable of compiling guile scheme directly to Lua (and
>>     then easily from there to Lua bytecodes); or
>>  2. Running Zile with the Guile implementation of Lua, and getting Guile as
>>     an extension language for free.
>> 
>> The first, I can do, though it's a long time since I paid attention to Guile,
>> so I'd need guidance and/or test-cases from someone familiar with it to make
>> sure my implementation would be compatible with canonical Guile Scheme.
> 
> Rather than going for Scheme integration, it'd be better to target
> tree-il, which is the level below it.

But surely, the point of having an Emacs that can be extended with Guile Scheme,
is that the user can feed Guile Scheme code to it?  (1) above proposes compiling
the users Scheme to Lua bytecodes for sandboxed evaluation by Lua Zile.

(2) above is outside of my skill-set.  I guess you are saying that resurrecting
Lua on Guile should target tree-il. 

>> The second, I was asking about because I was initially drawn to Guile during
>> the era when it was being touted as a good compiler target platform to become
>> a runtime for code written in any language and then translated to Guile Scheme
>> before execution.  But, my impression is that this work stalled and/or failed?
> 
> I'd say stalled, rather than failed.  We haven't heard from the
> "maintainer" for two years now, and I've been periodically asking around
> for people to pick it up, but without any luck.  The intersection of
> people interested in Guile and Lua is pretty small, it seems.

Yes indeed :(

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: Anniversary hack: Zile editor with Guile support

[Nala Ginrut]

On Mon, 2013-03-25 at 02:13 +0000, Ian Price wrote:
> "Gary V. Vaughan" <gary@gnu.org> writes:
> 
> > Rather than byte-code to byte-code translation, I was rather thinking of either:
> >
> >   1. Tweaking zlc to be capable of compiling guile scheme directly to Lua (and
> >      then easily from there to Lua bytecodes); or
> >   2. Running Zile with the Guile implementation of Lua, and getting Guile as
> >      an extension language for free.
> >
> > The first, I can do, though it's a long time since I paid attention to Guile,
> > so I'd need guidance and/or test-cases from someone familiar with it to make
> > sure my implementation would be compatible with canonical Guile Scheme.
> 
> Rather than going for Scheme integration, it'd be better to target
> tree-il, which is the level below it.
> 
> > The second, I was asking about because I was initially drawn to Guile during
> > the era when it was being touted as a good compiler target platform to become
> > a runtime for code written in any language and then translated to Guile Scheme
> > before execution.  But, my impression is that this work stalled and/or failed?
> 
> I'd say stalled, rather than failed.  We haven't heard from the
> "maintainer" for two years now, and I've been periodically asking around
> for people to pick it up, but without any luck.  The intersection of
> people interested in Guile and Lua is pretty small, it seems.
> 

Well, as the man who claimed to take up guile-lua, I shamed. :-(
Though we have guile-lua, it can't work successfully.
The problem of current guile-lua is that the original author didn't use
Guile inner LALR which ludo suggested to me, but a manual parser. So
it's a little hard for me to read & learn them all then fix the bug in a
short time.
Besides, I'm trying our brand new PEG, which is very cool.
And the dilemma comes to me: now that original guile-lua can't work, and
Guile suggest LALR/PEG to handle front-end, should I rewrite guile-lua?
Even keep it was, I have to spend more time to learn the original code,
which seems no efficient.

However, lua-bytecode->guile-bytecode or lua-ast->guile-tree-il maybe
another way to go, but no my aim.

Re: Anniversary hack: Zile editor with Guile support

[Ian Price]

"Gary V. Vaughan" <gary@gnu.org> writes:

>>> The first, I can do, though it's a long time since I paid attention to Guile,
>>> so I'd need guidance and/or test-cases from someone familiar with it to make
>>> sure my implementation would be compatible with canonical Guile Scheme.
>> 
>> Rather than going for Scheme integration, it'd be better to target
>> tree-il, which is the level below it.
>
> But surely, the point of having an Emacs that can be extended with Guile Scheme,
> is that the user can feed Guile Scheme code to it?  (1) above proposes compiling
> the users Scheme to Lua bytecodes for sandboxed evaluation by Lua Zile.

Of course we'd prefer Scheme, but I don't think that has to mean writing
a new Guile-compatible Scheme implementation, and implementing Tree-IL
doesn't preclude it.

Guile is made up of several layers: Scheme/Tree-IL/GLIL/Assembly/etc.
and we expose these through various modules. If you want to write a
compiler for Scheme (in this case to Lua bytecode), we have the
infrastructure available and documented for you.

I suggest Tree-IL since that is the compilation target we recommend for
new languages (both elisp and ecmascript compile to this), but if it is
convenient for Lua bytecode, pick an even lower level one.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Anniversary hack: Zile editor with Guile support

[Gary V. Vaughan]

Hi Ian,

On 25 Mar 2013, at 11:10, Ian Price <ianprice90@googlemail.com> wrote:
> "Gary V. Vaughan" <gary@gnu.org> writes:
>>>> The first, I can do, though it's a long time since I paid attention to Guile,
>>>> so I'd need guidance and/or test-cases from someone familiar with it to make
>>>> sure my implementation would be compatible with canonical Guile Scheme.
>>> 
>>> Rather than going for Scheme integration, it'd be better to target
>>> tree-il, which is the level below it.
>> 
>> But surely, the point of having an Emacs that can be extended with Guile Scheme,
>> is that the user can feed Guile Scheme code to it?  (1) above proposes compiling
>> the users Scheme to Lua bytecodes for sandboxed evaluation by Lua Zile.
> 
> Of course we'd prefer Scheme, but I don't think that has to mean writing
> a new Guile-compatible Scheme implementation, and implementing Tree-IL
> doesn't preclude it.
> 
> Guile is made up of several layers: Scheme/Tree-IL/GLIL/Assembly/etc.
> and we expose these through various modules. If you want to write a
> compiler for Scheme (in this case to Lua bytecode), we have the
> infrastructure available and documented for you.
> 
> I suggest Tree-IL since that is the compilation target we recommend for
> new languages (both elisp and ecmascript compile to this), but if it is
> convenient for Lua bytecode, pick an even lower level one.

I think we are misunderstanding one another somewhere :(

I'm talking about this:

  1. user writes some Guile Scheme, and feeds it to Lua Zile
  2. Lua Zile runs zlc to translate Guile Scheme to Lua
  3. Lua Zile runs luac to compile output of (2) to Lua bytecodes, and
     saves the result to disk
  4. Lua runtime executes file of Lua bytecodes.

I really don't see how Tree-IL fits in here, or makes loading and executing Guile
Scheme sources from Lua Zile any easier.

What am I missing?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: Anniversary hack: Zile editor with Guile support

[Ian Price]

"Gary V. Vaughan" <gary@gnu.org> writes:


> I think we are misunderstanding one another somewhere :(
>
> I'm talking about this:
>
>   1. user writes some Guile Scheme, and feeds it to Lua Zile
>   2. Lua Zile runs zlc to translate Guile Scheme to Lua
>   3. Lua Zile runs luac to compile output of (2) to Lua bytecodes, and
>      saves the result to disk
>   4. Lua runtime executes file of Lua bytecodes.
>
> I really don't see how Tree-IL fits in here, or makes loading and executing Guile
> Scheme sources from Lua Zile any easier.
>
> What am I missing?

Two observations:

1. The frequent references to Guile Scheme (as opposed to just Scheme)
imply that Guile compatibility is desirable.

2. The most compatible Scheme implementation with Guile is, quite
obviously, Guile.

So, then, my advice is quite simply to maximise the use of Guile, and
minimise the use of new code when writing this Guile-Scheme->Lua
compiler.

Since Guile is written as a hierarchy of translators, you don't need to
implement Scheme per se, but can instead implement one of the languages
to which we can compile Scheme already, and ask Guile to compile Scheme
to that for you.

e.g. guild compile foo.scm --to=tree-il --output=foo.tree-il

Tree-IL is the "default" option, as it is relatively close to Scheme,
but you won't have to deal with things like hygienic macro
expansion. However, you can pick whichever one you find easiest to
translate to Lua or Lua Bytecode.

I actually intend to follow a similar approach with a
guile-in-the-browser project I would like to write, however, I am
probably going to implement a vm, and have it interpret Guile's assembly
language directly.

I'm not sure I can be clearer than that. If it wasn't enough, well, just
pretend I didn't say anything :)

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Anniversary hack: Zile editor with Guile support

[Gary V. Vaughan]

Hi Ian,

On 25 Mar 2013, at 13:24, Ian Price <ianprice90@googlemail.com> wrote:
> "Gary V. Vaughan" <gary@gnu.org> writes:
>> I think we are misunderstanding one another somewhere :(
>> 
>> I'm talking about this:
>> 
>>  1. user writes some Guile Scheme, and feeds it to Lua Zile
>>  2. Lua Zile runs zlc to translate Guile Scheme to Lua
>>  3. Lua Zile runs luac to compile output of (2) to Lua bytecodes, and
>>     saves the result to disk
>>  4. Lua runtime executes file of Lua bytecodes.
>> 
>> I really don't see how Tree-IL fits in here, or makes loading and executing Guile
>> Scheme sources from Lua Zile any easier.
>> 
>> What am I missing?
> 
> Two observations:
> 
> 1. The frequent references to Guile Scheme (as opposed to just Scheme)
> imply that Guile compatibility is desirable.
> 
> 2. The most compatible Scheme implementation with Guile is, quite
> obviously, Guile.
> 
> So, then, my advice is quite simply to maximise the use of Guile, and
> minimise the use of new code when writing this Guile-Scheme->Lua
> compiler.
> 
> Since Guile is written as a hierarchy of translators, you don't need to
> implement Scheme per se, but can instead implement one of the languages
> to which we can compile Scheme already, and ask Guile to compile Scheme
> to that for you.
> 
> e.g. guild compile foo.scm --to=tree-il --output=foo.tree-il
> 
> Tree-IL is the "default" option, as it is relatively close to Scheme,
> but you won't have to deal with things like hygienic macro
> expansion. However, you can pick whichever one you find easiest to
> translate to Lua or Lua Bytecode.
> 
> I actually intend to follow a similar approach with a
> guile-in-the-browser project I would like to write, however, I am
> probably going to implement a vm, and have it interpret Guile's assembly
> language directly.
> 
> I'm not sure I can be clearer than that. If it wasn't enough, well, just
> pretend I didn't say anything :)

Okay, the penny has finally dropped.  And that does look like a more
compatible approach, so I will certainly experiment with it, when I reach
this item on my TODO list :)

Thank's for your patience!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)