Ada vs Eiffel - Ada programmer approach

Ada vs Eiffel - Ada programmer approach

[Tomek Walkuski]

Hi group,

I do not want to start another flame war which language is better. I
think that Ada and Eiffel target same field and I want to ask you, Ada
programmers, about:
- what, in your opinion, is better in Ada, in contrast to Eiffel?
- what, in your opinion, is worse in Ada, in contrast to Eiffel?

Please, share your thoughts if you have an experience in both
languages.

Re: Ada vs Eiffel - Ada programmer approach

[anon]

Ada is the better language, it was designed to be used in the real world, from 
the beginning. But as all languages Ada does have its weak points as well. 
But over time with each new release of the specs the language will grow to an 
even better language. 

As for Eiffel, well like PASCAL it was designed as a teaching tool.  Eiffel 
extends the tools for the educator to handle OOPs where PASCAL does not.  
And like PASCAL, there are some who have introduce the language real world, 
but just like PASCAL, they should left it is the educational world.

Then again, I think schools should have their own OS that the general public 
can not purchase.  Forcing the general public to learn to choose an OS they 
want, the best OS for the job they are using the system for, instead of just 
forcing everyone to learn Windows. Because there is no perfect OS. 



In <405b5054-4c8f-4e16-9ea8-503a9b9f976e@t21g2000yqi.googlegroups.com>, Tomek Walkuski <tomek.walkuski@gmail.com> writes:
>Hi group,
>
>I do not want to start another flame war which language is better. I
>think that Ada and Eiffel target same field and I want to ask you, Ada
>programmers, about:
>- what, in your opinion, is better in Ada, in contrast to Eiffel?
>- what, in your opinion, is worse in Ada, in contrast to Eiffel?
>
>Please, share your thoughts if you have an experience in both
>languages.

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

anon wrote:

> As for Eiffel, well like PASCAL it was designed as a teaching tool.

No. All essential Eiffel reading illustrates the opposite is true
about Eiffel.

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

Tomek Walkuski wrote:
> Hi group,
> 
> I do not want to start another flame war which language is better. I
> think that Ada and Eiffel target same field 

Ah, really? :-)


- Eiffel has garbage collection by default. Good for programs
  that can afford it.

- Eiffel offers a little less to support systems/hardware
  programming directly
 (for example, the base type system is frozen, which means
  that you cannot have basic types of the range 0 .. 100 kind,
  the advice being to use DbC assertions instead.  For bit
  operations we can use features from class NATURAL_32 ...
  There is class POINTER/POINTER_REF; it may be necessary
  to use "extern",  i.e. C, for hardware address things...
  Not sure about the latter, though.  Ada's loop is more
  flexible, which I guess matters when a program is to run
  in 64kB or less, or when I want tight control over inner
  loops).

- Eiffel has, or used to have, a "standardized" separate cluster
  language for namespace things and also configuration.
  (Currently being, uh, reworked?) I like the configuration part
  because it removes vendor specific language without impeding
  vendors I should think.
  You can't see the "namespaces" in the source proper. Good or bad?
  Advice is: Use EiffelStudio.

- Eiffel's cuncurrency features are basically experimental.
  (Side note: the Redomond amoeba has recently embraced the
  word "task".)  While Eiffel's "separate" and SCOOP are
  defined, class THREAD is mentioned a lot ...
  The SmartEiffel language is said not to be  thread safe at
  this time.

- Ada's separate specification is only possible using deferred
  classes in Eiffel.  You can then use the cluster language to
  rename this or that class as a "body" class, implementing
  any deferred feature.  Using deferred this way seems like a
  misuse to me.

- Eiffel has full multiple inheritance. Not sure this is
  a big deal, in practice, compared to mix-in generics, but it
  is being used to add characteristics such as HASHABLE or
  INDEXABLE.  Seems somewhat less "flexible" than Ada generic
  actuals that can be supplied from just about anywhere,
  including from local scopes.  (Not sure there are no Eiffel
  tricks here, using [anonymous] agents, though.)

- Eiffel's Design by Contract is only beginning to be present
  in Ada.  (Not mentioning SPARK.) Still praying...

- Eiffel is flat (anonymous agents being an exception of sorts...),
  Ada allows nesting, including local types.

I really missed the explicit packaging structure of Ada when
writing the same (sequential) program in both Eiffel and Ada.

Re: Ada vs Eiffel - Ada programmer approach

[Pascal Obry]

Tomek Walkuski a �crit :
> - what, in your opinion, is better in Ada, in contrast to Eiffel?

- a strong standard (Eiffel community is sadly split these days).

- string type system

- tasking

- distributed annex

- support for interfacing with hardware (e.g. representation clauses).

- not everything is a class (composability of Ada, packages, tagged
types, child packages...)

- more components and binding to common libraries

- bigger and more active community

> - what, in your opinion, is worse in Ada, in contrast to Eiffel?

- memory management (not GC - I know that there is nothing in the
standard that forbid it - and this would be certainly really handful for
some domain)

- multiple inheritance

- DbC with pre-condition/post-condition/invariant

> Please, share your thoughts if you have an experience in both
> languages.

I just like to add that I like very much Eiffel (I've done some projects
with this language) and to me it is second best after Ada. Worse
learning for sure!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada vs Eiffel - Ada programmer approach

[Rugxulo]

Hi,

On May 24, 11:31 am, Pascal Obry <pas...@obry.net> wrote:
>
> I just like to add that I like very much Eiffel (I've done some projects
> with this language) and to me it is second best after Ada. Worse
> learning for sure!

Freudian slip?  :-)  I assume you meant "worth learning".

Re: Ada vs Eiffel - Ada programmer approach

[Ludovic Brenta]

Pascal Obry wrote on comp.lang.ada:
> Tomek Walkuski a écrit :
> > - what, in your opinion, is worse in Ada, in contrast to Eiffel?
>
> - memory management (not GC - I know that there is nothing in the
> standard that forbid it - and this would be certainly really handful for
> some domain)

