Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!brunix!doorknob!rsw From: rsw@cs.brown.EDU (Bob Weiner) Newsgroups: comp.lang.eiffel Subject: Re: Suggestion for use of Void Message-ID: Date: 6 Dec 90 17:53:01 GMT References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP> <4144@tantalum.UUCP> Sender: news@brunix.UUCP Organization: Brown U. Lines: 89 In-reply-to: tom@eds.com's message of 4 Dec 90 23:57:32 GMT In article <4144@tantalum.UUCP> tom@eds.com (Tom H. Meyer) writes: > Indeed. I've encountered this problem several places but the following > should illustrate the problem more clearly: > > The problem domain is a relational database query compiler. In particular, > we are writing an SQL compiler so I will use SQL examples. > > 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. > Now my question becomes whether you want to dispatch on a single type or multiple types at certain points. If just a single type, then I see no problem. Define types of COMPOSITE_E_EXPR, BINARY_E_EXPR, LITERAL_E_EXPR, and ATTRIBUTE_E_EXPR, which then have subtypes. In the case of the literal, you could have INTEGER_E_EXPR, etc. Again, each of these could have an 'action' procedure that takes a parameter, even the operation to be applied within the expression. If you want to dispatch on multiple types, e.g. an optimized selection procedure when one does an AND selection of data based upon two fields, F1 and F2, then I would say that Eiffel does not provide a simple mechanism to accomodate you. C++ and CLOS make this easier through function overloading and generic functions respectively. > 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. > But that is the whole point of the 'action' feature, so you can perform quite different actions selected by type. > 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. No, the dispatch mechanism, whatever it may be, must know this in order to select the appropriate operation. You can choose to use the dynamic binding mechanism or produce a more limited more optimized dispatcher yourself, though I would do that only as a last resort. > 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 artificial. My point is not to write procedures that deal with arbitrary constants or expressions but more simply and elegantly to use dynamic binding to achieve specificity of operation. Meyer deals with this issue in Object-oriented Software Construction. > > 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. Or the design may simply be a poor one. But I agree, let's not use wrenches to clear our pipes. OO design is about building the proper tools to solve domain-specific problems. SQL is an example of a language that does not provide this flexibility. If one's database model does not fit well into a linear table format, there are still many SQL professionals who will cram it in to one. Now, of course, many people are working on object-oriented databases to overcome this precise limitation. > 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. > This would probably help. I still feel I haven't understood the essence of your problem. My knowledge of SQL is quite minimal, I assure you. -- Bob Weiner rsw@cs.brown.edu Brought to you by Super Global Mega Corp .com