🚀 go-pugleaf

On 01 Apr 1996 10:39:46 PST, martin@kcbbs.gen.nz (Martin D Kealey)
wrote:

>What are needed (to allow some function calls to be optimised
>away) are two new keywords:
>
>  * "clean" which guarantees that the function doesn't modify
>    objects that can only be reached as or through names
>    in an outer scope - and in turn will not call any non-clean
>    functions; and
>
>  * "pure" which guarantees that the function does not depend on
>    the value of any outer scope object - and in turn will not
>    call any non-pure function;
>
>To be fully useful, a function would be declared with both of
>these attibutes and with all pointer or reference parameters
>(including "this") declared "const".
>
>Anyone care to put this forward, or has it been discussed before?

Assuming you allow 'pure' and 'clean', the compiler would then have
to check to make sure your functions were in fact 'pure' and 'clean'.
If the compiler could do such checking as part of its array of
optimizations, why not just do it for every function as
part of a general optimization step?  If the compiler were to do
no checking for the adherence to 'pure' and 'clean' modifiers, then
such modifiers would essentially be a gentleman's contract.  Such
a "contract" could be freely violated with potentially disastrous
results; essentially making 'pure' and 'clean' meaningless.

Jason
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jdmorris@ix.netcom.com (Jason D. Morris) wrote:
>Assuming you allow 'pure' and 'clean', the compiler would then have
>to check to make sure your functions were in fact 'pure' and 'clean'.
>If the compiler could do such checking as part of its array of
>optimizations, why not just do it for every function as
>part of a general optimization step?

The problem is the compiler needs to know the "purity" of the
functions a given function calls during its compilation, or it can't
optimize the code.  You would thus have to compile all the called
functions first, and have that information available while  you
compile that given function. For reasons I hope are reasonably
obvious, this is impossible.  Conceivably you could have a compilation
system that does a first pass compilation over all of the code,
looking for purity of functions, and then a second pass to do the
actual compilation, but that's a bit beyond the capabilities of most
modern compilers...

With the proposed idea, a function that claims to pure and isn't would
be tagged with a compiler error.  This might be problematic with
templates, as instantiation for a particular type may lead to non-pure
functions being called.  Also, changing a function so that it is no
longer pure may lead to a cascade of changes to other functions, as
they would lose their purity tag.  There are probably some other
problems I may not have noticed also (libraries that depend on other,
canging, libraries?)

