[oleg@pobox.com: Re: [oleg@pobox.com: Minor quibbles on the latest draft]] scgmille@xxxxxx 03 Aug 2003 16:26 UTC
----- 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 -----

--