I agree that it would be nice if some Ada compilers would provide an
optional garbage collector. One exists as a third-party add-on to GNAT
but I've never used it and it's not part of AdaCore's or the FSF's
distributions.

In fact, I would like it if the garbage collector could optionally log
all deallocations while the program runs, so I can find memory leaks,
correct them, and remove the garbage collector later :)

> - multiple inheritance

I'm not sure this is a good thing. In fact, I'm not sure simple
inheritance is always a good thing, either. I tend to prefer
composition and generics.

> - DbC with pre-condition/post-condition/invariant

When I read Bertrand Meyer's "Object-Oriented Software Construction",
I too thought that DbC was a brilliant idea. Now I'm less convinced. I
see two major drawbacks to DbC:

- pre/post conditions and invariants involve run-time checks most of
the time (if not all the time). They slow the program down if enabled,
or become useless when disabled for performance. I like static
checking much better; Ada provides a lot of that out of the box (much
more than Eiffel) and Spark goes way beyond even that.

- in most of the examples I saw in the literature, only very simple
subprograms would have a contract and the contract would mostly repeat
the body of the subprogram. This redundancy is counter-productive. For
more complex subprograms, it can be very difficult to write pre and
postconditions and invariants; Ada's pragma Assert provides what I
need in these (rare) cases  because I can put such pragmas in the
middle of a subprogram, for example.

--
Ludovic Brenta.

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Tue, 26 May 2009 06:37:49 -0700 (PDT), Ludovic Brenta wrote:

> Pascal Obry wrote on comp.lang.ada:
>> Tomek Walkuski a �crit :
>>> - what, in your opinion, is worse in Ada, in contrast to Eiffel?
>>
>> - memory management (not GC - I know that there is nothing in the
>> standard that forbid it - and this would be certainly really handful for
>> some domain)
> 
> I agree that it would be nice if some Ada compilers would provide an
> optional garbage collector. One exists as a third-party add-on to GNAT
> but I've never used it and it's not part of AdaCore's or the FSF's
> distributions.
> 
> In fact, I would like it if the garbage collector could optionally log
> all deallocations while the program runs, so I can find memory leaks,
> correct them, and remove the garbage collector later :)

I don't think GC is a good idea. The language should allow scopes of all
objects to be static. In most cases GC is used order to overcome certain
language limitations like that T'Class cannot be a component.

>> - multiple inheritance
> 
> I'm not sure this is a good thing. In fact, I'm not sure simple
> inheritance is always a good thing, either. I tend to prefer
> composition and generics.

But generics is a case of inheritance. When a type is put in a generic
package, then an instance of the package produces a type that inherits the
operations defined in the package. This is inheritance. BTW generics
provide multiple inheritance:

generic
   type T is ...;   
package A is
   procedure Foo (X : in out T);
end A;

generic
   type T is ...;   
generic B is
   procedure Bar (X : in out T);
end B;

type Multiple is ...;
package Inherit_From_A is new A (Multiple);
package Inherit_From_B is new B (Multiple);

now Foo is inherited from A and Bar is inherited from B. It is possible to
construct an example with generics that would not only add operations but
also components to a record type. Nobody claims this bad...

>> - DbC with pre-condition/post-condition/invariant
> 
> When I read Bertrand Meyer's "Object-Oriented Software Construction",
> I too thought that DbC was a brilliant idea. Now I'm less convinced. I
> see two major drawbacks to DbC:
> 
> - pre/post conditions and invariants involve run-time checks most of
> the time (if not all the time). They slow the program down if enabled,
> or become useless when disabled for performance.

There should be no run-time contract checks. That is inconsistent:

function Return_False return Boolean is
    -- The contract of Return_False is to return False
begin
   if Is_OK (Return_False) then
      -- Is_OK returns True if Return_False satisfies its contract
      return True;
   else
      return False;
   end if;
end Return_False;

Now, if Return_False is OK, then Is_OK returns True and then Return_False
returns True and so it is not OK. So is it, or is it not?

Likewise Constraint_Error propagation is not a contract violation it is a
part of the contract mandated by the language. It *must* propagate in
specified cases, otherwise the program is incorrect.

> I like static
> checking much better; Ada provides a lot of that out of the box (much
> more than Eiffel) and Spark goes way beyond even that.

Yes.

> - in most of the examples I saw in the literature, only very simple
> subprograms would have a contract and the contract would mostly repeat
> the body of the subprogram. This redundancy is counter-productive.

That is when the contract is thought to be an equivalent of correctness
proof. But it is not. A contract is much weaker, so that a program which
fulfills its contract is not necessarily a correct program. Weaker
contracts have an advantage to remain statically checkable for complex
programs, leaving proofs of correctness aside.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Tue, 26 May 2009 06:37:49 -0700 (PDT), Ludovic Brenta wrote:

>> - pre/post conditions and invariants involve run-time checks most of
>> the time (if not all the time). They slow the program down if enabled,
>> or become useless when disabled for performance.
> 
> There should be no run-time contract checks. That is inconsistent:
> 
> function Return_False return Boolean is
>     -- The contract of Return_False is to return False
> begin
>    if Is_OK (Return_False) then
>       -- Is_OK returns True if Return_False satisfies its contract
>       return True;
>    else
>       return False;
>    end if;
> end Return_False;
> 
> Now, if Return_False is OK, then Is_OK returns True and then Return_False
> returns True and so it is not OK. So is it, or is it not?

Eiffel defines the conditions for when a contract's assertions
will be tested. In particular, not every call will
trigger the tests. ;-)  So the never ending loop above is
not a problem within the Eiffel DbC framework of definitions.
(The stack may overflow, though.)

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Tue, 26 May 2009 19:26:42 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Tue, 26 May 2009 06:37:49 -0700 (PDT), Ludovic Brenta wrote:
> 
>>> - pre/post conditions and invariants involve run-time checks most of
>>> the time (if not all the time). They slow the program down if enabled,
>>> or become useless when disabled for performance.
>> 
>> There should be no run-time contract checks. That is inconsistent:
>> 
>> function Return_False return Boolean is
>>     -- The contract of Return_False is to return False
>> begin
>>    if Is_OK (Return_False) then
>>       -- Is_OK returns True if Return_False satisfies its contract
>>       return True;
>>    else
>>       return False;
>>    end if;
>> end Return_False;
>> 
>> Now, if Return_False is OK, then Is_OK returns True and then Return_False
>> returns True and so it is not OK. So is it, or is it not?
> 
> Eiffel defines the conditions for when a contract's assertions
> will be tested. In particular, not every call will
> trigger the tests. ;-)

Certainly. They are tested when do not assert contracts. (:-))

>  So the never ending loop above is
> not a problem within the Eiffel DbC framework of definitions.
> (The stack may overflow, though.)

There is no loop since "contract is satisfied" is not a variable. Otherwise
you cannot design "by contract", obviously. Even considering some
test-driven-design rubbish, since the target is oscillating, your design
will never end. You cannot work around an inconsistency.

Whatever you check or assert at run-time that is not a contract. The effect
of checking is a behavior. Contract check cannot be a behavior. That is the
inconsistency of Eiffel's approach, as well as one of Ada's pragmas if they
have any run-time effects.

Ada's static typing system and SPARK do it right.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

>>> Now, if Return_False is OK, then Is_OK returns True and then Return_False
>>> returns True and so it is not OK. So is it, or is it not?
>> Eiffel defines the conditions for when a contract's assertions
>> will be tested. In particular, not every call will
>> trigger the tests. ;-)
> 
> Certainly. They are tested when do not assert contracts. (:-))

Exactly.  That's an inside view of DbC modules.

>>  So the never ending loop above is
>> not a problem within the Eiffel DbC framework of definitions.
>> (The stack may overflow, though.)
> 
> There is no loop since "contract is satisfied" is not a variable. Otherwise
> you cannot design "by contract", obviously.

The Eiffel answer is that yes, you can do that because
in order to get anything done, assertion checking must
not happen at times.  That's a reasonable design, because
there is no practical alternative. ;-)


> Ada's static typing system and SPARK do it right.

SPARK imposes limitations that are not present when employing
DbC.  SPARK cannot replace DbC, or improve it, and vice versa,
basically because DbC (not used as static assertions only) and
SPARK are largely incommensurable.

This means that DbC and SPARK are both right:
You will --# hide certain uses of Ada constructs
in SPARK, for example.  Likewise, you will not
check all assertions in some situations when using
Eiffel DbC.

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Tue, 26 May 2009 19:59:26 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> There is no loop since "contract is satisfied" is not a variable. Otherwise
>> you cannot design "by contract", obviously.
> 
> The Eiffel answer is that yes, you can do that because
> in order to get anything done, assertion checking must
> not happen at times.  That's a reasonable design, because
> there is no practical alternative. ;-)

Confusing things? (:-))

>> Ada's static typing system and SPARK do it right.
> 
> SPARK imposes limitations that are not present when employing
> DbC.

More checks you want to do more language limitations you need. Nothing is
for free.

> SPARK cannot replace DbC, or improve it, and vice versa,
> basically because DbC (not used as static assertions only) and
> SPARK are largely incommensurable.

Nope, the point is not how many checks, it is about consistency of checks.
SPARK does it consistently, Eiffel does not.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Pascal Obry]

Dmitry A. Kazakov a �crit :
> Nope, the point is not how many checks, it is about consistency of checks.
> SPARK does it consistently, Eiffel does not.

Well SPARK and Eiffel are playing the same game at all!

SPARK imposes some very strong constraints on the developer (for good
reasons) to build and *prove* something right.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada vs Eiffel - Ada programmer approach

[Pascal Obry]

Pascal Obry a �crit :
> Dmitry A. Kazakov a �crit :
>> Nope, the point is not how many checks, it is about consistency of checks.
>> SPARK does it consistently, Eiffel does not.
> 
> Well SPARK and Eiffel are playing the same game at all!
                          ^^^
                          NOT

Sorry!

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Tue, 26 May 2009 22:14:18 +0200, Pascal Obry wrote:

> Dmitry A. Kazakov a �crit :
>> Nope, the point is not how many checks, it is about consistency of checks.
>> SPARK does it consistently, Eiffel does not.
> 
> Well SPARK and Eiffel are playing the same game at all!
> 
> SPARK imposes some very strong constraints on the developer (for good
> reasons) to build and *prove* something right.

Yes. The amount of checks and so the limitations imposed by them depends on
the word "something" you used above. You can require to prove less or more,
but never all.

Many programmers are already satisfied with much less than SPARK offers,
e.g. with strong static typing, which gives a proof of no type errors. But,
continuing this example, dynamic typing gives no such proof. Therefore it
is either not strong (most of dynamically typed language are in fact weakly
typed) or else the dynamic type checks (like dispatch in Ada) are not error
checks, but merely correct contracted behavior.

In my view run-time checks as a form of contract enforcement is a bad
practice, which makes the programmer believe in safety that does not exist.
Instead of that he should consider his design to define the behavior for
the cases where the "contract" can be violated, making a new contract that
is never violated and thus requires no checks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> function Return_False return Boolean is
>     -- The contract of Return_False is to return False
> begin
>    if Is_OK (Return_False) then
>       -- Is_OK returns True if Return_False satisfies its contract
>       return True;
>    else
>       return False;
>    end if;
> end Return_False;

Or, as I would write it:

return Is_OK (Return_False);

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

Re: Ada vs Eiffel - Ada programmer approach

[Tim Rowe]

Ludovic Brenta wrote:
> When I read Bertrand Meyer's "Object-Oriented Software Construction",
> I too thought that DbC was a brilliant idea. Now I'm less convinced. I
> see two major drawbacks to DbC:
> 
> - pre/post conditions and invariants involve run-time checks most of
> the time (if not all the time). They slow the program down if enabled,
> or become useless when disabled for performance. I like static
> checking much better; Ada provides a lot of that out of the box (much
> more than Eiffel) and Spark goes way beyond even that.
> 
> - in most of the examples I saw in the literature, only very simple
> subprograms would have a contract and the contract would mostly repeat
> the body of the subprogram. This redundancy is counter-productive. For
> more complex subprograms, it can be very difficult to write pre and
> postconditions and invariants; Ada's pragma Assert provides what I
> need in these (rare) cases  because I can put such pragmas in the
> middle of a subprogram, for example.


I still think it's a brilliant idea, but suffers from *Design* by 
Contract getting confused with *Programming* by Contract; not least 
because "Design by Contract" is a trademark, so people needed a 
different name to refer to the approach, but I'm not sure Bertrand Meyer 
always kept the distinction clear either.

Both of the problems you describe are programming issues, not design 
issues.  There's nothing about the *design* process that mandates any 
run-time checks or that requires you to have pre- and post-conditions 
expressed in the target language. That's a matter for coding standards. 
To me, Design by Contract simply means working out and documenting in 
advance under what circumstances a section of code can legitimately be 
entered, and, if that is satisfied, what we can guarantee on exit. 
Learning to do that rigorously and diligently has certainly improved my 
own design.

We had that before Meyer coined the term "Design by Contract" of course. 
We used to call it "specification" ;-)

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

Tim Rowe schrieb:
> Ludovic Brenta wrote:

>> - in most of the examples I saw in the literature, only very simple
>> subprograms would have a contract and the contract would mostly repeat
>> the body of the subprogram. This redundancy is counter-productive.

I tought that too, but don't consider redundancy counter-productive any
more; it makes me think twice.  In fact, trying to find a post-condition
---which must be consistent with the module invariant, for
which there isn't any support in Ada yet---has forced my to simplify
program structure. :-)  Isn't that a good thing?



>> For
>> more complex subprograms, it can be very difficult to write pre and
>> postconditions and invariants; Ada's pragma Assert provides what I
>> need in these (rare) cases  because I can put such pragmas in the
>> middle of a subprogram, for example.

Eiffel has "check" and "debug" which are more specific than
pragma Assert.


> Both of the problems you describe are programming issues, not design
> issues.  There's nothing about the *design* process that mandates any
> run-time checks or that requires you to have pre- and post-conditions
> expressed in the target language. That's a matter for coding standards.
> To me, Design by Contract simply means working out and documenting in
> advance under what circumstances a section of code can legitimately be
> entered, and, if that is satisfied, what we can guarantee on exit.

This "section of code" bit is important; loop invariants and
variants are part of Eiffel DbC.  Is there a loop variant
annotation is SPARK (so far, I didn't think there was).

Re: Ada vs Eiffel - Ada programmer approach

[Nicholas Paul Collin Gloucester]

On 2009-05-26, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:

|-------------------------------------------------------------------------|
|"Tim Rowe schrieb:                                                       |
|> Ludovic Brenta wrote:                                                  |
|                                                                         |
|>> - in most of the examples I saw in the literature, only very simple   |
|>> subprograms would have a contract and the contract would mostly repeat|
|>> the body of the subprogram. This redundancy is counter-productive."   |
|-------------------------------------------------------------------------|

Such redundancy is also exhibited in the SPARK literature.

|-------------------------------------------------------------------------|
|"I tought that too, but don't consider redundancy counter-productive any |
|more; it makes me think twice.  In fact, trying to find a post-condition |
|---which must be consistent with the module invariant, for               |
|which there isn't any support in Ada yet---has forced my to simplify     |
|program structure. :-)  Isn't that a good thing?                         |
|                                                                         |
|[..]"                                                                    |
|-------------------------------------------------------------------------|

Maybe, maybe not. Maintaining the pre-conditions and the
post-conditions and the imperative code in-between may be more work,
if no matter how much one is forced, the imperative code could not be
simplified any further.

Regards,
Colin Paul Gloster

Re: Ada vs Eiffel - Ada programmer approach

[Tim Rowe]

Georg Bauhaus wrote:

> This "section of code" bit is important; loop invariants and
> variants are part of Eiffel DbC.  Is there a loop variant
> annotation is SPARK (so far, I didn't think there was).

My point is that SPARK doesn't need one for *design* by contract, only 
for *coding* by contract. I can (and do) *design* loop variants and 
invariants without having to actually represent them in the code.

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 26 mai, 17:07, Tim Rowe <spamt...@tgrowe.plus.net> wrote:
> I still think it's a brilliant idea, but suffers from *Design* by
> Contract getting confused with *Programming* by Contract; not least
> because "Design by Contract" is a trademark,

Clearly an abuse. I will never understand how it is allowed to make a
common expression a trade mark. If GNAT is a trade mark, it is Ok, if
Pepsi is a trade mark, it is Ok, but saying the expression "this
common noun" or "doing a common-verb" is a trade mark... pffff....

I even heard to say that "Happy Birthday" is a trade mark of some one.

Re: Ada vs Eiffel - Ada programmer approach

[Martin]

On Jun 4, 8:35 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> On 26 mai, 17:07, Tim Rowe <spamt...@tgrowe.plus.net> wrote:
>
> > I still think it's a brilliant idea, but suffers from *Design* by
> > Contract getting confused with *Programming* by Contract; not least
> > because "Design by Contract" is a trademark,
>
> Clearly an abuse. I will never understand how it is allowed to make a
> common expression a trade mark. If GNAT is a trade mark, it is Ok, if
> Pepsi is a trade mark, it is Ok, but saying the expression "this
> common noun" or "doing a common-verb" is a trade mark... pffff....
>
> I even heard to say that "Happy Birthday" is a trade mark of some one.

The song "Happy Birthday" has IP rights (see http://en.wikipedia.org/wiki/Happy_Birthday_to_You)
but I don't think the phrase does...

Cheers
-- Martin

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 4 juin, 11:46, Martin <martin.do...@btopenworld.com> wrote:
> > I even heard to say that "Happy Birthday" is a trade mark of some one.
>
> The song "Happy Birthday" has IP rights (seehttp://en.wikipedia.org/wiki/Happy_Birthday_to_You)
> but I don't think the phrase does...
>
> Cheers
> -- Martin

Damned, this is the end :(

Re: Ada vs Eiffel - Ada programmer approach

[Jean-Pierre Rosen]

Hibou57 (Yannick Duch�ne) a �crit :
> On 26 mai, 17:07, Tim Rowe <spamt...@tgrowe.plus.net> wrote:
>> I still think it's a brilliant idea, but suffers from *Design* by
>> Contract getting confused with *Programming* by Contract; not least
>> because "Design by Contract" is a trademark,
> 
> Clearly an abuse. I will never understand how it is allowed to make a
> common expression a trade mark. If GNAT is a trade mark, it is Ok, if
> Pepsi is a trade mark, it is Ok, but saying the expression "this
> common noun" or "doing a common-verb" is a trade mark... pffff....
> 
> I even heard to say that "Happy Birthday" is a trade mark of some one.
> 
I believe that "free" is a trade-mark of Coca-Cola...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada vs Eiffel - Ada programmer approach

[ardjussi]

On 4 kesä, 10:35, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr>
wrote:
> On 26 mai, 17:07, Tim Rowe <spamt...@tgrowe.plus.net> wrote:
>
> > I still think it's a brilliant idea, but suffers from *Design* by
> > Contract getting confused with *Programming* by Contract; not least
> > because "Design by Contract" is a trademark,
>
> Clearly an abuse. I will never understand how it is allowed to make a
> common expression a trade mark.

Is it a common expression? Was the word "contract" alone in use in
program design or programming before DbC was coined? For me the single
word was totally new for any meaning in computer programming at
something 1990. The phrase "design by contract" may have occasionally
appeared in sales of construction or even program design services, but
not as a technical term.

br Jussi

If GNAT is a trade mark, it is Ok, if
> Pepsi is a trade mark, it is Ok, but saying the expression "this
> common noun" or "doing a common-verb" is a trade mark... pffff....
>
> I even heard to say that "Happy Birthday" is a trade mark of some one.

Re: Ada vs Eiffel - Ada programmer approach

[Jeffrey R. Carter]

ardjussi wrote:
> 
> Is it a common expression? Was the word "contract" alone in use in
> program design or programming before DbC was coined? For me the single
> word was totally new for any meaning in computer programming at
> something 1990. The phrase "design by contract" may have occasionally
> appeared in sales of construction or even program design services, but
> not as a technical term.

The term "contract model" to describe Ada package specifications has been around 
for quite a while. I think I first heard a package specification described as a 
contract in 1984.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18

Re: Ada vs Eiffel - Ada programmer approach

[Jeffrey R. Carter]

Ludovic Brenta wrote:
> Pascal Obry wrote on comp.lang.ada:
> 
>> - multiple inheritance
> 
> I'm not sure this is a good thing. In fact, I'm not sure simple
> inheritance is always a good thing, either. I tend to prefer
> composition and generics.

I agree. I never create tagged types, except to obtain finalization. I think the 
widespread acceptance of programming by extension, even by People Who Should 
Know Better, represents the triumph of those who emphasize ease of writing over 
ease of reading.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Tue, 26 May 2009 18:21:57 GMT, Jeffrey R. Carter wrote:

> Ludovic Brenta wrote:
>> Pascal Obry wrote on comp.lang.ada:
>> 
>>> - multiple inheritance
>> 
>> I'm not sure this is a good thing. In fact, I'm not sure simple
>> inheritance is always a good thing, either. I tend to prefer
>> composition and generics.
> 
> I agree. I never create tagged types, except to obtain finalization. I think the 
> widespread acceptance of programming by extension, even by People Who Should 
> Know Better, represents the triumph of those who emphasize ease of writing over 
> ease of reading.

Tagged type represents just one case in inheritance. When you write

   subtype S is T (<constraint>)

you inherit form T. When you write

   type I is range <>;

you inherit from universal integer, etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 26 mai, 20:21, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> I agree. I never create tagged types, except to obtain finalization. I think the
> widespread acceptance of programming by extension, even by People Who Should
> Know Better, represents the triumph of those who emphasize ease of writing over
> ease of reading.

So how do you do extentions ?
Did you never need this ?

Re: Ada vs Eiffel - Ada programmer approach

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
> On 26 mai, 20:21, "Jeffrey R. Carter"
>
> <spam.jrcarter....@nospam.acm.org> wrote:
> > I agree. I never create tagged types, except to obtain finalization. I think the
> > widespread acceptance of programming by extension, even by People Who Should
> > Know Better, represents the triumph of those who emphasize ease of writing over
> > ease of reading.
>
> So how do you do extentions ?
> Did you never need this ?

The question is not really "how do you do extension", but "why do you
do extension". In my experience, composition is usually a more correct
choice. There are, of course, some cases where extension is good but
my inheritance hierarchies are usually very shallow.

For example, if you want some record type T to become controlled, you
don't have to make extend Ada.Finalization.Controlled; you don't even
have to make T tagged. You can use a mixin instead:

with Ada.Finalization;
package P is
   type T is private; -- note: not publicly tagged
private
   type Controller_T (Enclosing : access T) is
     new Ada.Finalization.Controlled with null record;
   overriding procedure Initialize (C : in out Controller);
   overriding procedure Adjust (C : in out Controller);
   overriding procedure Finalize (C : in out Controller);
   type T is record -- note: not privately tagged, either.
      Controller : Controller_T (Enclosing => T'Access);
      -- other components...
   end record;
end P;

The primitive subprograms Initialize, Adjust and Finalize can see the
entire enclosing object through the discriminant of C.

--
Ludovic Brenta.

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Thu, 4 Jun 2009 02:02:01 -0700 (PDT), Ludovic Brenta wrote:

> Yannick Duch�ne wrote on comp.lang.ada:
>> On 26 mai, 20:21, "Jeffrey R. Carter"
>>
>> <spam.jrcarter....@nospam.acm.org> wrote:
>>> I agree. I never create tagged types, except to obtain finalization. I think the
>>> widespread acceptance of programming by extension, even by People Who Should
>>> Know Better, represents the triumph of those who emphasize ease of writing over
>>> ease of reading.
>>
>> So how do you do extentions ?
>> Did you never need this ?
> 
> The question is not really "how do you do extension", but "why do you
> do extension".

In order to reuse the interface and some implementations of these
operations.

> In my experience, composition is usually a more correct
> choice.

It is not a choice because composition inherits to the record type
interface and provides an implementation of the interface (e.g. member
access, assignment of the record etc). In a more general case composition
inherits to the container interface.

So the question is why do you inherit to the container rather than to
number, task, file, employee etc?

> There are, of course, some cases where extension is good but
> my inheritance hierarchies are usually very shallow.

Extension /= inheritance. It is a case of inheritance.

There is nothing that could replace inheritance, because there is no way to
"invent" a new type out of nothing. Whatever type algebra operation you
take, it always uses some building blocks (the arguments) from which you
inherit the interface of the result. There is nothing really useful beyond
inheritance. Even if you use the minimal possible type-algebraic operation
in Ada:

   type T (<>) is limited private;

you still inherit a lot of things. For example attributes, like X'Address.

> For example, if you want some record type T to become controlled, you
> don't have to make extend Ada.Finalization.Controlled; you don't even
> have to make T tagged.

All types are "controlled" in Ada, in the sense that they are properly
finalized upon destruction.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 4 juin, 11:19, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> There is nothing that could replace inheritance, because there is no way to
> "invent" a new type out of nothing. Whatever type algebra operation you
> take, it always uses some building blocks (the arguments) from which you
> inherit the interface of the result. There is nothing really useful beyond
> inheritance. Even if you use the minimal possible type-algebraic operation
> in Ada:
>
>    type T (<>) is limited private;
>
> you still inherit a lot of things. For example attributes, like X'Address.

That's true. But in some languages, like Eiffel, inheritance comes
with classes, and classes are too much things at the same time. Many
things could be said about it, but the first one in this context,
would be : inheritance is one thing, dynamic dispatching is another.

As Ludovic said (I agree with what he said), most of time, things can
be done another way.

Through time, I've learned that the tipical OO inheritance+dynamic-
dispatching, is rarely needed. Although when it is needed, it is...
Through time I've also learned that when it is needed, it is most of
time for some kind of advanced low level and basic type. Large scale
architecture can avoid it : not the inheritance, but the type driven
dynamic dispatching which confusingly comes with it in traditional OO
languages.

Hope I did not answer out of the subject :p

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Thu, 4 Jun 2009 05:14:56 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote:

> On 4 juin, 11:19, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> There is nothing that could replace inheritance, because there is no way to
>> "invent" a new type out of nothing. Whatever type algebra operation you
>> take, it always uses some building blocks (the arguments) from which you
>> inherit the interface of the result. There is nothing really useful beyond
>> inheritance. Even if you use the minimal possible type-algebraic operation
>> in Ada:
>>
>> � �type T (<>) is limited private;
>>
>> you still inherit a lot of things. For example attributes, like X'Address.
> 
> That's true. But in some languages, like Eiffel, inheritance comes
> with classes, and classes are too much things at the same time. Many
> things could be said about it, but the first one in this context,
> would be : inheritance is one thing, dynamic dispatching is another.

Right. It is a language design fault to bind these things together. Ada
probably made many mistakes, but not this one. In Ada inherited operations
do never dispatch because S inheriting to T is a plain type. Dispatch
happens strictly on T'Class. No polymorphic objects, no dispatch.

> As Ludovic said (I agree with what he said), most of time, things can
> be done another way.

I don't think so. I have an impression that Ludovic mixes S inheriting to T
with the use of both S and T within T'Class. The first does not imply the
second. It only makes the second possible. But if you do not need T'Class
nobody forces you to use it in Ada, unlikely to other OO languages.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Jeffrey R. Carter]

Hibou57 (Yannick Duch�ne) wrote:
> 
> So how do you do extentions ?

I don't.

> Did you never need this ?

There is nothing that can't be done more readably through composition.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 26 mai, 15:37, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> [...] Ada's pragma Assert provides what I
> need in these (rare) cases  because I can put such pragmas in the
> middle of a subprogram, for example.
>
> --
> Ludovic Brenta.

This is not the same as Eiffel assertions. Eiffel's assertions are
aware of the invokation contexte. Let say you have a class C and a
method M and the class C has an invariant I. Then, if a client invoks
M, the invariant will be checked before M returns. That's Ok, this is
the same as with "in code assertions". But if M is invoked by anoher
method of the class, i.e. as an implementation method (this is very
common to use a public method for internal purpose), you will have
this : the client of C invok a method M2 which in turn will invok M
(the client may or may not know about it). In this context, the class
invariant will obviously be checked before returning from M2, but *it
will not be check before return from M*.

That is beceause M is allowed to left the class invariant in an
illegal state, as it may be the sole responsability of M2.

So, Eiffel's assertions are not the same as "in code assertions".
Eiffel's assertions are well formalized.

Re: Ada vs Eiffel - Ada programmer approach

[Ludovic Brenta]

On Jun 4, 9:30 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> On 26 mai, 15:37, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > [...] Ada's pragma Assert provides what I
> > need in these (rare) cases  because I can put such pragmas in the
> > middle of a subprogram, for example.
>
> > --
> > Ludovic Brenta.
>
> This is not the same as Eiffel assertions. Eiffel's assertions are
> aware of the invokation contexte. Let say you have a class C and a
> method M and the class C has an invariant I. Then, if a client invoks
> M, the invariant will be checked before M returns. That's Ok, this is
> the same as with "in code assertions". But if M is invoked by anoher
> method of the class, i.e. as an implementation method (this is very
> common to use a public method for internal purpose), you will have
> this : the client of C invok a method M2 which in turn will invok M
> (the client may or may not know about it). In this context, the class
> invariant will obviously be checked before returning from M2, but *it
> will not be check before return from M*.
>
> That is beceause M is allowed to left the class invariant in an
> illegal state, as it may be the sole responsability of M2.
>
> So, Eiffel's assertions are not the same as "in code assertions".
> Eiffel's assertions are well formalized.

I think my point was precisely that Ada assertions were different from
Eiffel's. I like the fact that, in Ada, I can place assertions in the
middle of a complex subprogram; this is not possible Eiffel, as you
aptly described. I agree that Eiffel's assertions are well-defined but
my argument is that they are less useful and more diffucult to use in
practice than the beauty of the design suggests.

--
Ludovic Brenta.

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

Ludovic Brenta schrieb:

> I think my point was precisely that Ada assertions were different from
> Eiffel's. I like the fact that, in Ada, I can place assertions in the
> middle of a complex subprogram; this is not possible Eiffel,

Yes, you can. You can place an assertion anywhere in an Eiffel program.
That is what the reserved word "check" is for.

Re: Ada vs Eiffel - Ada programmer approach

[Ludovic Brenta]

Georg Bauhaus wrote on comp.lang.ada:
> Ludovic Brenta schrieb:
>
> > I think my point was precisely that Ada assertions were different from
> > Eiffel's. I like the fact that, in Ada, I can place assertions in the
> > middle of a complex subprogram; this is not possible Eiffel,
>
> Yes, you can. You can place an assertion anywhere in an Eiffel program.
> That is what the reserved word "check" is for.

OK, I stand corrected. Thanks for that. But I think my earlier point
about DbC remains valid; what you just showed is that you can do Ada-
like assertions in Eiffel, too, instead of or as a complement to pre/
post conditions and invariants.

--
Ludovic Brenta.

Re: Ada vs Eiffel - Ada programmer approach

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> I think my point was precisely that Ada assertions were different from
> Eiffel's. I like the fact that, in Ada, I can place assertions in the
> middle of a complex subprogram; this is not possible Eiffel, as you
> aptly described.

It's possible in Eiffel -- Eiffel has a feature analogous to Ada's
pragma Assert.

Newer versions of GNAT have pragmas Precondition and Postcondition.
We're thinking about adding pragma Invariant.

The ARG is also thinking about adding pre/post/inv features to
the language.

- Bob

Re: Ada vs Eiffel - Ada programmer approach

[Martin]

On Jun 4, 2:25 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
> > I think my point was precisely that Ada assertions were different from
> > Eiffel's. I like the fact that, in Ada, I can place assertions in the
> > middle of a complex subprogram; this is not possible Eiffel, as you
> > aptly described.
>
> It's possible in Eiffel -- Eiffel has a feature analogous to Ada's
> pragma Assert.
>
> Newer versions of GNAT have pragmas Precondition and Postcondition.
> We're thinking about adding pragma Invariant.
>
> The ARG is also thinking about adding pre/post/inv features to
> the language.
>
> - Bob

Please! :-)

Cheers
-- Martin

Re: Ada vs Eiffel - Ada programmer approach

[stefan-lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 599 bytes --]

On Thu, 4 Jun 2009, Martin wrote:

> On Jun 4, 2:25�pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> > Newer versions of GNAT have pragmas Precondition and Postcondition.
> > We're thinking about adding pragma Invariant.
> >
> > The ARG is also thinking about adding pre/post/inv features to
> > the language.
> >
> > - Bob
> 
> Please! :-)

Yes, that would be great!

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Ada vs Eiffel - Ada programmer approach

[Samuel Tardieu]

>>>>> "Robert" == Robert A Duff <bobduff@shell01.TheWorld.com> writes:

Robert> Newer versions of GNAT have pragmas Precondition and
Robert> Postcondition.  We're thinking about adding pragma Invariant.

Where would pragma Invariant be declared? At the type/object level or at
the subprogram level?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: Ada vs Eiffel - Ada programmer approach

[Robert A Duff]

Samuel Tardieu <sam@rfc1149.net> writes:

>>>>>> "Robert" == Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
> Robert> Newer versions of GNAT have pragmas Precondition and
> Robert> Postcondition.  We're thinking about adding pragma Invariant.
>
> Where would pragma Invariant be declared? At the type/object level or at
> the subprogram level?

An invariant (whether it be a pragma, or some special syntax) would be
attached to a type, and would mean "all objects of this type have
this property, always" (except that maybe objects can temporarily
violate their invariant, so long as the code puts it back).

A related concept that has been discussed is "user-defined constraints".
I'm not sure what the difference is, exactly -- I think with user-defined
constraints, you can't "temporarily violate".

I have expressed the opinion that invariants and/or user-defined
constraints should apply to subtypes, not just types.  Not everyone
agrees.

And if they apply to subtypes, it's a small step to let them apply to
standalone objects ("this object (almost) always has so-and-so
property").

Package invariants have also been discussed.

- Bob

Re: Ada vs Eiffel - Ada programmer approach

[Randy Brukardt]

"Robert A Duff"  writes:
...
> An invariant (whether it be a pragma, or some special syntax) would be
> attached to a type, and would mean "all objects of this type have
> this property, always" (except that maybe objects can temporarily
> violate their invariant, so long as the code puts it back).
>
> A related concept that has been discussed is "user-defined constraints".
> I'm not sure what the difference is, exactly -- I think with user-defined
> constraints, you can't "temporarily violate".

A user-defined constraint applies to a view (usually via a subtype), while 
an invariant applies to a type (always). For instance, a user-defined 
constraint can apply to a formal parameter but not to the actual parameter 
object (just as any other constraint). Calling such a thing an "invariant" 
would be completely wrong, because it's not invariant at all - the values 
are only checked against the constraints at the points where Ada does 
subtype conversions (and possibly a few others - this is TBD and hopefully 
will be discussed at this week's ARG meeting).

Tucker explains the distinction somewhat in his new draft of AI-146 (to be 
posted tonight, along with the ARG meeting agenda). There also is a partial 
user-defined constraint AI (AI-153), but I got stuck over how invariant we 
want these to be. Check them both out tomorrow.

                                           Randy.

Re: Ada vs Eiffel - Ada programmer approach

[Dmitry A. Kazakov]

On Mon, 8 Jun 2009 17:52:27 -0500, Randy Brukardt wrote:

> "Robert A Duff"  writes:
> ...
>> An invariant (whether it be a pragma, or some special syntax) would be
>> attached to a type, and would mean "all objects of this type have
>> this property, always" (except that maybe objects can temporarily
>> violate their invariant, so long as the code puts it back).
>>
>> A related concept that has been discussed is "user-defined constraints".
>> I'm not sure what the difference is, exactly -- I think with user-defined
>> constraints, you can't "temporarily violate".
> 
> A user-defined constraint applies to a view (usually via a subtype), while 
> an invariant applies to a type (always).

I do not see any difference. Invariant is merely a private constraint.
User-defined constraint is a [public] part of the invariant.

> For instance, a user-defined 
> constraint can apply to a formal parameter but not to the actual parameter 
> object (just as any other constraint).

Hmm, I think this confuses constraints put on a type/subtype with
discriminants of an object. Obviously, any combination of discriminants'
values determine some anonymous subtype with a corresponding invariant.
That is an invariant of the object only in the sense that the object has
this anonymous subtype. Objects do not have invariants.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 8 juin, 21:37, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> [...] (except that maybe objects can temporarily
> violate their invariant, so long as the code puts it back).
Depending on invokation context

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 8 juin, 21:37, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> I have expressed the opinion that invariants and/or user-defined
> constraints should apply to subtypes, not just types.  Not everyone
> agrees.
I agree too
As subtypes have specific properties on value (it it is a subset),
specific constraints may come with it.

Re: Ada vs Eiffel - Ada programmer approach

[Georg Bauhaus]

Hibou57 (Yannick Duch�ne) schrieb:
> On 8 juin, 21:37, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>> I have expressed the opinion that invariants and/or user-defined
>> constraints should apply to subtypes, not just types.  Not everyone
>> agrees.
> I agree too
> As subtypes have specific properties on value (it it is a subset),
> specific constraints may come with it.

I wonder if to have invariants with subtypes is the
more practical alternative?

Also, what about overlapping subtypes?
What if invariants of two subtypes are contradictory?

Consider subtypes of the same type

  ... range 1 .. 10;
  ... range 0 .. 10;

Should it be possible for these two subtypes to have further
invariants/constraints that could possibly contradict each other?
(An object from the first range can now be used where an object
of the second is expected.)

I'm considering a programming use case, such as this:

  procedure Op(X: Whole_Number_Subtype; Result: T);
  pragma Precondition(X rem 2 = 1);

This lets me think that *not* having a constraint with the subtype
Whole_Number_Subtype is more flexible, at least if I'd be tempted to
define another subtype for imposing the set predicate X rem 2 = 1.

(As long as we don't have a type system for type constraints
like Dmitry Kazakov has suggested some time ago IIUC...)

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 24 mai, 18:31, Pascal Obry <pas...@obry.net> wrote:
> Tomek Walkuski a écrit :
>
> > - what, in your opinion, is better in Ada, in contrast to Eiffel?
>
> - multiple inheritance
>

Multiple inheritance gives headache and it is better handle with the
notion of interface.

Multiple inheritance does not exist in real life, but merge of
different interfaces does.

Re: Ada vs Eiffel - Ada programmer approach

[Hibou57 (Yannick Duchêne)]

On 24 mai, 10:39, Tomek Walkuski <tomek.walku...@gmail.com> wrote:
> Hi group,
>
> I do not want to start another flame war which language is better. I
> think that Ada and Eiffel target same field and I want to ask you, Ada
> programmers, about:
> - what, in your opinion, is better in Ada, in contrast to Eiffel?
> - what, in your opinion, is worse in Ada, in contrast to Eiffel?
>
> Please, share your thoughts if you have an experience in both
> languages.

My humble and short opinion : what is better is Eiffel is its require/
ensure/invariant clauses, and what is better in Ada is its life world
capabilities. I use to use Eiffel for some attempt, but finally think
that the "every thing is class" of Eiffel turns into confusion and
that Eiffel was lacking for precise type specifications (in a few
words... deeply, I may tell more).

Although I love some Eiffel stuff, in the end, it is not so much
usable in real life as Ada is. Eiffel is a nice theroy experiment.

About Ada : think about Spark and Mika as well, beside of formal
clauses in Eiffel.

Re: Ada vs Eiffel - Ada programmer approach

[Marco]

On Jun 3, 11:04 pm, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:

>
> About Ada : think about Spark and Mika as well, beside of formal
> clauses in Eiffel.

  What is Mika?  Please site reference.

Re: Ada vs Eiffel - Ada programmer approach

[Tomek Wałkuski]

On 6 Cze, 16:27, Marco <prenom_no...@yahoo.com> wrote:
>   What is Mika?  Please site reference.
http://www.midoan.com/