Hello,
Dick Hendrickson wrote:
>
> I like the idea of some sort of READONLY attribute for module variables
> and even tried to slip it past J3 a couple of times. But, I think there
> are 2 serious problems with them that I haven't seen addressed here.
>
> I don't think we can A) write a reasonable set of rules for then, and
> B) enforce the rules.
>
<snip discussion of A) & B)>
>
> So, we'd ultimately rely on the user not doing anything bad to the READONLY
> variables. True, the compiler can detect some user errors, but not all of
> them. From the posts of Peter and Dan I have the impression that they see
> this as a guaranteed safety feature. I don't see how it can be.
>
I don't think that READONLY, however spelled, can prevent the malicious
and/or sloppy user from ever making "bad code".
I do think READONLY can make the programmer's intentions clear.
This feature assists the programmer understand the code, and can
help the user of a module understand the writer's intentions.
I also think there's a benefit when one is parallelizing code,
to both the compiler and the programmer. My motto, when parallelizing
code is "Mind the memory, and the code will mind itself". Thus,
features of the language which make the intentions of memory usage
more easily seen are helpful.
I would be happy with whatever "protection" INTENT( IN) gives
be the effect of READONLY.
> So, the bottom line is that I don't see how to write a consistent set of
> rules that don't have seemingly arbitrary restrictions and still allow
> the compiler to guarantee safety.
Well, if I wanted _guarantees_, I wouldn't be a programmer. ;-)
But I can use all the help I can get.
Dick's points, however sobering, are well taken. There are subtleties.
Maybe this is an F2K + 1 feature after all.
>
> Dick Hendrickson
--
Cheers!
Dan Nagle [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|