----- Forwarded message from xxxxxx@pobox.com -----
Envelope-to: xxxxxx@localhost
Delivery-date: Fri, 01 Aug 2003 13:43:19 -0500
To: xxxxxx@freenetproject.org
Subject: Re: [xxxxxx@pobox.com: Minor quibbles on the latest draft]
Reply-To: xxxxxx@pobox.com
From: xxxxxx@pobox.com
Hello!
I'm replying to you although my comments are public. I'm
afraid that my mail to SRFI-44 would bounce, therefore, I don't
explicitly send to the list. Please feel free to forward or publicly
reply on the list.
[Re: advanced module system]
> The problem with this approach is that it doesn't let you use two
> collections of different types by the same Scheme function. For
> example:
>
> (define (myfunc a)
> (set-contains? a 3))
>
> (myfunc (foo-set 1 2 3))
> (myfunc (bar-set 4 5 6))
I'm afraid I failed to emphasize that I do not argue against OOP,
typeclasses or a similar facility. If a function is polymorphic with
respect to collections, as myfunc is, generally a dynamic dispatch is
required. This is true in general of polymorphic functions or
constrained polymorphic functions -- e.g., like '+' in Scheme. The
addition function should, at run-time, check if its arguments are
fixnum, bignum, rational, inexact, complex, etc -- and dispatch to the
appropriate addition function for specific sorts of numbers. However,
a compiler may often infer that a particular '+' in the code will be
applied only to exact integer arguments. The compiler can therefore
compile the appropriate specialized function there. This is, in
essence, a common technique of monomorphizing polymorphic functions
(which is similar to C++ template expansion). OCaml and Bigloo do that
often. Type declarations -- or in the case of Scheme module
declarations -- greatly help the compiler to make monomorphizing
decisions. Users can do monomorphizing by hand or given the compiler
specific instructions: e.g., in Gambit
(let () (##declare (fixnum)) (+ 1 2)))
SRFI-44 is not a SRFI about modules, generic functions or OOP
systems. Still, the 'issues' section of SRFI-44 does mention OOP and
generic functions and dynamic dispatch -- but does not say anything
about module systems and static dispatch. I thought that's odd. The
latter, although not general, do turn out useful in many
circumstances.
> > Edison says: insert [our add] keeps the new element in case of
> > duplicates, but insertSeq [our add-all] keeps an unspecified element.
> In the case of bags, its perfectly valid to keep all the values. Did
> you mean sets?
Yes, of course. I pasted the wrong lines...
>> For ordered collections, Edison defines procedures to view, insert or
BTW, view functions are quite nifty: they are deconstructors. So we
could write
(let-values (((max-val rest) (ordered-coll-remove-max coll)))
...)
The syntax even reminiscent of pattern-matching (aka Prolog's
[Head|T]). It also permits pure-functional removal functions.
Cheers,
Oleg
----- End forwarded message -----
--