(j3.2006) Frustrating consequence of F2003 allocation semantics

[Tom Clune]

On Apr 15, 2015, at 3:34 AM, Damian Rouson <damian at sourceryinstitute.org> wrote:

> 
> 
>> On Apr 14, 2015, at 8:41 AM, Craig Dedo CAPM <craig at ctdedo.com> wrote:
>> 
>> Everyone:
>>             It appears to me that the only solution would be to place the reallocation semantics of allocatable arrays into the hands of the developer, rather than being specified by the standard.  Thus, when declaring an allocatable array, the developer would have the option of specifying whether reallocation was automatic or it needed to be done explicitly. This would be another attribute. 
> 
> I would argue that the (re)allocation semantics of allocatable arrays is already in the hands of the developer.  Automatic (re)allocation can be turned off by make the left-hand side of the assignments (whole) array sections: 
> 
> buffer(:) = A
> buffer(:) = C
> 
> Admittedly one could impact the source code less by adding an attribute that precludes automatic (re)allocation at the point of declaration, but an unintended side effect is that it might also obscure the programmers? intention in long scoping units where the assignment and declaration are separated by a large number of lines.  I?d much rather see the programmers? intentions at each point of assignment. 

I tend to agree.   Though in a world where we all used IDE?s such attributes should not be ?far away? in practice.  We should be able to hover over ?buffer? and see ?oh - it does not automatically reallocate?.   Or alternatively hover over an expression and have a window pop on the side ?Warning possible reallocation on assignment.?  (Which we will quickly get sick of and start requesting IDE switches to deactivate that warning.)    

> 
>>  
> 
>>             Another related need would be the provision of an inquiry intrinsic function that would develop a list of the names of all pointers that point to a particular object.  A somewhat whimsical name could be, What_Pointers_are_Pointing_at_Me().
> 
> It could be argued that the real problem in the example is the use of raw pointers. Some object-oriented programming experts would argue that all pointers should be wrapped in a class that provides reference counting (see http://dl.acm.org/citation.cfm?id=1985786 and http://prod.sandia.gov/techlib/access-control.cgi/2010/102234.pdf).   Such a class could be defined by the end user or provided by the language.  In either case, it would presumably be straightforward to also provide the What_Pointers_are_Pointing_at_Me() function.

Well ? if you are talking about _strings_ that name those pointers, that would not be possible in practice due to nested data structures.  If you are talking about just the pointers,   it would be an amusing list - they would all be the ?same? in any sense detectable by Fortran. 

I think by the time a developer thought to check such a list (at run time?), she could have simply used ?buffer(:) = ??

I suspect you both are thinking of the former (string name), but not only does it imply dark corners that are problematic, it would be a big stretch for the language to provide that degree of introspection.   (Though - I would love to have a standard mechanism to associate a name-string with any variable/procedure - probably with a few associated intrinsics for stripping of modules, name mangling and so on.  Not holding my breath for that though.)

Cheers,

- Tom

> 
> Damian
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
Head ASTG,Code 606
NASA GSFC		
MS 610.8 B33-C128
Greenbelt, MD 20771
301-286-4635









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150415/2978e362/attachment-0001.html