eiffelroom - Comments

integer intervals and file line processing

nenieorg — Tue, 18 Nov 2008 12:19:03 -0800

upto can be done in Eiffel with integer intervals:

(1 |..| 5).do_all (agent ...)

it doesn't currently allow descending but we're not too far...

For reading files I'd rather see an iterator like API rather, where the processing agent takes a line, than having to iterate lines by hand: solves 2 problems in one go.

You can have object equality without expanded

nenieorg — Tue, 18 Nov 2008 08:59:34 -0800

I agree that if expanded is removed, including for basic types, you need to adapt the rules so that '=' points to object equality. I had left that as an exercise to the reader. Shouldn't be too taxing (e.g. have an altogether distinct operator or function for reference equality, frankly it would be clearer, it's not as if you actually need ref equality very often). Some exercises are left to the reader re tidying up ref semantics for numbers (one can think of a few angles) though I don't expect show stopping problems to pop up there (in a new language).

Performance is a moot point because whether you live conceptually in a reference-only model or an expanded one, a compiler can optimise one model into the implied 'natural' implementation of the other: that is implement expanded semantics with hidden pointers (what Eiffel compilers have often done until now for custom expandeds) or implement immutable references with hidden copying (trivially when no ref equality use is detected in a program), so I think expanded just pollutes the abstract model for nothing much.

Immutable collections

maverick — Sun, 16 Nov 2008 11:49:14 -0800

On second thought, there is one library where the notion of immutable collections is necessary: the MML library which provides mathematical models to write specifications with. Consistently, I am strongly in favor of making every exposed class expanded and I don't think I would add classes such as MML_SET_REF since there is no need for them to be mutable (at least as far as I can see). I don't exclude it yet, though.

Simon

Hash table has not been required to be immutable, yet

maverick — Sun, 16 Nov 2008 09:05:32 -0800

An important difference with hash tables is that nobody has suggested to make them immutable yet. It would seem that aliasing hash tables create less problems than aliasing strings. I think for such classes, we are used to be careful and we duplicate them explicitly whenever we want to avoid aliasing.

Object identity is only made useless in the case of immutable objects.

Simon

And hash tables?

colin-adams — Sun, 16 Nov 2008 00:30:24 -0800

As far as I can follow your argument, then it applies to hash tables too. Or any other container class. Again, the negative result from reference comparison doesn't tell us anything interesting. Do you think they should be expanded too? Colin Adams

No need for string identity

maverick — Sat, 15 Nov 2008 20:05:30 -0800

> My argument is that you were apparently propagating the common
> fallacy that expanded classes are free of aliasing issues. They are so
> only if all their attributes are also expanded, which makes the feature
> considerably more brittle and less useful. It's particularly misleading
> if naive people get thinking they can rely on this property for any
> expanded class.

> The aliasing properties of an expanded class are not enforced by any
> validity constraint, and cannot be known from the flat short of a class
> (even if it doesn't export any routine it could still be subject to transitive
> aliasing). So expanded is just a hint that a class might, or might not,
> have interesting properties re aliasing.

All I say is that an expanded class cannot be aliased although it can cause aliasing of other objects. Regarding the aliasing of a string's representation, it is up to the implementation of STRING to make sure that no side effects are applied to aliased object. It is doable and it is a sufficient statement for the issue I am trying to address. The matter at hand is to determine what use we can make of a string's identity. In most cases, there is no use for it and this is why we should compare its semantics to that of integers and reals.

> And given that you can do all you're trying to with aliasing with
> immutable (no-command) classes, with more or less the same
> balance of advantages and disadvantages, is there any use left
> for this feature? I don't think so.

I think that, by saying that, you miss the point completely. If we use reference type as the default for strings, and we have two string references s1 and s2, then

s1 = s2

Would yield a correct true result really quickly but the negative result cannot be relied upon. We end up having to use equal in this case (which is what would be used in the case of expanded types). Maybe we can think that we save on copy since a reference copy is done in constant time. Well, we can implement an expanded string copy in constant time too so the argument for immutable strings is not very strong here either.

What we have with reference type strings is what we could call conceptual pollution. We have two distinct notions of what a particular (reference type) string is: its identity and its value. We know its identity has no use at all since the strings would be immutable so they can only be the source of confusion and should be eliminated altogether (in the case of strings). Hence, let's use expanded classes to model regular strings.

> If expanded was removed from, or hadn't been in the language
> in the first place, we'd just have a better, cleaner, less confusing
> language at no loss of expressiveness.

Would you rather have only reference types for integers, characters and reals? I wouldn't. Saying that it is much more efficient to have them as expanded types is merely an interesting addition. The matter is that expanded classes capture the right abstraction for those classes. It is also true for strings. It is all a matter of thinking in terms of the right abstraction.

I'm not sure I said it often enough but seeking the right abstraction is what should drive the activity of designing classes and it leads directly to the conclusion that making strings expanded is far superior to making them immutable.

Simon

This is for any platform

Jocelyn Fiat — Fri, 14 Nov 2008 00:09:46 -0800

