[Scheme-reports] WG2 Scheme and Polymporphism Denis Washington (14 Oct 2011 12:10 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism Alaric Snell-Pym (14 Oct 2011 12:20 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism Alaric Snell-Pym (14 Oct 2011 12:33 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism Denis Washington (14 Oct 2011 13:57 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism Andy Wingo (14 Oct 2011 12:28 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism Andre van Tonder (14 Oct 2011 13:02 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism John Cowan (14 Oct 2011 22:48 UTC)
Re: [Scheme-reports] WG2 Scheme and Polymporphism Andre van Tonder (15 Oct 2011 20:15 UTC)

[Scheme-reports] WG2 Scheme and Polymporphism Denis Washington 14 Oct 2011 12:07 UTC

Hello,

Now with the WG1 process nearing its final draft, I thought it might be
time to think about what would be great to have in WG2. (I am neither a
WG1 or WG2 member, but I care a lot about Scheme.) There seem to be
quite a lot of ideas and proposals for this on the WG wiki already [1],
but I think that a major thing is missing that I would expect from a
modern language in this age: first-class support for polymorphism and
generic programming.

I guess (hope?) most of us agree that polymorphism is an invaluable tool
for creating more flexible software architectures and often
easier-to-read code. Unfortunately, Scheme lacks support for
polymorphism almost everywhere; with the notable exception of arithmetic
procedures, most of R5RS' (and R7RS') standard procedures are through
and through non-polymorphic.

Take the sequence operations as an example. Each of them only works on a
specific type of sequence - there are separate procedures to retrieve
the length of a list, a vector, a bytevector or a string, for instance.
As a consequence, it is impossible to write procedures that operate on
arbitrary sequences without excessive special-casing. For instance,
writing a generic version of "map" or "filter" would require an ugly
"cond" expression handling each type of sequence individually. And even
then, there would still be the problem that there would be no way to
create user-defined types that act "as if" they were sequences (like
e.g. lazy sequences or streams).

I don't think that this is an acceptable situation in 2011. Therefore I
think that we should bring extensible and efficiently implementable
means of polymorphism to Scheme to WG2 Scheme, that is:

- Adding generic variant to the set of WG1 procedures where appropiate,
and/or redefining existing WG1 procedures to be generic. (For instance,
"map" could be redefined to work on arbitrary sequences, with a new
"list-map" procedure handling the special case of lists.)

- Adding a way for programmers to define new kinds of polymorphic (sets
of) procedures.

For the latter, I propose to look into adding something like the
"protocols" feature of Clojure [2] into Scheme. In short, this feature
allows the definition of a set of procedures that would have to be
implemented for a type to "conform to the protocol". The implementations
exist independently of the protocol definition, often in different
modules. It is then possible to just write code against the protocol
procedures and ignore the concrete type of the objects operated on.
Protocol procedures are namespaced through the module they are defined
in, so there are never name clashes when a type implements multiple
protocols with identically named procedures (unlike interfaces in Java
or C#).

This mechanism only supports single type-based dispatch, but in most
cases this is all that is needed, and this is very efficient to
implement on most platforms (the JVM and CLR have very fast single
dispatch, for instance).

What do you think?

Regards,
Denis

[1] http://trac.sacrideo.us/wg/wiki#WorkingGroup2
[2] http://clojure.org/protocols

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports