NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/eiffel/1093

Internet Message Format | 1992-08-27 | 5.1 KB

Path: sparky!uunet!pipex!unipalm!uknet!mucs!cs.man.ac.uk!mod
From: [e-mail] (Michael O'Docherty (CAG ra))
Newsgroups: comp.lang.eiffel
Subject: Re: system-level validity
Message-ID: <[e-mail]>
Date: 27 Aug 92 09:24:45 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Lines: 129

I apologise to those people who have already read this message but I think
I distributed it to `man' (ie. Manchester) rather than `world'. It's a reply
to Trevor Nash's message, which in turn was a reply to an earlier message
of mine asking whether ISE 3.0 checks system-level validity. I'm assuming
the initial post made it to everyone.


>Subject: Re: system-level validity
>References: <[e-mail]> <[e-mail]>

[e-mail] (Trevor Nash) writes:


>In article <[e-mail]> [e-mail] writes:

>>    "Does ISE Eiffel 3.0 perform system-level validity checking?"

>Fair question, but poorly phrased:

Just because a question is not as complete as you want it doesn't mean it's
poorly phrased ;-)

>having read the definition of system
>validity in Eiffel The Language,

Surprisingly enough, I've read it too. In fact it's because of statements like

    "Of course, to guarantee the type-safety of a system, you must
     check [class-level and system-level validity]"

without an accompanying opinion on whether it *should* be done, which prompted
my initial question.

>why pick on ISE - I'd like to hear what Sig have to say.

Because we have a maintenance contract with ISE.

>In particular it is important to know what the compiler does with programs
>which are system invalid

Exactly! I just want to know up front. ISE's glossy for Eiffel 3 states that
the melting ice tecnology

    "Performs class-level type checking and guarantees type security"

If you ask me (and you did) the second half of this statement is a blatant
contradiction of the first.

>> I only ask because I strongly believe that 3.0 vendors should be up
>> front about this very important issue; after all, is a compiler that
>> only performs 99% of the possible static checking any long term use,
>> especially when Eiffel is trumpeted as robust?

>Come on Mike, this is a bit OTT isnt it?

No.

>Eiffel claims to be more robust
>than most other languages, not that it is impossible to write an incorrect
>Eiffel program.

I quote from "Static Typing for Eiffel", B. Meyer, 1989: (Eiffel 2.3 release
notes):

    "...the *goal* of Eiffel typing in a complete yet simple
    way:
        Type safety constraint: An Eiffel system is said to be type-
        safe if for any routine application x.r(a), and for any
        dynamic types DX and DA that x and a may take *during the
        execution of a system, DX includes and exports a routine
        corresponding to r*, with a formal argument declared of a
        type which is an ancestor of DA."

(the emphases are mine!). Is the goal still the same?

>I wonder how many real errors you expect to find with the
>system-level checks that are not trapped by the class-level checks?

Believe it or not, system-level validity found me, not the other way round. I
accidentally found myself applying a feature to an object which didn't have it.
ISE Eiffel 2.3 seg-faulted at run-time (clearly unacceptable) and Eiffel/S
(first PC release) caught it at run-time (a bit better).

I quote from the same source:

    "...This explains why fixing the type rules and the corresponding type
    checking performed by the compiler has not been a top priority. *But of
    course the loopholes must eventually be closed*"

Have they been closed? Will they be closed? Has the position changed?

>do you realise that a system-invalid program is not necessarily incorrect?

Perhaps just a wee bit patronising, Trev?

>You seem to view the question of system validity as if it was simply a
>further type-check that the compiler writer has chosen not to implement.
>Its actually much more complicated than this:

You're doing it again.

It *is*  simply a further type check and it's not
difficult (ETL 364-367).
It may well be time consuming. IMHO it should
be a separate EiffelBuild option. Those who don't care about full type-safety
can leave it off, (but I bet you'll switch it on when you get a run-time type
failure!). I would probably use it as part of the validation process before
release.

>Which of these solutions conform to the standard defined by ETL, and thus
>earn the name Eiffel?

ETL defines the language, not the implementation. This can be frustrating. As
an example consider evaluation of boolean expressions in C and Pascal. I
believe the C standard says compilers will cause them to be evaluated left to
right and may finish evaluation as soon as a result is obvious; I also seem to
remember that the Pascal standard states that no assumption can be made about
evaluation order or unvisited clauses. I'd appreciate a definite stand on
what implementations *must* and *should* do in ETL version 2 and in the eventual
language definition.

Surely ISE are prepared to say something about this issue, and Sig?


So much for my brave attempt to keep things brief with my last message.

Mike

Internet: [e-mail], wet string: ([phone] ext. 2343