make FreeELKS more ECMA compliant

[helmut.brandl]

What is the reason, that FreeELKS is not more compliant with standard
Eiffel?

Even if "not breaking code" is considered, I think some things could be
adapted without disturbing the users.

E.g.

- removing the "is" keyword

- switching from "prefix/infix" to alias notation.

Being backward compatible is a good goal in principle. But having too
much of it .....

Regards
Helmut

http://www.sourceforge.net/projects/tecomp
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

[Peter Gummer-2]

Helmut Brandl wrote:

> - removing the "is" keyword

In current versions of EiffelStudio, code completion fails for arguments of
a routine that does not have "is". This can be irritating when trying to
edit the routine's implementation. I joyfully started removing "is" from my
own code, because as an old Pascal programmer I always considered "is" to be
redundant, and I frequently omitted it by accident, out of habit. But I've
started adding it back again because not being able to use code completion
is just too annoying.

But maybe this is not a good enough reason to leave "is" in FreeELKS. The
only EiffelStudio users who need to edit the FreeELKS routines are those who
are working on FreeELKS. Some of those developers will find it a bit
annoying ... but maybe that's a good thing because it might encourage them
to fix this EiffelStudio bug a bit sooner ;-)

So I agree, Helmut.

- Peter



-------------------------------------------------------------------------
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

[Emmanuel Stapf]

> What is the reason, that FreeELKS is not more compliant with standard
> Eiffel?

Time. Most people behind it have quite a few things on their plate.
 
> Even if "not breaking code" is considered, I think some things could be
> adapted without disturbing the users.
>
> E.g.
>
> - removing the "is" keyword

This is actually something we are doing with Eric, but only on a class per class
basis when we do are review. For example BOOLEAN_REF is done. We just need to do
more. In a few days, I hope, we will integrate the new version of STRING with the
immutable aspect and this won't have any `is' keyword.

> - switching from "prefix/infix" to alias notation.

This is a breaking change and Eric and I have been discussing a transition scheme
which requires a compiler change before this can be done.

> Being backward compatible is a good goal in principle. But having too
> much of it .....

We all know but we cherish very much that aspect.

Regards,
Manu


-------------------------------------------------------------------------
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]

Emmanuel Stapf [ES] wrote:

>> E.g.
>>
>> - removing the "is" keyword
>>    
>
> This is actually something we are doing with Eric, but only on a class per class
> basis when we do are review. For example BOOLEAN_REF is done. We just need to do
> more. In a few days, I hope, we will integrate the new version of STRING with the
> immutable aspect and this won't have any `is' keyword.
>  

Since it is only editorial work, it can be done faster by distributing
the work on more shoulders. I would volonteer to cleanup some classes.
If you don't want to give me writing access to your svn, I could send
the cleanedup classes to you or Eric and you can do the checkin
(convincing yourself via diff that nothing else has been changed).

By the way: What kind of immutable aspect of STRING are you going to
implement? It would be nice to read something about it before finding it
as a fact in ELKS. Don't forget: STRING belongs to the inner kernel of
Eiffel so I would really appreciate some discussion or at least
explanation of the matter.
>  
>> - switching from "prefix/infix" to alias notation.
>>    
>
> This is a breaking change and Eric and I have been discussing a transition scheme
> which requires a compiler change before this can be done.
>  
Why does this break code? I can imagine 2 cases:

1. A class inherits from INTEGER or REAL and redefines (or renames, etc)
infix "+".

2. A class inherits from INTEGER etc. and in the inherited class you get
naming conflicts with e.g. the feature plus (since in ECMA Eiffel every
feature must have a normal name beside the alias).

Both cases should be very rare. If you announce and explain the change,
I don't think you will annoy your users.

Regards
Helmut

http://www.sourceforge.net/projects/tecomp
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

[Peter Gummer-2]

Helmut Brandl wrote:
> By the way: What kind of immutable aspect of STRING are you going to
> implement? It would be nice to read something about it before finding it
> as a fact in ELKS. Don't forget: STRING belongs to the inner kernel of
> Eiffel so I would really appreciate some discussion or at least
> explanation of the matter.

