Tuples, iterators, and multiple return values in Eiffel?
Author |
Message |
Michael Christopher Vani #1 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
I was reading the Eiffel column in the latest issue of JOOP and it mentioned that some extensions to Eiffel that would support multiple-return-valued functions, tuples and iterators were being discussed. It also mentioned that there were documents online at ISE describing the proposals. Well, I looked and there are no such documents as far as I can tell. Can anyone post a summary of the proposal? If anyone from ISE is reading, could you please post the docs? Thanks, Mike -- ------------------------------------------------------------
Department of Computation and Neural Systems, Caltech 216-76 ------------------------------------------------------------
|
Tue, 20 Mar 2001 03:00:00 GMT |
|
|
Bertrand Meye #2 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Quote:
> I was reading the Eiffel column in the latest issue of JOOP and it > mentioned that some extensions to Eiffel that would support > multiple-return-valued functions, tuples and iterators were being > discussed. It also mentioned that there were documents online at ISE > describing the proposals. Well, I looked and there are no such > documents as far as I can tell.
They are there now. Follow "Papers" from the home page at http://eiffel.com or go directly to http://eiffel.com/doc/manuals/index.html#nice_extensions -- Bertrand Meyer, Interactive Software Engineering ISE Building, 2nd Floor, 270 Storke Road Goleta, CA 93117 USA 805-685-1006, Fax 805-685-6869,
|
Thu, 22 Mar 2001 03:00:00 GMT |
|
|
Reimer Behren #3 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
[Eiffel extensions.] Quote: > They are there now. Follow "Papers" from the home page at > http://eiffel.com > or go directly to > http://eiffel.com/doc/manuals/index.html#nice_extensions
First, thank you for making this available to us. Especially as it now appears that NICE is not quite as dead as it was made out to be. (I will resist temptation to bring up the obvious Mark Twain reference.) However, I have a few comments, especially regarding the TUPLE/ROUTINE proposal. First, I agree that the introduction of TUPLE cleans up some problematic areas in the language (like manifest arrays having no specific type). I am, however, not particularly convinced that the introduction of multiple return values is necessarily desirable. (Btw, while the paper claims that no other common language has such a mechanism besides certain functional languages, tuples to implement multiple return values are a common idiom in Python.) I would be interested to know what particular advantages a tuple gives you over existing language mechanisms. Technically, a tuple of type TUPLE[T1, ..., Tn] is more or less isomorphic to an object with just n attributes t1:T1; ...; tn:Tn and no invariants. Also, look at the proposed features supported by type TUPLE: item(i) requires a dynamic type check. Not very elegant. put(x, i) requires a dynamic type check, too. Worse, in this case any attempt to store a value of an inappropriate type will SILENTLY fail. This is defensive programming and not DBC as we know it. Generally, TUPLE seems to lean very much towards an ad-hoc programming style rather than designing your software. I am not certain if this is beneficial. As to the introduction of a ROUTINE class, I have to admit that the thought makes me a bit jumpy. I do not believe such an addition is necessary, and while I have seen several requests for the addition of such a feature, I would like to know the rationale behind it (it has been omitted from the paper). Regarding the second paper (generic creation), I am happy to see that !! will be replaced by a keyword. One of the problems I always had with the Eiffel 3 syntax was the proliferation of special symbols (// and \\ are other examples). With respect to the introduction of a create ... end clause, however, I have to say that it strikes me very much as an attempt to patch up a shortcoming in another place -- namely, that a creation clause cannot be part of the signature of a class. For instance, if we were creating a deferred class to model the mathematical concept of a FIELD (a structure with addition, subtraction, multiplication, and division), then we definitely would like to _require_ that every class inheriting from FIELD implement creation routines set_zero and set_one. It would be cumbersome if in each instance of a generic paramater constrained by FIELD we had to repeat them over and over again. Thus, I would much prefer a proposal that allows part of the "creation" section to belong to the signature of the class. Reimer Behrends
|
Fri, 23 Mar 2001 03:00:00 GMT |
|
|
Juergen Schlegelmil #4 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Quote:
>[Eiffel extensions.] >> They are there now. Follow "Papers" from the home page at [ ... ] >> http://eiffel.com/doc/manuals/index.html#nice_extensions >However, I have a few comments, especially regarding the TUPLE/ROUTINE >proposal. First, I agree that the introduction of TUPLE cleans up some >problematic areas in the language (like manifest arrays having no >specific type).
I think, in this particular case, it is not the correct cure. Rather than providing a generic TUPLE class, it would have been cleaner (at least IMHO) to provide means to denote constants for normal classes. This would also help with the STRING constant problem discussed in another thread, and would allow one to have constants of other classes (POINT, COMPLEX, etc.) as well, without the need for special treatment by the compiler. Allowing constants for arbitrary classes would not allow manifest arrays but require people to actually define classes for these arrays. IMHO, having constants of unnamed classes (or types) promotes ad-hoc programming, and introducing TUPLE to give them at least a proper type in Eiffel seems like a kludge. I recall discussions about closures being rejected because they are ad-hoc entities, and equivalent effects can be achieved by defining proper COMMAND classes with one feature execute() (or eval()). The same reasoning should hold in the case of manifest arrays. Quote: >I would be interested to know what particular advantages a tuple gives >you over existing language mechanisms. Technically, a tuple of type >TUPLE[T1, ..., Tn] is more or less isomorphic to an object with just n >attributes t1:T1; ...; tn:Tn and no invariants.
IMHO it allows to give types to entities without having to invent a name for the equivalent class, but does not add to the power of Eiffel. For example, TUPLE is used to specify the type of argument lists for ROUTINEs; this can be done with a normal class, too, but you have to name that. Doing this for all the argument list types is very tedious. The whole document seems to be aimed at reflection capabilities, i.e. treating methods as objects as done e.g. in Smalltalk. Quote: >Generally, TUPLE seems to lean very much towards an ad-hoc programming >style rather than designing your software. I am not certain if this is >beneficial.
It is also my impression, and I seriously doubt that it helps Eiffel. Quote: >As to the introduction of a ROUTINE class, I have to admit that the >thought makes me a bit jumpy. I do not believe such an addition is >necessary, and while I have seen several requests for the addition of >such a feature, I would like to know the rationale behind it (it has >been omitted from the paper).
Up to now, it has been argued that COMMAND classes can do the job better because they make the command set more explicit and are more extendable. Quote: >Regarding the second paper (generic creation), I am happy to see that >!! will be replaced by a keyword. One of the problems I always had with >the Eiffel 3 syntax was the proliferation of special symbols (// and \\ >are other examples).
There is also some asymetry since one can declare infix operators with special symbols but not with ordinary identifiers (like the logical operators `and', `or', let alone `and then', `or else'). The language should treat all operators alike, regardless of the characters they consist of. FWIW, I find keyword syntax usually more readable, since longer sequences of special symbols tend to look like noise; however, I think most of us accept a set of arithmetic operator symbols in order to write concise formulae. Quote: >With respect to the introduction of a create ... end clause, however, I >have to say that it strikes me very much as an attempt to patch up a >shortcoming in another place -- namely, that a creation clause cannot be >part of the signature of a class. For instance, if we were creating a >deferred class to model the mathematical concept of a FIELD (a structure >with addition, subtraction, multiplication, and division), then we >definitely would like to _require_ that every class inheriting from >FIELD implement creation routines set_zero and set_one. It would be >cumbersome if in each instance of a generic paramater constrained by >FIELD we had to repeat them over and over again.
This features set_zero and set_one should be constants of the class, in current Eiffel to be implemented as once functions (another kludge, to compensate for the lack of constants for arbitrary classes). These are (should be) creation routines so you can invoke them without a CURRENT object. Quote: >Thus, I would much prefer a proposal that allows part of the "creation" >section to belong to the signature of the class.
I agree. In fact, the GENERIC_CREATORS does effectively make the creation list part of the required signature of the class. Regards, Jrgen Schlegelmilch -- +-----------------------------------------------------------------------------+ Juergen Schlegelmilch http://www.informatik.uni-rostock.de/~schlegel
University of Rostock, Computer Science Department, 18051 Rostock, Germany +-----------------------------------------------------------------------------+
|
Fri, 23 Mar 2001 03:00:00 GMT |
|
|
Dan Higdo #5 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Quote:
>>As to the introduction of a ROUTINE class, I have to admit that the >>thought makes me a bit jumpy. I do not believe such an addition is >>necessary, and while I have seen several requests for the addition of >>such a feature, I would like to know the rationale behind it (it has >>been omitted from the paper). >Up to now, it has been argued that COMMAND classes can do the >job better because they make the command set more explicit and >are more extendable.
If the Eiffel vendors would implement repeated inheritance properly, (i.e. as defined in ETL), then this whole thing becomes somewhat pointless. Repeated inheritance from a deferred class can simulate "function pointer" semantics well, as demonstrated in the iterator discussion of ETL. I for one would rather see the Eiffel community finish the job implementing a feature that is ALREADY DEFINED than to introduce a separate, unnecessary complication to the language. ----------------------------------------
|
Fri, 23 Mar 2001 03:00:00 GMT |
|
|
Franck Arnau #6 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Dan Higdon: Quote: > Repeated inheritance from a deferred class can simulate > "function pointer" semantics well, as demonstrated in the iterator > discussion of ETL.
Can it? You still cannot pass "function pointers" around. E.g. if you have a COMMAND class with a single deferred feature 'execute', you can inherit repeatedly, but you cannot pass multiple COMMAND references to other parts of system -- all the COMMAND references you can extract will call the implementation of 'execute' that is select-ed in the repeatedly inheriting class. To be able to do that would mean having something akin to multiple Current(s) for a single object. This is _not_ intended to work as an extension of the Iterating-Several-Action example. Quote: > I for one would rather see the Eiffel community > finish the job implementing a feature that is ALREADY DEFINED > than to introduce a separate, unnecessary complication to the > language.
It is not really defined in ETL (there's little more than an example) and it is both difficult to implement and difficult to specify: a clean definition is a problem because it interacts with many things and has bizarre implications in cases outside the trivial examples. --
|
Fri, 23 Mar 2001 03:00:00 GMT |
|
|
Loryn Jenkin #7 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Quote: > This is _not_ intended to work as an > extension of the Iterating-Several-Action example.
Well, one of the benefits of the TUPLE / ROUTINE proposal is that you can actually use ISE-style iterators, whereas that is difficult to do now (unless you only iterate over a data structure using one test and one procedure). Quote: > > I for one would rather see the Eiffel community > > finish the job implementing a feature that is ALREADY DEFINED > > than to introduce a separate, unnecessary complication to the > > language. > It is not really defined in ETL (there's little more than an example) > and it is both difficult to implement and difficult to specify: a clean > definition is a problem because it interacts with many things and has > bizarre implications in cases outside the trivial examples.
How so? It is interesting that I didn't even read this section of ETL before naively expecting the features to work as described. Evidently, a lot of other people (Dan, Patrick, Ted, ...) also expected this to work. It seems that this is an 'intuitive' description of what should happen. Where do you see problems? Loryn Jenkins
|
Sat, 24 Mar 2001 03:00:00 GMT |
|
|
Reimer Behren #8 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
[Extensions of Eiffel.] Quote: > >However, I have a few comments, especially regarding the TUPLE/ROUTINE > >proposal. First, I agree that the introduction of TUPLE cleans up some > >problematic areas in the language (like manifest arrays having no > >specific type). > I think, in this particular case, it is not the correct cure. > Rather than providing a generic TUPLE class, it would have been > cleaner (at least IMHO) to provide means to denote constants for > normal classes. This would also help with the STRING constant > problem discussed in another thread, and would allow one to have > constants of other classes (POINT, COMPLEX, etc.) as well, without > the need for special treatment by the compiler.
While I tend to agree with most of your sentiments, there is no real need to have class-specific constants. IMO it is quite sufficient to be able to write c := complex(1.0, 0.0) or something similar. Keep in mind that any class "constant" has to satisfy the class invariant, which for an arbtitrary class is tantamount to given those constants the semantics of a creation routine. [...] Quote: > I recall discussions about closures being rejected because they > are ad-hoc entities, and equivalent effects can be achieved by > defining proper COMMAND classes with one feature execute() (or > eval()). The same reasoning should hold in the case of manifest > arrays.
I beg to differ. I do not see how manifest arrays facilitate ad-hoc programming. However, they are useful or necessary in quite a few non ad-hoc contexts. (Think of parameter lists of varying lengths.) [...] Quote: > Up to now, it has been argued that COMMAND classes can do the > job better because they make the command set more explicit and > are more extendable.
I tend to agree with that reasoning. Naturally, on occasion I have coursed the absence of routine pointers/closures/etc. when I wanted to get something together quickly, but in the long run I have generally appreciated the increased clarity of an approach that requires me to name the abstractions that I use. Quote: > >Regarding the second paper (generic creation), I am happy to see that > >!! will be replaced by a keyword. One of the problems I always had with > >the Eiffel 3 syntax was the proliferation of special symbols (// and \\ > >are other examples). > There is also some asymetry since one can declare infix operators > with special symbols but not with ordinary identifiers (like the > logical operators `and', `or', let alone `and then', `or else').
The problem with allowing the introduction of arbitrary operators leads to a host of parsing problems that far exceed their utility, I'm afraid. It would be nice to have a Smalltalk style way of defining parameter lists, but again I doubt whether the benefits (after all, it's just syntactic sugar) justify the costs. There are too many languages around already with lots of features that were simply added because somebody thought they were "neat". Quote: > The language should treat all operators alike, regardless of the > characters they consist of. FWIW, I find keyword syntax usually > more readable, since longer sequences of special symbols tend to > look like noise; however, I think most of us accept a set of > arithmetic operator symbols in order to write concise formulae.
Yes. The case for arithmetic operators is different, because they are so fundamental that everybody immediately understands what "+" or "-" mean. [...] Quote: > This features set_zero and set_one should be constants of the class, > in current Eiffel to be implemented as once functions (another kludge, > to compensate for the lack of constants for arbitrary classes). These > are (should be) creation routines so you can invoke them without a > CURRENT object.
This is precisely my point. Actually, if you look at class NUMERIC (aside from the confusing division semantics), you will notice that there are two routines called "one" and "zero". Clearly, they are only useful if you already have an element of that type (you can use them in a post- or precondition). There is no way to create an element of this value without either throwing encapsulation out of the window or creating other irritations. I think that the proposal recognizes this, too. What I question is the specification of create ... end clauses on a case-by-case basis. As far as I am concerned, every heir of FIELD should be forced to implement set_zero and set_one as creation routines. Quote: > >Thus, I would much prefer a proposal that allows part of the "creation" > >section to belong to the signature of the class. > I agree. In fact, the GENERIC_CREATORS does effectively make the > creation list part of the required signature of the class.
Yes, but on a case-by-case basis, which is the problem I have with it. Reimer Behrends
|
Sat, 24 Mar 2001 03:00:00 GMT |
|
|
Juergen Schlegelmil #9 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Quote:
[ ... ] >> Rather than providing a generic TUPLE class, it would have been >> cleaner (at least IMHO) to provide means to denote constants for >> normal classes. This would also help with the STRING constant >> problem discussed in another thread, and would allow one to have >> constants of other classes (POINT, COMPLEX, etc.) as well, without >> the need for special treatment by the compiler. >While I tend to agree with most of your sentiments, there is no real >need to have class-specific constants. IMO it is quite sufficient to be >able to write > c := complex(1.0, 0.0) >or something similar. Keep in mind that any class "constant" has to >satisfy the class invariant, which for an arbitrary class is tantamount >to given those constants the semantics of a creation routine.
The right hand side of the above assigment _is_ a constant, at least in my understanding. I did not mean fancy syntax like [1.0,0.0] to denote a COMPLEX; just a (globally) unique constructor name with suitable arguments is sufficient. BTW, I later realized that special compiler treatment is still necessary to distinguish between identifiers and strings (and numbers, of course), so this will not end the discussion about manifest strings (but it would make the introduction of a CONSTANT_STRING easier since you can choose it if you need it on a case-by-case basis). Regards, Jrgen -- /-----------------------------------------------------------------------------\ Juergen Schlegelmilch http://www.informatik.uni-rostock.de/~schlegel
University of Rostock, Computer Science Department, 18051 Rostock, Germany
|
Sat, 24 Mar 2001 03:00:00 GMT |
|
|
Franck Arnau #10 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
Loryn Jenkins: [Iterating-Several-Actions problems] Quote: > How so?
I don't have time to repeat in detail what is already in c.l.e. archives, just briefly a few things of the top of my head: - It breaks the "Current.feature" is the same as "feature" (an altogether different feature can be called under replication). - I believe the magic rebinding is not intended to be deep -- the replication must be fully described in a single inheritance clause -- so it is intended to fail when the replicable renames occur in different classes merged later. - It's impossible to get more than one part object (which seriously reduces the usability/consistency of the construct). Fixing those problems is very likely to make the construct even more complex and prone to dangerous side effects. Multiple inheritance is already quite complex, and the feature is hardly missed by practising Eiffelists, so do we really need it? We certainly don't need Iterating-Several-Actions if we have ROUTINE/TUPLE. Bertrand Meyer once said: "the language [...] should provide one good way to express operations of interest; it should avoid providing two". Replication, feature objects and the ordinary command pattern makes three ways to do the same thing. --
|
Sat, 24 Mar 2001 03:00:00 GMT |
|
|
Alexander Kogtenko #11 / 35
|
Tuples, iterators, and multiple return values in Eiffel?
... Quote: > As to the introduction of a ROUTINE class, I have to admit that the > thought makes me a bit jumpy. I do not believe such an addition is > necessary, and while I have seen several requests for the addition of > such a feature, I would like to know the rationale behind it (it has > been omitted from the paper).
... From my point of view the proposed extension is much like Java reflection API. In order to be complete, other classes which reflect Eiffel structure should be introduced: FEATURE_, ATTRIBUTE, VARIABLE, CONSTANT and, maybe, others (e.g., CLASS_). One of the reason is that Eiffel does not make a distinction between attributes and functions without arguments. From the other hand, introduction of ROUTINE/TUPLE types to implement iterators and nothing else seems to be strange. -- Alexander Kogtenkov Object Tools, Moscow
|
Sun, 25 Mar 2001 03:00:00 GMT |
|
|
Page 1 of 3
|
[ 35 post ] |
|
Go to page:
[1]
[2] [3] |
|