self initializing types and SPECIAL

10 messages

self initializing types and SPECIAL

Reply Threaded

From my perspective, the actual generic of SPECIAL has to be a self
initializing type.

This seems to be necessary, because the creation of a SPECIAL object
returns an array with all entries initialized to their default value.

In addition to SPECIAL I would like to have a class SPECIAL_SEQUENCE[G]
in the kernel library which is initially empty, but has the capacity to
be filled with objects. For that class, we would not need the
restriction of feeding it with a self initializing actual generic. I
would consider SPECIAL_SEQUENCE more basic than SPECIAL (you can
implement SPECIAL with SPECIAL_SEQUENCE but not the other way round).

Opinions?

Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Simon Hudon

Re: self initializing types and SPECIAL

Reply Threaded

I disagree with the need of introducing something more primitive than
SPECIAL. In my perspective, SPECIAL has a very basic definition which
is used to implement all kinds of other data structures. It must be
seen as a sequence of self-initialized type whose size is fixed. It
is not intended to be carried around but rather it should be seen as a
component frequently used to implement data structures.

If you need a sequence of varying size which can range over more than
just self-initialized types, the useful abstraction is a LIST which
can effectively be implemented in terms of a SPECIAL.

One could argue that there is a mismatch between the generic parameter
of ARRAYED_LIST [G] and the one that would be provided to SPECIAL [?
G]. This mismatch can be overcome using
an invariant saying that all items from 1 to count must not be void.
Whenever the list has to returned, an object test would have to be
used (in an assertion, once it will be implemented).

This way, you have a sequence equivalent to your SPECIAL_SEQUENCE but
implemented in terms of SPECIAL. I believe also that this precise
implementation is not much different of what you would have to do for
SPECIAL_SEQUENCE [G].

Did you see any use of SPECIAL_SEQUENCE not covered by an ARRAYED_LIST?

I'm waiting for your feedback.

Regards,

Simon Hudon

On 4-Sep-08, at 1:33 PM, Helmut Brandl wrote:

> From my perspective, the actual generic of SPECIAL has to be a self
> initializing type.
>
> This seems to be necessary, because the creation of a SPECIAL object
> returns an array with all entries initialized to their default value.
>
> In addition to SPECIAL I would like to have a class
> SPECIAL_SEQUENCE[G]
> in the kernel library which is initially empty, but has the capacity
> to
> be filled with objects. For that class, we would not need the
> restriction of feeding it with a self initializing actual generic. I
> would consider SPECIAL_SEQUENCE more basic than SPECIAL (you can
> implement SPECIAL with SPECIAL_SEQUENCE but not the other way round).
>
> Opinions?
>
> Helmut
>
> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
> Documentation: http://tecomp.sourceforge.net
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> freeelks-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freeelks-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

helmut.brandl

Re: self initializing types and SPECIAL

Reply Threaded

Simon Hudon wrote:

> I disagree with the need of introducing something more primitive than
> SPECIAL. In my perspective, SPECIAL has a very basic definition which
> is used to implement all kinds of other data structures. It must be
> seen as a sequence of self-initialized type whose size is fixed. It
> is not intended to be carried around but rather it should be seen as a
> component frequently used to implement data structures.
>
> If you need a sequence of varying size which can range over more than
> just self-initialized types, the useful abstraction is a LIST which
> can effectively be implemented in terms of a SPECIAL.

I doubt that it will be very efficient, see below.
>
> One could argue that there is a mismatch between the generic parameter
> of ARRAYED_LIST [G] and the one that would be provided to SPECIAL
> [?G]. This mismatch can be overcome using
> an invariant saying that all items from 1 to count must not be void.
> Whenever the list has to returned, an object test would have to be
> used (in an assertion, once it will be implemented).
With the current version of the kernel library, I don't see another way
of implementing an ARRAYED_LIST than the one you proposed (it is
probably implemented that way). With assertion checking on, it will not
be very efficient. On the contrary. It can be awfully slow on large
arrays. Each feature call has to check the invariant iterating over all
the elements to check that they are attached. This has O(n2) complexity
(e.g. inserting 1.000.000 items into a list will require
(1.000.000+1)*1.000.000/2 checks). Each item query has to do an object
test in an assertion. You can argue, that one could turn class invariant
monitoring off for ARRAYED_LIST. But is this really the solution? Will
ECMA specify, that assertions with object tests cannot be switched off
(see next point)?

Up to now I have not yet seen any clear strategy of the ECMA committee
on how they will handle object test in assertions. The last that I
understood from remarks of Manu is that even if assertion checking is
off, assertions with object tests (or void test, which is practically
the same) have to be executed. Remember that an object test has a side
effect. You cannot switch the assertions off which have a side effect.

Another way would be to have a kind of proofing engine in the compiler,
which can prove, that the invariant will never be violated.

And all this powerful machinery just for not having an elementary class
with builtin features which will cost just an attribute more (the actual
count) than the class SPECIAL. No O(n2) invariant checking, no object
tests necessary, the change would not break any code. So my question is
rather straightforward: What do you loose, if you had a very primitive
builtin class like SPECIAL_SEQUENCE? And what a gain in performance and
reduced complexity for implementing classes like ARRAYED_LIST?

It may be possible, that the ECMA committee will abandon the possibility
of object tests in assertions. What then? To be honest, I don't see a
lot of use of having object tests in assertions except for providing a
workaround for not having a primitive class like SPECIAL_SEQUENCE. All
the other cases you can probably handle by intelligent use of attached
types.

Peter mentioned in some previous post the possibility that object tests
in assertions are just a migration facility to attached/detachable
types. I think he has got a point. Look into the libraries being
developed without having void safety. You see a lot of assertions like
require arg /= Void. Accepting that as a CAP gives you the possibility
of introducing attached types without breaking code. But maybe the
ladder will be removed after successful migration ..... Then the ECMA
committee might come up with a class like SPECIAL_SEQUENCE ....

>
> This way, you have a sequence equivalent to your SPECIAL_SEQUENCE but
> implemented in terms of SPECIAL. I believe also that this precise
> implementation is not much different of what you would have to do for
> SPECIAL_SEQUENCE [G].
>
> Did you see any use of SPECIAL_SEQUENCE not covered by an ARRAYED_LIST?
No, it does not give me more functionality. SPECIALS_SEQUENCE can be the
primitive class for building classes like ARRAYED_LIST, ARRAYED_SET,
ARRAYED_MAP, ARRAYED_LIST_SORTED, ... The improvement I see is the
reduced complexity and improved performance. Note that SPECIAL_SEQUENCE
does not require any additional indirection like ARRAYED_LIST. So for
applications, where that difference counts (I admit, that very few
application will suffer from the one more indirection in ARRAYED_LIST,
but they surely will suffer from the needed assertions, if the list
contains a big number of items), they have the freedom to use the more
basic class SPECIAL_SEQUENCE.

Helmut
The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net

>
> I'm waiting for your feedback.
>
> Regards,
>
> Simon Hudon
>
> On 4-Sep-08, at 1:33 PM, Helmut Brandl wrote:
>
>> From my perspective, the actual generic of SPECIAL has to be a self
>> initializing type.
>>
>> This seems to be necessary, because the creation of a SPECIAL object
>> returns an array with all entries initialized to their default value.
>>
>> In addition to SPECIAL I would like to have a class SPECIAL_SEQUENCE[G]
>> in the kernel library which is initially empty, but has the capacity to
>> be filled with objects. For that class, we would not need the
>> restriction of feeding it with a self initializing actual generic. I
>> would consider SPECIAL_SEQUENCE more basic than SPECIAL (you can
>> implement SPECIAL with SPECIAL_SEQUENCE but not the other way round).
>>
>> Opinions?
>>
>> Helmut
>>
>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>> Documentation: http://tecomp.sourceforge.net
>

helmut.brandl

Re: self initializing types and SPECIAL

Reply Threaded

Simon,

I have got another challenge for you.

Let's assume that there is an "expanded class EXP" which is not
self-initializing. What happens, if you create a SPECIAL[?EXP]? What
value will the n items of the array have? Will you need an extra flag in
objects of type EXP to mark whether they are initialized or not?

What is the boolean value of {x:EXP} (create
SPECIAL[?EXP].make(100))[5]? Does ECMA allow detachable versions of
expandeds?

Note that usually it is not necessary to have a detached expanded type.

Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net

Helmut Brandl wrote:

> Simon Hudon wrote:
>
>> I disagree with the need of introducing something more primitive than
>> SPECIAL. In my perspective, SPECIAL has a very basic definition which
>> is used to implement all kinds of other data structures. It must be
>> seen as a sequence of self-initialized type whose size is fixed. It
>> is not intended to be carried around but rather it should be seen as a
>> component frequently used to implement data structures.
>>
>> If you need a sequence of varying size which can range over more than
>> just self-initialized types, the useful abstraction is a LIST which
>> can effectively be implemented in terms of a SPECIAL.
>>
> I doubt that it will be very efficient, see below.
>
>> One could argue that there is a mismatch between the generic parameter
>> of ARRAYED_LIST [G] and the one that would be provided to SPECIAL
>> [?G]. This mismatch can be overcome using
>> an invariant saying that all items from 1 to count must not be void.
>> Whenever the list has to returned, an object test would have to be
>> used (in an assertion, once it will be implemented).
>>
> With the current version of the kernel library, I don't see another way
> of implementing an ARRAYED_LIST than the one you proposed (it is
> probably implemented that way). With assertion checking on, it will not
> be very efficient. On the contrary. It can be awfully slow on large
> arrays. Each feature call has to check the invariant iterating over all
> the elements to check that they are attached. This has O(n2) complexity
> (e.g. inserting 1.000.000 items into a list will require
> (1.000.000+1)*1.000.000/2 checks). Each item query has to do an object
> test in an assertion. You can argue, that one could turn class invariant
> monitoring off for ARRAYED_LIST. But is this really the solution? Will
> ECMA specify, that assertions with object tests cannot be switched off
> (see next point)?
>
> Up to now I have not yet seen any clear strategy of the ECMA committee
> on how they will handle object test in assertions. The last that I
> understood from remarks of Manu is that even if assertion checking is
> off, assertions with object tests (or void test, which is practically
> the same) have to be executed. Remember that an object test has a side
> effect. You cannot switch the assertions off which have a side effect.
>
> Another way would be to have a kind of proofing engine in the compiler,
> which can prove, that the invariant will never be violated.
>
> And all this powerful machinery just for not having an elementary class
> with builtin features which will cost just an attribute more (the actual
> count) than the class SPECIAL. No O(n2) invariant checking, no object
> tests necessary, the change would not break any code. So my question is
> rather straightforward: What do you loose, if you had a very primitive
> builtin class like SPECIAL_SEQUENCE? And what a gain in performance and
> reduced complexity for implementing classes like ARRAYED_LIST?
>
>
> It may be possible, that the ECMA committee will abandon the possibility
> of object tests in assertions. What then? To be honest, I don't see a
> lot of use of having object tests in assertions except for providing a
> workaround for not having a primitive class like SPECIAL_SEQUENCE. All
> the other cases you can probably handle by intelligent use of attached
> types.
>
> Peter mentioned in some previous post the possibility that object tests
> in assertions are just a migration facility to attached/detachable
> types. I think he has got a point. Look into the libraries being
> developed without having void safety. You see a lot of assertions like
> require arg /= Void. Accepting that as a CAP gives you the possibility
> of introducing attached types without breaking code. But maybe the
> ladder will be removed after successful migration ..... Then the ECMA
> committee might come up with a class like SPECIAL_SEQUENCE ....
>
>
>> This way, you have a sequence equivalent to your SPECIAL_SEQUENCE but
>> implemented in terms of SPECIAL. I believe also that this precise
>> implementation is not much different of what you would have to do for
>> SPECIAL_SEQUENCE [G].
>>
>> Did you see any use of SPECIAL_SEQUENCE not covered by an ARRAYED_LIST?
>>
> No, it does not give me more functionality. SPECIALS_SEQUENCE can be the
> primitive class for building classes like ARRAYED_LIST, ARRAYED_SET,
> ARRAYED_MAP, ARRAYED_LIST_SORTED, ... The improvement I see is the
> reduced complexity and improved performance. Note that SPECIAL_SEQUENCE
> does not require any additional indirection like ARRAYED_LIST. So for
> applications, where that difference counts (I admit, that very few
> application will suffer from the one more indirection in ARRAYED_LIST,
> but they surely will suffer from the needed assertions, if the list
> contains a big number of items), they have the freedom to use the more
> basic class SPECIAL_SEQUENCE.
>
> Helmut
> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
> Documentation: http://tecomp.sourceforge.net
>
>
>
>> I'm waiting for your feedback.
>>
>> Regards,
>>
>> Simon Hudon
>>
>> On 4-Sep-08, at 1:33 PM, Helmut Brandl wrote:
>>
>>
>>> From my perspective, the actual generic of SPECIAL has to be a self
>>> initializing type.
>>>
>>> This seems to be necessary, because the creation of a SPECIAL object
>>> returns an array with all entries initialized to their default value.
>>>
>>> In addition to SPECIAL I would like to have a class SPECIAL_SEQUENCE[G]
>>> in the kernel library which is initially empty, but has the capacity to
>>> be filled with objects. For that class, we would not need the
>>> restriction of feeding it with a self initializing actual generic. I
>>> would consider SPECIAL_SEQUENCE more basic than SPECIAL (you can
>>> implement SPECIAL with SPECIAL_SEQUENCE but not the other way round).
>>>
>>> Opinions?
>>>
>>> Helmut
>>>
>>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>>> Documentation: http://tecomp.sourceforge.net
>>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> freeelks-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freeelks-devel
>
>