You're new to this list. It was discussed at length a couple of months ago:

http://sourceforge.net/mailarchive/forum.php?thread_name=1afdeaec0805180759g30d70fd5u56a49ccda96525fe%40mail.gmail.com&forum_name=freeelks-devel

And there was some earlier discussion some months before that.

- Peter
 



-------------------------------------------------------------------------
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

[Emmanuel Stapf]

> By the way: What kind of immutable aspect of STRING are you going to
> implement? It would be nice to read something about it before finding it
> as a fact in ELKS. Don't forget: STRING belongs to the inner kernel of
> Eiffel so I would really appreciate some discussion or at least
> explanation of the matter.

Look at Peter's email with the link to the prior discussion. For the moment, the
adopted simplified hierarchy is:

READABLE_STRING_GENERAL
^
|
READABLE_STRING_8    STRING_GENERAL
^                          ^
|                          |
STRING_8 -------------------

Same goes for the _32 variant. What we haven't done yet is writing the
IMMUTABLE_STRING variant mostly because we haven't really decided how. The current
thoughts are that if you do IMMUTABLE_STRING.substring, you get another
IMMUTABLE_STRING object but the `area' part is shared among the 2 IMMUTABLE_STRING
objects. The only drawback of this approach is let say that you start with an
IMMUTABLE_STRING of 2MB, then do a substring of 10 characters on it and the
original IMMUTABLE_STRING is not referenced anymore, then the 10 characters
IMMUTABLE_STRING still holds a reference to an area of 2MB which is maybe not
expected.

> Why does this break code? I can imagine 2 cases:
> 1. A class inherits from INTEGER or REAL and redefines (or renames, etc)
> infix "+".
>
> 2. A class inherits from INTEGER etc. and in the inherited class you get
> naming conflicts with e.g. the feature plus (since in ECMA Eiffel every
> feature must have a normal name beside the alias).

We were not thinking about those cases which are indeed very rare, but about
COMARABLE. Many classes do inherit from it and this is what we would be breaking
if their specification was to use `alias'.
 
Regards,
Manu



-------------------------------------------------------------------------
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

[Colin Adams-3]

2008/7/29 Emmanuel Stapf [ES] <[hidden email]>:

> thoughts are that if you do IMMUTABLE_STRING.substring, you get another
> IMMUTABLE_STRING object but the `area' part is shared among the 2 IMMUTABLE_STRING

This is how I have implemented ST_STRING.

> objects. The only drawback of this approach is let say that you start with an
> IMMUTABLE_STRING of 2MB, then do a substring of 10 characters on it and the
> original IMMUTABLE_STRING is not referenced anymore, then the 10 characters
> IMMUTABLE_STRING still holds a reference to an area of 2MB which is maybe not
> expected.

I thought about that too.
For my usage cases, I couldn't see it actually happening except in
vary rare circumstances, and I concluded that I could ignore that
drawback.

It would be possible to provide an additional routine substring_copy,
in READABLE_STRING_GENERAL, with a postcondition that Result is not
the same object as Current. This should further reduce the problematic
cases.

-------------------------------------------------------------------------
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

[Emmanuel Stapf]

> I thought about that too.
> For my usage cases, I couldn't see it actually happening except in
> vary rare circumstances, and I concluded that I could ignore that
> drawback.

I think that too. This is why we want IMMUTABLE_STRING, but in the long run, it is
possible that this usage is going to be problematic for some people.
 
> It would be possible to provide an additional routine substring_copy,
> in READABLE_STRING_GENERAL, with a postcondition that Result is not
> the same object as Current. This should further reduce the problematic
> cases.

Actually I think that `substring' might/should duplicate the area and only if the
user knows better he can use `aliased_substring' which would not duplicate the
`area'.

Manu


-------------------------------------------------------------------------
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]

