Hi Andy,
> commit 59c557056cff1ce6146b4d689922300b6278
> Author: Andy Wingo
> Date: Tue Apr 10 15:56:23 2012 -0700
>
> peval: elide redundant predicates; eliminate some common subexpressions
>
> * module/language/tree-il/peval.scm (fold-constants): Returns #f instead
> of
At first I thought you were right. But then I realized there's an even
deeper problem here. Imagine implementing a record mutator like this:
(define (set-foo-a! foo new-value)
(if (is-foo? foo)
(%unsafe-set-foo-a! foo new-value)
(error)))
That code is incorrect, by the same logic you
Hi Mark!
And Happy Friday, as our friend would say. :-)
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>> Mark H Weaver skribis:
>>> l...@gnu.org (Ludovic Courtès) writes:
I’d still want named single-field setters, for convenience. For that,
we probably still need
Hi,
On Fri 13 Apr 2012 07:22, Mark H Weaver writes:
>> * module/language/tree-il/peval.scm (fold-constants): Returns #f instead
>> of the expression, as all continuations handle #f themselves.
>> (negate, bailout?, extract-facts, infer, infer-defined?)
>> (infer-struct-vtab
Hi Andy,
Andy Wingo writes:
> On Fri 13 Apr 2012 07:22, Mark H Weaver writes:
>>> * module/language/tree-il/peval.scm (fold-constants): Returns #f instead
>>> of the expression, as all continuations handle #f themselves.
>>> (negate, bailout?, extract-facts, infer, infer-defined?
Hi Ludovic!
l...@gnu.org (Ludovic Courtès) writes:
> I’d say ‘set-fields’, no?
Okay, good enough.
>>> Would these checks be alleviated by Andy’s work on peval “predicates”?
>>
>> Unfortunately, no. The 'vtable' field of a struct is a mutable field,
>> and in fact when a GOOPS class is redefined
Noah Lavine skribis:
> I'm somewhat afraid, however, that the real solution is changing how
> we deal with parallelism, and that is a much bigger problem.
And this is where functional setters come in. ;-)
Ludo’.
On Fri, Apr 13, 2012 at 3:59 PM, Ludovic Courtès wrote:
> Noah Lavine skribis:
>
>> I'm somewhat afraid, however, that the real solution is changing how
>> we deal with parallelism, and that is a much bigger problem.
>
> And this is where functional setters come in. ;-)
Yes, functional data str