Functions without side-effects. Proposal

On Sep 4, 3:28 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
> Zara ha scritto:
>
> > In fact, I am almost certain that these sets of restrictions (or at
> > least, part of them) do change language semantic.
>
> There's a quick test to discern that. Write a well-formed program with
> the proposed decoration. Then, remove *all* decorations. If the program
> is still well-formed and produces the same observable behaviour, then
> the decoration did no affect the language semantic.

It depends if overloading based on pureness is allowed (muck like
const). For instance, functions like acos() affect the global errno
variable. There you could have two prorotpyes:

double acos(double);
double acos(double) pure;

If you can only call pure functions from within pure functions (like
const methods), then the two can potentially produce different
retults:

double foo(double d) pure {return acos(d);}
acos(0);
foo(-10);
if(errno == EDOM)
...

Another point is that pure functions of compile-time constants could
result in compile time constants, which would be useful.

Finally, if it really helps correctness and optimization, then is it
worth it? With many programs, you could remove all consts, and still
get the same results, bit I find them useful. Likewise, inline should
not be necessary either.


-Ed


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 4, 2:28 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
> Zara ha scritto:
>
> > In fact, I am almost certain that these sets of restrictions (or at
> > least, part of them) do change language semantic.
>
> There's a quick test to discern that. Write a well-formed program with
> the proposed decoration. Then, remove *all* decorations. If the program
> is still well-formed and produces the same observable behaviour, then
> the decoration did no affect the language semantic.

To define a well formed program with the new pure qualifier involves
adding to the language semantic. So, all old well formed programs are
still well formed, and their behavior is the same, but additional
language semantic rules are required for the new specifier. So, one
can say, as Zara ha scritto did, that an addition is a change, or you
can go with what Ganesh said, that an addition is not a change (to
current semantics).


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Edward Rosten ha scritto:
> On Sep 4, 3:28 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
> wrote:
>> Zara ha scritto:
>>
>>> In fact, I am almost certain that these sets of restrictions (or at
>>> least, part of them) do change language semantic.
>> There's a quick test to discern that. Write a well-formed program with
>> the proposed decoration. Then, remove *all* decorations. If the program
>> is still well-formed and produces the same observable behaviour, then
>> the decoration did no affect the language semantic.
>
> It depends if overloading based on pureness is allowed (muck like
> const). For instance, functions like acos() affect the global errno
> variable. There you could have two prorotpyes:
>
> double acos(double);
> double acos(double) pure;

In this case by removing "pure" the program would be ill-formed because
it would have two definitions of acos() and thus it would be violating
ODR. When I said "remove all decorations" I really meant *all of them*:
both in the program and in the library. If the program is no longer
well-formed after the removal then the result of the "quick test" is:
the proposal affects semantic, which would be correct if I understand
your point.

> If you can only call pure functions from within pure functions (like
> const methods), then the two can potentially produce different
> retults:
>
> double foo(double d) pure {return acos(d);}
> acos(0);
> foo(-10);
> if(errno == EDOM)
> ...

