[Expert stuff] Revising the syntax of object test and attached type declarations

[Bertrand Meyer]

Hi,

This is a proposal for improving the object test mechanism. It has been
discussed briefly within the ECMA TC49-TG4 committee; we would be interested
in Eiffel Software user feedback. This is an individual request which does
not commit TG4; we will use the feedback to provide our own input to the
committee.

Another disclaimer: this is all expert stuff about a specific language
point; if you are not familiar with the intricate details of the attached
type (void safety) mechanism just ignore this discussion. There is
definitely a need for explanatory material on these topics, accessible to
non-experts; I intend to devote both my March and April EiffelWorld columns
to attached types and void safety, and be as pedagogic as I can. But the
present material is not for novices.

1. Rationale
------------

1.1 To facilitate the conversion of existing code to void safety.

1.2 As a particular subgoal of 1.1, to simplify the writing of cases in
which we are not casting to a particular type but only seizing the value of
an expression and binding it temporarily to a local for purposes of void
safety. In such cases we should not have to repeat the type.

1.3 To improve the readability of code using object test. This is in
particular an issue raised by Éric Bezault. it is of personal interest to me
for my work in teaching introductory programming. The existence of the
problem is confirmed by Eiffel Software's current conversion effort, which
results in more pervasive use of object tests than we thought, making it
essential that object test be more immediately understandable.

1.4 To be more in line with the rest of Eiffel syntax. In retrospect it
seems that we repeated earlier errors of introducing a symbol-based syntax,
such as !!, where keywords are more clear.

1.5 To address criticism of the mechanism as present in ISO/ECMA 367. This
goal also mitigates an obvious argument against the present proposal: that
it is inappropriate at the present stage to change a mechanism introduced
recently. As far as we know the only major use of object test so far is
within Eiffel Software, to adapt our libraries, and we are willing to
perform the change if TG4 endorses the new version.


2. Overview and examples
------------------------

The proposal retains the validity and semantics of object test as described
in ISO/ECMA 367 (and implemented), in particular the notions of object-test
local and scope. It changes the syntax to a keyword-oriented style, and adds
possibilities:
        - Do not specify a type.
        - Do not specify an object-test local.

Examples (here and below exp is an expression):

        attached exp as x: T -- [2.1]
                -- The complete form, replaces {x: T} exp

        attached exp as x -- [2.2]
                -- Bind only, no casting
                -- Previously would have been written {x: like exp} exp,
                -- or (if exp is of type T, and not a variable) {x: T} exp

        attached exp: T -- [2.3]
                -- Cast only, no binding

        attached exp -- [2.4]
                -- Equivalent to exp /= Void


Note that the two key cases are [2.1] and [2.2]. As discussed in section 3,
the
other two are more arguable; a limited version of the proposal which only
allows [2.1] or [2.2] retains its essential advantages.

3. Syntax
---------

Object_test = `attached' Expression [Object_test_local]
[Specific_type]
Object_test_local = `as' Identifier
Specific_type = ':' Type

4. Validity
-----------

VUOT remains unchanged.

5. Semantics
------------

In this specification, v is the value of the Expression, T the Specific_type
if given:

        - (Boolean) value of the expression: if T is given, whether v
          is attached to an object of type T; otherwise, whether v is
attached.

        - In addition, if the Object_test_local is given, it is bound to v
          for the duration of the scope's execution, as in the current
          specification.

6. Discussion
-------------

Form [2.3] is proposed for completeness. In Eiffel Software's code it does
not appear necessary; we are interested in opinions as to its usefulness.

Form [2.4] has the disadvantage that it is exactly equivalent to exp /=
Void, hence potentially confusing users as to what they should write. See
section 9 below.


7. Replacing attachment marks with keywords
--------------------------------------------

In line with the revision of object test syntax discussed in previous
sections, it seems appropriate to keywordize the syntax for declarations:

        7.1 Replace ? by `detachable' (new keyword)
        7.2 Replace ! by `attached' (keyword introduced by the changes in
previous sections)

`attached' in this role (like ! in the current syntax), are useful for the
transition period only, not in new code, and will go away as the entire
Eiffel code base is moved to void safety.

Examples:

        x: detachable T
                -- Instead of x: ? T
        x: attached T
                -- Instead of x: ! T


8. Proposed policy
------------------

Our current policy for release 6.4 of EiffelStudio (May 15, 2009) is to
implement
        2.1
        2.2
        2.3 (but not 2.4)
        7.1
        7.4

As usual the compiler will continue to support "old" syntax, i.e. everything
that is in ISO/ECMA 367: previous syntax for object test, ? and !. Also, we
will provide tools for automatic conversion from that old syntax to the new
one.

The reason for not implementing 2.4 (`attached x' with no further
qualification) is explained in section 9 next. Obviously 2.4 is trivial to
implement once the rest is done, so that decision can easily be reversed.

9. Getting rid of "Void"?
-------------------------

If we accepted 2.4, the use of plain `attached x', then this notation would
be synonymous with `x /= Void'. In Eiffel we don't like to have two equally
acceptable ways of writing something. Some have suggested that we should get
rid of the Void value altogether. (Again, this would be a language decision,
not a compiler incompatibility -- the compiler would continue to support the
old style for a long time, and offer conversion tools.) This approach would
require introducing a new instruction

        detach x

which makes x void, replacing `x := Void'. This change introduces one more
new keyword, `detach'. It leaves open the question of how two handle the
following two cases expressed with current conventions:

        9.1 - f (Void) -- Passing a void value to a routine
        9.2 - x.a := Void -- If a has an associated assigner
command

9.2 can probably be addressed by allowing `detach x.a' if `a' is detachable
and has an associated assigner command with the right signature. For 9.2
there seems to be no other solution than to force introduction of a
detachable local variable x and use of f (x), where x has not been
initialized explicitly, or is set through `detach x'. There have been
objections to this style since f (Void) appears quite often in existing
code. Of course we don't know common such cases will be in new void-safe
code.

Because of these uncertainties, we are not planning at the moment to go
ahead with the `detach' instruction; this is also the reason why we are not
implementing 2.4 yet. But we are interested in views on this topic.

To facilitate discussion, please distinguish comments on the changes in
sections 1 to 8 -- the really urgent matter for the moment -- from those in
section 9 which are more tentative and perhaps more cosmetic.  

Thanks and best regards,

-- Bertrand Meyer


 

[Ian King [ES]]

A couple of minor corrections:

"For 9.2 there seems to be no other solution than to force introduction
of a detachable local variable x and use of f (x)"

The text should actually refer to 9.1 instead of 9.2. We can also use
{T}.default (where T is the type that Void is being passed to) in place
of a detached local variable.

Ian


Bertrand Meyer wrote:

