View mode: basic / threaded / horizontal-split · Log in · Help
June 19, 2009
Re: Ranges
Robert Fraser Wrote:

> Steve Teale wrote:
> > template isInputRange(R)
> > {
> >     enum bool isInputRange = is(typeof(
> >     {
> >         R r;             // can define a range object
> >         if (r.empty) {}  // can test for empty
> >         r.popFront;          // can invoke next
> >         auto h = r.front; // can get the front of the range
> >     }()));
> > }
> > 
> > I can not possibly be the only D enthusiast who finds this completely incomprehensible. 
> 
> Yeah, that one is a bit tricky, and what makes it worse is that it seems 
> officially sanctioned by Walter/Andrei as the "right way" to check if a 
> type supports some operations. Basically, if you have:
> 
> is(typeof({ @@@ }()));
> 
> this means "if I made a function containing @@@, would that function 
> compile?". It's a hack which stems from the way the is expression works.
> 
> > What is a range?
> 
> As others have mentioned, it's just a struct (or other type) that 
> happens to support certain operations.

So does this mean that interfaces are just a tragic mistake. I'd always thought that what you said was a pretty good description of what an interface is!
June 19, 2009
Re: Ranges
Steve Teale wrote:
...
> Robert Fraser Wrote:
>> As others have mentioned, it's just a struct (or other type) that
>> happens to support certain operations.
> 
> So does this mean that interfaces are just a tragic mistake. I'd always
> thought that what you said was a pretty good description of what an
> interface is!

Could you explain why that makes interfaces a mistake? Interfaces (as in 
classes implementing an interface) do provide dynamic polymorphism which 
these compile time constraints (or 'concepts' in STL terms) don't.
June 19, 2009
Re: Ranges
Steve Teale wrote:
> Robert Fraser Wrote:
> 
>> Steve Teale wrote:
>>> template isInputRange(R)
>>> {
>>>     enum bool isInputRange = is(typeof(
>>>     {
>>>         R r;             // can define a range object
>>>         if (r.empty) {}  // can test for empty
>>>         r.popFront;          // can invoke next
>>>         auto h = r.front; // can get the front of the range
>>>     }()));
>>> }
>>>
>>> I can not possibly be the only D enthusiast who finds this completely incomprehensible. 
>> Yeah, that one is a bit tricky, and what makes it worse is that it seems 
>> officially sanctioned by Walter/Andrei as the "right way" to check if a 
>> type supports some operations. Basically, if you have:
>>
>> is(typeof({ @@@ }()));
>>
>> this means "if I made a function containing @@@, would that function 
>> compile?". It's a hack which stems from the way the is expression works.
>>
>>> What is a range?
>> As others have mentioned, it's just a struct (or other type) that 
>> happens to support certain operations.
> 
> So does this mean that interfaces are just a tragic mistake. I'd always thought that what you said was a pretty good description of what an interface is!
> 

IMHO, duck-typing in D is a tragic mistake...  This should have been 
implemented with compile time interfaces.
June 19, 2009
Re: Ranges
Yigal Chripun wrote:
...
> 
> IMHO, duck-typing in D is a tragic mistake...  This should have been
> implemented with compile time interfaces.

Care to provide arguments?
June 19, 2009
Re: Ranges
Lutger Wrote:

> Yigal Chripun wrote:
> ...
> > 
> > IMHO, duck-typing in D is a tragic mistake...  This should have been
> > implemented with compile time interfaces.
> 
> Care to provide arguments?

ignorance 'n' arrogance should do.
June 19, 2009
Re: Ranges
superdan wrote:

> Lutger Wrote:
> 
>> Yigal Chripun wrote:
>> ...
>> > 
>> > IMHO, duck-typing in D is a tragic mistake...  This should have been
>> > implemented with compile time interfaces.
>> 
>> Care to provide arguments?
> 
> ignorance 'n' arrogance should do.

