chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of re


From: megane
Subject: Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables
Date: Thu, 04 Jul 2019 22:37:08 +0300
User-agent: mu4e 1.0; emacs 25.1.1

Peter Bex <address@hidden> writes:

> On Wed, Jul 03, 2019 at 02:05:21PM +0200, Peter Bex wrote:
>> You're right, good catch!  That was an oversight on my part, I only
>> removed the captured check of the other variable.  I hope this makes
>> things faster in more cases.  I can make and test a new patch, but don't
>> know when I'll get around to it.  Possibly in the weekend.
>
> I tried this, but I got a crash when compiling CHICKEN with itself after
> having built it with this patch.

Do you mean you tried with the '(not captured)' check removed?

>
> I'm not even sure why it's doing this.  The offending procedure was
> append-map from mini-srfi-1, it's calling proc with the wrong number
> of arguments.

There's this in the definition of append-map:

(define (append-map proc lst1 . lsts)
  ...
  (append (proc x) r)
           ^^^^
           Calling proc with 1 argument

The error was:

Error: mini-srfi-1.scm:72: proc: procedure `proc' called with wrong number of 
arguments
rules.make:831: recipe for target 'chicken-ffi-syntax.c' failed

In chicken-ffi-syntax.scm in the definition for let-syntax there's this:

       (append-map
          (lambda (b a)
             ^^^^
             This expects 2 arguments!!!
            (if (pair? (cddr b))
                (list (cons a (cddr b)))
                '() ) )
                bindings aliases)
>
> I *think* the reason is that you can't replace variables which are
> formal arguments to user procedures, because then all the calls will
> have the wrong number of arguments.
>
> Currently we don't seem to mark formal arguments in any special way,
> so checking if they're captured seems to be the best way.  So my initial
> patch is fine, but perhaps we can refine it in some way by adding this
> distinction?
>
> Cheers,
> Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]