It looks to me that all that talk about mutable/immutable strings resembles very much to the (somewhat) new idea about expandedness.  It seems that for immutable objects, we're just not interested in its value/identity duality as is the case for integers for example.  So I thought that a simpler design would be to have STRING_XX_REF and STRING_XX (value type) in addition to the parent class STING_GENERAL.  In those classes we could implement all kinds of optimization such as representation sharing, copy on write in the case of shared representations, etc.  

I've tried several times to implement them but EiffelStudio seems to have issues with expanded classes containing reference field.  If that was to work, is there any reason why we should prefer immutable strings to expanded strings?

Regards,
Simon

Emmanuel Stapf [ES] wrote:

> By the way: What kind of immutable aspect of STRING are you going to
> implement? It would be nice to read something about it before finding it
> as a fact in ELKS. Don't forget: STRING belongs to the inner kernel of
> Eiffel so I would really appreciate some discussion or at least
> explanation of the matter.

Look at Peter's email with the link to the prior discussion. For the moment, the
adopted simplified hierarchy is:

READABLE_STRING_GENERAL
^
|
READABLE_STRING_8    STRING_GENERAL
^                          ^
|                          |
STRING_8 -------------------

Same goes for the _32 variant. What we haven't done yet is writing the
IMMUTABLE_STRING variant mostly because we haven't really decided how. The current
thoughts are that if you do IMMUTABLE_STRING.substring, you get another
IMMUTABLE_STRING object but the `area' part is shared among the 2 IMMUTABLE_STRING
objects. The only drawback of this approach is let say that you start with an
IMMUTABLE_STRING of 2MB, then do a substring of 10 characters on it and the
original IMMUTABLE_STRING is not referenced anymore, then the 10 characters
IMMUTABLE_STRING still holds a reference to an area of 2MB which is maybe not
expected.

> Why does this break code? I can imagine 2 cases:
> 1. A class inherits from INTEGER or REAL and redefines (or renames, etc)
> infix "+".
>
> 2. A class inherits from INTEGER etc. and in the inherited class you get
> naming conflicts with e.g. the feature plus (since in ECMA Eiffel every
> feature must have a normal name beside the alias).

We were not thinking about those cases which are indeed very rare, but about
COMARABLE. Many classes do inherit from it and this is what we would be breaking
if their specification was to use `alias'.
 
Regards,
Manu



-------------------------------------------------------------------------
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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Adams-3]

2008/7/29 Simon Hudon <[hidden email]>:

>
> It looks to me that all that talk about mutable/immutable strings resembles
> very much to the (somewhat) new idea about expandedness.  It seems that for
> immutable objects, we're just not interested in its value/identity duality
> as is the case for integers for example.  So I thought that a simpler design
> would be to have STRING_XX_REF and STRING_XX (value type) in addition to the
> parent class STING_GENERAL.  In those classes we could implement all kinds
> of optimization such as representation sharing, copy on write in the case of
> shared representations, etc.
>
> I've tried several times to implement them but EiffelStudio seems to have
> issues with expanded classes containing reference field.  If that was to
> work, is there any reason why we should prefer immutable strings to expanded
> strings?

Yes. Performance.

If you are going to substring an expanded type, then you must get a
new object, and so the character-storage is duplicated (just as in the
current situation). This can cause extereme garbage collection
overhead for string-intensive applications (which is the reason I have
been pushing this issue for over a year).

-------------------------------------------------------------------------
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]

Colin Adams wrote:

> 2008/7/29 Simon Hudon <[hidden email]>:
>  
>> It looks to me that all that talk about mutable/immutable strings resembles
>> very much to the (somewhat) new idea about expandedness.  It seems that for
>> immutable objects, we're just not interested in its value/identity duality
>> as is the case for integers for example.  So I thought that a simpler design
>> would be to have STRING_XX_REF and STRING_XX (value type) in addition to the
>> parent class STING_GENERAL.  In those classes we could implement all kinds
>> of optimization such as representation sharing, copy on write in the case of
>> shared representations, etc.
>>
>> I've tried several times to implement them but EiffelStudio seems to have
>> issues with expanded classes containing reference field.  If that was to
>> work, is there any reason why we should prefer immutable strings to expanded
>> strings?
>>    
>
> Yes. Performance.
>
> If you are going to substring an expanded type, then you must get a
> new object, and so the character-storage is duplicated (just as in the
> current situation). This can cause extereme garbage collection
> overhead for string-intensive applications (which is the reason I have
> been pushing this issue for over a year).
>
>  

