www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Const on the call site?

reply Robert Fraser <fraserofthenight gmail.com> writes:
Well, between episodes of Veronica Mars, I thought I'd visit Digital Mars with
an idea that just popped into my head. I understand Walter has solved the const
thing, and the conversation has been done to death, so this isn't a serious
proposal as it is more a mental language-design exercise (it wouldn't work for
D anyway, since there's no way to use this info for functional programming or
optimization, which are the goals of the new const regime).

What about requiring constants be declared on the call site rather than at the
function declaration? The compiler then checks the function and issues an error
if the value isn't const. That way, library writers wouldn't have to worry at
all about const, so only the people ho WANTED to use const in their code could.
It's not part of the interface of a function, but for most functions, it's the
caller who knows whether or not the data SHOULD be constant, and that way the
caller can see automatically that a function changes something, and find out
where.

Thoughts?
Nov 14 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Robert Fraser wrote:

 Well, between episodes of Veronica Mars, I thought I'd visit Digital
 Mars with an idea that just popped into my head. I understand Walter
 has solved the const thing, and the conversation has been done to
 death, so this isn't a serious proposal as it is more a mental
 language-design exercise (it wouldn't work for D anyway, since
 there's no way to use this info for functional programming or
 optimization, which are the goals of the new const regime).
 
 What about requiring constants be declared on the call site rather
 than at the function declaration? The compiler then checks the
 function and issues an error if the value isn't const. That way,
 library writers wouldn't have to worry at all about const, so only
 the people ho WANTED to use const in their code could. It's not part
 of the interface of a function, but for most functions, it's the
 caller who knows whether or not the data SHOULD be constant, and that
 way the caller can see automatically that a function changes
 something, and find out where.
 
 Thoughts?


So the contract would be from caller to callee and would read "you can 
have this data if you promise not to modify it" as opposed to callee to 
caller "I promise not to modify this data".

Interesting... however I don't think I like it.

Say you have a piece of data which should not be modified, no matter 
what functions it's passed to, etc.  A typical const system supports 
this idea, i.e. you would say:

const Foo foo;

No matter what you did with it, where you passed it, the compiler would 
hopefully catch you trying to modify it and complain.

This new idea doesn't support that concept in as robust a manner, eg.

Foo foo;

bar(const foo);
baz(foo);  //oops forgot to put const here.

There are more "points of failure", places where you could forget to 
enforce it.

Regan
Nov 14 2007
prev sibling next sibling parent 0ffh <frank frankhirsch.bogus.net> writes:
Robert Fraser wrote:

 Thoughts?


I think it's possible, if you have all source code of
the project you are compiling.
Then again, object files could be annotated to show
which functions do not try to change which parameters.
So it would be possible, as long as you do not try
to use any libs which are do not support this kind of
meta-information. Including OS calls, which is kind
of a bummer. But then again, you could wrap them in
functions that use const in their declaration again
to indicate that even while the compiler is not able
to follow the code from there on, the coder guarantees
that the thing will not be changed...

So in principle, I think, the approach is viable.

Regards, Frank
Nov 14 2007
prev sibling next sibling parent Gilles G. <schaouette free.fr> writes:
We have similar ideas. See:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=61562

Robert Fraser Wrote:


 Well, between episodes of Veronica Mars, I thought I'd visit Digital Mars with
an idea that just popped into my head. I understand Walter has solved the const
thing, and the conversation has been done to death, so this isn't a serious
proposal as it is more a mental language-design exercise (it wouldn't work for
D anyway, since there's no way to use this info for functional programming or
optimization, which are the goals of the new const regime).
 
 What about requiring constants be declared on the call site rather than at the
function declaration? The compiler then checks the function and issues an error
if the value isn't const. That way, library writers wouldn't have to worry at
all about const, so only the people ho WANTED to use const in their code could.
It's not part of the interface of a function, but for most functions, it's the
caller who knows whether or not the data SHOULD be constant, and that way the
caller can see automatically that a function changes something, and find out
where.
 
 Thoughts?
Nov 14 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:

 What about requiring constants be declared on the call site rather
 than at the function declaration? The compiler then checks the
 function and issues an error if the value isn't const. That way,
 library writers wouldn't have to worry at all about const, so only
 the people ho WANTED to use const in their code could. It's not part
 of the interface of a function, but for most functions, it's the
 caller who knows whether or not the data SHOULD be constant, and that
 way the caller can see automatically that a function changes
 something, and find out where.


