unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Stephen Compall <s11@member.fsf.org>
Cc: Guile User List <guile-user@gnu.org>
Subject: Re: Using a macro with FOLD alters FOLD procedure!
Date: Fri, 15 Apr 2005 14:50:48 -0500	[thread overview]
Message-ID: <1113594648.3650.8.camel@cslabpc3.evansville.edu> (raw)
In-Reply-To: <56190b6c05041511382ae259d@mail.gmail.com>

On Fri, 2005-04-15 at 11:38 -0700, Steve Juranich wrote:
> I was wondering, is this "expected behavior", or have I uncovered
> something?  If this is expected behavior, I'd suggest that FOLD should
> do a check to make sure that the KONS argument is not a macro.  If
> I've uncovered a bug, I'll file a bug report.

`fold' in SRFI-1 mentions that KONS is supposed to be a function.

If you give a macro to fold, the macro gets expanded and memoized as
such, when the macro is called normally, as it is as an optimization in
the common case of one list.  Try passing multiple lists; I bet you will
get a type error on `apply'.

As for checking whether KONS is a function, well, here is from SRFI-1:

@q
Note that statements of the form "it is an error" merely mean "don't do
that." They are not a guarantee that a conforming implementation will
"catch" such improper use by, for example, raising some kind of
exception. Regrettably, R5RS Scheme requires no firmer guarantee even
for basic operators such as car and cdr, so there's little point in
requiring these procedures to do more.
@end q

So I would say "it is an error" to pass a macro to fold.  Seems like a
serious error, of course, that leaves the system in an undefined state
unlike errors that don't modify the implementation :); I am no authority
on whether this should be fixed (which is the only issue; the fix is
trivial, but has potential philosophical implications).

--
Stephen Compall


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


  reply	other threads:[~2005-04-15 19:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-15 18:38 Using a macro with FOLD alters FOLD procedure! Steve Juranich
2005-04-15 19:50 ` Stephen Compall [this message]
2005-04-15 22:20   ` Steve Juranich
2005-04-16 11:46     ` Neil Jerram
2005-04-18  0:45       ` Rob Browning
2005-04-21  6:35         ` Neil Jerram
2005-04-21 22:16           ` Kevin Ryde
2005-04-22  8:27             ` Andy Wingo
2005-04-23 20:18             ` Neil Jerram

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=1113594648.3650.8.camel@cslabpc3.evansville.edu \
    --to=s11@member.fsf.org \
    --cc=guile-user@gnu.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).