Using a macro with FOLD alters FOLD procedure!

Using a macro with FOLD alters FOLD procedure!

[Steve Juranich]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

I've noticed some strange behavior from (srfi-1) "fold" using a macro
as the KONS argument.

I've attached a file that exhibits the problem.  In a nutshell, using
a macro as the KONS argument for FOLD results in the procedure source
for FOLD being altered.

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.
-- 
Steve Juranich
Tucson, AZ
USA

[-- Attachment #2: exhibit-bug.scm --]
[-- Type: text/x-scheme, Size: 712 bytes --]

#! /bin/bash
exec guile -s "$0"
!#

(use-modules (ice-9 pretty-print)
	     (srfi srfi-1))

;;; First, show that "fold" is in a good state (cf. srfi/srfi-1.scm).
(display "Original source for FOLD:\n")
(pretty-print (procedure-source fold))
(display "\n\n")

;;; Run "fold" with "+" as the KONS.
(fold + 0 '(1 2 3 4 5))

;;; Show that the source has NOT been altered (substantially)
(display "(More or less) Unaltered source for FOLD:\n")
(pretty-print (procedure-source fold))
(display "\n\n")

;;; Run "fold" with a macro as the KONS argument.
(define-macro (++ a b) `(+ ,a ,b))
(fold ++ 0 '(1 2 3 4 5))

(display "Altered (broken) source for FOLD:\n")
(pretty-print (procedure-source fold))
(display "\n\n")


[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

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

Re: Using a macro with FOLD alters FOLD procedure!

[Stephen Compall]

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

Re: Using a macro with FOLD alters FOLD procedure!

[Steve Juranich]

On 4/15/05, Stephen Compall <s11@member.fsf.org> wrote:
> `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'.

Thanks for taking the time to reply.  Please understand that I'm not
taking a harsh tone with you at all.  But this "not quite a bug" bit
me very hard and I'm still stinging a little.

I see your point that the documentation mentions that KONS needs to be
a procedure.  But from a user's perspective, I don't think that I
should have to be reading the docs with a lawyer's mindset to avoid
this kind of problem.

Furthermore, the reason I got bit with this was because I was using
REDUCE (an alias for FOLD) with builtin AND as the KONS.  Please
observe:

guile> (fold + 0 '(1 2 3 4 5)) ; works
15
guile> (fold and #t '(#t #t #t)) ; seems okay.
#t
guile> (fold + 0 '(1 2 3 4 5)) ; WTF??
0

It will take a lot of fancy talking and beer to make me believe that
the above is not a demonstration of a bug.  I would strongly disagree
with the SRFI's author's opinion that "there's little point in
requiring these procedures to do more."  In this case, the point would
be to make sure that the user (i.e, me) doesn't render the
painstakingly crafted software completely useless.

> 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).

Well, speaking on the authority of being a Guile user, is this the
kind of behavior you want Guile to have?  This is exactly the reason I
left Perl.  There is no good reason to have silently failing software.
 This is even worse, as what has happened is that the implementation
has been silently redefined!!

I think that, at the very least, this is a bug in the documentation. 
There should be all kinds of  flashing red lights and sirens when this
kind of behavior is possible.

-- 
Steve Juranich
Tucson, AZ
USA


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

Re: Using a macro with FOLD alters FOLD procedure!

[Neil Jerram]

Steve Juranich wrote:

> Well, speaking on the authority of being a Guile user, is this the
> kind of behavior you want Guile to have?  This is exactly the reason I
> left Perl.  There is no good reason to have silently failing software.
>  This is even worse, as what has happened is that the implementation
> has been silently redefined!!
> 
> I think that, at the very least, this is a bug in the documentation. 
> There should be all kinds of  flashing red lights and sirens when this
> kind of behavior is possible.
> 

FWIW, I agree.  In 1.7.x I believe we have more of the infrastructure in 
place to get this right - by which I mean to signal an error if a macro 
is passed in this way.  But (having just tried your tests out on 1.7.x) 
it's not doing this just yet.

	Neil


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

Re: Using a macro with FOLD alters FOLD procedure!

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> FWIW, I agree.  In 1.7.x I believe we have more of the infrastructure
> in place to get this right - by which I mean to signal an error if a
> macro is passed in this way.  But (having just tried your tests out on
> 1.7.x) it's not doing this just yet.

I haven't considered it carefully yet, but if fold's only supposed to
take a procedure for kons, then why not just add a check-arg-type
procedure? call for kons?

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Using a macro with FOLD alters FOLD procedure!

[Neil Jerram]

Rob Browning wrote:
> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> 
>>FWIW, I agree.  In 1.7.x I believe we have more of the infrastructure
>>in place to get this right - by which I mean to signal an error if a
>>macro is passed in this way.  But (having just tried your tests out on
>>1.7.x) it's not doing this just yet.
> 
> 
> I haven't considered it carefully yet, but if fold's only supposed to
> take a procedure for kons, then why not just add a check-arg-type
> procedure? call for kons?
> 
We could certainly do this, but I think I remember a thread where it was 
suggested that we treat any occurrence of a macro in non-car position as 
an error - which would catch the problem more generally.  Am I 
completely imagining this?

	Neil


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

Re: Using a macro with FOLD alters FOLD procedure!

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> We could certainly do this, but I think I remember a thread where it was 
> suggested that we treat any occurrence of a macro in non-car position as 
> an error - which would catch the problem more generally.

I suppose it depends if a macro should be a first class object to be
thrown around (or do I misunderstand?).

I've been gradually converting srfi-1 procs to C, which has the side
effect of checking the procs are actual procedures.  I suppose there
must be plenty of ordinary application code passing procedures around
in exactly the same way that's vulnerable to memoizing macros.

(Could a memoized form check it's got the same macro as originally
expanded, as a safety check?  Or do I misunderstand again?)


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

Re: Using a macro with FOLD alters FOLD procedure!

[Andy Wingo]

Yo,

On Fri, 2005-04-22 at 08:16 +1000, Kevin Ryde wrote:
> Neil Jerram <neil@ossau.uklinux.net> writes:
> >
> > We could certainly do this, but I think I remember a thread where it was 
> > suggested that we treat any occurrence of a macro in non-car position as 
> > an error - which would catch the problem more generally.
> 
> I suppose it depends if a macro should be a first class object to be
> thrown around (or do I misunderstand?).

Occaisionally useful for introspection -- getting the macro's source,
object-properties (like 'documentation), even digging in the source of a
defmacro to get the procedure's docstring.

A procedure has already-memoized code though, no? Shouldn't a macro only
operate on non-memoized code?
-- 
Andy Wingo
http://wingolog.org/



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

Re: Using a macro with FOLD alters FOLD procedure!

[Neil Jerram]

Kevin Ryde wrote:
> I suppose it depends if a macro should be a first class object to be
> thrown around (or do I misunderstand?).
> 
> I've been gradually converting srfi-1 procs to C, which has the side
> effect of checking the procs are actual procedures.  I suppose there
> must be plenty of ordinary application code passing procedures around
> in exactly the same way that's vulnerable to memoizing macros.
> 
> (Could a memoized form check it's got the same macro as originally
> expanded, as a safety check?  Or do I misunderstand again?)
> 

I think you understand fine - to the extent that I understand myself, 
anyway.

For reference, here's the first message in the 2002 thread that I 
mentioned: 
http://lists.gnu.org/archive/html/guile-devel/2002-01/msg00030.html

The key mail in this thread is probably Marius's one.  I have to say, 
though, that I don't yet understand how Marius's solution would solve 
the problem in the case of passing a macro to fold.

Regards,
	Neil



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