Eiffel is a 10-year-old language which seems to possess everything that D hopes to implement:  design-by-contract, compiled C performance, clean syntax, clean OO, templates, static typing, dynamic binding, multiple inheritance, garbage collection, etc.  It's worth a hard look as a source of inspiration.

Pay particular attention to concepts like Command-Query Separation, which connects to recent D threads about calling conventions ("Notice how the [need for] comments ... disappeared").

Also look at the granularity of class inheritance mechanism ("In C++, ... [t]he decision is made at the granularity of the class - that is, entire classes are merged or replicated...In the Eiffel model, the choice between merging and replication is made at the feature granularity").

Finally the C++ critique cited below is well worth a read.  "The C++?? Critique is an analysis of some of the flaws of C++....The critique uses Java and Eiffel as comparisons to C++ to give a more concrete feel to the criticisms, viewing conceptual differences rather than syntactic ones as being more important."

Mark


C++ comparisons to Eiffel http://www.elj.com/eiffel/cpp_report_980807.txt http://www.elj.com/eiffel/lj/eiffel-cpp-map/

C++ critique
http://www.elj.com/cppcv3/

Advanced Introduction to Eiffel http://www.elj.com/eiffel/intro/

Eiffel FAQ
http://www.faqs.org/faqs/eiffel-faq/

GNU Eiffel
http://smarteiffel.loria.fr/index.html

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:aohv4n$o7g$1@digitaldaemon.com...
> Eiffel is a 10-year-old language which seems to possess everything that D
hopes
> to implement:  design-by-contract, compiled C performance, clean syntax,
clean
> OO, templates, static typing, dynamic binding, multiple inheritance,
garbage
> collection, etc.  It's worth a hard look as a source of inspiration.

multiple inheritance? I didn't know that was planned for D.

"... Although D and Java share the notion that garbage collection is good and multiple inheritance is bad ..."

Anyway a comparison between D and Eiffel would be interesting.

Eiffel has a different form of virtual methods then D.
Eiffel is "pure OO" (D is a hybrid with standard datatypes).
D doesn't have multi inheritance (and I don't think it's planned. Walter?).
D has type casting.
D is C/C++ based (Eiffel is not).

I wouldn't be supprised if D outperforms Eiffel (because it is not pure OO
and because Walter programmed it ;) ).

Good or bad these are substantial differences, I think.

Eiffel does have some nice things, that may be useful in D.  The ability to remove or rename methods (however, I can also see disadvantages to this such as code learnability and reusability).

I do think that Walter would have well reserached simular languages to D making sure that he wasn't repeating something that has already been done. I'm sure he would have looked into a language as popular as Eiffel.

Anyway good comments.  You should look deeper into D and see if there's anything good in Eiffel you would like in D.

>Anyway good comments.  You should look deeper into D and see if there's anything good in Eiffel you would like in D.

Object persistence (or serialization): you can deep_copy/deep_clone an entire inter-linked structure by just specify the root object; then you can save and retrieve that whole structure either to a disk file or over a network connection.

There has been some discussion on this topic before.  Walter, is there any plan to implement it?

Yes I remember that. And I want , I want it, please?

<someanon@yahoo.com> wrote in message news:aoid99$16ko$1@digitaldaemon.com...
> >Anyway good comments.  You should look deeper into D and see if there's anything good in Eiffel you would like in D.
>
> Object persistence (or serialization): you can deep_copy/deep_clone an
entire
> inter-linked structure by just specify the root object; then you can save
and
> retrieve that whole structure either to a disk file or over a network connection.
>
> There has been some discussion on this topic before.  Walter, is there any
plan
> to implement it?
>
>

someanon@yahoo.com wrote:
>>Anyway good comments.  You should look deeper into D and see if there's
>>anything good in Eiffel you would like in D.
> 
> Object persistence (or serialization): you can deep_copy/deep_clone an entire
> inter-linked structure by just specify the root object; then you can save and
> retrieve that whole structure either to a disk file or over a network
> connection.
> 
> There has been some discussion on this topic before.  Walter, is there any plan
> to implement it?

Pickling is implemented in DLI, in a robust manner.  Walter's previously expressed sentiment is that he wants introspection to be purpose-oriented (to serve tasks as they come up, rather than just throwing things in).  Look up the TypeInfo thread.