>
> Hi,
>
> This is a proposal for improving the object test mechanism. It has been
> discussed briefly within the ECMA TC49-TG4 committee; we would be
> interested
> in Eiffel Software user feedback. This is an individual request which does
> not commit TG4; we will use the feedback to provide our own input to the
> committee.
>
> Another disclaimer: this is all expert stuff about a specific language
> point; if you are not familiar with the intricate details of the attached
> type (void safety) mechanism just ignore this discussion. There is
> definitely a need for explanatory material on these topics, accessible to
> non-experts; I intend to devote both my March and April EiffelWorld
> columns
> to attached types and void safety, and be as pedagogic as I can. But the
> present material is not for novices.
>
> 1. Rationale
> ------------
>
> 1.1 To facilitate the conversion of existing code to void safety.
>
> 1.2 As a particular subgoal of 1.1, to simplify the writing of cases in
> which we are not casting to a particular type but only seizing the
> value of
> an expression and binding it temporarily to a local for purposes of void
> safety. In such cases we should not have to repeat the type.
>
> 1.3 To improve the readability of code using object test. This is in
> particular an issue raised by Éric Bezault. it is of personal interest
> to me
> for my work in teaching introductory programming. The existence of the
> problem is confirmed by Eiffel Software's current conversion effort, which
> results in more pervasive use of object tests than we thought, making it
> essential that object test be more immediately understandable.
>
> 1.4 To be more in line with the rest of Eiffel syntax. In retrospect it
> seems that we repeated earlier errors of introducing a symbol-based
> syntax,
> such as !!, where keywords are more clear.
>
> 1.5 To address criticism of the mechanism as present in ISO/ECMA 367. This
> goal also mitigates an obvious argument against the present proposal: that
> it is inappropriate at the present stage to change a mechanism introduced
> recently. As far as we know the only major use of object test so far is
> within Eiffel Software, to adapt our libraries, and we are willing to
> perform the change if TG4 endorses the new version.
>
> 2. Overview and examples
> ------------------------
>
> The proposal retains the validity and semantics of object test as
> described
> in ISO/ECMA 367 (and implemented), in particular the notions of
> object-test
> local and scope. It changes the syntax to a keyword-oriented style,
> and adds
> possibilities:
> - Do not specify a type.
> - Do not specify an object-test local.
>
> Examples (here and below exp is an expression):
>
> attached exp as x: T -- [2.1]
> -- The complete form, replaces {x: T} exp
>
> attached exp as x -- [2.2]
> -- Bind only, no casting
> -- Previously would have been written {x: like exp} exp,
> -- or (if exp is of type T, and not a variable) {x: T} exp
>
> attached exp: T -- [2.3]
> -- Cast only, no binding
>
> attached exp -- [2.4]
> -- Equivalent to exp /= Void
>
> Note that the two key cases are [2.1] and [2.2]. As discussed in
> section 3,
> the
> other two are more arguable; a limited version of the proposal which only
> allows [2.1] or [2.2] retains its essential advantages.
>
> 3. Syntax
> ---------
>
> Object_test = `attached' Expression [Object_test_local]
> [Specific_type]
> Object_test_local = `as' Identifier
> Specific_type = ':' Type
>
> 4. Validity
> -----------
>
> VUOT remains unchanged.
>
> 5. Semantics
> ------------
>
> In this specification, v is the value of the Expression, T the
> Specific_type
> if given:
>
> - (Boolean) value of the expression: if T is given, whether v
> is attached to an object of type T; otherwise, whether v is
> attached.
>
> - In addition, if the Object_test_local is given, it is bound to v
> for the duration of the scope's execution, as in the current
> specification.
>
> 6. Discussion
> -------------
>
> Form [2.3] is proposed for completeness. In Eiffel Software's code it does
> not appear necessary; we are interested in opinions as to its usefulness.
>
> Form [2.4] has the disadvantage that it is exactly equivalent to exp /=
> Void, hence potentially confusing users as to what they should write. See
> section 9 below.
>
> 7. Replacing attachment marks with keywords
> --------------------------------------------
>
> In line with the revision of object test syntax discussed in previous
> sections, it seems appropriate to keywordize the syntax for declarations:
>
> 7.1 Replace ? by `detachable' (new keyword)
> 7.2 Replace ! by `attached' (keyword introduced by the changes in
> previous sections)
>
> `attached' in this role (like ! in the current syntax), are useful for the
> transition period only, not in new code, and will go away as the entire
> Eiffel code base is moved to void safety.
>
> Examples:
>
> x: detachable T
> -- Instead of x: ? T
> x: attached T
> -- Instead of x: ! T
>
> 8. Proposed policy
> ------------------
>
> Our current policy for release 6.4 of EiffelStudio (May 15, 2009) is to
> implement
> 2.1
> 2.2
> 2.3 (but not 2.4)
> 7.1
> 7.4
>
> As usual the compiler will continue to support "old" syntax, i.e.
> everything
> that is in ISO/ECMA 367: previous syntax for object test, ? and !.
> Also, we
> will provide tools for automatic conversion from that old syntax to
> the new
> one.
>
> The reason for not implementing 2.4 (`attached x' with no further
> qualification) is explained in section 9 next. Obviously 2.4 is trivial to
> implement once the rest is done, so that decision can easily be reversed.
>
> 9. Getting rid of "Void"?
> -------------------------
>
> If we accepted 2.4, the use of plain `attached x', then this notation
> would
> be synonymous with `x /= Void'. In Eiffel we don't like to have two
> equally
> acceptable ways of writing something. Some have suggested that we
> should get
> rid of the Void value altogether. (Again, this would be a language
> decision,
> not a compiler incompatibility -- the compiler would continue to
> support the
> old style for a long time, and offer conversion tools.) This approach
> would
> require introducing a new instruction
>
> detach x
>
> which makes x void, replacing `x := Void'. This change introduces one more
> new keyword, `detach'. It leaves open the question of how two handle the
> following two cases expressed with current conventions:
>
> 9.1 - f (Void) -- Passing a void value to a routine
> 9.2 - x.a := Void -- If a has an associated assigner
> command
>
> 9.2 can probably be addressed by allowing `detach x.a' if `a' is
> detachable
> and has an associated assigner command with the right signature. For 9.2
> there seems to be no other solution than to force introduction of a
> detachable local variable x and use of f (x), where x has not been
> initialized explicitly, or is set through `detach x'. There have been
> objections to this style since f (Void) appears quite often in existing
> code. Of course we don't know common such cases will be in new void-safe
> code.
>
> Because of these uncertainties, we are not planning at the moment to go
> ahead with the `detach' instruction; this is also the reason why we
> are not
> implementing 2.4 yet. But we are interested in views on this topic.
>
> To facilitate discussion, please distinguish comments on the changes in
> sections 1 to 8 -- the really urgent matter for the moment -- from
> those in
> section 9 which are more tentative and perhaps more cosmetic.
>
> Thanks and best regards,
>
> -- Bertrand Meyer
>
>  

