public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
From: Keisuke Nishida <kxn30@po.cwru.edu>
To: Kalle Olavi Niemitalo <tosi@ees2.oulu.fi>
Cc: guile-emacs@sourceware.cygnus.com
Subject: Re: special forms (save-excursion)
Date: Wed, 15 Mar 2000 05:43:00 -0000	[thread overview]
Message-ID: <m33dpsl56b.fsf@kei.cwru.edu> (raw)
In-Reply-To: <iznpuswqsyf.fsf@stekt.oulu.fi>

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

> Why not?  It's expanded to:
> 
> (let ((start (point)))
>   (emacs-eval `(save-excursion
>                  (,(lambda ()
>                      (goto-char start))))))

Oh, sorry, I was careless.  Yes, you are right.  If we had Lisp-side
Scheme values with some more extensions, it would work.

> The Emacs evaluator would have to be changed to call the
> equivalent of guile-apply if the function being called is a
> Scheme object.  I don't know how difficult that is.  If it is too
> much work, the version with an explicit guile-eval could be used.
> This is really the only difference between the versions.

Right.  I guess it's not very difficult to patch the evaluator,
but I would choose the latter since it is easier to implement.
We can switch to the other one anytime later on.

Could you work on adding the new Lisp type to Emacs?  I'm doing
other stuff right now.

> > OK, I'll try to add the type soon.  I guess you can define a new
> > macro `import-lisp-macro'.
> 
> That could be used for all the `save-' macros / special forms.
> But others like `when' and `condition-case' take their parameters
> in different ways and would have to be handled separately.
> Perhaps the importing macro should be called
> `import-lisp-body-macro' because it applies only to macros whose
> parameters form a single body.  Then there could be
> `import-lisp-1-body-macro' for things like `with-current-buffer'
> which take one normal parameter and a body.

I see.  How about this form?

  (import-lisp-body-macro save-execution)
  (import-lisp-body-macro with-current-buffer #t 2)

The second argument can be a Scheme name of the macro unless it is #t.
The third argument is the number of arguments of the macro (1 is default).

> Should I use defmacro instead of syntax-rules?  I like
> syntax-rules more, but it seems slower.

I think faster one is better.  This is not a complex syntax and
easy to maintain.

> How do I define documentation strings for Guile macros?

I have no idea yet.  We can extend our implementation later on.

> >   lisp-variable-ref, lisp-variable-set!,
> >   import-lisp-function, import-lisp-variable
> 
> Are they used like this?
> (lisp-variable-set! (import-lisp-variable 'buffer-read-only) 't)

Like this:

  (import-lisp-variable buffer-read-only)
  (set! (buffer-read-only) t)

or

  (lisp-variable-set! 'buffer-read-only 't)

How this looks like?  This is my current implementation.

------------------------------------------------------------------------
(define-module (emacs emacs))

(define-public t 't)
(define-public nil 'nil)

(define-public (lisp-false? sexp) (or (eq? sexp ()) (eq? sexp nil)))
(define-public (lisp-true? sexp) (not (lisp-false? sexp)))

(define-public (lisp-variable-ref symbol)
  (lisp-eval symbol))

(define-public (lisp-variable-set! symbol value)
  (lisp-eval `(setq ,symbol ,value)))

(define-macro (import-lisp-variable-1 variable . rest)
  (let ((name (if (pair? rest) (car rest) variable)))
    `(define ,name (make-procedure-with-setter
		    (lambda () (lisp-variable-ref ',variable))
		    (lambda (value) (lisp-variable-set! ',variable value))))))
(define-public import-lisp-variable import-lisp-variable-1)

(define-macro (import-lisp-function-1 name)
  (if (lisp-true? (lisp-apply 'functionp (list name)))
      `(define ,name (lambda args (lisp-apply ,name args)))
      (lisp-apply 'error (list "No such function: %s" name))))
(define-public import-lisp-function import-lisp-function-1)
------------------------------------------------------------------------

  reply	other threads:[~2000-03-15  5:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-14 12:46 Kalle Olavi Niemitalo
2000-03-14 13:32 ` Keisuke Nishida
2000-03-14 14:11 ` Keisuke Nishida
2000-03-14 14:17   ` Keisuke Nishida
2000-03-15  0:34   ` Kalle Olavi Niemitalo
2000-03-15  3:32     ` Keisuke Nishida
2000-03-15  5:11       ` Kalle Olavi Niemitalo
2000-03-15  5:43         ` Keisuke Nishida [this message]
2000-03-15  6:12           ` Kalle Olavi Niemitalo
2000-03-15 11:37             ` guile-emacs GC (was special forms) Kalle Olavi Niemitalo
2000-03-15 12:18               ` Keisuke Nishida
2000-03-15 13:48                 ` Jim Blandy
2000-03-15 15:14                   ` Keisuke Nishida
2000-03-15 11:30           ` special forms (save-excursion) Kalle Olavi Niemitalo
2000-03-15 12:42             ` Keisuke Nishida

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m33dpsl56b.fsf@kei.cwru.edu \
    --to=kxn30@po.cwru.edu \
    --cc=guile-emacs@sourceware.cygnus.com \
    --cc=tosi@ees2.oulu.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).