View mode: basic / threaded / horizontal-split · Log in · Help
September 04, 2012
scope for array parameters
To make functions definitions more expressive and give the compiler more 
information to optimize I propose to make array function parameters 
extendable with 'scope' such as follows:

size_t find(scope float[] haystack, float needle){ ... }

This would give the compiler the information that the array haystack 
only has to be valid as long as the scope of the function find is valid. 
As soon as the function scope is left, the array does not need to be 
valid any more. This would greatly help when programming without a GC to 
know, if the array one passes to the function will be saved internally 
or if it only needs to be valid for the duration in which the function 
is executed. Also it would allow the compiler to optimize array literals 
such as:

find([1,2,3,4,5], 5)

The function call would not allocate on the heap, but would allocate the 
array literal on the stack, as the compiler knows that is only has to be 
valid for the scope of find.

Passing a scope array to another function which does not have the scope 
annotation should be an error. Assining a a scope array to a non local 
variable should be an error too. You could go really fancy on checking 
scoped function parameters but for a start simple rules should be enough.

The same could be done with references and pointers. The purpose of this 
would be to allow the compiler to do more static checking on the usage 
of the passed arguments and make the function definitions contain 
information if the passed references will be saved internally or not.

I do understand that non-gc programming is not considered often for the 
D-Programming Language, but it would be nice if this idea does not get 
ignored completely.

What do you think about this idea?

Kind Regards
Benjamin Thaut
September 04, 2012
Re: scope for array parameters
On 04-09-2012 22:13, Benjamin Thaut wrote:
> To make functions definitions more expressive and give the compiler more
> information to optimize I propose to make array function parameters
> extendable with 'scope' such as follows:
>
> size_t find(scope float[] haystack, float needle){ ... }
>
> This would give the compiler the information that the array haystack
> only has to be valid as long as the scope of the function find is valid.
> As soon as the function scope is left, the array does not need to be
> valid any more. This would greatly help when programming without a GC to
> know, if the array one passes to the function will be saved internally
> or if it only needs to be valid for the duration in which the function
> is executed. Also it would allow the compiler to optimize array literals
> such as:
>
> find([1,2,3,4,5], 5)
>
> The function call would not allocate on the heap, but would allocate the
> array literal on the stack, as the compiler knows that is only has to be
> valid for the scope of find.
>
> Passing a scope array to another function which does not have the scope
> annotation should be an error. Assining a a scope array to a non local
> variable should be an error too. You could go really fancy on checking
> scoped function parameters but for a start simple rules should be enough.
>
> The same could be done with references and pointers. The purpose of this
> would be to allow the compiler to do more static checking on the usage
> of the passed arguments and make the function definitions contain
> information if the passed references will be saved internally or not.
>
> I do understand that non-gc programming is not considered often for the
> D-Programming Language, but it would be nice if this idea does not get
> ignored completely.
>
> What do you think about this idea?
>
> Kind Regards
> Benjamin Thaut

This is already what scope does today. See http://dlang.org/function.html:

"references in the parameter cannot be escaped (e.g. assigned to a 
global variable)"

It's just that the compiler doesn't actually enforce it fully.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
September 04, 2012
Re: scope for array parameters
Am 04.09.2012 22:18, schrieb Alex Rønne Petersen:
> On 04-09-2012 22:13, Benjamin Thaut wrote:
> This is already what scope does today. See http://dlang.org/function.html:
>
> "references in the parameter cannot be escaped (e.g. assigned to a
> global variable)"
>
> It's just that the compiler doesn't actually enforce it fully.
>

Does the compiler already use this information to optimize array literals?

Kind Regards
Benjamin Thaut
September 04, 2012
Re: scope for array parameters
On Tuesday, September 04, 2012 22:19:55 Benjamin Thaut wrote:
> Am 04.09.2012 22:18, schrieb Alex Rønne Petersen:
> > On 04-09-2012 22:13, Benjamin Thaut wrote:
> > This is already what scope does today. See http://dlang.org/function.html:
> > 
> > "references in the parameter cannot be escaped (e.g. assigned to a
> > global variable)"
> > 
> > It's just that the compiler doesn't actually enforce it fully.
> 
> Does the compiler already use this information to optimize array literals?

It had better not (I doubt that it does though). Unless scope is actually 
properly enforced, then you're going to have major bugs if you use scope and 
then escape references to that data anyway. And without the compiler checks, 
that _will_ happen (especially when some folks use in all over the place).

