Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!hsi!wright
From: wright@hsi.UUCP (Gary Wright)
Newsgroups: comp.lang.eiffel
Subject: Re: Interesting problems to try in Eiffel
Message-ID: <983@hsi86.hsi.UUCP>
Date: 8 Jan 90 16:31:31 GMT
References: <1721@novavax.UUCP>
Reply-To: wright@hsi.com (Gary Wright)
Organization: Health Systems Intl., New Haven, CT.
Lines: 114

In article <1721@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes:
>(I assume you're using Eiffel 2.2.)
>

>* Build a COMPLEX_NUM class.  This is one of the most basic classes needed
>for any sort of scientific programming yet missing from the ISE provided
>Eiffel libraries.  Naturally you'll want it to be an expanded type just
>like an INTEGER.  But you'll find there is no way to define an expanded
>class but only expanded instances.  Thus your code will be littered with
>declarations of the type 'c: expanded COMPLEX_NUM'.  Very, very
>unnerving for such a simple idea.

If there were such a thing as an expanded class, how would I create an
instance that was not expanded?  I would need a way to create two
seperate classes, one expanded, one not.  Of course, now I would have
COMPLEX_NUM and EXP_COMPLEX_NUM (or COMPLEX_NUM_REF and COMPLEX_NUM).
A solution, but not any better than the current method in my opinion.
Also, you can't have an inheritance graph below an expanded class.  So
the notion of a class always having expanded instances seems to be of limited
use.  Perhaps a more terse notation for an expanded instance
would help?  Unfortunately, the only thing that comes to mind right now
is notation from C: "c: *COMPLEX_NUM".  Even better would be naming the
class COMPLEX which would allow: "c : *COMPLEX".  Any other ideas out
there?

>* Add an INTEGER to a REAL.  The compiler will tell you something akin
>to INTEGER is not a descendent of REAL.  Conceptually, it should be a
>specialization of and thus should inherit but the more significant
>matter is that this is a simple thing that programmers often do everyday,
>yet it does not work as expected.

I don't think programmers do this everyday.  What they do is use languages
that perform default conversions thus converting the INTEGER to a REAL
before performing the addition.  Are default numeric conversions a good idea?
Do they mix well with other Eiffel concepts?".

From looking at C++, I don't know if I want a language that permits simple 
syntactic structures to result in complex semantics.  Better to have
the conversion written explicitly.  Of course the compiler needs to be smart
about this and avoid the function call overhead.

>
>* Create an SDF (system build configuration file) in directory A and a
>class in directory B.  This is often useful as one tries to categorize
>classes in the same system below different directories.  Now try to
>compile the class from directory B which is where you are likely to be
>if you have just edited the class and want to see if it will compile.
>You'll find that the compiler can't locate the SDF and so remains unhappy.
>'ec' the Eiffel class compiler has no published option with which to
>specify the SDF directory as does 'es', the Eiffel system builder.  Is
>this the result of two different implementers not speaking to one
>another in the same small company?

I agree, some work needs to be done in this area.

>
>* Use a smart editor to parse ISE's Eiffel compiler error
>messages in order to displaying the offending class line.  It can be
>done but is made very difficult by the fact that error messages do not
>contain full pathnames but only class names.

Full pathnames are very annoying if you aren't using a smart editor.
One solution is to have the editor know about Eiffel idea of the
current universe.

>* Create a large class library without creating any names that conflict
>with ISE library class names.  My belief is that a class definition
>which represents a data type to be used in programs should be named
>clearly enough to indicate its true nature.  Classes that implement
>obviously incomplete abstractions should not take the name of the
>abstraction.  Part of the point behind OO is to represent abstractions
>in a way that will appear natural to people.  Now look at these ISE
>class names and guess what they do: BASIC, CELL, CHAIN, COMMAND,
>SCREENMAN, INTERNAL.

Naming in a single namespace is always difficult.  The mapping between
the class name and the file name unfortunately limits the length of class 
identifiers but I really don't expect a single identifier to be
able to unambiguously describe a complete abstraction.  It doesn't
work in any programming language I know about and there have been endless
discussions on the net regarding the use of extremely long identifiers.
Of course you are free to critizise particular name choices but there
will never be a consesus on that!  Perhaps a tool that renames a class
would help.  The problem you have pointed out is much larger than Eiffel.

>* Cast the value of a STRING into an entity name and then assign to it.
>This is fairly common in Lisp.  This may break the type system but is
>extraodinarily useful in everyday practice.  (How can one justify
>elegance in the face of impracticality anyway?)  

Please define type system, useful, elegance and impracticality and then
maybe we can draw some conclusions.  1/2 :-)

>Without the aforementioned
>capability, one is in for a very long if-then-else structure which is
>both inefficient and contrary to the open-closed principles often
>eloquently espoused by Dr. Meyer.  A non-mundane use of this facility
>would be to create a self-modifying program; a concept that is going to
>play an important role in software throughout the next decade and
>beyond.

Again, you have pointed out a problem that is not unique to Eiffel.
Maybe this discussion should be in comp.lang.misc?  A self-modifying
program is not exactly an idea on which a concensus has been reached.
Can you propose a syntax/method to incorporate this capability in
Eiffel?  You say that an if-then-else structure is inefficient, how
does a Lisp run-time system take care of this mapping?  Why can't that
technique be used in Eiffel?  What is the use for this technique in a
commercial application (vs. research, lab application)?  Of course,
simply because a programming technique is "useful", does not mean that
it is wise to include it in every language that comes along.
-- 
Gary Wright                                     ...!uunet!hsi!wright
Health Systems International                    wright@hsi.com