[helmut.brandl]

Bertrand Meyer wrote:
...

>
> The proposal retains the validity and semantics of object test as described
> in ISO/ECMA 367 (and implemented), in particular the notions of object-test
> local and scope. It changes the syntax to a keyword-oriented style, and adds
> possibilities:
> - Do not specify a type.
> - Do not specify an object-test local.
>
> Examples (here and below exp is an expression):
>
> attached exp as x: T -- [2.1]
> -- The complete form, replaces {x: T} exp
>
> attached exp as x -- [2.2]
> -- Bind only, no casting
> -- Previously would have been written {x: like exp} exp,
> -- or (if exp is of type T, and not a variable) {x: T} exp
>
> attached exp: T -- [2.3]
> -- Cast only, no binding
>
> attached exp -- [2.4]
> -- Equivalent to exp /= Void
>

In order to discuss the proposal, I think we have should embed it to
some real world code. In the following I use an example of a linked list
from the tutorial (see http://tecomp.sourceforge.net -> eiffel language
-> tutorial -> linked list) to compare the proposal to current ECMA Eiffel.

ECMA Eiffel:

class LINKABLE[G] create put feature
    item: G
    next: ?like Current
    put (el:G)
       do
         item := el
        end
    put_next (n: ?like Current)
       do
         next := n
       end
end


Proposal:

class LINKABLE[G] create put feature
    item: G
    next: detachable like Current
    put (el:G)
       do
         item := el
       end
    put_next (n: detachable like Current)
       do
         next := n
       end
end



ECMA:

class
   LINKED_LIST[G]
feature {NONE}
   first_linkable: ?LINKABLE[G]
   last_linkable:  ?LINKABLE[G]
feature
   is_empty: BOOLEAN
      do
        Result := first_linkable = Void
      end
   first: G
      ...
   last:  G
      ...
   extend_front ( el: G )
      ...
   extend_rear  ( el: G )
      ...
   remove_first
      ...
invariant
   (first_linkable = Void) =  (last_linkable = Void)
end



Proposal:

class
   LINKED_LIST[G]
feature {NONE}
   first_linkable: detachable LINKABLE[G]
   last_linkable:  detachable LINKABLE[G]
feature
   is_empty: BOOLEAN
      do
        Result := first_linkable = Void
      end
   first: G
      ...
   last:  G
      ...
   extend_front ( el: G )
      ...
   extend_rear  ( el: G )
      ...
   remove_first
      ...
invariant
   (first_linkable = Void) =  (last_linkable = Void)
end



ECMA:

   first: G
     require
       not is_empty
     do
       check
         {l:LINKABLE[G]} first_linkable
       end
       Result := l.item  -- Now valid!
     end

Proposal:

   first: G
     require
       not is_empty
     do
       check
         attached first_linkable as l: LINKABLE[G]
       end
       Result := l.item  -- Now valid!
     end


After comparing to two versions and smelling the taste I have the
following observations:

1. The keyword "attached" is not necessary, neither in the declaration
of variables nor in the object test. It may be necessary for transition,
but in the final version it is just noise. E.g. one could write


   first: G
     require
       not is_empty
     do
       check
         first_linkable as l: LINKABLE[G]
       end
       Result := l.item  -- Now valid!
     end

without any loss of information, since an object test only makes sense
to test against "attachedness" (sorry for the awful word).

2. Using detachable instead of the symbol "?" pollutes the keyword space
with one keyword more. Prefering "detachable T" over "?T" is a matter of
taste. I personally like keyword syntax more than operator syntax. But
?T is quite intuitive, because it naturally reads "maybe T". Without the
pollution I would vote for the keyword, but I think the win in beauty
does not justify the pollution. But in the end it boils down to "It is a
matter of taste!".

3. Using the syntax "exp as x:T" is definitely less cryptic and better
readable than "{x:T} exp". It has the advantage of not polluting the
keyword space.

4. The proposal just adresses a syntax change, not any semantic change.
This is good, since the ECMA semantics for void safety is sound. However
there are still some "certified attachment pattern" (CAP) missing in the
current ECMA spec. The CAPs in the current spec will cause a lot of
repetive code (as already discussed in previous threads).


Kind regards
Helmut

The Eiffel Compiler: http://tecomp.sourceforge.net

[Colin LeMahieu]

2.3: This seems that at best it can be used for dubious usage
scenarios.  Requiring a type that's more narrow than the feature
signature, ensuring a return type that's more narrow than the feature
signature.  Checks on the concrete types assigned to variables at
certain times.  This type of expression would seem logical for use in
contracts when there's no place to use a bound variable, if this kind
of type checking in contracts is desirable; I haven't thought about
this type of usages so I call it dubious.

I like keywords instead of symbols.

9: This seems interesting and promising though I don't have input to
offer.  Resolving the reference versus value type conundrum further
would be excellent.

--- In [hidden email], "Bertrand Meyer"
<Bertrand.Meyer@...> wrote:
>
> Hi,
>
> This is a proposal for improving the object test mechanism. It has been
> discussed briefly within the ECMA TC49-TG4 committee; we would be
interested
> in Eiffel Software user feedback. This is an individual request
which does
> not commit TG4; we will use the feedback to provide our own input to the
> committee.
>
> Another disclaimer: this is all expert stuff about a specific language
> point; if you are not familiar with the intricate details of the
attached
> type (void safety) mechanism just ignore this discussion. There is
> definitely a need for explanatory material on these topics,
accessible to
> non-experts; I intend to devote both my March and April EiffelWorld
columns

> to attached types and void safety, and be as pedagogic as I can. But the
> present material is not for novices.
>
> 1. Rationale
> ------------
>
> 1.1 To facilitate the conversion of existing code to void safety.
>
> 1.2 As a particular subgoal of 1.1, to simplify the writing of cases in
> which we are not casting to a particular type but only seizing the

value of
> an expression and binding it temporarily to a local for purposes of void
> safety. In such cases we should not have to repeat the type.
>
> 1.3 To improve the readability of code using object test. This is in
> particular an issue raised by Éric Bezault. it is of personal
interest to me
> for my work in teaching introductory programming. The existence of the
> problem is confirmed by Eiffel Software's current conversion effort,
which
> results in more pervasive use of object tests than we thought, making it
> essential that object test be more immediately understandable.
>
> 1.4 To be more in line with the rest of Eiffel syntax. In retrospect it
> seems that we repeated earlier errors of introducing a symbol-based
syntax,
> such as !!, where keywords are more clear.
>
> 1.5 To address criticism of the mechanism as present in ISO/ECMA
367. This
> goal also mitigates an obvious argument against the present
proposal: that
> it is inappropriate at the present stage to change a mechanism
introduced
> recently. As far as we know the only major use of object test so far is
> within Eiffel Software, to adapt our libraries, and we are willing to
> perform the change if TG4 endorses the new version.
>
>
> 2. Overview and examples
> ------------------------
>
> The proposal retains the validity and semantics of object test as
described
> in ISO/ECMA 367 (and implemented), in particular the notions of
object-test
> local and scope. It changes the syntax to a keyword-oriented style,
and adds

