* import-lisp-macro @ 2000-03-17 9:40 Keisuke Nishida 2000-03-18 3:59 ` import-lisp-macro Kalle Olavi Niemitalo 2000-03-20 7:50 ` import-lisp-macro Kalle Olavi Niemitalo 0 siblings, 2 replies; 8+ messages in thread From: Keisuke Nishida @ 2000-03-17 9:40 UTC (permalink / raw) To: guile-emacs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-17 9:40 import-lisp-macro Keisuke Nishida @ 2000-03-18 3:59 ` Kalle Olavi Niemitalo 2000-03-18 10:08 ` import-lisp-macro Keisuke Nishida 2000-03-20 7:50 ` import-lisp-macro Kalle Olavi Niemitalo 1 sibling, 1 reply; 8+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-18 3:59 UTC (permalink / raw) To: guile-emacs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-18 3:59 ` import-lisp-macro Kalle Olavi Niemitalo @ 2000-03-18 10:08 ` Keisuke Nishida 2000-03-18 10:47 ` import-lisp-macro Keisuke Nishida 2000-03-18 11:00 ` import-lisp-macro Keisuke Nishida 0 siblings, 2 replies; 8+ messages in thread From: Keisuke Nishida @ 2000-03-18 10:08 UTC (permalink / raw) To: guile-emacs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-18 10:08 ` import-lisp-macro Keisuke Nishida @ 2000-03-18 10:47 ` Keisuke Nishida 2000-03-18 11:00 ` import-lisp-macro Keisuke Nishida 1 sibling, 0 replies; 8+ messages in thread From: Keisuke Nishida @ 2000-03-18 10:47 UTC (permalink / raw) To: guile-emacs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-18 10:08 ` import-lisp-macro Keisuke Nishida 2000-03-18 10:47 ` import-lisp-macro Keisuke Nishida @ 2000-03-18 11:00 ` Keisuke Nishida 1 sibling, 0 replies; 8+ messages in thread From: Keisuke Nishida @ 2000-03-18 11:00 UTC (permalink / raw) To: guile-emacs 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!) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-17 9:40 import-lisp-macro Keisuke Nishida 2000-03-18 3:59 ` import-lisp-macro Kalle Olavi Niemitalo @ 2000-03-20 7:50 ` Kalle Olavi Niemitalo 2000-03-20 16:04 ` import-lisp-macro Keisuke Nishida 1 sibling, 1 reply; 8+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-20 7:50 UTC (permalink / raw) To: guile-emacs 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-20 7:50 ` import-lisp-macro Kalle Olavi Niemitalo @ 2000-03-20 16:04 ` Keisuke Nishida 2000-03-21 11:05 ` import-lisp-macro Kalle Olavi Niemitalo 0 siblings, 1 reply; 8+ messages in thread From: Keisuke Nishida @ 2000-03-20 16:04 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: import-lisp-macro 2000-03-20 16:04 ` import-lisp-macro Keisuke Nishida @ 2000-03-21 11:05 ` Kalle Olavi Niemitalo 0 siblings, 0 replies; 8+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-21 11:05 UTC (permalink / raw) To: guile-emacs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2000-03-21 11:05 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-17 9:40 import-lisp-macro Keisuke Nishida 2000-03-18 3:59 ` import-lisp-macro Kalle Olavi Niemitalo 2000-03-18 10:08 ` import-lisp-macro Keisuke Nishida 2000-03-18 10:47 ` import-lisp-macro Keisuke Nishida 2000-03-18 11:00 ` import-lisp-macro Keisuke Nishida 2000-03-20 7:50 ` import-lisp-macro Kalle Olavi Niemitalo 2000-03-20 16:04 ` import-lisp-macro Keisuke Nishida 2000-03-21 11:05 ` import-lisp-macro Kalle Olavi Niemitalo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).