Guile on Zile, module questions

Guile on Zile, module questions

[Mike Gran]

Hello Guilers!
 
Over the USA holiday I started looking at the last C version of
Zile, which has its own toy Lisp interpreter.  (Zile also
comes in a new Lua version!)  I looks like it would be simple to
strip out that Zile Lisp and replace it with Guile Scheme. 
But I don't think anyone has tried it.
 
This notion is not new: Ludo and Reuben chatted about it once.
But Zile wants to be tiny, portable and doesn't need to be
extensible.  Guile is not tiny, and for the moment, not very 
portable.  
 
I thought it might be a fun hack, strictly for my own amusement.
And I thought that it could actually be completed by one guy:
unlike Guile in EMACS.  That codebase is k-krazy big.
 
I got pretty far along until I ran into my first real
problem having to do with extracting a list of all the
top-level variables so I can to tab completion.
 
Zile has two scopes.
1) a Zile scope
2) a buffer-specific scope
 
In Guile terms, the Zile module is imported into and shadowed by
the buffer-specific module.
 
In EMACS, you'd use 'setq' for new Zile-scope vars, and
'make-local-variable' for buffer-specific. (A simplification, but
close enough)
 
Anyway, I need to extract all the procedure or variable names
for use with the tab-key autocompletion function.  I don't
want autocomplete to give all accessible Guile vars/funcs,
only editor-specific vars/funcs.
 
So, I went source diving so I could figure out how to extract
a list of
1) the public, exported bindings in the Zile module, and
2) the top-level bindings in the buffer-specific module
 
As far as I can tell, I should use 'module-obarray' to get
all the bindings for the buffer-specific module and I should
look at '%module-public-interface' to get the list of exported
functions and vars in the top Zile module.
 
Is that right?
 
Thanks,
 
Mike Gran

Re: Guile on Zile, module questions

[Reuben Thomas]

On 30 November 2011 23:09, Mike Gran <spk121-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
> Hello Guilers!
>
> Over the USA holiday I started looking at the last C version of
> Zile, which has its own toy Lisp interpreter.  (Zile also
> comes in a new Lua version!)  I looks like it would be simple to
> strip out that Zile Lisp and replace it with Guile Scheme.
> But I don't think anyone has tried it.
>
> This notion is not new: Ludo and Reuben chatted about it once.
> But Zile wants to be tiny, portable and doesn't need to be
> extensible.  Guile is not tiny, and for the moment, not very
> portable.

Zile in its traditional shipped form is indeed meant to be tiny and
portable, but since it's been (ab)used for various experimental
purposes (for example, the Lua version, which is currently still
experimental), I'd be very happy to have a Guile integration branch
too. I've found Zile a good platform for experimentation precisely
because it's small and simple, but nonetheless a full-fledged editor.

-- 
http://rrt.sc3d.org

Re: Guile on Zile, module questions

[Ludovic Courtès]

Hi Mike!

Mike Gran <spk121@yahoo.com> skribis:

> Over the USA holiday I started looking at the last C version of
> Zile, which has its own toy Lisp interpreter.  (Zile also
> comes in a new Lua version!)  I looks like it would be simple to
> strip out that Zile Lisp and replace it with Guile Scheme. 
> But I don't think anyone has tried it.

This sounds great!  Another competitor for Gano and Guile-Emacs!  ;-)

Where’s the source?  :-)

> Zile has two scopes.
> 1) a Zile scope
> 2) a buffer-specific scope

You might want to check the crazy things BT Templeton did to handle
that:

  http://www.gnu.org/ghm/2011/paris/slides/bt-templeton-guile-emacs.pdf

(You might need additional input from him, though.  ;-))

> As far as I can tell, I should use 'module-obarray' to get
> all the bindings for the buffer-specific module and I should
> look at '%module-public-interface' to get the list of exported
> functions and vars in the top Zile module.

Note that you should use ‘module-public-interface’ instead of referring
to the ‘%module-public-interface’ binding.

