Some surprising results

[the blind squirrel]

Here is a snippet from a class I am trying to make void safe:

     set_attributes_using_font_constants
             -- Set all attributes relying on font constants to the
current
             -- value of the associated constant.
         local
             f: detachable EV_FONT
             t: detachable TUPLE
         do
         ...
            loop
                 f := font_constant_retrieval_functions.i_th
(font_constant_set_procedures.index).last_result
                 create t.default_create
                 t.put (f, 1)    -- surprise #1
                 font_constant_set_procedures.item.call (t) -- surprise
#2
                 t := Void      -- surprise #3

When this compiled, with complete void safety turned on, the compiler
allowed the instructions at 'surprise #1' and 'surprise #3', but threw a
VUAR error, 'Non-conforming actual argument in feature call', at
surprise #2, for the argument 't'. ('call' is from class PROCEDURE and
is declared as 'call (args: detachable OPEN_ARGS)'.)

What surprised me about #1 is that the compiler allowed the call to
'put' outside a CAP, on an entity declared to be detachable. Surprise #2
confirmed that, apparently, the compiler has converted 't' to an
attached type. But it passed the assignment to Void at surprise
#3--presumably 't' is restored to a detachable type at that point.

I don't remember reading anything in the documentation about
detachable-type entities being converted to attached, by implication
(the 'create' instruction) or otherwise. It's true that 't' is properly
set at the time 'put' is called. Does that mean that 't' has been
transformed to an attached type entity? If so, then why is it allowed to
revert to detachable?

I also don't understand why calling a routine whose formal argument is
detachable, with an actual argument that is attached, is an error.
Preventing the opposite--formal argument attached, actual argument
detachable--makes sense outside a CAP, but this to me is analogous to
assigning a detachable target to an attached source.

I'd really appreciate being set straight about what the compiler did
here.



[Non-text portions of this message have been removed]

[Peter Horan]

David Jenkins wrote:
> Here is a snippet from a class I am trying to make void safe:

> set_attributes_using_font_constants
>         -- Set all attributes relying on font constants to the current
>         -- value of the associated constant.
>      local
>         f: detachable EV_FONT
>         t: detachable TUPLE
>     do
>         ...
>         loop
>            f := font_constant_retrieval_functions.i_th
>                 (font_constant_set_procedures.index).last_result
>            create t.default_create
>            t.put (f, 1) -- surprise #1
>            font_constant_set_procedures.item.call (t) -- surprise #2
>            t := Void -- surprise #3

f and t are local variables. No one can interfere with them.

After creation, `t' is guaranteed to exist - no side effect can interfere. It is a CAP, I think. So, no surprise at #1. And because `t' is detachable, assignment of Void is allowed - no surprise at #3.

As for surprise #2, my guess is that because the instruction is not immediately after create, `t' could be Void. But, I am not sure about this reasoning. What does the compiler say if you do 'item.call(Void)'?
--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation

[the blind squirrel]

I had the same reaction to surprise #1: it is a new CAP. The compiler
seems to be saying that a local detachable variable, properly set at the
point of a call, makes the call void safe. (Does that mean we've
discovered a 2nd CAP? And does that make us famous?)

>What does the compiler say if you do 'item.call(Void)'?

The compiler is happy with that. Surprise #2 was my mistake, I know now
what I did wrong.

Surprise #3 shouldn't have been a surprise either, you're right. I guess
the only true surprise was the compiler allowing a call to a detachable
entity outside the one official CAP.

--- In [hidden email], Peter Horan <peter.horan@...>
wrote:It's also happy with this little one-class application, compiled
(I'm pretty sure) with the same options (complete void safety, full
class checking, types attached by default):
>
> David Jenkins wrote:
> > Here is a snippet from a class I am trying to make void safe:
>
> > set_attributes_using_font_constants
> >         -- Set all attributes relying on font constants to the
current

> >         -- value of the associated constant.
> >      local
> >         f: detachable EV_FONT
> >         t: detachable TUPLE
> >     do
> >         ...
> >         loop
> >            f := font_constant_retrieval_functions.i_th
> >                 (font_constant_set_procedures.index).last_result
> >            create t.default_create
> >            t.put (f, 1) -- surprise #1
> >            font_constant_set_procedures.item.call (t) -- surprise #2
> >            t := Void -- surprise #3
>
> f and t are local variables. No one can interfere with them.
>
> After creation, `t' is guaranteed to exist - no side effect can

interfere. It is a CAP, I think. So, no surprise at #1. And because `t'
is detachable, assignment of Void is allowed - no surprise at #3.
>
> As for surprise #2, my guess is that because the instruction is not
immediately after create, `t' could be Void. But, I am not sure about
this reasoning. What does the compiler say if you do 'item.call(Void)'?
> --
> Peter Horan             Faculty of Science and Technology
> peter@...     Deakin University
> [phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
> [phone] (Mobile)
>
> -- The Eiffel guarantee: From specification to implementation
>