> possibilities:
> - Do not specify a type.
> - Do not specify an object-test local.
>
> Examples (here and below exp is an expression):
>
> attached exp as x: T -- [2.1]
> -- The complete form, replaces {x: T} exp
>
> attached exp as x -- [2.2]
> -- Bind only, no casting
> -- Previously would have been written {x: like exp} exp,
> -- or (if exp is of type T, and not a variable) {x: T} exp
>
> attached exp: T -- [2.3]
> -- Cast only, no binding
>
> attached exp -- [2.4]
> -- Equivalent to exp /= Void
>
>
> Note that the two key cases are [2.1] and [2.2]. As discussed in

section 3,
> the
> other two are more arguable; a limited version of the proposal which
only

> allows [2.1] or [2.2] retains its essential advantages.
>
> 3. Syntax
> ---------
>
> Object_test = `attached' Expression [Object_test_local]
> [Specific_type]
> Object_test_local = `as' Identifier
> Specific_type = ':' Type
>
> 4. Validity
> -----------
>
> VUOT remains unchanged.
>
> 5. Semantics
> ------------
>
> In this specification, v is the value of the Expression, T the

Specific_type

> if given:
>
> - (Boolean) value of the expression: if T is given, whether v
>  is attached to an object of type T; otherwise, whether v is
> attached.
>
> - In addition, if the Object_test_local is given, it is bound to v
>  for the duration of the scope's execution, as in the current
>  specification.
>
> 6. Discussion
> -------------
>
> Form [2.3] is proposed for completeness. In Eiffel Software's code

it does
> not appear necessary; we are interested in opinions as to its
usefulness.
>
> Form [2.4] has the disadvantage that it is exactly equivalent to exp /=
> Void, hence potentially confusing users as to what they should
write. See
> section 9 below.
>
>
> 7. Replacing attachment marks with keywords
> --------------------------------------------
>
> In line with the revision of object test syntax discussed in previous
> sections, it seems appropriate to keywordize the syntax for
declarations:
>
> 7.1 Replace ? by `detachable' (new keyword)
> 7.2 Replace ! by `attached' (keyword introduced by the changes in
> previous sections)
>
> `attached' in this role (like ! in the current syntax), are useful
for the

> transition period only, not in new code, and will go away as the entire
> Eiffel code base is moved to void safety.
>
> Examples:
>
> x: detachable T
> -- Instead of x: ? T
> x: attached T
> -- Instead of x: ! T
>
>
> 8. Proposed policy
> ------------------
>
> Our current policy for release 6.4 of EiffelStudio (May 15, 2009) is to
> implement
> 2.1
> 2.2
> 2.3 (but not 2.4)
> 7.1
> 7.4
>
> As usual the compiler will continue to support "old" syntax, i.e.

everything
> that is in ISO/ECMA 367: previous syntax for object test, ? and !.
Also, we
> will provide tools for automatic conversion from that old syntax to
the new
> one.
>
> The reason for not implementing 2.4 (`attached x' with no further
> qualification) is explained in section 9 next. Obviously 2.4 is
trivial to
> implement once the rest is done, so that decision can easily be
reversed.
>
> 9. Getting rid of "Void"?
> -------------------------
>
> If we accepted 2.4, the use of plain `attached x', then this
notation would
> be synonymous with `x /= Void'. In Eiffel we don't like to have two
equally
> acceptable ways of writing something. Some have suggested that we
should get
> rid of the Void value altogether. (Again, this would be a language
decision,
> not a compiler incompatibility -- the compiler would continue to
support the
> old style for a long time, and offer conversion tools.) This
approach would
> require introducing a new instruction
>
> detach x
>
> which makes x void, replacing `x := Void'. This change introduces
one more
> new keyword, `detach'. It leaves open the question of how two handle the
> following two cases expressed with current conventions:
>
> 9.1 - f (Void) -- Passing a void value to a routine
> 9.2 - x.a := Void -- If a has an associated assigner
> command
>
> 9.2 can probably be addressed by allowing `detach x.a' if `a' is
detachable

> and has an associated assigner command with the right signature. For 9.2
> there seems to be no other solution than to force introduction of a
> detachable local variable x and use of f (x), where x has not been
> initialized explicitly, or is set through `detach x'. There have been
> objections to this style since f (Void) appears quite often in existing
> code. Of course we don't know common such cases will be in new void-safe
> code.
>
> Because of these uncertainties, we are not planning at the moment to go
> ahead with the `detach' instruction; this is also the reason why we

are not
> implementing 2.4 yet. But we are interested in views on this topic.
>
> To facilitate discussion, please distinguish comments on the changes in
> sections 1 to 8 -- the really urgent matter for the moment -- from
those in
> section 9 which are more tentative and perhaps more cosmetic.  
>
> Thanks and best regards,
>
> -- Bertrand Meyer
>

[Jimmy Johnson]

7.  I like keywords.  But, I have to strain a little to get the
intended meaning of "attached" because a detachable entity is usually
attached to some object.  I would prefer something
like "nondetachable".

3.  I have always marvalled at the pascal simplicity of Eiffel.  
Object test and to a small bit, agents, are two areas that I would
think are harder to teach.  So, I agree the systax need to change.  
But I still have to use too many brain cells to understand the
proposal.

Instead of "exp as x:T" use some form of "x:T from exp"
or even "x:T ?= exp" .