Here’s an example:

  (hash-fold (lambda (k v r) (cons k r))
             '()
             (module-obarray (module-public-interface the-root-module)))

There’s also ‘module-for-each’:

  (module-for-each (lambda (b v)
                     (format #t "variable `~a' has value `~a'~%" b
                             (variable-ref v)))
                   (resolve-interface '(ice-9 q)))

Looking forward to using this new Zile.  :-)

Ludo’.

Re: Guile on Zile, module questions

[Mike Gran]

> Hi Mike!
> 
>>  Over the USA holiday I started looking at the last C version of
>>  Zile, which has its own toy Lisp interpreter.  (Zile also
>>  comes in a new Lua version!)  I looks like it would be simple to
>>  strip out that Zile Lisp and replace it with Guile Scheme. 
>>  But I don't think anyone has tried it.
> 
> This sounds great!  Another competitor for Gano and Guile-Emacs!  ;-)
> 
> Where’s the source?  :-)

I have a somewhat complete version at
https://github.com/spk121/zile
 
There's a few regressions, and some problems with self-documentation,
and the build it still fragile, but, it basically works.
 
-Mike

Re: [Help-zile] Guile on Zile, module questions

[Reuben Thomas]

On 28 December 2011 04:57, Mike Gran <spk121@yahoo.com> wrote:
>> Hi Mike!
>>
>>>  Over the USA holiday I started looking at the last C version of
>>>  Zile, which has its own toy Lisp interpreter.  (Zile also
>>>  comes in a new Lua version!)  I looks like it would be simple to
>>>  strip out that Zile Lisp and replace it with Guile Scheme.
>>>  But I don't think anyone has tried it.
>>
>> This sounds great!  Another competitor for Gano and Guile-Emacs!  ;-)
>>
>> Where’s the source?  :-)
>
> I have a somewhat complete version at
> https://github.com/spk121/zile
>
> There's a few regressions, and some problems with self-documentation,
> and the build it still fragile, but, it basically works.

A couple more comments:

1. I'm very happy for Zile to be used as an experimental platform.
It's increasingly obsolete as an actual editor (Emacs starts up fast
and runs on most things), but I still maintain it and it has a test
suite. Hence, it's good for making experiments that change the
implementation but keep exactly the same behaviour.

2. The Lua version will shortly become the primary one. In a way this
makes it easier to experiment on the C base, because the C will change
increasingly slowly, but also do not neglect the possibilities of
experimenting with the Lua version. It's much more convenient to
change; Lua is happy to talk to C, so it's transitively happy to talk
to other languages that talk to C; and finally, with respect to Guile
in particular, don't forget that Guile has experimental Lua support,
so there's an obvious way to short-circuit C.

Anything I can do to assist experiments, and ESPECIALLY experiments
aimed at improving GNU, please don't hesitate to write to help-zile or
bug-zile.

-- 
http://rrt.sc3d.org

Re: Guile on Zile, module questions

[Ludovic Courtès]

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

Hi Mike!

Mike Gran <spk121@yahoo.com> skribis:

> I have a somewhat complete version at
> https://github.com/spk121/zile

Nice!

So, first, the obligatory patch:


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

diff --git a/build-aux/snarf-c2h.scm b/build-aux/snarf-c2h.scm
index 10ca880..edc933c 100755
--- a/build-aux/snarf-c2h.scm
+++ b/build-aux/snarf-c2h.scm
@@ -1,5 +1,5 @@
-#!/usr/local/bin/guile \
--e c2h -s
+#!/bin/sh
+guile -e c2h -s
 !#
 ;;; output.scm  --  Output documentation "snarffed" from C files in Texi/GDF.
 ;;;

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


Then, it fails to build for me, basically because the all the subrs are
undeclared; for instance, G_beginning_of_line is DEFUN’d in basic.c but
then there’s no header that declares it, which leads to errors when
trying to use it in another compilation unit:

  src/funcs.c: In function 'G_backward_paragraph':
  src/funcs.c:747:58: error: 'G_beginning_of_line' undeclared (first use in this function)