Once scope is properly enforced, then optimizing based on it would be great, 
but until it is, it's a _bad_ idea.

- Jonathan M Davis
September 04, 2012
Re: scope for array parameters
On Tuesday, September 04, 2012 22:13:44 Benjamin Thaut wrote:
> What do you think about this idea?

scope on function parameters is supposed to prevent any reference to that data 
escaping from the function. e.g. scope on a delegate would make it an error to 
assign that delegate to anything which could escape the function. It is my 
understanding that this is also supposed to include arrays such that if you 
mark an array parameter with scope, it should be illegal for any references to 
it (including slices of it or references to its elements) to escape the 
function, which _would_ allow compiler optimizations. But the compiler doesn't 
seem to properly check for much with regards to scope right now. A _lot_ of 
code is going to break once it does, particularly since some people seem to 
think that it's a good idea to use in (which is the same as const scope) 
everywhere.

- Jonathan M Davis
September 04, 2012
Re: scope for array parameters
Jonathan M Davis:

> Once scope is properly enforced, then optimizing based on it 
> would be great, but until it is, it's a _bad_ idea.

Today we use "in" often for function arguments, and it implies 
"scope". Surely some of those programs use the arguments wrongly, 
this means they probably sometime escape. So are those programs 
someday going to become compilation errors? For the "-property" 
and for the arguments of delegate/function pointers the idea of 
turning some code currently used in errors is failing...
Such things need to be implemented early in a language.

Bye,
bearophile
September 04, 2012
Re: scope for array parameters
On Tuesday, 4 September 2012 at 21:41:58 UTC, bearophile wrote:
> Jonathan M Davis:
>
>> Once scope is properly enforced, then optimizing based on it 
>> would be great, but until it is, it's a _bad_ idea.
>
> Today we use "in" often for function arguments, and it implies 
> "scope". Surely some of those programs use the arguments 
> wrongly, this means they probably sometime escape. So are those 
> programs someday going to become compilation errors?

Yep.

> Such things need to be implemented early in a language.

Yep.

It's very unfortunate because it puts us in a lose-lose 
situations where we can't fix the language without breaking 
people's code. I think the best course of action is to fix these 
things as soon as possible and get the problem out of the way.
September 04, 2012
Re: scope for array parameters
On Tuesday, September 04, 2012 23:57:24 Peter Alexander wrote:
> It's very unfortunate because it puts us in a lose-lose
> situations where we can't fix the language without breaking
> people's code. I think the best course of action is to fix these
> things as soon as possible and get the problem out of the way.

Indeed. The same goes for stuff like deprecating things that we've long said 
was going to be deprecated but hasn't yet been deprecated (e.g. delete). Lots 
of code is going to break when it happens, and the longer that we wait, the 
worse it's going to be. But until someone takes the time to fix it (and Walter 
is constantly busy on other things), it's not going to happen, which is 
obviously a big problem.

- Jonathan M Davis
September 04, 2012
Re: scope for array parameters
On Tuesday, September 04, 2012 23:42:33 bearophile wrote:
> Jonathan M Davis:
> > Once scope is properly enforced, then optimizing based on it
> > would be great, but until it is, it's a _bad_ idea.
> 
> Today we use "in" often for function arguments, and it implies
> "scope". Surely some of those programs use the arguments wrongly,
> this means they probably sometime escape. So are those programs
> someday going to become compilation errors? For the "-property"
> and for the arguments of delegate/function pointers the idea of
> turning some code currently used in errors is failing...
> Such things need to be implemented early in a language.

That's part of why I keep saying not to use in whenever it comes up. scope is 
very broken, so in is very broken. And honestly, given how often arrays are 
used in structs, I suspect that it's not at all uncommon for in to be used 
incorrectly.

I'd actually argue to _never_ to use in at this point. If you want const, then 
use const. If you want scope, then use scope. But using scope on anything 
which isn't checked properly by the compiler is just asking for it. You _will_ 
have code that breaks when scope is fixed. I believe that the only case that 
has _any_ protection at all with scope right now is delegates, which almost 
never should be const. So, using in makes little to no sense to me.

- Jonathan M Davis
September 04, 2012
Re: scope for array parameters
What does -property supposedly solve? It creates a horrid mess of 
brackets that ruin the elegance of UFCS code.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home