Tuples, iterators, and multiple return values in Eiffel? 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. ???Eiffel idiom for multiple return values???

2. C-API, Tuple return value refcounts

3. return multiple values from an awk function?

4. Wait ms Timer Multiple returning inaccurate timer value

5. multiple values in a return from function

6. Multiple return values

7. multiple return values

8. Multiple return values

9. Newbie on multiple return values

10. multiple return values for functions

11. Multiple return values

12. 1st-class method closures (was Re: Multiple return values)

 

 
Powered by phpBB® Forum Software