[m-dev.] a conditional field update operator

Michael Day mikeday at yeslogic.com
Wed Mar 8 16:46:38 AEDT 2017


Hi Zoltan,

> The reason why I want to preserve the ability of programmers
> to ask for the current behavior of := is that in cases like this,
> where you know that the "are the old and new values the same?"
> test won't succeed often, or at all, the cost of the test is effectively
> "distributed fat": a cost imposed on one part of the program
> just because *another* part of the program may benefit from it.
> Avoiding distributed fat whereever possible is one of the core principles
> of the project. In this case, avoiding it is trivial.

That seems reasonable.

> One other consideration is that code that updates more than one field,
> such as
>
>    !Info ^ field1 := F1,
>    !Info ^ field2 := F2
>
> can be expanded one goal at a time. The parser will expand this
> into code that constructs Info1 from Info0, and then Info2 from Info1,
> and the common struct optimization pass will come along later,
> process the resulting conjunction of unifications, and construct
> Info2 directly from Info0, optimizing away the materialization of Info1.

Also very reasonable.

> Does Prince make extensive use of conditional assignment?
> Was that the motivation behind your proposal?

Some of our conditional assignments would need an explicit test anyway 
as they have to do other operations if the test fails:

     ( if LineJoin0 = LineJoin then
         Gs = Gs0
     else
         Gs = Gs0 ^ gs0 ^ stroke_linejoin := LineJoin,
         (
             LineJoin = miter,
             write_op(Buf, [int(0)], "j", !IO)
         ;
             LineJoin = round,
             write_op(Buf, [int(1)], "j", !IO)
         ;
             LineJoin = bevel,
             write_op(Buf, [int(2)], "j", !IO)
         )
     )

Our CSS style processing code goes to some effort to avoid allocating 
structures that haven't changed, but I think it wouldn't get any value 
from this pointer equality test unless we canonicalised more values 
deeper in the struct; currently we only canonicalise the whole thing at 
the top level instead of each subfield.

There may be other places where we do conditional assignment (mostly on 
float values not pointers I suspect), but probably not a sufficient 
number to justify doing the test for every assignment.

Michael

-- 
Prince: Print with CSS!
http://www.princexml.com


More information about the developers mailing list