This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
----- Forwarded message from oleg@xxxxxxxxx ----- Envelope-to: scgmille@localhost Delivery-date: Thu, 30 Oct 2003 15:25:12 -0600 To: scgmille@xxxxxxxxxxxxxxxxxx Subject: Static, dynamic dispatch and OO system Reply-To: oleg@xxxxxxxxx From: oleg@xxxxxxxxx Hello! [ The discussion seems to have turned constructive, and many interesting suggestions have been proposed. OOP and dispatch is frequently mentioned. Could you please forward this message to the list? Thank you.] The topic of object or type hierarchies, generic functions, and dynamic or static dispatch to appropriate specializing functions has come several times in recent discussions. I wonder if I may make a suggestion that hopefully can uncouple some of the issues, so we can deal with them separately. I'd like to remark first that many of the discussed issues fall under the scope of a module system. It seems Ray Dillinger's recent proposal is precisely that of a light-weight module system. At Scheme 2000 workshop Olin Shivers repeatedly said that Scheme urgently needs a module system. He arranged for a special meeting of the implementors on this topic. The issue of a module system came up again at Scheme 2002 workshop. It was agreed that the best hope for a new Scheme is a layered design (the core plus educational/performance, etc. additions). A module system is crucial for such a modularization. At the end of PLI2002, a prominent Scheme implementor told me that they have had meetings and I should be glad to know that the implementors of Bigloo, Gambit, PLT Scheme, and Scheme48/SCSH had agreed to move their systems towards a common module framework. I was indeed very glad to know that. I'm perhaps too impatient for the results. For now, I routinely test my libraries under six different Scheme systems, and solve the problem of module system by some higher-order Makefile functions (and by well-placed cond-expands in some cases). Regarding SRFI-44 and collection hierarchies, I'd like to make a proposal by the way of an extended example. Let us consider a TIFF image directory as a SRFI-44 collection. The implementation in a file tiff.scm has the following structure: ; tiff-directory collection (define (tiff-directory? coll) <code>) (define (collection-name coll) (and (tiff-directory? coll) 'tiff-directory)) (define collection? tiff-directory?) (define (mutable-collection? coll) #f) (define (dictionary? coll) (tiff-directory? coll)) (define (tiff-directory-size coll) <code>) (define (tiff-directory-fold-left coll fn . seeds) <code>) (define collection-fold-left tiff-directory-fold-left) (define (tiff-directory-get coll key . default-val) <code>) (define (tiff-directory-get-as-symbol coll key . default-val) <code>) Incidentally, this example is not hypothetical. It is snipped from the TIFF library announced on comp.lang.scheme the other week. An application code that uses only the TIFF library, for example, tiff-prober.scm, should include (or just load) the tiff.scm file -- and that's it. We should point out several things. First of all, tiff.scm defines a function tiff-directory-get-as-symbol, which is not in SRFI-44. That should be OK -- as long as tiff.scm defines enough functions for a collection or a dictionary signatures (speaking in ML terms), the structure tiff.scm can claim to be an implementation of these signatures. A structure can implement several signatures. Extra functions such as tiff-directory-get-as-symbol, which really make sense only for a TIFF directory, can be accessed through a specific TIFF directory signature. We should also note that tiff.scm defines functions like collection-name, collection? and dictionary? -- as if TIFF directory were the only one collection and the dictionary in the universe. And as far as that file is concerned, that is indeed the case. The application code tiff-probe.scm that uses only the TIFF directory guarantees that the TIFF directory is the only one collection, in that application's universe. Therefore, absolutely no dispatch and no OO system is needed. tiff-prober.scm merely includes tiff.scm, and everything works. Now, suppose we define an implementation of a set that can contain at most 24 objects. The objects are integers 0 through 23. We will use integers as the backing data structure for our set. We will write a file limited-set.scm with the following code: (define (limited-set? coll) (and (integer? coll) (exact? coll))) (define (collection-name coll) (and (limited-set? coll) 'limited-set)) (define collection? limited-set?) (define (set? coll) (limited-set? coll)) (define (set-size coll) <code>) (define (limited-set-fold-left coll fn . seeds) <code>) (define collection-fold-left limited-set-fold-left) Again, we write the code as if our limited set is the only collection in existence. Now, suppose we are writing code that uses both tiff.scm and limited-set.scm. If we load both these files, we've got a problem. The assumption that the tiff-directory _or_ the set are the only collections no longer holds. Now we really need some dispatch. How precisely we do that greatly depends on the available OO system -- Meroon, TinyCLOS, etc. In some cases (and given a powerful module system) we can probably get by with a static dispatch. We write the following code: (load "tiff.scm") ; this brings tiff-directory?, tiff-directory-fold-left etc. functions ; into scope. ; Also, it brings collection-fold-left bound to ; tiff-directory-fold-left, ; and collection? bound to tiff-directory? ; Save the values of the generic procedures of interest (define tiffs-fold collection-fold-left) (define tiffs-pred collection?) (load "limited-set.scm") ; this brings limited-set?, etc. functions into scope. ; Also, collection-fold-left will be re-bound to ; limited-set-fold-left, ; and collection? will be rebound to limited-set? ; Save the values of the generic procedures of interest (define lset-fold collection-fold-left) (define lset-pred collection?) ; Now, re-define collection? and collection-fold-left to be generic ; The following implementation is really simple-minded. It is intended ; as an illustration. A better OO system or Ray Dillinger's approach ; should be used. See also Dan Friedman's OO Style ; http://www.cs.indiana.edu/hyplan/dfried/ooo.pdf (define (collection? coll) (or (tiffs-pred coll) (lset-pred coll))) (define (collection-fold-left coll . args) (cond ((tiffs-pred coll) (apply tiffs-fold coll args)) ((lset-pred coll) (apply lset-fold coll args)))) Now we have a universe with two collections and can use both the TIFF directory and the limited set in the same code. I should point out that the files limited-set.scm and tiff.scm do NOT depend on a particular OO system. Whether we would use generic functions, CLOS, multiple inheritance, multiple dispatch or anything else is irrelevant as far as the interface and the implementation of dictionaries and sets are concerned. Of course it would be nice if we had one uniform module and OO systems. But we don't. Therefore, each particular user of dictionaries and collections has to inject SRFI-44 collections into his preferred OO/module system. It's not that complicated, as we saw. Moreover, particular Scheme implementations may already do the needed work. The advantage of that approach is the uncoupling of SRFI-44 from the OO system or a module system. The consistent naming of collections becomes really important -- which is what SRFI-44 set out to do. ----- End forwarded message ----- --
Description: PGP signature