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.
At Tue, 28 Oct 2003 14:35:15 -0600, scgmille@xxxxxxxxxxxxxxxxxx wrote: > > In an attempt to break this circular flame war, please state your > objections in a point by point matter, citing evidence. First I'd like to retract my previous comment on dictionaries. After discussing with Scott on IRC I found there is no actual make-dictionary procedure or concrete dictionary type, so those comments are irrelevant until such time as a hash/av-tree dictionary is realized. However, that was when I first truly grasped that this is purely a meta-SRFI, and relies entirely on future work to be useful. Although SRFI-35, for example, was designed with the intent for future expansion (SRFI-36), it is encapsulated and usable in and of itself. Moreover, the method of expansion is concretely laid out and a reference implementation given in portable Scheme. From this I see two problems with SRFI-44 (specific interface issues aside, I think it's too late to bring them up if they weren't mentioned earlier): 1) SRFI-44 is not self-contained, and not expandable in a portable fashion. I agree with the others that TinyCLOS is not an acceptable pre-requisite. SRFI-44, despite the fact that the document never mentions it, is an API presuming a polymorphic OO system, and attempts at implementation outside such a system would be worthless. An OO SRFI is a pre-requisite to this style of API. 2) SRFI-44 is acting as an Oracle. It presumes to know in advance the best API for all collections and dictionaries, without having nailed down or even explored those individual areas. There is a *huge* amount of variation and discussion waiting to happen on such individual primitive API's as hash tables, heaps and trees, and from those usage as sets, dictionaries, priority queues, etc. While in the end an API not unlike SRFI-44 may in fact be the best suited to unification of those data-types, I think we need to lay the foundation before we start the interior decoration. -- Alex