Simon Hudon

Re: self initializing types and SPECIAL

Reply Threaded

In reply to this post by helmut.brandl

On 4-Sep-08, at 4:51 PM, Helmut Brandl wrote:

> With the current version of the kernel library, I don't see another
> way of implementing an ARRAYED_LIST than the one you proposed (it is
> probably implemented that way). With assertion checking on, it will
> not be very efficient. On the contrary. It can be awfully slow on
> large arrays. Each feature call has to check the invariant iterating
> over all the elements to check that they are attached. This has
> O(n2) complexity (e.g. inserting 1.000.000 items into a list will
> require (1.000.000+1)*1.000.000/2 checks). Each item query has to do
> an object test in an assertion. You can argue, that one could turn
> class invariant monitoring off for ARRAYED_LIST. But is this really
> the solution? Will ECMA specify, that assertions with object tests
> cannot be switched off (see next point)?
>
> Up to now I have not yet seen any clear strategy of the ECMA
> committee on how they will handle object test in assertions. The
> last that I understood from remarks of Manu is that even if
> assertion checking is off, assertions with object tests (or void
> test, which is practically the same) have to be executed. Remember
> that an object test has a side effect. You cannot switch the
> assertions off which have a side effect.
>
> Another way would be to have a kind of proofing engine in the
> compiler, which can prove, that the invariant will never be violated.
>
> And all this powerful machinery just for not having an elementary
> class with builtin features which will cost just an attribute more
> (the actual count) than the class SPECIAL.

I can assure you that the mentioned machinery has a far greater
incidence on software quality than just making sure the invariant of
ARRAYED_LIST does not take a quadratic time to check.

> No O(n2) invariant checking, no object tests necessary, the change
> would not break any code. So my question is rather straightforward:
> What do you loose, if you had a very primitive builtin class like
> SPECIAL_SEQUENCE? And what a gain in performance and reduced
> complexity for implementing classes like ARRAYED_LIST?
>
>
> It may be possible, that the ECMA committee will abandon the
> possibility of object tests in assertions. What then? To be honest,
> I don't see a lot of use of having object tests in assertions except
> for providing a workaround for not having a primitive class like
> SPECIAL_SEQUENCE. All the other cases you can probably handle by
> intelligent use of attached types.
>
> Peter mentioned in some previous post the possibility that object
> tests in assertions are just a migration facility to attached/
> detachable types. I think he has got a point. Look into the
> libraries being developed without having void safety. You see a lot
> of assertions like require arg /= Void. Accepting that as a CAP
> gives you the possibility of introducing attached types without
> breaking code. But maybe the ladder will be removed after successful
> migration ..... Then the ECMA committee might come up with a class
> like SPECIAL_SEQUENCE ....
>
>>
>> This way, you have a sequence equivalent to your SPECIAL_SEQUENCE
>> but implemented in terms of SPECIAL. I believe also that this
>> precise implementation is not much different of what you would have
>> to do for SPECIAL_SEQUENCE [G].
>>
>> Did you see any use of SPECIAL_SEQUENCE not covered by an
>> ARRAYED_LIST?
> No, it does not give me more functionality. SPECIALS_SEQUENCE can be
> the primitive class for building classes like ARRAYED_LIST,
> ARRAYED_SET, ARRAYED_MAP, ARRAYED_LIST_SORTED, ... The improvement I
> see is the reduced complexity and improved performance. Note that
> SPECIAL_SEQUENCE does not require any additional indirection like
> ARRAYED_LIST. So for applications, where that difference counts (I
> admit, that very few application will suffer from the one more
> indirection in ARRAYED_LIST, but they surely will suffer from the
> needed assertions, if the list contains a big number of items), they
> have the freedom to use the more basic class SPECIAL_SEQUENCE.
>
> Helmut
> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
> Documentation: http://tecomp.sourceforge.net
>

