import-lisp-macro

import-lisp-macro

[Keisuke Nishida]

Hello,

OK, I did it.  Now we can import some lisp macros like this:

  (import-lisp-macro save-excursion)

This works only for (NAME BODY...) style macros for now.
The new version is available from CVS:

  http://sourceforge.net/cvs/?group_id=3545

It seems this version has some GC-related bugs, and the code is not
very clean.  I'll rewrite them before long.

An important change has been made.  All imported lisp functions now
returns a kind of pointer to a lisp value.  The new scheme code looks
like this:

  ;; Call a lisp function with a return value from a lisp function
  (let ((str (buffer-substring start end)))
    (insert str))

  ;; Call a scheme function with a return value from a lisp function
  (let ((str (buffer-substring start end)))
    (eval-string (str)))

  ;; Another way of writing
  (eval-string ((buffer-substring start end)))

The difference is additional parentheses around the return value.
It actually converts a lisp value to a scheme value.  I think this
is a necessary but a confusing feature.  We shouldn't write too many
code in this manner.

Now we are almost ready to write Emacs Scheme programs.  I'd like to
write some more experimental programs and to think about a better way
of writing scheme programs.

Since I'm going to be busy from this weekend, I am not sure if I can
work a lot for a while...

-- Kei

Re: import-lisp-macro

[Kalle Olavi Niemitalo]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

>   http://sourceforge.net/cvs/?group_id=3545

Got it.

> It seems this version has some GC-related bugs

Is there a way to fix them?

> An important change has been made.  All imported lisp functions now
> returns a kind of pointer to a lisp value.

I think this is bad.  A function like buffer-substring should
return a Scheme string directly, because that's what it will do
in a Guile-based Emacs.  There could be a separate function
buffer-substring-lispref for cases where the Lisp reference is
needed.

Re: import-lisp-macro

[Keisuke Nishida]

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> > It seems this version has some GC-related bugs
> 
> Is there a way to fix them?

I think so, but I have not investigated it yet.

bash$ gdb emacs core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...