I tried the hack below but that doesn’t capture all uses:


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

diff --git a/src/main.h b/src/main.h
index 3a01b49..f06d4bb 100644
--- a/src/main.h
+++ b/src/main.h
@@ -230,7 +230,10 @@ SCM_DEFINE (G_ ## c_func, zile_func,				\
 
 /* Call an interactive function. */
 #define FUNCALL(c_func)				\
-  gfuncall (G_ ## c_func)
+  ({						\
+     extern SCM G_ ## c_func ();		\
+     gfuncall (G_ ## c_func);			\
+   })
 
 /* Call an interactive function with a universal argument. */
 #define FUNCALL_ARG(c_func, uniarg)             \
@@ -330,11 +333,17 @@ SCM_DEFINE (G_ ## c_func, zile_func,				\
       cname = true;					 \
     }
 
-#define G_FUNCALL(c_func) \
-  gfuncall (G_ ## c_func)
-
-#define G_FUNCALL_ARG(c_func, uniarg) \
-  gfuncall_arg (G_ ## c_func, uniarg)
+#define G_FUNCALL(c_func)			\
+   ({						\
+      extern SCM G_ ## c_func ();		\
+      gfuncall (G_ ## c_func);			\
+    })
+
+#define G_FUNCALL_ARG(c_func, uniarg)		\
+   ({						\
+      extern SCM G_ ## c_func ();		\
+      gfuncall_arg (G_ ## c_func, uniarg);	\
+    })
 
 /*--------------------------------------------------------------------------
  * Keyboard handling.

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


Am I missing something?

Thanks!

Ludo’.

Re: Guile on Zile

[Mike Gran]

 
> From: Ludovic Courtès <ludo@gnu.org>
 > 
> Hi Mike!
> 
> Mike Gran <spk121@yahoo.com> skribis:
> 
>>  I have a somewhat complete version at
>>  https://github.com/spk121/zile
> 
> Nice!
> 
> So, first, the obligatory patch:

Thanks

> Am I missing something?

There's a bad makefile rule for tbl_gdecl.h.

Give it a couple of weeks.  When I can get it
to build on both my boxes, I'll announce a rev 0.0.

Thanks for trying,

Mike

Re: Guile on Zile, module questions

[Mike Gran]

 
> From: Ludovic Courtès ludo@gnu.org
 
> 
> This sounds great!  Another competitor for Gano and Guile-Emacs!  ;-)

LOL. Gano.  Gano lead to a fairly complete ECMA-48 soft term library, which
was the fun part.  But building the state machine got boring.  So 
Gano is dead.  Long live Gano.
I could post the ECMA-48 soft term library, I guess, but, I imagine
the potential number of users of such a library to be approximately zero.

-Mike

Re: Guile on Zile, module questions

[Klaus Schilling]

From: Mike Gran <spk121@yahoo.com>
Subject: Re: Guile on Zile, module questions
Date: Tue, 27 Dec 2011 20:59:34 -0800 (PST)

> I could post the ECMA-48 soft term library, I guess, but, I imagine
> the potential number of users of such a library to be approximately zero.
> 
what is an ecma-48 soft term library?

Klaus Schilling

Re: Guile on Zile

[Mike Gran]

> From: Klaus Schilling <schilling.klaus@web.de>
> 
>>  I could post the ECMA-48 soft term library, I guess, but, I imagine
>>  the potential number of users of such a library to be approximately zero.
>> 
> what is an ecma-48 soft term library?

It is an object that contains a sequential list of fixed-width strings
and a position of a virtual cursor in that list of strings.
A set of operations modify the object, such as 'add character'
'insert line' 'delete line', etc.  If you choose, for example, 25
strings of 80 characters width, it could form the software model
behind a terminal emulator.

The list of operations are as described in ECMA-48, which is the standard
on which terminal emulators like xterm are based. 

Thanks,

Mike