The problem with language picklers I've found has been a presumption that it can possibly do everything.  The things need to be transparent and user-controllable with a clean break between the high-level interface and the low-level nuts and bolts.

Once I get back to DLI it'll be one of the things to revisit.  I'll look into Eiffel's method.

Eiffel and D share practically identical objectives.  They do not have "substantial differences" at the conceptual level.

The major differences are that (1) D wants to be closer to the hardware and (2)
D wants to look and feel like C++.  Goal (1) is reasonable -- though it has ill
effects on high-level goals.  Goal (2) is a mistake, because C++ is flawed at
all levels.

Unattributed quotations below are from "C++?? A Critique of C++" by Ian Joyner. Everyone should sit down for an hour and read the PDF.  It would elevate the level of thought and discussion about D.  The PDF is at http://www.elj.com/cppcv3/

If the D project succeeds, then it might end up looking like "Eiffel with pointers."  It probably should.  D will offer more capability at the low level but more awkwardness/ugliness at the high level.


> 
> Eiffel has a different form of virtual methods then D.

Not really.  The goals are practically identical.  Default virtual applies as in D.  Eiffel uses the dot notation like D.  Private is gone (and good riddance). D has static constructors and Eiffel has "once."  The C++ critique covers this topic in great detail.  "Virtual is an example of where C++ obscures the concepts of OOP."  "In Eiffel ... global analysis of the entire system is done to determine the truly polymorphic calls and accordingly construct the virtual tables."



> Eiffel is "pure OO" (D is a hybrid with standard datatypes).

I might quibble with both characterizations but that can pass.  It's instructive that Python recently unified its type/class distinction.  (Python types now act like classes.)  In C++, there is little difference between structs and classes (structs are public classes).

There is a more fundamental problem with the C++ type system.  "C++ is statically typed, but there are many mechanisms that allow the programmer to render it effectively untyped [e.g. type casting, void pointers], which means errors are not detected until a serious failure....Undermining the type system is not needed [in a well-designed language], as the type system is where the flexibility should be, not in the ability to undermine the type system."  That statement addresses the negative connotations carried by the "pure OO" epithet.

Take a look at how Eiffel handles the "gettor/settor" problem recently discussed on the list.  It's in the Critique too.



> D doesn't have multi inheritance (and I don't think it's planned. Walter?).

Then Eiffel wins on that score.  Eiffel even implements a name resolution technique that was advocated by Stroustroup for C++, but nixed in committee.

"Both Eiffel and C++ provide multiple inheritance. Java does not, claiming it
results in many problems. Instead Java provides interfaces [like D?], which are
similar to Objective C’s protocols. Sun claims [that] interfaces provide all the
desirable features of multiple inheritance....Eiffel has taken the approach that
multiple inheritance poses some interesting and challenging problems, but rises
to the challenge, and solves them elegantly. Nor does the order of inheritance
matter. All resolutions that the programmer must specify are given in the
inheritance clause of a class. This includes renaming to ensure that multiple
features inherited with the same name end up as multiple features with
unambiguous names, redefining, new export policies for inherited features,
undefining, and disambiguating with select. In all cases, the action taken by
the compiler, whether using fork or join semantics is made clear, and the
programmer has complete control."


> D has type casting.

See comments under pure-OO.  By the way, Stroustroup would like to get rid of type casting in C++.


> D is C/C++ based (Eiffel is not).

C/C++ is a flawed foundation and D is trying to fill in the cracks instead of laying a new one (Walter can correct the metaphor if I'm wrong on that).  I view D as an opportunity to break with C++ tradition and do things right.  The basis of D, or any language, should be software engineering concepts.


> I wouldn't be surprised if D outperforms Eiffel (because it is not pure OO
> and because Walter programmed it ;) ).

Very wrong.  Eiffel is a screamer.  From the Eiffel FAQ:

"How fast do Eiffel applications run? Eiffel is a statically typed object-oriented language using automatic memory management.  Many Eiffel compilers make use of the static typing and perform extensive global optimisations producing performance comparable with other well-optimised statically typed languages like C++."

Many Eiffel compilers produce C code as their output, so performance is as good as C and just as portable.


> Good or bad these are substantial differences, I think.