Before making this part of the standard, it would be nice to have some
sample evidence of how much of a performance difference it makes in
meaningful programs.  In general, you can simulate this by saving in a
variable what you would use multiple calls to get (this is not as nice
for normal programming as having tags, however, as it would require
substantially more work to change if the called function is no longer
pure, or (even worse) might not get changed when it needs to be. 

Andrew Bell
abell@mindspring.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jdmorris@ix.netcom.com (Jason D. Morris) wrote:
>>Assuming you allow 'pure' and 'clean', the compiler would then have
>>to check to make sure your functions were in fact 'pure' and 'clean'.

abell@mindspring.com (Andrew Bell) writes:
>The problem is the compiler needs to know the "purity" of the
>functions a given function calls during its compilation, or it can't
>optimize the code.  You would thus have to compile all the called
>functions first,

No, you wouldn't.  Think of contractual programming, as in Eiffel.
If a keyword associated with a prototype makes a promise (e.g. that
a function has no side effects), users of that function can assume
that promise is kept.  When the compiler compiles the "pure function",
only then does it need to check the function for purity, using only
local information.  No complex analysis is required: any function
calls not so tagged would be assumed to be impure.

>With the proposed idea, a function that claims to pure and isn't would
>be tagged with a compiler error.  This might be problematic with
>templates, as instantiation for a particular type may lead to non-pure
>functions being called.

Replace "pure" with "const".  It's no different.
-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

jbuck@Synopsys.COM (Joe Buck) wrote:
 >abell@mindspring.com (Andrew Bell) writes:
>>The problem is the compiler needs to know the "purity" of the
>>functions a given function calls during its compilation, or it can't
>>optimize the code.  You would thus have to compile all the called
>>functions first,

>No, you wouldn't. 

Tsk, tsk, Joe, you misidentified someone else's statements as Jason's,
and then edited out the part I was responding to, thus making it look
like I was responding to something I wasn't.  I was responding to
Jason's comment that "pure" and "clean" as modifiers weren't necessary
with a slightly smarter compiler.  My response was that in that case,
all the code would have to be precompiled for purity/cleanliness,
before anything could be compiled, a statement I still stand by.

>>With the proposed idea, a function that claims to pure and isn't would
>>be tagged with a compiler error.  This might be problematic with
>>templates, as instantiation for a particular type may lead to non-pure
>>functions being called.

>Replace "pure" with "const".  It's no different.

In that case, pure would have to be part of the function
prototype(specification? Not sure if I'm using the right term here),
which would increase its impact on the language specification.  It
also means you could conceivably have both pure and impure (*) and
clean and unclean versions of the same function, though you could
restrict it to not allow this.  

I suspect the standardization committee might be reluctant to make
such a change just for optimization reasons (especially at this
point), but maybe there will be a C++ '98 or some such.  (Gotta be,
for my wrappers proposal! :-)

Andrew Bell
abell@mindspring.com

* Although impure functions might be illegal in functions that might
be used by children because of the Exon Amendment....
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4k7c9s$t5e@mule1.mindspring.com> abell@mindspring.com
(Andrew Bell) writes:

|> jbuck@Synopsys.COM (Joe Buck) wrote:
|>  >abell@mindspring.com (Andrew Bell) writes:
|> >>The problem is the compiler needs to know the "purity" of the
|> >>functions a given function calls during its compilation, or it can't
|> >>optimize the code.  You would thus have to compile all the called
|> >>functions first,

|> >No, you wouldn't. 

|> Tsk, tsk, Joe, you misidentified someone else's statements as Jason's,
|> and then edited out the part I was responding to, thus making it look
|> like I was responding to something I wasn't.  I was responding to
|> Jason's comment that "pure" and "clean" as modifiers weren't necessary
|> with a slightly smarter compiler.  My response was that in that case,
|> all the code would have to be precompiled for purity/cleanliness,
|> before anything could be compiled, a statement I still stand by.

Concerning the qualification of `pure': I had considered a pragma for C
to this effect back when I was doing compiler work (late 80's).  In the
end, if I remember right, I decided that it wouldn't work, because most
of the functions you would want to label `pure' in fact aren't.  For
example, most of the mathematical functions (which was the main interest
at the time) aren't pure, because they may modify the global variable
`errno'.

I still think that the pragma idea has merit.  There are functions (like
exp or sqrt) that you want to the compiler to treat as pure, even though
they are not pure according to the strict rules.

|> >>With the proposed idea, a function that claims to pure and isn't would
|> >>be tagged with a compiler error.  This might be problematic with
|> >>templates, as instantiation for a particular type may lead to non-pure
|> >>functions being called.

|> >Replace "pure" with "const".  It's no different.

|> In that case, pure would have to be part of the function
|> prototype(specification? Not sure if I'm using the right term here),
|> which would increase its impact on the language specification.  It
|> also means you could conceivably have both pure and impure (*) and
|> clean and unclean versions of the same function, though you could
|> restrict it to not allow this.  

To have both versions, you would have to have a criteria in order for
the compiler to select one or the other.  In this case, having both
would imply that any call to the function was, by definition, ambiguous.
So it is implicitly forbidden.  (Note that const/non-const is only valid
for member functions.)

|> I suspect the standardization committee might be reluctant to make
|> such a change just for optimization reasons (especially at this
|> point), but maybe there will be a C++ '98 or some such.  (Gotta be,
|> for my wrappers proposal! :-)

I am 99.9% certain that such a proposal will not be considered for the
current round of standardization.  It really is too late.  So it won't
make it into C++ '98.  (The year normally refers to the year in which
the standard is formally adapted.  so C++ '98 is about the earliest
possible for this round.)  How about C++ '05?
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]