warning: exec file is newer than core file.
Core was generated by `emacs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libXaw.so.6...done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/lib/libncurses.so.4...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /usr/local/lib/libguile.so.7...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0  0x401fb4e1 in __kill () from /lib/libc.so.6
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x8093dc7: file emacs.c, line 277.
Breakpoint 2 at 0x8085f6e: file xterm.c, line 5335.
(gdb) bt
#0  0x401fb4e1 in __kill () from /lib/libc.so.6
#1  0x8093db6 in fatal_error_signal (sig=11) at emacs.c:249
#2  0x401fb408 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#3  0x40319067 in scm_make_stack (args=10612) at stacks.c:467
#4  0x403206a9 in ss_handler (data=0x0, tag=1077217144, throw_args=1077803392)
    at throw.c:315
#5  0x40320d19 in scm_ithrow (key=1077217144, args=1077803392, noreturn=1)
    at throw.c:683
#6  0x402eb036 in scm_error (key=1077217144, subr=0x0, 
    message=0x403388a0 "Unbound variable: ~S", args=1077803408, rest=8564)
    at error.c:82
#7  0x402ec17e in scm_lookupcar (vloc=1077808224, genv=1077814064, check=1)
    at eval.c:349
#8  0x402ec288 in scm_eval_car (pair=1077808224, env=1077814064) at eval.c:434
#9  0x402ecce4 in iqq (form=1077808232, env=1077814064, depth=1) at eval.c:847

Well, this might not be a GC bug...

> > An important change has been made.  All imported lisp functions now
> > returns a kind of pointer to a lisp value.
> 
> I think this is bad.  A function like buffer-substring should
> return a Scheme string directly, because that's what it will do
> in a Guile-based Emacs.  There could be a separate function
> buffer-substring-lispref for cases where the Lisp reference is
> needed.

Yes, we can do that by defining this:

  (import-lisp-function buffer-substring buffer-substring-lispref)

  (define (buffer-substring . args)
    ((apply buffer-substring-lispref args)))

My point is lisp-eval should have this change for completeness.
And that's why I think we need to develop a new set of functions
for Scheme programs.

-- Kei

Re: import-lisp-macro

[Keisuke Nishida]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Yes, we can do that by defining this:
> 
>   (import-lisp-function buffer-substring buffer-substring-lispref)
> 
>   (define (buffer-substring . args)
>     ((apply buffer-substring-lispref args)))

Of course, we could add a new macro that does this automatically:

  (define-macro (import-lisp-function-by-value func . rest)
    (if (null? (lispref->scm (lisp-apply 'functionp (list func))))
        (lisp-apply 'error (list "No such function: %s" func)))
    (let ((name (if (pair? rest) (car rest) func)))
      `(define (,name . args)
         (lispref->scm (lisp-apply ',func args)))))
  (export import-lisp-function-by-value)

  (import-lisp-function-by-value buffer-substring)

This works in the previous manner.  I guess all functions that
return a number, symbol, or string may be imported by using this.

Re: import-lisp-macro

[Keisuke Nishida]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> My point is lisp-eval should have this change for completeness.
> And that's why I think we need to develop a new set of functions
> for Scheme programs.

Or another approach for the moment is to discourage people from
using lots of Emacs functions in Scheme.  We can write the core
of a program in Scheme, and an Emacs interface in Lisp.  Such a
program will work best with this Guile Emacs...
(It's confusing anyway!)

Re: import-lisp-macro

[Kalle Olavi Niemitalo]

The current version (emacs.scm 1.3) of import-lisp-macro can't
handle this:

(let ((msg "Hello!"))
  (save-excursion
    msg))

because it evaluates the lambda in the wrong place.

The following definition seems to work better.  I moved most of
the code emitted by the macro to a new function "call-lisp-macro"
because nested backquotes confuse me.  There is still some
nesting; I hope I got it right.  I am currently unable to access
SourceForge via SSH so please commit this change for me.
(You could use this mail as the log message. :-) )

(define-private (call-lisp-macro macro-name thunk)
  (lispref->scm (lisp-eval `(,macro-name
			      (scheme-eval '(',thunk))))))

(define-macro (import-lisp-macro macro . rest)
  (let ((scheme-name (if (pair? rest) (car rest) macro)))
    `(define-macro (,scheme-name . body)
       `(',',call-lisp-macro ',',macro (lambda () ,@body)))))
(export import-lisp-macro)

Re: import-lisp-macro

[Keisuke Nishida]

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> The current version (emacs.scm 1.3) of import-lisp-macro can't
> handle this:
> (let ((msg "Hello!"))
>   (save-excursion
>     msg))
> because it evaluates the lambda in the wrong place.

That's right.

> The following definition seems to work better.  I moved most of
> the code emitted by the macro to a new function "call-lisp-macro"
> because nested backquotes confuse me.  There is still some
> nesting; I hope I got it right.  I am currently unable to access
> SourceForge via SSH so please commit this change for me.
> (You could use this mail as the log message. :-) )
> 
> (define-private (call-lisp-macro macro-name thunk)
>   (lispref->scm (lisp-eval `(,macro-name
> 			      (scheme-eval '(',thunk))))))
> 
> (define-macro (import-lisp-macro macro . rest)
>   (let ((scheme-name (if (pair? rest) (car rest) macro)))
>     `(define-macro (,scheme-name . body)
>        `(',',call-lisp-macro ',',macro (lambda () ,@body)))))
> (export import-lisp-macro)

Thanks.  I'll commit this soon.  Could you extend this so that it
handles with-current-buffer properly?  Maybe defining a new macro
import-lisp-macro-1 is better.

Re: import-lisp-macro

[Kalle Olavi Niemitalo]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Could you extend this so that it handles with-current-buffer
> properly?  Maybe defining a new macro import-lisp-macro-1 is
> better.

OK, I'll define import-lisp-macro-1 for with-* macros.  I hope we
won't need import-lisp-macro-2.