unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>
Subject: Internal defines
Date: Sun, 09 Nov 2003 23:40:26 +0100	[thread overview]
Message-ID: <3FAEC259.302@dirk-herrmanns-seiten.de> (raw)

Hi folks,

Guile currently chokes on the following form:

  (defmacro a forms
    (cons 'define forms))
  (let ((c identity) (x #t))
    (define (a x y) (and x y))
    (a (c x) (c x))))

According to R5RS, the body of a form like lambda, let, let* etc. looks 
like follows:

<body> --> <definition>* <sequence>
<sequence> --> <command>* <expression>
<command> --> <expression>
<definition> --> (define <variable> <expression>)
      | (define (<variable> <def formals>) <body>)
      | (begin <definition>*)

That is, it starts with zero or more definitions followed by one or more 
expressions.
The definition forms must start with the literal symbol 'define' or 
'begin', which
may enclose further definitions or begin forms.  In any case, there is 
no mentioning
of macro expansion here.

In other words, the examle code above should return #t, because the 
expression
(a (c x) (c x)) refers to the internal define rather than to the outer 
macro.
Guile, however, has up to now performed macro expansion before checking 
whether the
form is a definition.  Thus, the example above returns an error, since Guile
interprets (a (c x) (c x)) as a macro application, in this case a 
definition.
The body then (according to Guile's interpretation) consists only of 
definitions.

The above example also shows that it is no good practice to define 
macros that
expand into definitions.  Messing with 'define' always means to play 
around with
one of scheme's most basic syntactical structures.  The optargs 
implementation
of define* is an example for a macro that expands to a 'define' form.  
According
to R5RS and as demonstrated by the above example, such macros are 
confusing, and
Guile's current implementation breaks code that already has a meaning 
with respect
to R5RS.

I am about to submit a patch that fixes Guile's behaviour, such that the 
example
above would work.  This means, that there is not macro expansion 
performed prior
to detecting the internal defines.  I want, however, to check with you 
before doing
so, since it is likely to break existing code.  In the long term, just 
to mention
it early, I would also like to fix Guile's code such that it also 
handles top-level
defines correctly, since there a similar problem applies.

Best regards
Dirk Herrmann




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


             reply	other threads:[~2003-11-09 22:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-09 22:40 Dirk Herrmann [this message]
2003-11-11  2:21 ` Internal defines Rob Browning
2003-11-11  3:11   ` Tom Lord
2003-11-11  3:50     ` David Van Horn
2003-11-11  4:22       ` Tom Lord
2003-11-11  4:33       ` Tom Lord

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=3FAEC259.302@dirk-herrmanns-seiten.de \
    --to=dirk@dirk-herrmanns-seiten.de \
    /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).