From: Neil Jerram <neil@ossau.uklinux.net>
To: Stephen Compall <s11@member.fsf.org>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: [patch] variable datums with syncase transformer
Date: Thu, 06 Mar 2008 23:28:57 +0000 [thread overview]
Message-ID: <87hcfjph3a.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <1197619616.5218.34.camel@nocandy.dyndns.org> (Stephen Compall's message of "Fri, 14 Dec 2007 02:06:56 -0600")
Hi Stephen,
Following Ludovic's request for me to review this...
Stephen Compall <s11@member.fsf.org> writes:
> +;; The question syncase is asking when it asks `self-evaluating?' is
> +;; not really whether a given datum is self-evaluating, but whether it
> +;; should pass the datum through as-is to the evaluator. With that in
> +;; mind, we wrap core `self-evaluating?' here so that syncase will
> +;; pass-through variables, meaning (variable? datum) => #t, to the
> +;; evaluator. Without this, the system transformer will see a
> +;; variable datum as invalid syntax, which it is not to the core
> +;; transformer.
> +(define (self-evaluating? datum)
> + (or ((@ (guile) self-evaluating?) datum)
> + (variable? datum)))
> +
Given that self-evaluating? has no other purpose, I think it would be
preferable just to add "case scm_tc7_variable:" to the C code, along
with your excellent comment above.
I know that would technically be an incompatible change, but given
that I never heard mention of self-evaluating? before, I think we can
risk it.
(And someone can always write
(define (compatible-self-evaluating? obj)
(and (self-evaluating? obj)
(not (variable? obj))))
if they need to.)
> ;;; Load the preprocessed code
>
> (let ((old-debug #f)
> Index: test-suite/tests/syncase.test
> ===================================================================
> RCS file: /sources/guile/guile/guile-core/test-suite/tests/syncase.test,v
> retrieving revision 1.5
> diff -u -d -u -r1.5 syncase.test
> --- test-suite/tests/syncase.test 16 Apr 2006 23:27:14 -0000 1.5
> +++ test-suite/tests/syncase.test 14 Dec 2007 07:55:49 -0000
> @@ -34,3 +34,15 @@
>
> (pass-if "basic syncase macro"
> (= (plus 1 2 3) (+ 1 2 3)))
> +
> +(pass-if "variable?s recognized as datums"
> + (false-if-exception
> + (begin (eq? car (eval '(@ (guile) car) (current-module)))
> + #t)))
> +
> +(define-syntax export-safe-plus
> + (syntax-rules ()
> + ((_ x ...) ((@ (guile) +) x ...))))
> +
> +(pass-if "variable?s passed through to evaluator"
> + (= (export-safe-plus 1 2 3) (+ 1 2 3)))
These tests are fine (of course!).
Regards,
Neil
prev parent reply other threads:[~2008-03-06 23:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-14 8:06 [patch] variable datums with syncase transformer Stephen Compall
2008-03-05 14:59 ` Ludovic Courtès
2008-03-05 15:36 ` Stephen Compall
2008-03-05 16:34 ` Ludovic Courtès
2008-03-05 20:55 ` Neil Jerram
2008-03-05 22:16 ` Stephen Compall
2008-03-05 23:21 ` Ludovic Courtès
2008-03-06 23:28 ` Neil Jerram [this message]
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hcfjph3a.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=s11@member.fsf.org \
/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).