This comes under the heading of 'interprocedural analysis', and it 
requires that the compiler have access to all the source for all the 
functions (in fact, 100% of the source to the entire program). Such 
makes it impossible to have opaque interfaces or anything that 
recursively depends on opaque interfaces.

This would include anything that calls anything that depends on the C 
runtime library (or any other C library). The compiler would have to 
understand every language used for every part of the program.
Nov 14 2007
parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:

 Robert Fraser wrote:
 

 What about requiring constants be declared on the call site rather
 than at the function declaration? The compiler then checks the
 function and issues an error if the value isn't const. That way,
 library writers wouldn't have to worry at all about const, so only
 the people ho WANTED to use const in their code could. It's not part
 of the interface of a function, but for most functions, it's the
 caller who knows whether or not the data SHOULD be constant, and that
 way the caller can see automatically that a function changes
 something, and find out where.


 
 
 This comes under the heading of 'interprocedural analysis', and it 
 requires that the compiler have access to all the source for all the 
 functions (in fact, 100% of the source to the entire program). Such 
 makes it impossible to have opaque interfaces or anything that 
 recursively depends on opaque interfaces.
 
 This would include anything that calls anything that depends on the C 
 runtime library (or any other C library). The compiler would have to 
 understand every language used for every part of the program.


Just hypothetically, what if the name mangling already contained a bit 
to signify whether the function has No Side Effects?

Thus the compiler would know, even if the library souce is absent.

I can't help thinking that this single thing would give most of the 
benefits now sought with (variously elaborate) constness schemes, while 
being conceptually trivial, easy to implement, and robust within its domain.


When compiling a new function, it IMHO is easy for the compiler to 
notice whether this new function has any side effects. And if it does, 
then show that in the mangled name.

We have essentially two design choices here: either a single tag for 
Entirely Pure vs not, or a more comprehensive tagging scheme. The latter 
choice comprises a separate tag for each of the arguments, and one extra 
tag for Has Side Effects Outside Its Arguments. (As in changing globals 
or whatever.)

(I'd assume the programmer is interested in the argument tags, while the 
compiler is also interested in the side effects tag for optimizing etc.)

IMHO, the programmer should assume that a function doesn't change its 
arguments unless specifically stated. Therefore a normal function call

   foo(x);

should be taken as assuming x not to change. For the situation where the 
programmer wants to allow x to change, he sould write

   foo(var x);

Of course, we will use six months upon deciding which particular keyword 
to use here instead of "var". (I wrote "var" here just arbitrarily, no 
problem.)

If you use foo(x) where foo actually is a function that does 
(potentially) change x, then you'd get a compiler error.

------

I'd actually love this to be in D -- and remain, even if a Fancy and 
Comprehensive Solution is invented for the Const Problem one day, too.

------

If foo changes y via, say, x.addressOfY, then foo(var x) should be 
written, because x is used to get at whatever is changed.

C routines called should implicitly be considered as changing any 
variables that are not passed by value.

As with any other thing in D, this is not deliberate-suicide-proof, but 
I think this is Adequate.
Nov 15 2007
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:


 Robert Fraser wrote:

 What about requiring constants be declared on the call site rather
 than at the function declaration? The compiler then checks the
 function and issues an error if the value isn't const. That way,
 library writers wouldn't have to worry at all about const, so only
 the people ho WANTED to use const in their code could. It's not part
 of the interface of a function, but for most functions, it's the
 caller who knows whether or not the data SHOULD be constant, and that
 way the caller can see automatically that a function changes
 something, and find out where.


 
 This comes under the heading of 'interprocedural analysis', and it 
 requires that the compiler have access to all the source for all the 
 functions (in fact, 100% of the source to the entire program). Such 
 makes it impossible to have opaque interfaces or anything that 
 recursively depends on opaque interfaces.
 
 This would include anything that calls anything that depends on the C 
 runtime library (or any other C library). The compiler would have to 
 understand every language used for every part of the program.


I never thought of it in that way; indeed, it would be impossible for a
compiled language like D. Might make an interesting feature for a scripting
language, though.
Nov 14 2007