This reminds me of when `clone' was a keyword and not a feature.  Is
there a way to make the object test a feature call?  How to handle it
when the target is Void, though?



--- In [hidden email], "Bertrand Meyer"
<Bertrand.Meyer@...> wrote:
>
> Hi,
>
> This is a proposal for improving the object test mechanism. It has
been
> discussed briefly within the ECMA TC49-TG4 committee; we would be
interested
> in Eiffel Software user feedback. This is an individual request
which does
> not commit TG4; we will use the feedback to provide our own input
to the
> committee.
>
> Another disclaimer: this is all expert stuff about a specific
language
> point; if you are not familiar with the intricate details of the
attached
> type (void safety) mechanism just ignore this discussion. There is
> definitely a need for explanatory material on these topics,
accessible to
> non-experts; I intend to devote both my March and April EiffelWorld
columns
> to attached types and void safety, and be as pedagogic as I can.
But the
> present material is not for novices.
>
> 1. Rationale
> ------------
>
> 1.1 To facilitate the conversion of existing code to void safety.
>
> 1.2 As a particular subgoal of 1.1, to simplify the writing of
cases in
> which we are not casting to a particular type but only seizing the
value of
> an expression and binding it temporarily to a local for purposes of
void
> safety. In such cases we should not have to repeat the type.
>
> 1.3 To improve the readability of code using object test. This is in
> particular an issue raised by Éric Bezault. it is of personal
interest to me
> for my work in teaching introductory programming. The existence of
the
> problem is confirmed by Eiffel Software's current conversion
effort, which
> results in more pervasive use of object tests than we thought,
making it
> essential that object test be more immediately understandable.
>
> 1.4 To be more in line with the rest of Eiffel syntax. In
retrospect it
> seems that we repeated earlier errors of introducing a symbol-based
syntax,
> such as !!, where keywords are more clear.
>
> 1.5 To address criticism of the mechanism as present in ISO/ECMA
367. This
> goal also mitigates an obvious argument against the present
proposal: that
> it is inappropriate at the present stage to change a mechanism
introduced
> recently. As far as we know the only major use of object test so
far is
> within Eiffel Software, to adapt our libraries, and we are willing
to
> perform the change if TG4 endorses the new version.
>
>
> 2. Overview and examples
> ------------------------
>
> The proposal retains the validity and semantics of object test as
described
> in ISO/ECMA 367 (and implemented), in particular the notions of
object-test
> local and scope. It changes the syntax to a keyword-oriented style,
and adds

> possibilities:
> - Do not specify a type.
> - Do not specify an object-test local.
>
> Examples (here and below exp is an expression):
>
> attached exp as x: T -- [2.1]
> -- The complete form, replaces {x: T} exp
>
> attached exp as x -- [2.2]
> -- Bind only, no casting
> -- Previously would have been written {x: like exp}

exp,
> -- or (if exp is of type T, and not a variable) {x:
T} exp
>
> attached exp: T -- [2.3]
> -- Cast only, no binding
>
> attached exp -- [2.4]
> -- Equivalent to exp /= Void
>
>
> Note that the two key cases are [2.1] and [2.2]. As discussed in
section 3,
> the
> other two are more arguable; a limited version of the proposal
which only
> allows [2.1] or [2.2] retains its essential advantages.
>
> 3. Syntax
> ---------
>
> Object_test = `attached' Expression
[Object_test_local]

> [Specific_type]
> Object_test_local = `as' Identifier
> Specific_type = ':' Type
>
> 4. Validity
> -----------
>
> VUOT remains unchanged.
>
> 5. Semantics
> ------------
>
> In this specification, v is the value of the Expression, T the

Specific_type
> if given:
>
> - (Boolean) value of the expression: if T is given, whether v
>  is attached to an object of type T; otherwise, whether v is
> attached.
>
> - In addition, if the Object_test_local is given, it is bound
to v
>  for the duration of the scope's execution, as in the current
>  specification.
>
> 6. Discussion
> -------------
>
> Form [2.3] is proposed for completeness. In Eiffel Software's code
it does
> not appear necessary; we are interested in opinions as to its
usefulness.
>
> Form [2.4] has the disadvantage that it is exactly equivalent to
exp /=
> Void, hence potentially confusing users as to what they should
write. See
> section 9 below.
>
>
> 7. Replacing attachment marks with keywords
> --------------------------------------------
>
> In line with the revision of object test syntax discussed in
previous
> sections, it seems appropriate to keywordize the syntax for
declarations:
>
> 7.1 Replace ? by `detachable' (new keyword)
> 7.2 Replace ! by `attached' (keyword introduced by the
changes in
> previous sections)
>
> `attached' in this role (like ! in the current syntax), are useful
for the
> transition period only, not in new code, and will go away as the
entire

> Eiffel code base is moved to void safety.
>
> Examples:
>
> x: detachable T
> -- Instead of x: ? T
> x: attached T
> -- Instead of x: ! T
>
>
> 8. Proposed policy
> ------------------
>
> Our current policy for release 6.4 of EiffelStudio (May 15, 2009)

is to
> implement
> 2.1
> 2.2
> 2.3 (but not 2.4)
> 7.1
> 7.4
>
> As usual the compiler will continue to support "old" syntax, i.e.
everything
> that is in ISO/ECMA 367: previous syntax for object test, ? and !.
Also, we
> will provide tools for automatic conversion from that old syntax to
the new
> one.
>
> The reason for not implementing 2.4 (`attached x' with no further
> qualification) is explained in section 9 next. Obviously 2.4 is
trivial to
> implement once the rest is done, so that decision can easily be
reversed.
>
> 9. Getting rid of "Void"?
> -------------------------
>
> If we accepted 2.4, the use of plain `attached x', then this
notation would
> be synonymous with `x /= Void'. In Eiffel we don't like to have two
equally
> acceptable ways of writing something. Some have suggested that we
should get
> rid of the Void value altogether. (Again, this would be a language
decision,
> not a compiler incompatibility -- the compiler would continue to
support the
> old style for a long time, and offer conversion tools.) This
approach would
> require introducing a new instruction
>
> detach x
>
> which makes x void, replacing `x := Void'. This change introduces
one more
> new keyword, `detach'. It leaves open the question of how two
handle the
> following two cases expressed with current conventions:
>
> 9.1 - f (Void) -- Passing a void value to a routine
> 9.2 - x.a := Void -- If a has an associated
assigner
> command
>
> 9.2 can probably be addressed by allowing `detach x.a' if `a' is
detachable
> and has an associated assigner command with the right signature.
For 9.2
> there seems to be no other solution than to force introduction of a
> detachable local variable x and use of f (x), where x has not been
> initialized explicitly, or is set through `detach x'. There have
been
> objections to this style since f (Void) appears quite often in
existing
> code. Of course we don't know common such cases will be in new void-
safe
> code.
>
> Because of these uncertainties, we are not planning at the moment
to go
> ahead with the `detach' instruction; this is also the reason why we
are not
> implementing 2.4 yet. But we are interested in views on this topic.
>
> To facilitate discussion, please distinguish comments on the
changes in
> sections 1 to 8 -- the really urgent matter for the moment -- from
those in
> section 9 which are more tentative and perhaps more cosmetic.  
>
> Thanks and best regards,
>
> -- Bertrand Meyer
>

[Bertrand Meyer]

Dear Jimmy Jack,

> Instead of "exp as x:T" use some form of "x:T from exp"
> or even "x:T ?= exp" .

Actually one of the small problems that bothered me with the previous
(braces) syntax is that the object-test local appears first, whereas in fact
the property is fundamentally about the expression. So I personally prefer
to see the expression first, as in

        attached exp as x: T

which immediately shows that we are talking about whether exp is attached,
and only then states that it will be referred to as x in the ensuing scope.
In addition (case 2.3) sometimes we don't need the object-test local, in
which case we can write just

        attached exp: T

With best regards,

-- BM

[Jimmy Johnson]

I know you put a caveat on this thread for experts only, but as
someone who has been following this somewhat in my peripheral vision,
I may be able to help, because at some point you are going to have to
teach this to morons like me. :)

