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 applica
Yo,
On Fri, 2005-04-22 at 08:16 +1000, Kevin Ryde wrote:
> Neil Jerram <[EMAIL PROTECTED]> 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 pr
Neil Jerram <[EMAIL PROTECTED]> 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 f
Rob Browning wrote:
Neil Jerram <[EMAIL PROTECTED]> 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 j
Neil Jerram <[EMAIL PROTECTED]> 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
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
On 4/15/05, Stephen Compall <[EMAIL PROTECTED]> 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 lis
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 fil
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 behavi