Note the dark_es.xml is not only for unix, it is for EiffelStudio on any platform (even Windows). While dark_es.reg works only for Windows (but it is much more convenient). We should make a tool to quickly export/import preferences. It is possible with EiffelStudio's preferences dialog, but it is slow because for most of the preferences, there is a "change_action" which trigger update on the UI side. We could add a usage to "ec", something like "ec --load-preferences prefs.xml", so it would load the preferences before any UI is really built.

So it was just to say, you should rename dark_es_unix.zip into dark_es_anyplatform.zip and add a little text to explain how to "import" this unzipped file.

However, the goal of this article is mostly to show the possibility to have almost a dark color theme (or any color theme)

No need for expanded

nenieorg — Thu, 13 Nov 2008 08:47:18 -0800

My argument is that you were apparently propagating the common fallacy that expanded classes are free of aliasing issues. They are so only if all their attributes are also expanded, which makes the feature considerably more brittle and less useful. It's particularly misleading if naive people get thinking they can rely on this property for any expanded class.

The aliasing properties of an expanded class are not enforced by any validity constraint, and cannot be known from the flat short of a class (even if it doesn't export any routine it could still be subject to transitive aliasing). So expanded is just a hint that a class might, or might not, have interesting properties re aliasing.

And given that you can do all you're trying to with aliasing with immutable (no-command) classes, with more or less the same balance of advantages and disadvantages, is there any use left for this feature? I don't think so.

If expanded was removed from, or hadn't been in the language in the first place, we'd just have a better, cleaner, less confusing language at no loss of expressiveness.

Thank you

ted_eiffel — Wed, 12 Nov 2008 22:57:04 -0800

Thank you Jocelyn for the Unix version.

expanded must be applied to the STRING class

maverick — Wed, 12 Nov 2008 08:06:08 -0800

In your example, PERSON is not aliasable. Whatever you do, it is impossible to have to references to the same PERSON instance. In my proposal, I say that STRING should be expanded and, of course, the implementation should make sure that no harmful aliasing can happen.

One important thing to do for this is to make sure the client cannot manipulate directly the implementation. Among other things, this means that there should be no setter for the internal representation of the string.

On the other hand, the copy mechanism of the string should be carefully designed to make sure that, if the representation is aliased, a flag is set so that no side effect is applied to the representation until it has been duplicated.

In your example, expanded has no effect because it is applied to the wrong class. If you apply it to STRING, you will see that the last statement has no effect at all. If I'm not mistaken, a.name will yield a copy of a's name which will be mutated and lost.

Simon

.reg is for Windows only

Jocelyn Fiat — Wed, 12 Nov 2008 05:54:02 -0800

.reg is for Windows only, it is a way to import value into registry keys. However, for any platform, you can do the following

Open the preferences dialog
download dark_es.xml from http://gist.github.com/24157
click on import (bottom) using this dark_es.xml file

It might take some time, but at the end, you'll get the preferences "patched" with the one from the dark_es.xml file.

Hope this helps.

Beautiful, but ...

schoelle — Wed, 12 Nov 2008 05:03:35 -0800

schoelle@lcp:~$ unzip dark_es_0.zip
Archive:  dark_es_0.zip
  inflating: dark_es.reg
schoelle@lcp:~$ file dark_es.reg
dark_es.reg: MPEG ADTS, layer I, v1, 160 kBits, 48 kHz, Stereo

WTF?

expanded classes are neither immutable nor eliminating aliasing

nenieorg — Tue, 11 Nov 2008 10:45:48 -0800

it just pushes the problem one step away:

expanded class PERSON
  name: STRING
  set_name (a: STRING) is do name := a end
end

a,b: PERSON -- expanded!
l_name: STRING

l_name := "Bob"
a.set_name (l_name)
b.set_name (l_name)

a.name.append_string (" is a fool!")
-- b.name has changed!

The example works as well if you had immutable strings, replace the string attribute with any other mutable attribute.

A better pattern for immutable classes is procedure-less classes -- no functions, could call them functional classes :) -- which are immutable if CQS is respected (and for which expandedness has no impact, and therefore is of no use).

The aliasing issue remains the same: aliasing disappears only for transitively functional classes, as it does for transitively expanded classes.

What assertions are you

colin-adams — Thu, 16 Oct 2008 23:23:24 -0700

What assertions are you going to be checking against? At the moment, we have no way of specifying any assertions.

And how do you make a library like FACTORY (or a routine like do_all) correct? My proposal addresses that directly.

Colin Adams

What I'm saying is that

manus_eiffel — Thu, 16 Oct 2008 13:37:55 -0700

What I'm saying is that whenever you can, you evaluate a precondition at compile time during the agent creation. If not you do it at runtime. Of course not all the assertions can be verified (like the one involving an attribute), but you can easily verify the ones for which it involves one of the closed operands. In both cases, you get the precondition violation much earlier than at agent call time and getting a correctness violation earlier is always better.

My proposal is to help programmers write their routine properly which is I think an issue when you want to use a library and you have no idea on how the library is going to call your agents which what matters. Supplier is for me the one providing the agent and the client is the one calling it; in this definition it is up to the supplier to provide weaker precondition than the one requested by the client.