On 02/07/2011 09:18 AM, Lars T. Kyllingstad wrote:
I cannot stand the "is()" idiom/syntax ;-) Dunno why. Would happily
>>> get rid of it in favor of type-classes (built eg as an extension to
>>> current interfaces). For instance, instead of:
>>>
>>> void func (T) (T t)
>>> if (is(someConstraint1)&& is(someConstraint2))
>>> {
>>> ...
>>> }
>>>
>>> use:
>>>
>>> void func (SomeTypeClass T) (T t)
>>> {
>>> ...
>>> }
>>>
>>> For instance (untested):
>>>
>>> void func (T) (T t)
>>> if (isInputRange(T)&& is(ElementType!T == E))
>>> -->
>>> void func (InputRange!E T) (T t)
>>>
>>> where InputRange is a (templated) interface / type-class.
>>>
>>> Type-class checks on/type/ /template/ parameters (as opposed to type
>>> checks on regular value parameters) would be performed structurally
>>> (as opposed to nominally). D knows how to do this, since that's what
>>> it needs to perform when checking is() constraints.
>>
>> I agree that is() is rather ugly. Same with __traits. If you haven't
>> already done so, I suggest you vote up this issue:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=3702
>
> Done!
> (I did not get all the details 'cause no time for a deep look, but
> anything impulsed by the motivation of getting rid of is() and __traits
> can hardly be a Bad Thing ;-)
>
> What do you think of type classes, as an alternative to Don's proposal
> in issue #3702.
> See also "Type Classes as Objects and Implicits":
> http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
>
>> Anyway, you can hide is()'s ugliness in the most common cases, though,
>> by defining new templates. For instance, I wouldn't mind having the
>> following in std.range as an overload of isInputRange:
>>
>> template isInputRange(R, T)
>> {
>> enum isInputRange = isInputRange!R&& is(ElementType!R == T);
>> }
>>
>> Then, you'd simply write
>>
>> void func(R)(R range) if (isInputRange!(R, E)) { ... }
>>
>> -Lars
>
> A great improvement, indeed.
>
> While we're at defining a set of constraints in a template, let us make
> it an interface / type-class that the E must (structurally) satisfy, and
> just write:
> void func(InputRange!E R)(R range) { ... }
>
> What do you think?
>
> Note: a template is not always required, I guess:
> void writeElements (Iterable Elements) (Elements elements) {
> foreach (element, elements) {
> write(element,' ');
> }
> }
> (In this case, because write is itself generic.)
How would you deal with the case where the input must satisfy more than
one concept/constraint? I mean, for the simple case where you say "R
must be an input range of E", sure, type classes/concepts are cleaner.
But what about the case where, say, you want R to be an infinite random
access range that supports slicing? With template constraints it's
simple:
void doStuff(R)(R someRange)
if (isRandomAccessRange!R&& isInfinite!R&& hasSlicing!R)
{
...
}
Now, I'm no expert on concepts at all---my main sources of information
about them are superficial comments on the D newsgroup and a quick browse
of the Wikipedia page---but it seems to me that you'd have to define a
new concept for each such combination of constraints. Or?
Well, dunno really. If a language implements type classes, let us see how
things work there :-)
Note that above, you use 3 implicite type-class defining check funcs. Agreed?
Certainly, because they are common, one wrote a fucn to wrap a bigger set of
is() stuff. Replacing them with a type-class interface allows
(1) reusing an interface for what it's meant: defining a (super) type, instead
of a func which is appropriate and does /not/ correctly convey the meaning
(2) avoiding is()
Now, you may be right in that type-class check may need be written externally:
void doStuff(R)(R someRange)
if (RandomAccessRange R && InfiniteRange R && Slicable R)
or not:
interface ASpecialOne : RandomAccessRange, InfiniteRange, Slicable {}
void doStuff (ASpecialOneR) (R someRange)
Ain't that clean? For sure, if I was to define a new static PL, I would go
/that/ way for generic constraints.
This remembers me about another option maybe: when I have time, I'll go and see
how XL does it. If (you do not know XL, then /really/ have a look when you have
time: http://en.wikipedia.org/wiki/XL_%28programming_language%29 ;esp explore
the notion of "conceptual programming")
Denis
--
_________________
vita es estrany
spir.wikidot.com
