Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!unmvax!bbx!tantalum!tom
From: tom@eds.com (Tom H. Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Suggestion for use of Void
Summary: More detailed example
Message-ID: <4144@tantalum.UUCP>
Date: 4 Dec 90 23:57:32 GMT
References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP> <RSW.90Dec4075159@tahiti.cs.brown.EDU>
Sender: usenet@tantalum.UUCP
Reply-To: tom@ozmium.UUCP (Tom H. Meyer)
Organization: EDS Research
Lines: 79

In article <RSW.90Dec4075159@tahiti.cs.brown.EDU> rsw@cs.brown.EDU (Bob Weiner) writes:
>The key question is whether you know at class design time whether or not
>objects of the class type will be used on the list.  Even if you don't,
>you could still define a somewhat generalized protocol (varying numbers
>of parameters are still a problem) in which all of your non-generic
>classes have an arbitrary 'action' procedure.  Then when you pop an
>object off the list into an entity of type ANY, simply invoke
>'entity.action(params)'.  Eiffel's dynamic binder will do the rest.
>
>My guess is that your problem is more complicated than this, so you will
>have to elaborate some more.

Indeed. I've encountered this problem several places but the following
should illustrate the problem more clearly:

(btw, I cannot distribute code I write for my employer over the net so I
hope a verbal description will suffice.)

The problem domain is a relational database query compiler. In particular,
we are writing an SQL compiler so I will use SQL examples.

Consider two queries:

select a from T

This query will retrieve all the values of the field named 'a' from table T.
(I apologize if you already know all this, sorry to be a bore)

select a + b - 2.0 from T

Similarly, this query will perform the expression on each tuple and return
those values, one per tuple of T.

Somewhere in the grammar for SQL there is something like:

e-expr :: e-expr | binary-e-expr | literal | attribute

meaning that an elementary expression can be several things including such
disparate things as arbitrarialy complex sub-expressions or a simple
attribute for a table.

Attributes contain lots of information about their location within the tuple,
where their null bit is, and other similar things that are totally unrelated
to, say, a binary e-expr. The reverse is also true. This makes it difficult
to come up with a really tight generic class. The actual classes for the
base cases in such a grammar tree look extremely different.

When I'm compiling an e-expr, I have a 'incoming' list of e-exprs that I need to
deal with and take appropriate actions for each one. Unfortunately, a single
generic 'action' feature isn't good enough. For example, literal e-expr's
have a value. In the previous query there is a literal e-expr of (say) type
real with a value of 2.0. During constant folding, you need to know the
actual value so you must, somewhere, know explicitly that this is a real.
It could have been a double, boolean, integer, character, etc. and you
must know it's actual type to deal with it. While constant folding of
numeric types is fairly generic (not completely), it is quite different from
folding the other types. I cannot envision writing generic constant
folding code that wasn't extremely arcane and artificle. IMHO, that's letting
the tail wag the dog. Actually, I can't see how to do it at all but 
perhaps that's just my own inexperience. There are many similar, even more
difficult examples but they are too detailed for such a discussion.

I don't know how compelling you found this example but I hope that it, at
least, gave a clearer picture of the sorts of problems you can encounter.

Perhaps the kernel issue here to me is one of letting the programmer deal
with the paradigm they are most comfortable with. If writing generic,
typeless code results in bizzare gyrations and a lack of clarity, it is
the wrong tool for the job. I do not believe in the "one tool solves all"
theory. If it's more natural to deal with explict types, fine. Thus,
my reverse assignments. I also acknowledge this could result from my
programming background rather than a real limitation of Eiffel.

If this still isn't detailed enough, I'll try to spend some time to
come up with some real code that illustrates the problem.


tom meyer, EDS Research               | If I don't see you in the future
...uunet!tantalum!tom                 | I'll see you in the pasture


Brought to you by Super Global Mega Corp .com