The languages have more similarities than differences.  They are chasing after identical software engineering goals in any case (two exceptions were noted above).


> Eiffel does have some nice things, that may be useful in D.  The ability to remove or rename methods (however, I can also see disadvantages to this such as code learnability and reusability).

Don't follow you. Eiffel is the king of learnability, readability, and reusability.


> I do think that Walter would have well researched similar languages to D making sure that he wasn't repeating something that has already been done. I'm sure he would have looked into a language as popular as Eiffel.

I hope so but it's never too late. I haven't heard Eiffel mentioned once in connection with D.  As far as I know, my post was the first mention.


> Anyway good comments.

Thanks.


> You should look deeper into D and see if there's
> anything good in Eiffel you would like in D.

It's not a matter of cherry-picking features and putting them in a blender.  We are talking about high-level language design.

I'd like D to be bolder about dropping C-isms and C-ish syntax.  I'd like D to have a solid foundation of nice, clean, orthogonal software engineering concepts instead of the mishmash heritage of C++.

The C++?? paper shows the problems of C++, and Eiffel shows how to do things right.  Between these two sources of inspiration I think D can strike a nice balance in its target domain.

Mark

D more simular to Ada, no pascal, no C, no Eiffel, C#, no ....oh I forget the rest.  The point is who do I agree with?  You can't all be right? ;) Everyone seems to have a differnt view.

All I was don't was providing some differnces, which in some cases you simply underlined, "good or bad".

PS - And java did you know I've also been told java can just as fast as C (and I believe both of you).  It all depends on what your doing and how much you know.

I'm going to make a stand right now!

D's more like Godel (pronounced go da hell).

* Past its due buy date.
* A logic language.
* Hated by all.
* Not used by anyone.
* Left to bleed when the grant money ran out.
* unloved.
* A pain to get running.
(NOT)

PS - this is not a flamer, I'm just having a bit of fun.

>> I do think that Walter would have well researched similar languages to D making sure that he wasn't repeating something that has already been done. I'm sure he would have looked into a language as popular as Eiffel.
>
>I hope so but it's never too late. I haven't heard Eiffel mentioned once in connection with D.  As far as I know, my post was the first mention.

Walter has definitely looked into Eiffel.  Design By Contract was "invented" by Bertrand Meyer, the inventor of Eiffel.  Walter liked Design By Contract enough to put it into his C++ compiler, and has included it as a major feature of D.

I brought up Eiffel's "Constrained Genericity" features a couple of times during earlier discussions of how templates should be done in D.  During those conversations, I seem to remember that Walter liked the capabilities of Eiffel, but not the syntax, and possibly not some of the heavy-handedness.

