From: Ron Shepard on
In article <1jir427.k3gugd1tcivoyN%nospam(a)see.signature>,
nospam(a)see.signature (Richard Maine) wrote:

>
> > Also, just to be sure, for allocatable components of an array of
> > structure, you have to separately (with a loop) allocate each one?
>
> Yes. Well, unless you are using the f2003 allocate-on-assignment thing,
> which would also apply to assignment of the whole thing.

Did you guys see my post with the elemental function? That does avoid
the explicit loop (although it is still there implicitly, of course).
Is it legal to do that?

$.02 -Ron Shepard
From: Richard Maine on
Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote:

> In article <1jir427.k3gugd1tcivoyN%nospam(a)see.signature>,
> nospam(a)see.signature (Richard Maine) wrote:
>
> >
> > > Also, just to be sure, for allocatable components of an array of
> > > structure, you have to separately (with a loop) allocate each one?
> >
> > Yes. Well, unless you are using the f2003 allocate-on-assignment thing,
> > which would also apply to assignment of the whole thing.
>
> Did you guys see my post with the elemental function? That does avoid
> the explicit loop (although it is still there implicitly, of course).
> Is it legal to do that?

I saw your elemental subroutine. I assume that's what you are referring
to, but I'm being a bit picky as I just finished reading replies in a
different thread where subroutine versus function was an important
distinction.

I think it is ok, but I didn't drag out the standard to check every one
of the restrictions. (That's why I didn't reply before). I don't
off-hand see why it wouldn't be ok.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Ron Shepard on
In article <1jiskqv.12niejx16nsw6qN%nospam(a)see.signature>,
nospam(a)see.signature (Richard Maine) wrote:

> Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote:
>
> > In article <1jir427.k3gugd1tcivoyN%nospam(a)see.signature>,
> > nospam(a)see.signature (Richard Maine) wrote:
> >
> > >
> > > > Also, just to be sure, for allocatable components of an array of
> > > > structure, you have to separately (with a loop) allocate each one?
> > >
> > > Yes. Well, unless you are using the f2003 allocate-on-assignment thing,
> > > which would also apply to assignment of the whole thing.
> >
> > Did you guys see my post with the elemental function? That does avoid
> > the explicit loop (although it is still there implicitly, of course).
> > Is it legal to do that?
>
> I saw your elemental subroutine.

Yes, it was a subroutine, not a function. Sorry for the confusion.

> I assume that's what you are referring
> to, but I'm being a bit picky as I just finished reading replies in a
> different thread where subroutine versus function was an important
> distinction.
>
> I think it is ok, but I didn't drag out the standard to check every one
> of the restrictions. (That's why I didn't reply before). I don't
> off-hand see why it wouldn't be ok.

My main question is whether allocate() is an allowed side effect. The
code I posted does compile and run (apparently) correctly on a couple of
compilers, but that is not a definitive test of legality.

$.02 -Ron Shepard
From: Richard Maine on
Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote:

[about elemental procedures]
> My main question is whether allocate() is an allowed side effect.

I understood that was the question. Ok, I'll drag out the standard....

I see nothing that hints at a prohibition against that. Admitedly, I
skimmed it pretty quickly and with bias beforehand in that I didn't
expect to find anything.

It is perhaps important to realize that, although we might slopily talk
about pure procedures as prohibitting side effects, that's not the way
the standard specifies it. The standard gives a very concrete list of
things that are prohibitted. They are all quite specific syntactic
things rather than vague terms like "side effect."

After all, it can be (and has been) argued that consuming CPU time is a
detectable side effect, so if pure procedures prohibitted all side
effects, we wouldn't need to waste much time debating them. Allocation
is a side effect in a simillar sense. Doing allocation in a pure
procedure could make some apparently unrelated allocation elsewhere fail
because of insufficient memory or some such thing.

But it isn't on the list. Most of the things on the list have to do with
I/O in some sense or with changing the values or status of variables
that aren't "obviously" expected to change based on the interface.
(THat's my descriptopn - not the standard's). Allocation certainly
changes the value or status of a variable, but we are talking an
intent(inout) argument here, and those get a "pass" from those rules
because they are "obviously" expected to change based on th einterface.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
> Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote:

> [about elemental procedures]
>> My main question is whether allocate() is an allowed side effect.

> I understood that was the question. Ok, I'll drag out the standard....

> I see nothing that hints at a prohibition against that. Admitedly, I
> skimmed it pretty quickly and with bias beforehand in that I didn't
> expect to find anything.

> It is perhaps important to realize that, although we might slopily talk
> about pure procedures as prohibitting side effects, that's not the way
> the standard specifies it. The standard gives a very concrete list of
> things that are prohibitted. They are all quite specific syntactic
> things rather than vague terms like "side effect."

As I have been writing, though, one reason for the limitations is
that they might be processed in parallel.

> After all, it can be (and has been) argued that consuming CPU time is a
> detectable side effect, so if pure procedures prohibitted all side
> effects, we wouldn't need to waste much time debating them. Allocation
> is a side effect in a simillar sense. Doing allocation in a pure
> procedure could make some apparently unrelated allocation elsewhere fail
> because of insufficient memory or some such thing.

Doing allocation while parallel processing would complicate it,
but it shouldn't be so hard to do. It does seem like a reasonable
side effect. But then again, I might have thought that STOP or
printing error messages would also be reasonable side effects, but
the standard doesn't seem to agree.

> But it isn't on the list. Most of the things on the list have to do with
> I/O in some sense or with changing the values or status of variables
> that aren't "obviously" expected to change based on the interface.
> (THat's my descriptopn - not the standard's). Allocation certainly
> changes the value or status of a variable, but we are talking an
> intent(inout) argument here, and those get a "pass" from those rules
> because they are "obviously" expected to change based on th einterface.

It isn't the argument side effects that I would consider, but the
side effects in terms of the allocated memory. Consider that some
might succeed and some might fail. I suppose it is an implementation
detail, but it might be that one should allocate them all before
doing anything else.

-- glen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: reshape efficiency
Next: parameter incosistency