But isn't the objective to get `x' and do something with it?

I thought this was originally a replacement for assignment attempt
and its corresponding local variable declaration and subsequent check
for not Void.  I would think that you [usually] know that exp is
attached, and you just need to type-cast it [bad word].  In this case
I am really more focused on the local and how I will use this local
not on exp.

For case 2.3 where you don't need the local I would prefer something
like "exp.conforms_to ({T}) or if exp could be Void then "if exp /=
Void and then exp.conforms_to ({T})".  Or am I missing the point?

And the keyword "attached" and its placement really seems ambiguous.  
It looks like a declaration instead of a question.

Best regards,

jjj

[Peter Gummer-2]

Jimmy J. Johnson wrote:
> And the keyword "attached" and its placement really seems ambiguous.  
> It looks like a declaration instead of a question.
>  

I had the same feeling about the proposed "attached" keyword, on both
counts.

But this small point of confusion would disappear if the "attached"
keyword is, as Helmut said, redundant. I would like to see an example
where "attached" prevented ambiguity; otherwise why have it?

By the way, Jimmy, I like the "as" syntax very much. Perhaps that's
because my eyes have been trained by years of Delphi and C# programming
which use "as" in a similar way to the proposal.

- Peter Gummer

[rfo]

Hi All!

I will consider myself more of an interested observer than an expert,
but I'd like the chime in on this just a little.

It strikes me that readability is at the heart of the discussion, and
that's a good thing.  I trust the language experts to make it work
correctly.  Making it consumable by morons such as Jimmy and myself
(meant affectionately in Jimmy's case) is I think equally important.

How does it read to a human?  Let's see.

attached exp as x: T

Reads, to me like an HP calculator, not like Eiffel should read.  On the
other hand, as Bertrand notes, we are trying to associate exp with
attached, so they should be adjacent if at all possible.  Jimmy's point
about caring about x is also important.

When we look at the full and short forms together, it's hard to see the
connection.

attached exp as x: T
attached exp: T

Huh?  We forgot to put in the 'as x'.  Sure I know this is correct, but
to the _reader_ it looks like exp has taken the place of x, and that's
clearly not the intent.

How would we like this construct to read?  How about something like:

"exp is an expression of type T, and is attached in this context as x"

I'm thinking that's a bit long winded.  A more terse form of the same
statement might be:

exp: T attached as x

Hmmmm.

Now the short form (no local) becomes

exp: T attached

Now the two forms do seem to be related.  We still have droped the 'as
x', but the rest of the bits and pieces don't seem to have changed.  To
me, it's more readable and more consistent.

Just my admittedly uninformed observations.
Thanks,

     R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: [eiffel_software] Re: [Expert stuff] Revising the syntax of
> object test and attached type declarations
> From: "Jimmy J. Johnson" <[hidden email]>
> Date: Tue, January 27, 2009 6:12 pm
> To: [hidden email]
> I know you put a caveat on this thread for experts only, but as
> someone who has been following this somewhat in my peripheral vision,
> I may be able to help, because at some point you are going to have to
> teach this to morons like me. :)
> But isn't the objective to get `x' and do something with it?
> I thought this was originally a replacement for assignment attempt
> and its corresponding local variable declaration and subsequent check
> for not Void.  I would think that you [usually] know that exp is
> attached, and you just need to type-cast it [bad word].  In this case
> I am really more focused on the local and how I will use this local
> not on exp.
> For case 2.3 where you don't need the local I would prefer something
> like "exp.conforms_to ({T}) or if exp could be Void then "if exp /=
> Void and then exp.conforms_to ({T})".  Or am I missing the point?
> And the keyword "attached" and its placement really seems ambiguous.  
> It looks like a declaration instead of a question.
> Best regards,
> jjj

[Peter Gummer-2]

[hidden email] wrote:
> exp: T attached as x
>
> Hmmmm.
>
> Now the short form (no local) becomes
>
> exp: T attached
>
> Now the two forms do seem to be related.


I think this is a nice observation, Roger, although I think "attached"
should go before "T", analogous to "like T":

exp: attached T as x
exp: attached T

But then, if it's both "attached" and "like T", then how should we write
it: "attached like T" or "like attached T"?

If the "attached" keyword is dropped from the proposal, however, then
this whole question of where to put it disappears. Your suggested form
become simply:

exp: T as x
exp: T

And the form of the original proposal becomes:

exp as x: T
exp: T

- Peter Gummer

[Jimmy Johnson]

Okay, the light finally came on.  I see the reason for the
keyword "attached" in examples 2.1 to 2.4.  Much better than the
braces but would be much clearer, I think, if for 7.2 replace ! by
some other word like "nondetachable"  (someone please find a better
word) and save "attached" for the object test.

Sorry for all the other noise.

jjj


--- In [hidden email], "Bertrand Meyer"
<Bertrand.Meyer@...> wrote:
>
> Dear Jimmy Jack,
>
> > Instead of "exp as x:T" use some form of "x:T from exp"
> > or even "x:T ?= exp" .
>
> Actually one of the small problems that bothered me with the
previous
> (braces) syntax is that the object-test local appears first,
whereas in fact
> the property is fundamentally about the expression. So I personally
prefer
> to see the expression first, as in
>
> attached exp as x: T
>
> which immediately shows that we are talking about whether exp is
attached,
> and only then states that it will be referred to as x in the
ensuing scope.
> In addition (case 2.3) sometimes we don't need the object-test
local, in
> which case we can write just
>
> attached exp: T
>
> With best regards,
>
> -- BM
>

[Peter Gummer-2]

The motivation behind the idea of replacing "void" with various other
mechanisms escapes me. Sure, the advent of void-safety does make one's
mind drift towards the even more radical idea of dispensing with void
altogether, but the ideas below do not do so. Unless I'm missing
something, they are just dressing void up in some other syntax.

Could you please explain why writing "attached x" is superior to writing
"x /= void", and why writing "detach x" is superior to writing "x :=
void"? In each case, the "void" syntax seems clearer to me.

By the way, if "void" goes, what happens to {NONE}?

- Peter Gummer



Bertrand Meyer wrote:

> ...
> 9. Getting rid of "Void"?
> -------------------------
>
> If we accepted 2.4, the use of plain `attached x', then this notation would
> be synonymous with `x /= Void'. In Eiffel we don't like to have two equally
> acceptable ways of writing something. Some have suggested that we should get
> rid of the Void value altogether. (Again, this would be a language decision,
> not a compiler incompatibility -- the compiler would continue to support the
> old style for a long time, and offer conversion tools.) This approach would
> require introducing a new instruction
>
> detach x
>
> which makes x void, replacing `x := Void'. This change introduces one more
> new keyword, `detach'. It leaves open the question of how two handle the
> following two cases expressed with current conventions:
>
> 9.1 - f (Void) -- Passing a void value to a routine
> 9.2 - x.a := Void -- If a has an associated assigner
> command
>
> 9.2 can probably be addressed by allowing `detach x.a' if `a' is detachable
> and has an associated assigner command with the right signature. For 9.2
> there seems to be no other solution than to force introduction of a
> detachable local variable x and use of f (x), where x has not been
> initialized explicitly, or is set through `detach x'. There have been
> objections to this style since f (Void) appears quite often in existing
> code. Of course we don't know common such cases will be in new void-safe
> code.
>
> Because of these uncertainties, we are not planning at the moment to go
> ahead with the `detach' instruction; this is also the reason why we are not
> implementing 2.4 yet. But we are interested in views on this topic.
>
> To facilitate discussion, please distinguish comments on the changes in
> sections 1 to 8 -- the really urgent matter for the moment -- from those in
> section 9 which are more tentative and perhaps more cosmetic.  
>
> Thanks and best regards,
>
> -- Bertrand Meyer
>  

[David Broadfoot]

I agree with Peter. It introduces what *appears* to be new concepts to the
language, which further distances it from the traditional mindset, which
then serves to make the language less appealing to people coming from other
languages.

Furthermore, Helmut's example of
    f: detachable LINKABLE[G]
reads bizarrely: "detachable linkable"?!

Why not instead use this syntax:
    f: LINKABLE[G] or NONE

Its meaning is obvious without explanation; it adds no new concepts; it adds
no new keywords; and it generalises cleanly to boolean combinations of types
should such a feature ever be introduced in the future.

Though I hate the "!" syntax, I really like the "?" syntax... its natural
punctuation meaning applies. The "?" syntax could be retained so that:
    dob: ?DATE
is just sugar for
    dob: DATE or NONE


!David

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Peter Gummer
> Sent: Wednesday, 28 January 2009 11:39 PM
> To: [hidden email]
> Subject: [eiffel_software] Getting rid of "Void"?
>
> The motivation behind the idea of replacing "void" with various other
> mechanisms escapes me. Sure, the advent of void-safety does make one's
> mind drift towards the even more radical idea of dispensing with void
> altogether, but the ideas below do not do so. Unless I'm missing
> something, they are just dressing void up in some other syntax.
>
> Could you please explain why writing "attached x" is superior to writing
> "x /= void", and why writing "detach x" is superior to writing "x :=
> void"? In each case, the "void" syntax seems clearer to me.
>
> By the way, if "void" goes, what happens to {NONE}?
>
> - Peter Gummer
>
>
>
> Bertrand Meyer wrote:
> > ...
> > 9. Getting rid of "Void"?
> > -------------------------
> >
> > If we accepted 2.4, the use of plain `attached x', then this notation

would
> > be synonymous with `x /= Void'. In Eiffel we don't like to have two
equally
> > acceptable ways of writing something. Some have suggested that we should
get
> > rid of the Void value altogether. (Again, this would be a language
decision,
> > not a compiler incompatibility -- the compiler would continue to support
the
> > old style for a long time, and offer conversion tools.) This approach
would
> > require introducing a new instruction
> >
> > detach x
> >
> > which makes x void, replacing `x := Void'. This change introduces one
more
> > new keyword, `detach'. It leaves open the question of how two handle the
> > following two cases expressed with current conventions:
> >
> > 9.1 - f (Void) -- Passing a void value to a routine
> > 9.2 - x.a := Void -- If a has an associated assigner
> > command
> >
> > 9.2 can probably be addressed by allowing `detach x.a' if `a' is
detachable

> > and has an associated assigner command with the right signature. For 9.2
> > there seems to be no other solution than to force introduction of a
> > detachable local variable x and use of f (x), where x has not been
> > initialized explicitly, or is set through `detach x'. There have been
> > objections to this style since f (Void) appears quite often in existing
> > code. Of course we don't know common such cases will be in new void-safe
> > code.
> >
> > Because of these uncertainties, we are not planning at the moment to go
> > ahead with the `detach' instruction; this is also the reason why we are

not
> > implementing 2.4 yet. But we are interested in views on this topic.
> >
> > To facilitate discussion, please distinguish comments on the changes in
> > sections 1 to 8 -- the really urgent matter for the moment -- from those
in

> > section 9 which are more tentative and perhaps more cosmetic.
> >
> > Thanks and best regards,
> >
> > -- Bertrand Meyer
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[helmut.brandl]

David Broadfoot wrote:

> I agree with Peter. It introduces what *appears* to be new concepts to the
> language, which further distances it from the traditional mindset, which
> then serves to make the language less appealing to people coming from other
> languages.
>
> Furthermore, Helmut's example of
>     f: detachable LINKABLE[G]
> reads bizarrely: "detachable linkable"?!
>
> Why not instead use this syntax:
>     f: LINKABLE[G] or NONE
>

Hello David,

if we really want to get rid of the operator style declaration "?T",
then your proposal of using "T or NONE" is the best I have heard up to
now. I had nearly the same idea of using "T or Void", but "T or NONE" is
more consistent.

But I am not sure, if it is an advantage of getting rid of "?T". The
declaration "?T" is quite intuitive and reads naturally "maybe T".

The notations "?T" and "T or NONE" are ok, "detachable T" is a little
bit clumsy, but acceptable as well.

However, I would claim that this is a minor detail. If we want to
improve the language really, we should concentrate on making Eiffel
typesafe. Eiffel has still a significant hole its typesystem which needs
to be fixed (the catcall issue). That fix would be (in my opinion) more
important than the syntactic sugar we are discussing here.

Next point: concurrency ....

Next point: verification ...

Eiffel once the avantgarde in object orientation seems to loose the race
against java which is already typesafe. Not to talk about JML ...

I hope, that the ECMA committee discussed a little bit more than that
during their meeting 2 weeks ago.


Regards
Helmut

The Eiffel Compiler/Interpreter: http://tecomp.sourceforge.net

[David Broadfoot]

> But I am not sure, if it is an advantage of getting rid of "?T". The
> declaration "?T" is quite intuitive

Exactly what I said.


> and reads naturally "maybe T".

Not only that, "maybe T" is also a good choice of syntax itself, and should
be added to the list of options under discussion. Haskell uses that
terminology, though the concept is different.

 
> However, I would claim that this is a minor detail. If we want to
> improve the language really, we should concentrate on making Eiffel
> typesafe. Eiffel has still a significant hole its typesystem which needs
> to be fixed (the catcall issue). That fix would be (in my opinion) more
> important than the syntactic sugar we are discussing here.