As I see it, all of this comes down to getting around the performance
penalty incurred by checking assertions. I think it is a pretty
general understanding that we must design assertions with their
documentation usage in head rather than considering their performance
impact. We all know that checking assertions has cost in performance
but it is a price we are willing to pay to detect errors early in the
cycle of development while no sound theory exists to allow us to
develop systematic correctness proofs.

Also on the performance topic, if the speed is a real inconvenience,
it is always possible to disable the invariant of classes that are not
under test.

I think also that the issue is far more general than SPECIAL versus
SPECIAL_SEQUENCE. It is will inevitably occur whenever a generic
class (say A [G]) has a client (say B [?G]) whose attachment/self-
initializing marks differs in the way mentioned. This situation does
not involve any specific properties of SPECIAL and the solution of
duplicating classes for our convenience is not a very attractive one.

Regards,

Simon

>
>>
>> I'm waiting for your feedback.
>>
>> Regards,
>>
>> Simon Hudon
>>
>> On 4-Sep-08, at 1:33 PM, Helmut Brandl wrote:
>>
>>> From my perspective, the actual generic of SPECIAL has to be a self
>>> initializing type.
>>>
>>> This seems to be necessary, because the creation of a SPECIAL object
>>> returns an array with all entries initialized to their default
>>> value.
>>>
>>> In addition to SPECIAL I would like to have a class
>>> SPECIAL_SEQUENCE[G]
>>> in the kernel library which is initially empty, but has the
>>> capacity to
>>> be filled with objects. For that class, we would not need the
>>> restriction of feeding it with a self initializing actual generic. I
>>> would consider SPECIAL_SEQUENCE more basic than SPECIAL (you can
>>> implement SPECIAL with SPECIAL_SEQUENCE but not the other way
>>> round).
>>>
>>> Opinions?
>>>
>>> Helmut
>>>
>>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>>> Documentation: http://tecomp.sourceforge.net
>>

helmut.brandl

Re: self initializing types and SPECIAL

Reply Threaded

Simon Hudon wrote:
> As I see it, all of this comes down to getting around the performance
> penalty incurred by checking assertions. I think it is a pretty
> general understanding that we must design assertions with their
> documentation usage in head rather than considering their performance
> impact. We all know that checking assertions has cost in performance
> but it is a price we are willing to pay to detect errors early in the
> cycle of development while no sound theory exists to allow us to
> develop systematic correctness proofs.
No need to teach me the value of design by contract. I have not made any
proposal for not using assertions. My proposal made a point for a simple
and robust solution which avoids as a side effect a performance penalty
which occurs on large arrays which assertion monitoring on.

For me, having the choice between a simple solution which is easy to
verify and a more complicated one, I always vote for the simpler one. We
can have different opinions. But you cannot deny the fact, that the
availability of a class like SPECIAL_SEQUENCE makes the design of
classes like ARRAYED_LIST, ARRAYED_SET, ... simpler (or do you? Then
explain! Show me the higher complexity or any other disadvantage!). I
have not heard anything from you, which denies that fact.
>
> I think also that the issue is far more general than SPECIAL versus
> SPECIAL_SEQUENCE. It is will inevitably occur whenever a generic
> class (say A [G]) has a client (say B [?G]) whose
> attachment/self-initializing marks differs in the way mentioned.
Can you give me any real world examples beside the issue with SPECIAL
and ARRAYED_LIST? I have made the hypothesis, that SPECIAL[?G] and
ARRAYED_LIST[G] (and family) are probably the only ones where the issue
with attached and detachable types cannot be avoided with the current
kernel library. I might change my mind, if you show me a resonable
counterexample (but please, a real example).

Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Simon Hudon

Re: self initializing types and SPECIAL

Reply Threaded

In reply to this post by helmut.brandl

Helmut,

As far as I know, it is necessary to define default_create as a
creation procedure in every expanded classes so the situation you
mentioned cannot occur.

For the second, I can't find precise description of the interactions
between detachable and expanded semantics and I would think that your
expression would yield a true since it seems that manipulating an
expanded object through a reference (e.g. an entity of type
INTEGER_REF which is assigned an integer) keeps value semantics. It
would make sense to assume that, in the context of expanded types, a
default value plays the role Void plays in the context of reference
types.

Obviously, Manus or Eric would be more capable or answering the
particular question.

Regards,

Simon

On 4-Sep-08, at 5:15 PM, Helmut Brandl wrote:

> Simon,
>
> I have got another challenge for you.
>
> Let's assume that there is an "expanded class EXP" which is not self-
> initializing. What happens, if you create a SPECIAL[?EXP]? What
> value will the n items of the array have? Will you need an extra
> flag in objects of type EXP to mark whether they are initialized or
> not?
>
> What is the boolean value of {x:EXP} (create SPECIAL[?EXP].make(100))
> [5]? Does ECMA allow detachable versions of expandeds?
>
> Note that usually it is not necessary to have a detached expanded
> type.
>
> Helmut
>
> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
> Documentation: http://tecomp.sourceforge.net
>
>
>
> Helmut Brandl wrote:
>> Simon Hudon wrote:
>>
>>> I disagree with the need of introducing something more primitive
>>> than SPECIAL. In my perspective, SPECIAL has a very basic
>>> definition which is used to implement all kinds of other data
>>> structures. It must be seen as a sequence of self-initialized
>>> type whose size is fixed. It is not intended to be carried around
>>> but rather it should be seen as a component frequently used to
>>> implement data structures.
>>>
>>> If you need a sequence of varying size which can range over more
>>> than just self-initialized types, the useful abstraction is a LIST
>>> which can effectively be implemented in terms of a SPECIAL.
>>>
>> I doubt that it will be very efficient, see below.
>>
>>> One could argue that there is a mismatch between the generic
>>> parameter of ARRAYED_LIST [G] and the one that would be provided
>>> to SPECIAL [?G]. This mismatch can be overcome using
>>> an invariant saying that all items from 1 to count must not be
>>> void. Whenever the list has to returned, an object test would
>>> have to be used (in an assertion, once it will be implemented).
>>>
>> With the current version of the kernel library, I don't see another
>> way of implementing an ARRAYED_LIST than the one you proposed (it
>> is probably implemented that way). With assertion checking on, it
>> will not be very efficient. On the contrary. It can be awfully slow
>> on large arrays. Each feature call has to check the invariant
>> iterating over all the elements to check that they are attached.
>> This has O(n2) complexity (e.g. inserting 1.000.000 items into a
>> list will require (1.000.000+1)*1.000.000/2 checks). Each item
>> query has to do an object test in an assertion. You can argue, that
>> one could turn class invariant monitoring off for ARRAYED_LIST. But
>> is this really the solution? Will ECMA specify, that assertions
>> with object tests cannot be switched off (see next point)?
>>
>> Up to now I have not yet seen any clear strategy of the ECMA
>> committee on how they will handle object test in assertions. The
>> last that I understood from remarks of Manu is that even if
>> assertion checking is off, assertions with object tests (or void
>> test, which is practically the same) have to be executed. Remember
>> that an object test has a side effect. You cannot switch the
>> assertions off which have a side effect.
>>
>> Another way would be to have a kind of proofing engine in the
>> compiler, which can prove, that the invariant will never be violated.
>>
>> And all this powerful machinery just for not having an elementary
>> class with builtin features which will cost just an attribute more
>> (the actual count) than the class SPECIAL. No O(n2) invariant
>> checking, no object tests necessary, the change would not break any
>> code. So my question is rather straightforward: What do you loose,
>> if you had a very primitive builtin class like SPECIAL_SEQUENCE?
>> And what a gain in performance and reduced complexity for
>> implementing classes like ARRAYED_LIST?
>>
>>
>> It may be possible, that the ECMA committee will abandon the
>> possibility of object tests in assertions. What then? To be honest,
>> I don't see a lot of use of having object tests in assertions
>> except for providing a workaround for not having a primitive class
>> like SPECIAL_SEQUENCE. All the other cases you can probably handle
>> by intelligent use of attached types.
>>
>> Peter mentioned in some previous post the possibility that object
>> tests in assertions are just a migration facility to attached/
>> detachable types. I think he has got a point. Look into the
>> libraries being developed without having void safety. You see a lot
>> of assertions like require arg /= Void. Accepting that as a CAP
>> gives you the possibility of introducing attached types without
>> breaking code. But maybe the ladder will be removed after
>> successful migration ..... Then the ECMA committee might come up
>> with a class like SPECIAL_SEQUENCE ....
>>
>>
>>> This way, you have a sequence equivalent to your SPECIAL_SEQUENCE
>>> but implemented in terms of SPECIAL. I believe also that this
>>> precise implementation is not much different of what you would
>>> have to do for SPECIAL_SEQUENCE [G].
>>>
>>> Did you see any use of SPECIAL_SEQUENCE not covered by an
>>> ARRAYED_LIST?
>>>
>> No, it does not give me more functionality. SPECIALS_SEQUENCE can
>> be the primitive class for building classes like ARRAYED_LIST,
>> ARRAYED_SET, ARRAYED_MAP, ARRAYED_LIST_SORTED, ... The improvement
>> I see is the reduced complexity and improved performance. Note that
>> SPECIAL_SEQUENCE does not require any additional indirection like
>> ARRAYED_LIST. So for applications, where that difference counts (I
>> admit, that very few application will suffer from the one more
>> indirection in ARRAYED_LIST, but they surely will suffer from the
>> needed assertions, if the list contains a big number of items),
>> they have the freedom to use the more basic class SPECIAL_SEQUENCE.
>>
>> Helmut
>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>> Documentation: http://tecomp.sourceforge.net
>>
>>
>>
>>> I'm waiting for your feedback.
>>>
>>> Regards,
>>>
>>> Simon Hudon
>>>
>>> On 4-Sep-08, at 1:33 PM, Helmut Brandl wrote:
>>>
>>>
>>>> From my perspective, the actual generic of SPECIAL has to be a self
>>>> initializing type.
>>>>
>>>> This seems to be necessary, because the creation of a SPECIAL
>>>> object
>>>> returns an array with all entries initialized to their default
>>>> value.
>>>>
>>>> In addition to SPECIAL I would like to have a class
>>>> SPECIAL_SEQUENCE[G]
>>>> in the kernel library which is initially empty, but has the
>>>> capacity to
>>>> be filled with objects. For that class, we would not need the
>>>> restriction of feeding it with a self initializing actual
>>>> generic. I
>>>> would consider SPECIAL_SEQUENCE more basic than SPECIAL (you can
>>>> implement SPECIAL with SPECIAL_SEQUENCE but not the other way
>>>> round).
>>>>
>>>> Opinions?
>>>>
>>>> Helmut
>>>>
>>>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>>>> Documentation: http://tecomp.sourceforge.net
>>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> freeelks-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freeelks-devel
>>
>>

helmut.brandl

Re: self initializing types and SPECIAL

Reply Threaded

In reply to this post by helmut.brandl

Hello Simon,

great that you gave an example. Now we can discuss more specifically.

As I understand a hash table, I don't see any need for a
SPECIAL_FUNCTION. For a hash table you need an array implemented
probably by SPECIAL[LST]. LST is usually a linked list of items which
hash to the same hash code. So either you use ?LINKABLE[ELEMENT_TYPE]
(or directly an available implementation of a linked list, but that
would just push the discussion to the implementation of a linked list).

I don't see any need for an invariant, checking the attached status of
LST. On the contrary. A void value indicates that there are no entries
for that specific hash value. I don't see any other needed assertion
with an object test either. Just some simple ifs