My personal experience is that Eiffel looks really good in the books (and I own several, as well as my own copy of EiffelStudio 5.1 from ISE), but is somewhat painful in practice.  It is entirely possible, and even probable, that the pain I have experienced is caused more by the substantial shift of paradigm and by poorly designed (at least IMHO) standard libraries.  I have found the ISE product (EiffelStudio) to have fairly buggy libraries, which tends to deaden my enthusiasm for all of the claims of good software engineering and so forth. Logically, I realize that there is a considerable difference between how good the tool can be and how well it is used, but it is depressing when the creators of the tool fail to use it properly.  It is especially depressing when you consider that EiffelStudio generally goes for over $2000 (my copy was $500 as a special introductory deal 'coz I took a training seminar, but still quite a bit for a development system that sits in an envelope in a drawer at my house and is never used).  I do not have tremendous experience with the GNU SmallEiffel effort, though I have repeatedly downloaded the elj-win32 package, installed it, and played around with it.  I probably need to spend some more concerted time with it at some point.

I have also discovered that the STL tends to be more capable than the EiffelBase libraries, although the EiffelBase is probably broader and easier for basic usage.  I am unfamiliar with Gobo or any of the other "standard" libaries for Eiffel.

I definitely think that Eiffel is a good language to examine for ideas.  I think that anyone planning on constructing an object oriented language should set aside a year or so and do a serious and in-depth read of "Object Oriented Software Construction, 2nd Edition", also written by Bertrand Meyer.  Such a reading will provide a tremendous insight both into some of the weirder problems that OO faces, and various solutions that have been proposed.  I like several Eiffel features.  I personally find the syntax mildly painful to read, but that is probably the whole paradigm issue again -- I also find most languages mildly painful to read until I've worked with them for awhile.  I think D could use some of the Eiffel functionality, though I would be perfectly happy if a more C-ish syntax was proposed.

I would like to point out, however, that Walter does have a more pragmatic approach than Bertrand.  During the seminar, I engaged Bertrand in a discussion of deterministic object finalization, and no matter how I phrased it or attempted to tackle it, he could never see any need for such a capability.  As such, Eiffel will probably never have deterministic object finalization (DOF), which makes it almost useless for certain categories of application.  Walter understood this need and worked with us to provide at least some level of DOF support (I'd still prefer an option to reference count, but I'll take what I can get, since it's much more than I could get from Bertrand).

Sorry, I'm not sure if that post really had any particular direction.  Just wanted to throw in another set of perspectives (and toss out some keywords for people who might be interested in looking at Eiffel ;-).  If I could summarize, I guess it would be that I would like D to take the good features of Eiffel, fill in the missing features (DOF, a few others that escape me at the moment), and make a more comfortable syntax for it all...

Mac

Oh, and while we're discussing things that Eiffel has and D doesn't ;-)

I *really* like "agents", otherwise known as "anonymous functions", "lambda functions", or "lambda expressions".  These are especially useful once your language has generic algorithms that can iterate over some form of a collection and do something (the Visitor pattern, if I remember correctly).  It is nice to be able to specify what you would like done at each point directly inline, rather than having to go somewhere else and write up a tiny little function and then pass that function to the generic algorithm.

This capability is so useful that the BOOST library has even figured out a way to do it from within C++, which is so painful to contemplate that I don't even want to start.  The interface is fairly nice, with a few kludges because of limitations of C++.

Eiffel sets off agents with a special keyword ("agent", not surprisingly).  The agent mechanism is not discussed in OOSC2 (Object Oriented Software Construction, 2nd Ed), so you'll have to retrieve some of the newer documentation for the Eiffel language to see how it works.  GNU SmallEiffel now has agent support, so they should have some documentation, or at least links to good documentation.

D could have a similar capability.  I think someone even suggested it during the for_each discussion, possibly with the "anon" keyword to set off the function body.

As a more concrete example, instead of:

void increment(long x)
{
x++;
}

void do_something(void)
{
// lots of code here

for_each(x, set_of_xs, increment);

// lots more code here
}


you can do:

void do_something(void)
{
// lots of code here

for_each(x, set_of_xs, anon(long x){x++;});

// lots more code here
}


without needing to write the trivial and mostly pointless increment() function and worry about if you are going to have a namespace collision with someone else who needed to do a similar task.

Of course, this can be abused.  anon(){} should only be used for very small functions -- putting a large function in such a place would make the code unreadable, and should use the standard "write a function and use the name here" method.  But for small behaviors that are not encapsulated in standard functions (which is STL's answer -- supply common functions for increment, decrement, etc), this capability is very nice.  It can actually make the generic algorithms worth using.  Without it, the amount of extra effort needed means that it would be easier to rewrite the generic algorithm than to use it.

Mac

Mac Reiter wrote:
> Oh, and while we're discussing things that Eiffel has and D doesn't ;-)
> 
> I *really* like "agents", otherwise known as "anonymous functions", "lambda
> functions", or "lambda expressions".  These are especially useful once your
> language has generic algorithms that can iterate over some form of a collection
> and do something (the Visitor pattern, if I remember correctly).  It is nice to
> be able to specify what you would like done at each point directly inline,
> rather than having to go somewhere else and write up a tiny little function and
> then pass that function to the generic algorithm.

I doish tooish.  Lambda in Python is generally next-to-useless in my experience, but any nested functions are very useful.  The problem is that doing it with only the function pointer is a rather hackish process called trampolines; basically on-stack function call building.  It's so limited, I tell you what.

We already have the engineering solution with delegates.  The "this" pointer can be a pointer to the stack frame which the nested function uses.  This would have slightly loosened restrictions over trampolining, and will definitely be a lot simpler.

I also want frozen-scope nested functions, which is what I generally use Python's nested functions for.  That would involve allocating a struct and filling it with the locals the nested function uses when the function pointer is retrieved.  It'll be easier to present as a matter of contrast once normal nested functions are implemented.