Those I hold I high esteem, you convinced me.
June 20, 2009
Re: Ranges
Lutger wrote:
> Yigal Chripun wrote:
> ...
>> IMHO, duck-typing in D is a tragic mistake...  This should have been
>> implemented with compile time interfaces.
> 
> Care to provide arguments?
> 
> 

duck typing makes more sense in dynamic languages like Ruby which is 
famous for it.

in static languages I as a user prefer to trade flexibility due to 
duck-typing for compile time checks.

yes, at compile time, duck typing and (compile-time) interfaces are 
basically the same thing, but since the rest of the language uses formal 
interfaces, it is more consistent (and easier to understand) to use the 
same approach at compile-time as well. point in case, look how much 
unnecessary confusion Ranges cause which would be eliminated had D 
allowed for compile-time interfaces.
i.e.
Interface I { .. }
struct S : I { ... }
this is basically the same as C++ concepts only without redundant and 
confusing syntax.

templates are hard for users to understand and one of the main reasons 
for this is that templates are essentially a completely different 
language with different syntax and semantics which to me looks like 
mis-design.
June 20, 2009
Re: Ranges
Yigal Chripun:
> point in case, look how much 
> unnecessary confusion Ranges cause which would be eliminated had D 
> allowed for compile-time interfaces.

What are interfaces from the point of view of the compiler?

Bye,
bearophile
(P.S.: Is Walter around still? He's pretty silent lately. Talking when he's not around looks quite academic).
June 20, 2009
Re: Ranges
Yigal Chripun Wrote:

> Lutger wrote:
> > Yigal Chripun wrote:
> > ...
> >> IMHO, duck-typing in D is a tragic mistake...  This should have been
> >> implemented with compile time interfaces.
> > 
> > Care to provide arguments?
> > 
> > 
> 
> duck typing makes more sense in dynamic languages like Ruby which is 
> famous for it.

yer didnt say why & this adds nutt'n'.

> in static languages I as a user prefer to trade flexibility due to 
> duck-typing for compile time checks.

yer dunno what yer talking about do ya. d checks duck typed shit at compile time.

> yes, at compile time, duck typing and (compile-time) interfaces are 
> basically the same thing, but since the rest of the language uses formal 
> interfaces, it is more consistent (and easier to understand) to use the 
> same approach at compile-time as well. point in case, look how much 
> unnecessary confusion Ranges cause which would be eliminated had D 
> allowed for compile-time interfaces.
> i.e.
> Interface I { .. }
> struct S : I { ... }
> this is basically the same as C++ concepts only without redundant and 
> confusing syntax.

& how do ya figure tat I defines a type elementtype?

> templates are hard for users to understand and one of the main reasons 
> for this is that templates are essentially a completely different 
> language with different syntax and semantics which to me looks like 
> mis-design.

2 me looks like yer in way over yer head.
June 20, 2009
Re: Ranges
== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> Yigal Chripun:
> > point in case, look how much
> > unnecessary confusion Ranges cause which would be eliminated had D
> > allowed for compile-time interfaces.
> What are interfaces from the point of view of the compiler?

Abstract classes with only pure virtual functions.  In other words, basically
under the hood, an interface is just the layout of a vtable.

This actually leads to a comment I want to make in the wider debate:  I personally
find explicit interfaces really, really annoying and I think that duck typing is
by far the most intuitive type system there is.  I used to program primarily in
duck typed languages and resort to every kludge imaginable for speed.  What
attracted me to D was that the templates and type inference are so powerful that I
almost feel like it's still a duck typed language, but much faster and with more
error checking.  I guess that's why I like ranges so much.

Also, while the fact that you need interfaces to specify a vtable layout is an
implementation detail, I would argue that, in close to the metal languages, it
does more harm than good to try too hard to prevent implementation details from
leaking into the language abstractions.  Otherwise, what would be the point of it
being a close to the metal language?  The fact that, for templates, one does not
need to specify vtable layouts and for OO you do justifies the asymmetry between
templates and OO.  Interfaces for templates would just add boilerplate and make
explicit something that is already implicitly knowable and checked at compile time
anyhow.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home