We can't concentrate on one thing just because it is more important.
Discussions about syntax and syntactic sugar are also worthwhile.

 
> Next point: concurrency ....
>
> Next point: verification ...
>
> Eiffel once the avantgarde in object orientation seems to loose the race
> against java which is already typesafe.

Is that some sort of joke? It's easy enough to be typesafe if you remove
covariance.


> I hope, that the ECMA committee discussed a little bit more than that
> during their meeting 2 weeks ago.

They may have touched on few other things...

Regards,
David

[helmut.brandl]

David Broadfoot wrote:

>> But I am not sure, if it is an advantage of getting rid of "?T". The
>> declaration "?T" is quite intuitive
>
> Exactly what I said.
>
>
>> and reads naturally "maybe T".
>
> Not only that, "maybe T" is also a good choice of syntax itself, and should
> be added to the list of options under discussion. Haskell uses that
> terminology, though the concept is different.
>
>  
>> However, I would claim that this is a minor detail. If we want to
>> improve the language really, we should concentrate on making Eiffel
>> typesafe. Eiffel has still a significant hole its typesystem which needs
>> to be fixed (the catcall issue). That fix would be (in my opinion) more
>> important than the syntactic sugar we are discussing here.
>
> We can't concentrate on one thing just because it is more important.
> Discussions about syntax and syntactic sugar are also worthwhile.
>

Agreed! I just wanted bring the hole in the typesystem back into the
discussion. But count on me to discuss the syntax aspects as well.

>>
>> Eiffel once the avantgarde in object orientation seems to loose the race
>> against java which is already typesafe.
>
> Is that some sort of joke? It's easy enough to be typesafe if you remove
> covariance.

Fine. But I would not agree with the conclusion that because of
covariance Eiffel cannot be typesafe. Type safety is an important
property. The issue is pending since OOSC2 (or maybe even earlier).



>
>
>> I hope, that the ECMA committee discussed a little bit more than that
>> during their meeting 2 weeks ago.
>
> They may have touched on few other things...
>

Hopefully .....

Regards
Helmut



The Eiffel Compiler/Interpreter: http://tecomp.sourceforge.net

[Ian Joyner-2]

On 28/01/2009, at 11:38 PM, Peter Gummer wrote:

> The motivation behind the idea of replacing "void" with various other
> mechanisms escapes me.
>
Perhaps they want to cast void into the void!

[Ian Joyner-2]

On 30/01/2009, at 9:57 AM, Ian Joyner wrote:
> On 28/01/2009, at 11:38 PM, Peter Gummer wrote:
>
> > The motivation behind the idea of replacing "void" with various  
> other
> > mechanisms escapes me.
> >
> Perhaps they want to cast void into the void!
>
But others are rather attached to it.

Void does seem to be a problem that goes back at least to Plato or  
Aristotle – "some philosophers (notably Aristotle, perhaps Plato)  
rejected the notion as incoherent" (Oxford Companion to Philosophy).

I can't say that I've followed this very closely, so maybe the  
following thoughts have been covered before.

Dan Ingalls says about "storage management":

'To be truly "object-oriented", a computer system must provide  
automatic storage management.'

http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

I believe this means, not just garbage collection, but object  
allocation (and relocation). Smalltalk does have a new call (or at  
least the libraries do, if not the language). The Burroughs B5000  
(1963) certainly had this principle built in and it has a simple, yet  
very powerful programming model (one that is still good today). Object  
(array) allocation was also lazy – only allocated when actually  
referenced (via pbits).

Could object-oriented systems provide the same functionality? In  
Eiffel, dropping the create instruction, so that objects are  
automatically allocated when a reference is accessed. This would also  
get rid of creation procedures (constructors), which would become  
regular routines in Eiffel to force the object into a consistent state  
(not violating the invariant).

Temporary objects (those only used locally in a routine and not having  
reference passed to outside) could also be automatically deallocated  
on routine exit, removing the burden of cleaning up temporaries from  
the garbage collector.

This would considerably change the programming model, so would have to  
be carefully thought about. Maybe that has already been done. However,  
I think it would also simplify the programming model and do away with  
concepts like Void, and present programmers with something as simple  
as BASIC, which has proven quite popular because of its simplicity  
(even though its horrible). That way we can stop "passing paths that  
climb half way into the void" and are programming a little less close  
to the edge!

Ian
------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[hidden email]
    mailto:[hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Bertrand Meyer]

[Peter Gummer]

> Could you please explain why writing "attached x" is superior to writing
> "x /= void", and why writing "detach x" is superior to writing "x :=
> void"? In each case, the "void" syntax seems clearer to me.

Yes, it's partly a matter of taste. But Void is not that easy to accommodate
in the type system, although the standard manages to do it. In any case
there is no consensus at the moment about removing it, as the reactions in
this forum indicate.

On object test, however, we think we have a viable syntax update which we
will post as soon as all the details are firm and the ECMA committee agrees
at least informally. Many thanks for all the comments and suggestions, they
have been very useful in this process.

In case anyone is wondering why we are making so much fuss about void
safety, and spending so much effort both to get the mechanism's conceptual
details right and to implement them in the compiler, the following link may
be relevant: http://tinyurl.com/8wmgtt. This is the abstract of a
forthcoming talk by Tony Hoare, where he calls Void (the concept, not the
notation) the "billion-dollar mistake". The text refers to Spec# from MSR,
which is a research project; as far as we know Eiffel is the first
production framework that achieves void safety. More precisely, will be once
everything is in place: language constructs and implementation (available in
6.3, modulo the latest syntax change), void-safe libraries (for 6.4, this
coming May).

While O-O languages may be type-safe, this is of little consolation once you
know that any x.f (...) call may cause a crash as x may in one particular
execution happen to be null/Void. The specter of such crashes hangs over
every execution of any O-O program written in a void-unsafe language. A
recent post mentioned Eiffel staying at the vanguard of programming language
development; this is a good example of the kind of issues which make a
difference.

-- BM

[David Broadfoot]

Ian Joyner wrote:
> Could object-oriented systems provide the same functionality? In
> Eiffel, dropping the create instruction, so that objects are
> automatically allocated when a reference is accessed. This would also
> get rid of creation procedures (constructors), which would become
> regular routines in Eiffel to force the object into a consistent state
> (not violating the invariant).

In trying to avoid the problem, you have only annulled it - I am not married
to the idea.

Instead of x.f (...) causing a null-reference exception (because x has not
yet been created), all this does is instead cause a contract invariant
violation (because we are calling f on x when x is not yet in a consistent
state.)


 
> That way we can stop "passing paths that climb half way into the void" and
are
> programming a little less close to the edge!

Nevertheless, I admit your proposal is a real cliff-hanger!

David