guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interesting project proposal for generics in Racket


From: Panicz Maciej Godek
Subject: Re: Interesting project proposal for generics in Racket
Date: Sat, 8 Mar 2014 10:40:56 +0100

2014-03-05 19:12 GMT+01:00 Jan Wedekind <address@hidden>:
>> Besides, I think that Scheme + OOP has its own flaws. In most OOP
>> languages, you have this notation object.property or object->method(),
>> which also allows for chain calls, i.e. object->getChild()->method(),
>> or -- if you have nested objects -- to use
>> object.property.propertys_property.
>
> Somewhat related I have seen an interesting project proposal for generics in
> Racket [1]. The generics use predicate functions instead of classes. E.g.:
>
>     (defmethod add ((x number?) (y number?))
>       (+ (x y))
>
> where 'number?' is a function returning '#t' for numbers.
>
> The type hierarchy (specialisation) is declared using 'defsubtype'. E.g.:
>
>     (defsubtype zero? integer?)

I don't know whether it's better to provide a separate entity for
types/classes or to use bare predicates. I think that an advantage of
explicit first class types (such as the ones used in GOOPS) is that
one could easily provide a method to generate exemplars of objects of
those types, which could be useful for unit tests performed by systems
such as QuickCheck.

I think it should be fairly easy to implement such system portably for
Scheme. Even better, I believe it would be nice to employ the
Wright-Shinn pattern matcher (known as (ice-9 match) for Guilers) in
signatures of functions, so that one could write e.g.

(generic factorial)
(specialize (factorial 0) 1)
(specialize (factorial (? number? n)) (* n (factorial (- n 1)))

[I am using the name 'specialize' here in order to avoid confuision,
but the concept is the same]

It's a nice idea to stipulate the ordering relation for predicates
(although it obviously would be better if the interpreter could infer
it automatically, at least to some extent). What would be needed for
the "match"-based implementation is a partial order of the "match"
patterns, so that they could be ordered from the most specific to the
least specific (which seems an interesting issue by itself).

It would also be nice if that could integrate with a full-blown type
system, so that apart from types for arguments, one could declare
types for the values being returned by a function, and if a tool for
static type analysis could be provided, because that would allow to
increase the type-safety of Scheme programs.

But I agree that this is an interesting and important issue.

Best regards,
M.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]