Colin,

to my understanding you did not respond to Simon's remark. Simon
proposed an expanded class with a reference attribute. The reference
attribute should point to a shared representation. This has advantages
and disadvantages. Garbage collection overhead is (at least a I
understood Simon) not a disadvantage of his proposal.

By the way, reference attributes in expanded classes are valid Eiffel
constructs. They should work fine. What is the problem with reference
attributes in expanded classes/types?


Regards
Helmut

http://www.sourceforge.net/projects/tecomp
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]

Helmut Brandl wrote:

Colin,

to my understanding you did not respond to Simon's remark. Simon
proposed an expanded class with a reference attribute. The reference
attribute should point to a shared representation. This has advantages
and disadvantages. Garbage collection overhead is (at least a I
understood Simon) not a disadvantage of his proposal.

This is actually what I meant.  The performance cost of copying a string would be a copy of a pointer and maybe two integers, one increment and one decrement if you want to keep a reference count.  It would avoid copying the array in write operations in cases where it is not shared.

Helmut Brandl wrote:

By the way, reference attributes in expanded classes are valid Eiffel
constructs. They should work fine. What is the problem with reference
attributes in expanded classes/types?

I've had all kinds of crashes of the compiler and the tool set I use.  I don't remember exactly which one but removing the keyword expanded always seemed to magically remove the problem.

Helmut Brandl wrote:

Regards
Helmut

http://www.sourceforge.net/projects/tecomp
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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Colin Adams wrote:
> 2008/7/29 Simon Hudon <[e-mail]>:
>  
>> It looks to me that all that talk about mutable/immutable strings resembles
>> very much to the (somewhat) new idea about expandedness.  It seems that for
>> immutable objects, we're just not interested in its value/identity duality
>> as is the case for integers for example.  So I thought that a simpler design
>> would be to have STRING_XX_REF and STRING_XX (value type) in addition to the
>> parent class STING_GENERAL.  In those classes we could implement all kinds
>> of optimization such as representation sharing, copy on write in the case of
>> shared representations, etc.
>>
>> I've tried several times to implement them but EiffelStudio seems to have
>> issues with expanded classes containing reference field.  If that was to
>> work, is there any reason why we should prefer immutable strings to expanded
>> strings?
>>    
>
> Yes. Performance.
>
> If you are going to substring an expanded type, then you must get a
> new object, and so the character-storage is duplicated (just as in the
> current situation). This can cause extereme garbage collection
> overhead for string-intensive applications (which is the reason I have
> been pushing this issue for over a year).
>
>  

Regards,

Simon

[helmut.brandl]

Simon Hudon wrote:
> This is actually what I meant.  The performance cost of copying a string
> would be a copy of a pointer and maybe two integers, one increment and one
> decrement if you want to keep a reference count.  It would avoid copying the
> array in write operations in cases where it is not shared.
>
>  
Simon,

unfortunately you cannot implement reference counting in Eiffel, because
there is nothing similar to a C++ destructor for expanded types. So the
disadvantage of your proposal is, that you have to allocate fresh memory
each time you modify the string.

But as long as you don't modify the string, your proposal should work
fine (e.g. for immutable strings).

Regards
Helmut
http://www.sourceforge.net/projects/tecomp
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]

Emmanuel Stapf [ES] wrote:

>> Why does this break code? I can imagine 2 cases:
>> 1. A class inherits from INTEGER or REAL and redefines (or renames, etc)
>> infix "+".
>>
>> 2. A class inherits from INTEGER etc. and in the inherited class you get
>> naming conflicts with e.g. the feature plus (since in ECMA Eiffel every
>> feature must have a normal name beside the alias).
>>    
>
> We were not thinking about those cases which are indeed very rare, but about
> COMARABLE. Many classes do inherit from it and this is what we would be breaking
> if their specification was to use `alias'.
>  
> Regards,
> Manu
>  

Oh, I forgot COMPARABLE. You are right. Many applications might have
comparable objects.

But does that mean that you want to support infix/prefix forever? If the
answer is no, the day will come to make the switch. Since the change in
the application is only editorial (no need to understand the semantics
to do the change) it could be done easily.

Wouldn't it be better instead of implementing hooks in your compiler to
support both notations to build into the compiler something which helps
the applications to adapt? The effort on your side will be the same. The
advantage is, that you can cut off effort in the future.

Don't get me wrong. I appreciate being backward compatible. But not
backward compatibility forever. You have to push your users also a
little bit (clearly with previous announcements and some help).

Helmut

http://www.sourceforge.net/projects/tecomp
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]

Helmut Brandl wrote:

Simon Hudon wrote:
> This is actually what I meant.  The performance cost of copying a string
> would be a copy of a pointer and maybe two integers, one increment and one
> decrement if you want to keep a reference count.  It would avoid copying the
> array in write operations in cases where it is not shared.
>
>  
Simon,

unfortunately you cannot implement reference counting in Eiffel, because
there is nothing similar to a C++ destructor for expanded types. So the
disadvantage of your proposal is, that you have to allocate fresh memory
each time you modify the string.

what about {MEMORY}.dispose?

Helmut Brandl wrote:

But as long as you don't modify the string, your proposal should work
fine (e.g. for immutable strings).

Regards
Helmut
http://www.sourceforge.net/projects/tecomp
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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Simon Hudon wrote:
> what about {MEMORY}.dispose?
>  
To the best of my knowledge {MEMORY}.dispose does not work on expanded
type objects.

Even if it worked, it would be a misuse of dispose. In dispose you shall
not use any reference to another object (I don't know, if the compiler
checks it).

This makes sense, because dispose has been designed to close e.g. open
file descriptors (i.e. reference external to the Eiffel world) during
garbage collection. Other objects might have been already reclaimed, so
any use of another object is dangerous.

Therefore I think the rule shall be enforced by the compiler.

Helmut

http://www.sourceforge.net/projects/tecomp
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

[Colin Adams-3]

2008/7/29 Simon Hudon <[hidden email]>:

>
>
>
> Helmut Brandl wrote:
>>
>> Colin,
>>
>> to my understanding you did not respond to Simon's remark. Simon
>> proposed an expanded class with a reference attribute. The reference
>> attribute should point to a shared representation. This has advantages
>> and disadvantages. Garbage collection overhead is (at least a I
>> understood Simon) not a disadvantage of his proposal.
>>
>>
>
> This is actually what I meant.

Sorry. I didn't read closely enough.

-------------------------------------------------------------------------
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]

Helmut Brandl wrote:

Simon Hudon wrote:
> what about {MEMORY}.dispose?
>  
To the best of my knowledge {MEMORY}.dispose does not work on expanded
type objects.

Even if it worked, it would be a misuse of dispose. In dispose you shall
not use any reference to another object (I don't know, if the compiler
checks it).

This makes sense, because dispose has been designed to close e.g. open
file descriptors (i.e. reference external to the Eiffel world) during
garbage collection. Other objects might have been already reclaimed, so
any use of another object is dangerous.

this may be the reason why my previous attempts failed.  The two solutions that I see are:
o Allocate the reference counter outside of the heap of the garbage collector.
o use a local boolean field remembering if the representation has already been shared with another string.  

The second option has the inconvenient of causing more duplications if you copy a string and write on both versions; since the boolean flag is not shared there is no way to know that the representation is not shared anymore.

On the other hand, the first option can may cause some fragmentation in the C heap.  However, if it is to be a standard, the runtime may be modified accordingly to ease the use of counted references.  I'm not sure, however what is the complexity of that modification.

In short, the whole point is to show that we may still be able to use a copy on write implementation strategy for expanded strings.

Helmut Brandl wrote:

Therefore I think the rule shall be enforced by the compiler.

Helmut

http://www.sourceforge.net/projects/tecomp
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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel