Peter Bex writes:
> On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
>> Here's a new patch that drops the (not captured) check.
>
> Thanks for making that! Now that my original patch has been pushed,
> here's an incremental patch based on yours which only drops that check.
>
> Cheers,
>
> On Sun, Sep 15, 2019 at 01:16:50PM +0200, Peter Bex wrote:
> > On Sun, Aug 25, 2019 at 04:34:02PM +0200, Peter Bex wrote:
> > > On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
> > > > Here's a new patch that drops the (not captured) check.
> > >
> > > Thanks for making that! Now that
On Sun, Sep 15, 2019 at 01:16:50PM +0200, Peter Bex wrote:
> On Sun, Aug 25, 2019 at 04:34:02PM +0200, Peter Bex wrote:
> > On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
> > > Here's a new patch that drops the (not captured) check.
> >
> > Thanks for making that! Now that my original
On Sun, Aug 25, 2019 at 04:34:02PM +0200, Peter Bex wrote:
> On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
> > Here's a new patch that drops the (not captured) check.
>
> Thanks for making that! Now that my original patch has been pushed,
> here's an incremental patch based on yours
On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
> Here's a new patch that drops the (not captured) check.
Thanks for making that! Now that my original patch has been pushed,
here's an incremental patch based on yours which only drops that check.
Cheers,
Peter
From
Peter Bex writes:
> On Thu, Jul 11, 2019 at 03:15:00PM +0300, megane wrote:
>> Of course if this is dropped the other conditions must still meet.
>>
[...]
>>
>> Here's a correct way to drop the (not captured) check:
>>
>> (and (not assigned)
>>(or (and (not (db-get db name 'unknown))
On Thu, Jul 11, 2019 at 03:15:00PM +0300, megane wrote:
> Of course if this is dropped the other conditions must still meet.
>
> Here's your proposed condition:
>
> (and (not captured)
>(or (and (not (db-get db name 'unknown))
> (db-get db name 'value))
>
megane writes:
> Peter Bex writes:
>
> Regarding the capturing, the capture test is still there:
>
>
>> (when (and value (not global))
>> (when (eq? '##core#variable (node-class value))
>> - (let* ((name (first (node-parameters value)))
>> -(nrefs (db-get
On Fri, Jul 05, 2019 at 09:13:36AM +0300, megane wrote:
> I reduced this case to this:
>
> (define (foo bindings)
> (define (append-map proc lst1)
> (if lst1
> (proc 1)
> (proc 1 2)))
> (append-map (lambda (b a) (begin)) bindings))
>
> Error: ../fail.scm:5:
Peter Bex 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
megane writes:
> Peter Bex 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
Peter Bex 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
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
On Wed, Jul 03, 2019 at 02:54:24PM +0300, megane wrote:
> Regarding the capturing, the capture test is still there:
>
> > (when (and value (not global))
> >(when (eq? '##core#variable (node-class value))
> > -(let* ((name (first (node-parameters value)))
> > -
Peter Bex writes:
> Hi all,
>
> I had a look at #1620 and as far as I can tell there's no reason why
> an aliased variable cannot be marked as replaceable when either the
> alias or the variable it aliases are captured.
>
> Captured simply means that it needs to be wrapped up in the closure,
>
On Sun, Jun 30, 2019 at 08:55:09PM +0200, felix.winkelm...@bevuta.com wrote:
> Yes, this appears to be the correct way - I wondered why there was not
> an additional constraint on assignment, but since the order of optimizations
> is not easily seen in advance, one has to be careful about many
> I had a look at #1620 and as far as I can tell there's no reason why
> an aliased variable cannot be marked as replaceable when either the
> alias or the variable it aliases are captured.
>
> Captured simply means that it needs to be wrapped up in the closure,
> AFAIK. But if it's replaced,
> On Sun, Jun 30, 2019 at 11:33:17AM -0400, John Cowan wrote:
> > Obviously this is not something you can do in a patch,
> > but at some point Chicken may want to go
> > over to the assignment conversion strategy, in which all mutable
> > local variables are transformed into immutable references
On Sun, Jun 30, 2019 at 11:33:17AM -0400, John Cowan wrote:
> Obviously this is not something you can do in a patch,
> but at some point Chicken may want to go
> over to the assignment conversion strategy, in which all mutable
> local variables are transformed into immutable references to boxes.
On Sun, Jun 30, 2019 at 9:57 AM Peter Bex wrote:
Captured simply means that it needs to be wrapped up in the closure,
> AFAIK. But if it's replaced, then the original variable will need
> to end up in the closure. The only case where you can't replace is
> if either variable is assigned to,
20 matches
Mail list logo