If the program were well-formed (and we saw that it isn't), a change in
errno is a change in the observable behaviour. Even in this case the
"quick test" would provide the correct answer.

> Another point is that pure functions of compile-time constants could
> result in compile time constants, which would be useful.

This is already been addressed by constexpr.

> Finally, if it really helps correctness and optimization, then is it
> worth it? With many programs, you could remove all consts, and still
> get the same results, bit I find them useful. Likewise, inline should
> not be necessary either.

I believe your opinion about const is very debatable.

Anyway, the situation is very simple: regardless of the usefulness of
this feature, it's too late to have it into C++0x. This means that we
have 5+ years to think about it and get it straight...

Just my opinion,

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 3, 8:44 am, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
> Zara ha scritto:
>
>
>
> > Proposal for the adaptation of some ideas from functional programming
> > in order to improve C++ language.
>
> I'm sorry to sound dismissive, but it seems to me that most of this
> proposal can either be achieved with constexpr or be automatically
> detected by the compiler. In the rest of the cases, your "no side
> effect" concept is just an optimization hint that doesn't change the
> language semantic, so it would be better handled using an attribute
> rather than a new syntax. Or am I missing something?
>
> Ganesh
>
Just consider having a complex data type as a template non-type(value)
parameter:

template<mytype value>...

regards,
FM.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

terminator ha scritto:
> On Sep 3, 8:44 am, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
> wrote:
>> Zara ha scritto:
>>
>>
>>
>>> Proposal for the adaptation of some ideas from functional programming
>>> in order to improve C++ language.
>> I'm sorry to sound dismissive, but it seems to me that most of this
>> proposal can either be achieved with constexpr or be automatically
>> detected by the compiler. In the rest of the cases, your "no side
>> effect" concept is just an optimization hint that doesn't change the
>> language semantic, so it would be better handled using an attribute
>> rather than a new syntax. Or am I missing something?
>>
>> Ganesh
>>
> Just consider having a complex data type as a template non-type(value)
> parameter:
>
> template<mytype value>...
>

Sorry, but I don't get your point.

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

JoshuaMaurice@gmail.com wrote:
> On Sep 4, 2:28 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
> wrote:
>> Zara ha scritto:
>>
>>> In fact, I am almost certain that these sets of restrictions (or at
>>> least, part of them) do change language semantic.
>> There's a quick test to discern that. Write a well-formed program with
>> the proposed decoration. Then, remove *all* decorations. If the program
>> is still well-formed and produces the same observable behaviour, then
>> the decoration did no affect the language semantic.
>
> To define a well formed program with the new pure qualifier involves
> adding to the language semantic. So, all old well formed programs are
> still well formed, and their behavior is the same, but additional
> language semantic rules are required for the new specifier. So, one
> can say, as Zara ha scritto did, that an addition is a change, or you
> can go with what Ganesh said, that an addition is not a change (to
> current semantics).

As indeed C++ has quite a few type-dependent semantics (overloading
being the most obvious case) I'd also think that addition of pure
function would imbue C++ with new semantics. Existing programs not using
the feature should work as expected, so probably there's not any change
per se, at least not of the breaking kind.


Andrei Wrote

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 5, 1:38 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
> terminator ha scritto:
>
>
>
> > On Sep 3, 8:44 am, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
> > wrote:
> >> Zara ha scritto:
>
> >>> Proposal for the adaptation of some ideas from functional programming
> >>> in order to improve C++ language.
> >> I'm sorry to sound dismissive, but it seems to me that most of this
> >> proposal can either be achieved with constexpr or be automatically
> >> detected by the compiler. In the rest of the cases, your "no side
> >> effect" concept is just an optimization hint that doesn't change the
> >> language semantic, so it would be better handled using an attribute
> >> rather than a new syntax. Or am I missing something?
>
> >> Ganesh
>
> > Just consider having a complex data type as a template non-type(value)
> > parameter:
>
> > template<mytype value>...
>
> Sorry, but I don't get your point.
>

template paramters are bound to have internal linkage so the above
example cant compile unless 'mytype' is an aliase for some numeric
type.but if the value needed can be evaluated at compile time then it
is possible to have data of any type as the none-type parameter of a
template .


regards,
FM.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 4, 10:20 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:

> In this case by removing "pure" the program would be ill-formed because
> it would have two definitions of acos() and thus it would be violating
> ODR. When I said "remove all decorations" I really meant *all of them*:
> both in the program and in the library. If the program is no longer
> well-formed after the removal then the result of the "quick test" is:
> the proposal affects semantic, which would be correct if I understand
> your point.

Bit of a thinko, there. Yes, it would affect semantics, as I put it.
One could make it not affect semantics, I suppose. If you disallowed
pure functions to call non-pure ones. That would make it essentially
enforce constraints, but programs which compile without pure should
behave the same.


> > Finally, if it really helps correctness and optimization, then is it
> > worth it? With many programs, you could remove all consts, and still
> > get the same results, bit I find them useful. Likewise, inline should
> > not be necessary either.
>
> I believe your opinion about const is very debatable.

I'm curious about this. I understand that it is possible to write
programs where void fooclass::method(); does something significantly
different to void fooclas::method() const; much like you could cause
operator+ to multiply classes of type Rational.

I can't think of an instance of where removing all consts (from a
program which compiles with them) would make a difference to a
reasonable program.

-Ed

--
(You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

/d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

terminator ha scritto:
> On Sep 5, 1:38 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
> wrote:
>> terminator ha scritto:
>>
>>
>>
>>> On Sep 3, 8:44 am, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
>>> wrote:
>>>> Zara ha scritto:
>>>>> Proposal for the adaptation of some ideas from functional programming
>>>>> in order to improve C++ language.
>>>> I'm sorry to sound dismissive, but it seems to me that most of this
>>>> proposal can either be achieved with constexpr or be automatically
>>>> detected by the compiler. In the rest of the cases, your "no side
>>>> effect" concept is just an optimization hint that doesn't change the
>>>> language semantic, so it would be better handled using an attribute
>>>> rather than a new syntax. Or am I missing something?
>>>> Ganesh
>>> Just consider having a complex data type as a template non-type(value)
>>> parameter:
>>> template<mytype value>...
>> Sorry, but I don't get your point.
>>
>
> template paramters are bound to have internal linkage so the above
> example cant compile unless 'mytype' is an aliase for some numeric
> type.but if the value needed can be evaluated at compile time then it
> is possible to have data of any type as the none-type parameter of a
> template .
>

Currently the allowed types for a non-type template parameter are listed
in 14.1/4:

— integral or enumeration type,
— pointer to object or pointer to function,
— reference to object or reference to function,
— pointer to member.

This list hasn't been modified in the current draft for C++0x, despite
the introduction of constexpr which allows any "literal type" to be
evaluated at compile time.

So:

1) we don't need this proposal to allow generic types in non-type
template arguments, constexpr expresses the required semantic more
precisely and we already have it in the draft. BTW, we won't have "any
type" in any case, we might have "any literal type" though

2) the fact that the committee has not yet included literal types in the
list of allowed types could be an indication that there are other
difficulties that need to be addressed, i.e.: compile-time computation
may not be enough

HTH,

Ganesh


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Edward Rosten ha scritto:
> On Sep 4, 10:20 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
>
>>> Finally, if it really helps correctness and optimization, then is it
>>> worth it? With many programs, you could remove all consts, and still
>>> get the same results, bit I find them useful. Likewise, inline should
>>> not be necessary either.
>> I believe your opinion about const is very debatable.
>
> I'm curious about this. I understand that it is possible to write
> programs where void fooclass::method(); does something significantly
> different to void fooclas::method() const; much like you could cause
> operator+ to multiply classes of type Rational.
>
> I can't think of an instance of where removing all consts (from a
> program which compiles with them) would make a difference to a
> reasonable program.
>

You can write code without const, but you can't just remove all consts
from a program that uses them. For example, if a method comes with both
a const and a non-const version, by simply removing the const keyword
the code will become ill-formed because you would get two definitions
for the same method.

Anyway, the biggest semantic obstacle is this:

struct A {};
A f();
void g(const A&);

int main()
{
g(f());
}

if you remove the "const" the code will be ill-formed because a
temporary cannot be bound to a non-const reference.

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]