i := element_to_search_for.hash_code \\ s.count
if {x:LINKABLE[ELEMENT_TYPE} s[i] then
-- find the element in the linked list s[i]
else
-- element not in the list
end

I have skipped some details (e.g. we are not looking for elements but
for keys in a hash map), but that is basically the search in a hash
table. If you want me to give you the code for stepping through the
linked list, I could do it as well. But I don't expect anything different.

Have you anything different in mind?

Helmut
The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net

Simon Hudon wrote:

> Hi Helmut,
>
> If you consider a hash table (also implemented in terms of SPECIAL),
> the set of indices where we expect the item to be attached is no
> longer a contiguous interval and you need to specify an invariant
> which would not be statically checkable. At that point, you would
> need to introduce something like SPECIAL_FUNCTION for which you must
> keep track of the indices that are attached and something you
> characterized as a simple solution is not so elegant anymore.
>
> I think on the other hand, relying on an invariant to bridge the
> attached/detachable semantic gives us the simplicity and flexibility
> we need. In addition, this is something that will mostly occur in
> data structure libraries (such as base). In most cases, we don't care
> about the overhead incurred by checking the invariant of those since
> they are supposed to be validated before any client lay hand on them
> and their invariant monitoring should therefore be turned off.
>
> As a personal taste, I must admit that I prefer to keep SPECIAL as a
> unique class and keep its abstraction as simple and small as possible
> to avoid committing it to any particular usage.
>
> Regards,
>
> Simon
>
> On 4-Sep-08, at 6:34 PM, Helmut Brandl wrote:
>
>> Simon Hudon wrote:
>>> As I see it, all of this comes down to getting around the
>>> performance penalty incurred by checking assertions. I think it is
>>> a pretty general understanding that we must design assertions with
>>> their documentation usage in head rather than considering their
>>> performance impact. We all know that checking assertions has cost
>>> in performance but it is a price we are willing to pay to detect
>>> errors early in the cycle of development while no sound theory
>>> exists to allow us to develop systematic correctness proofs.
>> No need to teach me the value of design by contract. I have not made
>> any proposal for not using assertions. My proposal made a point for a
>> simple and robust solution which avoids as a side effect a
>> performance penalty which occurs on large arrays which assertion
>> monitoring on.
>>
>> For me, having the choice between a simple solution which is easy to
>> verify and a more complicated one, I always vote for the simpler one.
>> We can have different opinions. But you cannot deny the fact, that
>> the availability of a class like SPECIAL_SEQUENCE makes the design of
>> classes like ARRAYED_LIST, ARRAYED_SET, ... simpler (or do you? Then
>> explain! Show me the higher complexity or any other disadvantage!). I
>> have not heard anything from you, which denies that fact.
>>>
>>> I think also that the issue is far more general than SPECIAL versus
>>> SPECIAL_SEQUENCE. It is will inevitably occur whenever a generic
>>> class (say A [G]) has a client (say B [?G]) whose
>>> attachment/self-initializing marks differs in the way mentioned.
>> Can you give me any real world examples beside the issue with SPECIAL
>> and ARRAYED_LIST? I have made the hypothesis, that SPECIAL[?G] and
>> ARRAYED_LIST[G] (and family) are probably the only ones where the
>> issue with attached and detachable types cannot be avoided with the
>> current kernel library. I might change my mind, if you show me a
>> resonable counterexample (but please, a real example).
>>
>> Helmut
>>
>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>> Documentation: http://tecomp.sourceforge.net
>>
>

Simon Hudon

Re: self initializing types and SPECIAL

Reply Threaded

Hi Helmut,

Great! I guess you could put both keys and values in the linkables.
The two issues left that I see are
1. What if we want to implement it through rehashing?
2. What if we implement buckets with arrays instead of linked list?

I don't think they are enough to counter your argument. But still,
I'm not convinced of fact that duplicating SPECIAL for that purpose
would worth our while. Especially since the structure would still
have to get the particular invariant that I was talking about
especially if we are to inherit from SPECIAL_SEQUENCE.

Either way, I'll have think some more about the problem. I'll get
back to the argument afterward but it may take a while: I'm all caught
up in my moving preparations.

Regards,
Simon

On 5-Sep-08, at 6:35 PM, Helmut Brandl wrote:

> Hello Simon,
>
> great that you gave an example. Now we can discuss more specifically.
>
> As I understand a hash table, I don't see any need for a
> SPECIAL_FUNCTION. For a hash table you need an array implemented
> probably by SPECIAL[LST]. LST is usually a linked list of items
> which hash to the same hash code. So either you use ?
> LINKABLE[ELEMENT_TYPE] (or directly an available implementation of a
> linked list, but that would just push the discussion to the
> implementation of a linked list).
>
> I don't see any need for an invariant, checking the attached status
> of LST. On the contrary. A void value indicates that there are no
> entries for that specific hash value. I don't see any other needed
> assertion with an object test either. Just some simple ifs
>
> i := element_to_search_for.hash_code \\ s.count
> if {x:LINKABLE[ELEMENT_TYPE} s[i] then
> -- find the element in the linked list s[i]
> else
> -- element not in the list
> end
>
> I have skipped some details (e.g. we are not looking for elements
> but for keys in a hash map), but that is basically the search in a
> hash table. If you want me to give you the code for stepping through
> the linked list, I could do it as well. But I don't expect anything
> different.
>
> Have you anything different in mind?
>
> Helmut
> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
> Documentation: http://tecomp.sourceforge.net
>
>
> Simon Hudon wrote:
>> Hi Helmut,
>>
>> If you consider a hash table (also implemented in terms of
>> SPECIAL), the set of indices where we expect the item to be
>> attached is no longer a contiguous interval and you need to specify
>> an invariant which would not be statically checkable. At that
>> point, you would need to introduce something like SPECIAL_FUNCTION
>> for which you must keep track of the indices that are attached and
>> something you characterized as a simple solution is not so elegant
>> anymore.
>>
>> I think on the other hand, relying on an invariant to bridge the
>> attached/detachable semantic gives us the simplicity and
>> flexibility we need. In addition, this is something that will
>> mostly occur in data structure libraries (such as base). In most
>> cases, we don't care about the overhead incurred by checking the
>> invariant of those since they are supposed to be validated before
>> any client lay hand on them and their invariant monitoring should
>> therefore be turned off.
>>
>> As a personal taste, I must admit that I prefer to keep SPECIAL as
>> a unique class and keep its abstraction as simple and small as
>> possible to avoid committing it to any particular usage.
>>
>> Regards,
>>
>> Simon
>>
>> On 4-Sep-08, at 6:34 PM, Helmut Brandl wrote:
>>
>>> Simon Hudon wrote:
>>>> As I see it, all of this comes down to getting around the
>>>> performance penalty incurred by checking assertions. I think it
>>>> is a pretty general understanding that we must design assertions
>>>> with their documentation usage in head rather than considering
>>>> their performance impact. We all know that checking assertions
>>>> has cost in performance but it is a price we are willing to pay
>>>> to detect errors early in the cycle of development while no sound
>>>> theory exists to allow us to develop systematic correctness proofs.
>>> No need to teach me the value of design by contract. I have not
>>> made any proposal for not using assertions. My proposal made a
>>> point for a simple and robust solution which avoids as a side
>>> effect a performance penalty which occurs on large arrays which
>>> assertion monitoring on.
>>>
>>> For me, having the choice between a simple solution which is easy
>>> to verify and a more complicated one, I always vote for the
>>> simpler one. We can have different opinions. But you cannot deny
>>> the fact, that the availability of a class like SPECIAL_SEQUENCE
>>> makes the design of classes like ARRAYED_LIST, ARRAYED_SET, ...
>>> simpler (or do you? Then explain! Show me the higher complexity or
>>> any other disadvantage!). I have not heard anything from you,
>>> which denies that fact.
>>>>
>>>> I think also that the issue is far more general than SPECIAL
>>>> versus SPECIAL_SEQUENCE. It is will inevitably occur whenever a
>>>> generic class (say A [G]) has a client (say B [?G]) whose
>>>> attachment/self-initializing marks differs in the way mentioned.
>>> Can you give me any real world examples beside the issue with
>>> SPECIAL and ARRAYED_LIST? I have made the hypothesis, that
>>> SPECIAL[?G] and ARRAYED_LIST[G] (and family) are probably the only
>>> ones where the issue with attached and detachable types cannot be
>>> avoided with the current kernel library. I might change my mind,
>>> if you show me a resonable counterexample (but please, a real
>>> example).
>>>
>>> Helmut
>>>
>>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>>> Documentation: http://tecomp.sourceforge.net
>>>
>>

helmut.brandl

Re: self initializing types and SPECIAL

Reply Threaded

Hello Simon,

some additional thoughts to the topic below.

Regards
Helmut

The Eiffel Compiler: http://tecomp.sourceforge.net
Download: http://www.sourceforge.net/projects/tecomp

Simon Hudon wrote:
> Hi Helmut,
>
> Great! I guess you could put both keys and values in the linkables.
> The two issues left that I see are
> 1. What if we want to implement it through rehashing?
Let's see, if we understand the same thing by "rehashing". For me
rehashing means to change the number of buckets. But what's the problem
there?

You allocate a new SPECIAL[?LINKABLE[ELEMENT_TYPE]] with the new size.
The you walk through all elements in the hash map, remove each element
from the linked list contained in the old SPECIAL, find the new index by
element.hash_code \\ new_size and link the LINKABLE to the new SPECIAL.

At the end of the procedure, the old SPECIAL contains only void links
and all elements can be found from now on via the new SPECIAL.

Do you have anything else in mind by "rehash"?
>
> 2. What if we implement buckets with arrays instead of linked list?
That is not very memory effective. But it is possible. But an ARRAY is
not the appropriate class. You have to use an ARRAYED_LIST or similar,
because the number of elements in the buckets change over time. If you
have a good hash function, the number of items is either zero or one.

Any comments?

Let me make some general remark to the point, on which we had different
opinions. The question is: Is SPECIAL sufficient as a kernel class or do
we need something like SPECIAL_SEQUENCE?

You voted for the former, I for the latter.

If think we basically agree, that the question is interesting only in
case of types which are not self initializing. Let me try to implement
ARRAYED_LIST on the basis of ARRAY (which is itself based on SPECIAL).
We will get something like (glossing over some details)

class ARRAYED_LIST[G] inherit LIST create with_capacity feature {NONE}
arr: ARRAY[?G]
with_capacity ( cap: INTEGER )
do
arr.make(0, cap-1)
end
feature
count: INTEGER
capacity: INTEGER do Result := arr.count
item alias "[]" ( i: INTEGER ) : G
require i < count
do
check {arr_result: G} arr[i] end -- <--- that is the
crucial point
Result := arr_result
-- alternatively you can use:
-- local res: ?G do res:=arr[i]; check res/=Void end;
Result:=res end"
end
all_elements_in_the_list_attached: BOOLEAN
do
... -- straightforward loop from 0 to count-1 with void test
end
...
invariant
0 <= count
count <= capacity
all_elements_in_the_list_attached
end

You can play a little bit around with it. But without having something
like SPECIAL_SEQUENCE you need the object (or void) test in an assertion.

What if assertion monitoring is off?

Alternative a: use a void test instead of an object test local and
ignore the assertion at runtime. Consequence: We have lost void safe
Eiffel (note: your code might be buggy and the returned item is void).
I.e. the compiler cannot guarantee, that there are no void calls during
runtime.

Alternative b: Even if assertion monitoring is off, assertions
containing object/void tests will be executed at runtime. (Manu told me,
that this is the current view of the ECMA committee). But the we have
lost void safety as well. We have improved the situation a little bit,
because we would not get a call on void target but an assertion
violation. But the consequence is the same. The compiler cannot
guarantee void safety.

I am convinced that in the end neither of the two solutions will be
chosen by the ECMA committee.

My opinion: They will forbid void/object tests in assertions in the long
run and come up with something like SPECIAL_SEQUENCE.

Reason: void/object tests in assertions are just a transitional vehicle
between etl2 and etl3 (don't get me wrong; it is a good vehicle, because
it allows introduction of attached/detachable types without breaking
code). In code written completely in etl3 they are not necessary. It is
sufficient to have them in control flow statements like conditionals and
loop exit conditions (and they are necessary for the silly workaround
for not having a class like SPECIAL_SEQUENCE ... ).

>
>
> I don't think they are enough to counter your argument. But still,
> I'm not convinced of fact that duplicating SPECIAL for that purpose
> would worth our while. Especially since the structure would still
> have to get the particular invariant that I was talking about
> especially if we are to inherit from SPECIAL_SEQUENCE.
>
> Either way, I'll have think some more about the problem. I'll get
> back to the argument afterward but it may take a while: I'm all caught
> up in my moving preparations.
>
> Regards,
> Simon
>
>
> On 5-Sep-08, at 6:35 PM, Helmut Brandl wrote:
>
>> Hello Simon,
>>
>> great that you gave an example. Now we can discuss more specifically.
>>
>> As I understand a hash table, I don't see any need for a
>> SPECIAL_FUNCTION. For a hash table you need an array implemented
>> probably by SPECIAL[LST]. LST is usually a linked list of items which
>> hash to the same hash code. So either you use ?LINKABLE[ELEMENT_TYPE]
>> (or directly an available implementation of a linked list, but that
>> would just push the discussion to the implementation of a linked list).
>>
>> I don't see any need for an invariant, checking the attached status
>> of LST. On the contrary. A void value indicates that there are no
>> entries for that specific hash value. I don't see any other needed
>> assertion with an object test either. Just some simple ifs
>>
>> i := element_to_search_for.hash_code \\ s.count
>> if {x:LINKABLE[ELEMENT_TYPE} s[i] then
>> -- find the element in the linked list s[i]
>> else
>> -- element not in the list
>> end
>>
>> I have skipped some details (e.g. we are not looking for elements but
>> for keys in a hash map), but that is basically the search in a hash
>> table. If you want me to give you the code for stepping through the
>> linked list, I could do it as well. But I don't expect anything
>> different.
>>
>> Have you anything different in mind?
>>
>> Helmut
>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>> Documentation: http://tecomp.sourceforge.net
>>
>>
>> Simon Hudon wrote:
>>> Hi Helmut,
>>>
>>> If you consider a hash table (also implemented in terms of SPECIAL),
>>> the set of indices where we expect the item to be attached is no
>>> longer a contiguous interval and you need to specify an invariant
>>> which would not be statically checkable. At that point, you would
>>> need to introduce something like SPECIAL_FUNCTION for which you must
>>> keep track of the indices that are attached and something you
>>> characterized as a simple solution is not so elegant anymore.
>>>
>>> I think on the other hand, relying on an invariant to bridge the
>>> attached/detachable semantic gives us the simplicity and flexibility
>>> we need. In addition, this is something that will mostly occur in
>>> data structure libraries (such as base). In most cases, we don't
>>> care about the overhead incurred by checking the invariant of those
>>> since they are supposed to be validated before any client lay hand
>>> on them and their invariant monitoring should therefore be turned off.
>>>
>>> As a personal taste, I must admit that I prefer to keep SPECIAL as a
>>> unique class and keep its abstraction as simple and small as
>>> possible to avoid committing it to any particular usage.
>>>
>>> Regards,
>>>
>>> Simon
>>>
>>> On 4-Sep-08, at 6:34 PM, Helmut Brandl wrote:
>>>
>>>> Simon Hudon wrote:
>>>>> As I see it, all of this comes down to getting around the
>>>>> performance penalty incurred by checking assertions. I think it
>>>>> is a pretty general understanding that we must design assertions
>>>>> with their documentation usage in head rather than considering
>>>>> their performance impact. We all know that checking assertions
>>>>> has cost in performance but it is a price we are willing to pay to
>>>>> detect errors early in the cycle of development while no sound
>>>>> theory exists to allow us to develop systematic correctness proofs.
>>>> No need to teach me the value of design by contract. I have not
>>>> made any proposal for not using assertions. My proposal made a
>>>> point for a simple and robust solution which avoids as a side
>>>> effect a performance penalty which occurs on large arrays which
>>>> assertion monitoring on.
>>>>
>>>> For me, having the choice between a simple solution which is easy
>>>> to verify and a more complicated one, I always vote for the simpler
>>>> one. We can have different opinions. But you cannot deny the fact,
>>>> that the availability of a class like SPECIAL_SEQUENCE makes the
>>>> design of classes like ARRAYED_LIST, ARRAYED_SET, ... simpler (or
>>>> do you? Then explain! Show me the higher complexity or any other
>>>> disadvantage!). I have not heard anything from you, which denies
>>>> that fact.
>>>>>
>>>>> I think also that the issue is far more general than SPECIAL
>>>>> versus SPECIAL_SEQUENCE. It is will inevitably occur whenever a
>>>>> generic class (say A [G]) has a client (say B [?G]) whose
>>>>> attachment/self-initializing marks differs in the way mentioned.
>>>> Can you give me any real world examples beside the issue with
>>>> SPECIAL and ARRAYED_LIST? I have made the hypothesis, that
>>>> SPECIAL[?G] and ARRAYED_LIST[G] (and family) are probably the only
>>>> ones where the issue with attached and detachable types cannot be
>>>> avoided with the current kernel library. I might change my mind, if
>>>> you show me a resonable counterexample (but please, a real example).
>>>>
>>>> Helmut
>>>>
>>>> The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
>>>> Documentation: http://tecomp.sourceforge.net
>>>>
>>>
>