www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static interface

reply Leandro Lucarella <llucax gmail.com> writes:
Why not? ;)

I know you might want to hit me for bringing just another feature request
inspired in Google's Go, but please do read it without preconceptions,
because I think the features I'm suggesting are mostly already in D, but
in a less convenient way.

With ranges, D is already using some kind of duck-typing. It's implemented
with template, template constraints and __traits(compiles)/is(typeof())
mostly. The range module makes extensive use of this trick.

All those features are great, and general and useful for a lot of things
besides duck-typing. But (compile-time) duck-typing is a very nice feature
which might deserve a little magic to avoid the boilerplate (or at least
odd implementation).

What I'm suggesting is just some syntax sugar for compile-time
duck-typing. My suggestion is to make this (a real example from the range
module):

static interface InputRange(T) {
	bool empty();
	T front();
	void popFront();
}

size_t walkLength(InputRange range, size_t upTo = size_t.max)
{
	// implementation
}

struct Stride(T): InputRange(T) {
	// implementation
}


Be somehow equivalent to:

template isInputRange(R)
{
    enum bool isInputRange = is(typeof(
    {
        R r;
        if (r.empty) {}
        r.popFront;
        auto h = r.front;
    }()));
}

size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
if (isInputRange!(Range))
{
	// implementation
}

struct Stride(T) if (isInputRange!(Range)) {
	// implementation
}


The former syntax is much pleasant for both defining 'static interfaces'
and writing algorithms for them.

I didn't thought about this too much, and I'm sure there are plenty of
holes to be worked out, but I wanted to throw the idea out there to see
what people think about it.

What do you think?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I always get the feeling that when lesbians look at me, they're thinking,
'*That's* why I'm not a heterosexual.'
	-- George Constanza
Nov 16 2009
next sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
Leandro Lucarella schrieb:

 What do you think?
 

I like it.
Nov 16 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella Wrote:

 static interface InputRange(T) {

Few days ago a professional C# programmer, a smart person that doesn't know much about D, has asked me if in D there are static interfaces. I think he was thinking about something similar. I think that's a nice idea, or it can become a nice idea after some improvement. Bye, bearophile
Nov 16 2009
prev sibling next sibling parent Jesse Phillips <JesseKPhillips+D gmail.com> writes:
Is there a reason not to have all interfaces compile time checked? It would
still be allowable to state a class implements an interface and have the
compiler check it.

The reason I say this is it would remove the complexity of having the two types
of interfaces. And if you wanted to be able to check for the interface at
run-time the same interface can be used.
Nov 16 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
Leandro Lucarella wrote:
 Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.
 static interface InputRange(T) {
 	bool empty();
 	T front();
 	void popFront();
 }
 
 size_t walkLength(InputRange range, size_t upTo = size_t.max)
 {
 	// implementation
 }
 
 struct Stride(T): InputRange(T) {
 	// implementation
 }

Or just: interface InputRange(T) { ... } struct Stride(T) : InputRange(T) { ... } size_t size_t walkLength(Range : InputRange)(Range range, ... The main purpose of the interface is to allow the compiler to do some type checking. (Interestingly, you could get an actual interface from a struct pointer. The compiler just needs to statically allocate a vtable (similar to a TypeInfo when writing typeid(T)). But I don't know if it'd be useful and is besides the point.) Actually I'd prefer your proposal, because walkLength could access only members that are actually in InputRange. But the declaration looks too much like an untemplated function. On the other hand, I remember that D2 once wanted to make this possible: void foo(static int x, int y) { ... } becomes void foo(int x)(int y) { ... } What happened to this? If it gets/got implemented, it would provide a nice opportunity to add syntax for such static interfaces.
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Leandro Lucarella wrote:
 Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. Andrei
Nov 16 2009
next sibling parent reply grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 grauzone wrote:
 Leandro Lucarella wrote:
 Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

That's understandable of course.
 FWIW I was keen on structs interacting in interesting ways with 
 interfaces (and submitted a number of enhancements in that directions) 
 but then realized there are a number of problems that structs/interfaces 
 cannot solve. I believe that a better path to pursue in checking 
 interface conformance is via reflection.

That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned?
 
 Andrei

Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 Leandro Lucarella wrote:
 Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

That's understandable of course.
 FWIW I was keen on structs interacting in interesting ways with 
 interfaces (and submitted a number of enhancements in that directions) 
 but then realized there are a number of problems that 
 structs/interfaces cannot solve. I believe that a better path to 
 pursue in checking interface conformance is via reflection.

That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned?

I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route. Andrei
Nov 16 2009
parent reply grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 grauzone wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 Leandro Lucarella wrote:
 Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

That's understandable of course.
 FWIW I was keen on structs interacting in interesting ways with 
 interfaces (and submitted a number of enhancements in that 
 directions) but then realized there are a number of problems that 
 structs/interfaces cannot solve. I believe that a better path to 
 pursue in checking interface conformance is via reflection.

That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned?

I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route.

In other words, a general solution inside the language would be too complex (because it had to support all sorts of type interfaces), so you'll just leave it to the user, who will implement the same thing with is() and friends?
 Andrei

Nov 16 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 Leandro Lucarella wrote:
 Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

That's understandable of course.
 FWIW I was keen on structs interacting in interesting ways with 
 interfaces (and submitted a number of enhancements in that 
 directions) but then realized there are a number of problems that 
 structs/interfaces cannot solve. I believe that a better path to 
 pursue in checking interface conformance is via reflection.

That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned?

I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route.

In other words, a general solution inside the language would be too complex (because it had to support all sorts of type interfaces), so you'll just leave it to the user, who will implement the same thing with is() and friends?

I don't think that's a fair characterization. With reflection you can implement such capability in a library. Sometimes a motivated and well-intended feature could grow into a monster of generalization. This is what happened to C++ concepts and what could have happened to typedef if we hadn't clipped it. Andrei
Nov 16 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste:
 grauzone wrote:
 Leandro Lucarella wrote:
 Why not? ;)

this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

I completely agree and understand. I wish I had the time to make patches myself for the things I propose. But it's very different if something is not implemented because it sucks or just because the lack of men power :) If some good feature has Walter's blessing, maybe other person can implement it. Nobody wants to implement something if it doesn't have Walter's blessing, because we all know he's very tough to convince, and nobody wants to work on something it won't get accepted.

What I can tell is that Walter's keenness on adding/changing something has a 10-fold improvement if a patch is present. For example Walter was sort of ambivalent about opDollar and opDollar!(dim)() until Don simply added it.
 FWIW I was keen on structs interacting in interesting ways with
 interfaces (and submitted a number of enhancements in that
 directions) but then realized there are a number of problems that
 structs/interfaces cannot solve. I believe that a better path to
 pursue in checking interface conformance is via reflection.

But that's very laborious, to be honest, I saw some points in std.range that would be hard to cover with static interfaces, but for those things you have all the flexibility you're already using. But static interfaces could cover a wide range of applications, making static duck-typing very easy to use.

There's a saying that most all girls may look good in the dark. Paraphrasing that, I'd say all language features look nice and easy when (a) detail is not discussed, (b) all the rest of the language is assumed to be mastered. There are places in D where we can't do what we want to do. Those are top priority. Those that do easier what we can do anyway (struct mixins, static interfaces, even the better switch which I actually personally like) are below top priority. The barrier is fuzzy because either I, Walter, or Don may suddenly catch fancy to a specific thing to work on, but I wish we were more, not less disciplined about that. Andrei
Nov 16 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el 16 de noviembre a las 13:19 me escribiste:
 Is there a reason not to have all interfaces compile time checked? It
 would still be allowable to state a class implements an interface and
 have the compiler check it.
 
 The reason I say this is it would remove the complexity of having the
 two types of interfaces. And if you wanted to be able to check for the
 interface at run-time the same interface can be used.

The problem is "regular" interfaces provide dynamic dispatch. Andrei could implement all the range stuff using interfaces, but that would mean: 1) You have to inherit from the interface (i.e., you can't use arrays) 2) All calls to ranges functions are virtual (inefficient; this is particularly relevant since they are called inside loops => lot of times) A static interface don't have those problems, and I don't see a way to mix static and dynamic interfaces without introducing a "new" type of interfaces (static interface). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Si pudiera acercarme un poco más, hacia vos Te diría que me tiemblan los dos pies, cuando me mirás Si supieras todo lo que me costó, llegar Hoy sabrías que me cuesta respirar, cuando me mirás
Nov 16 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste:
 grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

I completely agree and understand. I wish I had the time to make patches myself for the things I propose. But it's very different if something is not implemented because it sucks or just because the lack of men power :) If some good feature has Walter's blessing, maybe other person can implement it. Nobody wants to implement something if it doesn't have Walter's blessing, because we all know he's very tough to convince, and nobody wants to work on something it won't get accepted.
 FWIW I was keen on structs interacting in interesting ways with
 interfaces (and submitted a number of enhancements in that
 directions) but then realized there are a number of problems that
 structs/interfaces cannot solve. I believe that a better path to
 pursue in checking interface conformance is via reflection.

But that's very laborious, to be honest, I saw some points in std.range that would be hard to cover with static interfaces, but for those things you have all the flexibility you're already using. But static interfaces could cover a wide range of applications, making static duck-typing very easy to use. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Breathe, breathe in the air. Don't be afraid to care. Leave but don't leave me. Look around and choose your own ground.
Nov 16 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella <llucax gmail.com> wrote:
 Why not? ;)

 I know you might want to hit me for bringing just another feature request
 inspired in Google's Go, but please do read it without preconceptions,
 because I think the features I'm suggesting are mostly already in D, but
 in a less convenient way.

I, for one, think these are great things to talk about. Even if it's decided that it's a bad idea for D to get such a feature, then as many people as possible should know that reason so we can talk intelligently about why D does things the way it does. Because if we're asking ourselves why D doesn't have X, you can bet there are others who will wonder the same when they see D. --bb
Nov 16 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella <llucax gmail.com> wrote=
:

This topic is actually very close to a discussion last week about
retrieving error messages from failures of __traits(compiles, xxx).

My question is: is it really that much of an improvement?

I've rearranged your code to see the equivalent snippets side-by-side:

 static interface InputRange(T) {
 =A0 =A0 =A0 =A0bool empty();
 =A0 =A0 =A0 =A0T front();
 =A0 =A0 =A0 =A0void popFront();
 }

 template isInputRange(R)
 {
    enum bool isInputRange =3D is(typeof(
    {
        R r;
        if (r.empty) {}
        r.popFront;
        auto h =3D r.front;
    }()));
 }

There's actually not that much difference here. Of course we would like several general improvements that have been discussed before: 1) some kind of template 'this' so we don't have to repeat the template nam= e. 2) something better than is(typeof()) (or __traits(compiles, ...)) to check if code is ok. [hoping for meta.compiles(...)] In some ways the current code is better, because it actually checks if a construct works or not, rather than requiring a specific function signature. Whether the code will work is really the minimal restriction you can place on the interface. A specific may be too tight. For instance, above you don't really care if empty returns bool or not. Just if you can test it in an "if".
 struct Stride(T): InputRange(T) {
 =A0 =A0 =A0 =A0// implementation
 }

 struct Stride(T) if (isInputRange!(T)) {
 =A0 =A0 =A0 =A0// implementation
 }

There's really not a significant difference in those two.
 size_t walkLength(InputRange range, size_t upTo =3D size_t.max)
 {
        // implementation
 }

 size_t walkLength(Range)(Range range, size_t upTo =3D size_t.max)
 if (isInputRange!(Range))
 {
        // implementation
 }

Here is the only one where I see a significant improvement. Basically that all comes from not having to repeat yourself. So maybe we'd be better off attacking that repetitiveness directly. But in terms of functionality it seems we cover pretty much everything static interface gives you. The only exception may be that static interfaces could give you better error messages about why your type doesn't satisfy the requirements. That's where better ways to get the error messages from __traits(compiles,...) errors come in. But it's harder to make that useful in D without giving up overloading. In D if T doesn't satisfy isInputRange!(T), it might satisfy some other overload of the template. --bb
Nov 16 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Bill Baxter wrote:
 On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella <llucax gmail.com> wrote:
 
 This topic is actually very close to a discussion last week about
 retrieving error messages from failures of __traits(compiles, xxx).
 
 My question is: is it really that much of an improvement?
 
 I've rearranged your code to see the equivalent snippets side-by-side:
 
 static interface InputRange(T) {
        bool empty();
        T front();
        void popFront();
 }

 template isInputRange(R)
 {
    enum bool isInputRange = is(typeof(
    {
        R r;
        if (r.empty) {}
        r.popFront;
        auto h = r.front;
    }()));
 }

There's actually not that much difference here. Of course we would like several general improvements that have been discussed before: 1) some kind of template 'this' so we don't have to repeat the template name. 2) something better than is(typeof()) (or __traits(compiles, ...)) to check if code is ok. [hoping for meta.compiles(...)] In some ways the current code is better, because it actually checks if a construct works or not, rather than requiring a specific function signature. Whether the code will work is really the minimal restriction you can place on the interface. A specific may be too tight. For instance, above you don't really care if empty returns bool or not. Just if you can test it in an "if".

Another, related way in which the current code is better is that it doesn't care whether empty, front, and popFront are functions or variables. As we know, the standard trick for infinite ranges is to declare empty as an enum, not a function. BTW, I find it interesting that I see meta.* being mentioned in discussions and even used in code snippets all over the NG these days. It seems to be a popular proposal. I hope it gets implemented too. :) -Lars
Nov 17 2009
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Leandro Lucarella wrote:
 Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
 In some ways the current code is better, because it actually checks if
 a construct works or not, rather than requiring a specific function
 signature.  Whether the code will work is really the minimal
 restriction you can place on the interface.  A specific may be too
 tight.  For instance, above you don't really care if empty returns
 bool or not.  Just if you can test it in an "if".

doesn't care whether empty, front, and popFront are functions or variables. As we know, the standard trick for infinite ranges is to declare empty as an enum, not a function.

Is not that hard to write: bool empty() { return false; } instead of enum bool empty = false;

That's why I mentioned infinite ranges. An infinite range is *defined* as a range where empty is implemented as enum bool empty = false; isInfinite(Range) tests whether this is the case, which it wouldn't be able to do if empty() was a function. -Lars
Nov 17 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-17 09:12:04 -0500, "Lars T. Kyllingstad" 
<public kyllingen.NOSPAMnet> said:

 That's why I mentioned infinite ranges. An infinite range is *defined* 
 as a range where empty is implemented as
 
    enum bool empty = false;
 
 isInfinite(Range) tests whether this is the case, which it wouldn't be 
 able to do if empty() was a function.

Which makes me think: what about a range that can but may not necessarily be infinite depending on runtime parameters? For instance, you could have a range returning a rational number as decimal digits: some will be infinite and others will be finite depending on the rational number (like 1/3 vs. 1/4). You can't express that with an enum. I guess you could fix that by overloading isInfinite for your specific range type though. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 17 2009
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Leandro Lucarella (llucax gmail.com)'s article
 Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature.  Whether the code will work is really the minimal
restriction you can place on the interface.  A specific may be too
tight.  For instance, above you don't really care if empty returns
bool or not.  Just if you can test it in an "if".

Another, related way in which the current code is better is that it doesn't care whether empty, front, and popFront are functions or variables. As we know, the standard trick for infinite ranges is to declare empty as an enum, not a function.

bool empty() { return false; } instead of enum bool empty = false;

Yes, but there's a reason to use enum: This convention enables compile time introspection as to whether the ranges are infinite. It's also more efficient when inlining is disabled.
Nov 17 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el 16 de noviembre a las 15:42 me escribiste:
 On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella <llucax gmail.com> wrote:
 
 This topic is actually very close to a discussion last week about
 retrieving error messages from failures of __traits(compiles, xxx).
 
 My question is: is it really that much of an improvement?
 
 I've rearranged your code to see the equivalent snippets side-by-side:
 
 static interface InputRange(T) {
        bool empty();
        T front();
        void popFront();
 }

 template isInputRange(R)
 {
    enum bool isInputRange = is(typeof(
    {
        R r;
        if (r.empty) {}
        r.popFront;
        auto h = r.front;
    }()));
 }

There's actually not that much difference here. Of course we would like several general improvements that have been discussed before: 1) some kind of template 'this' so we don't have to repeat the template name. 2) something better than is(typeof()) (or __traits(compiles, ...)) to check if code is ok. [hoping for meta.compiles(...)] In some ways the current code is better, because it actually checks if a construct works or not, rather than requiring a specific function signature. Whether the code will work is really the minimal restriction you can place on the interface. A specific may be too tight. For instance, above you don't really care if empty returns bool or not. Just if you can test it in an "if".

I think one could argue if being more restrictive is actually good or bad. Being more restrictive cold lead to less errors. Maybe if a struct empty() method returns, say, a pointer, I don't want to think it is *really* a range. Maybe that method is doing a lot of work and removing stuff, and then returning a pointer to some removed stuff. Anyway, I'm not saying that that couldn't happen even if empty() return bool (that's a risk when duck-typing, always :), I'm just saying I'm not so sure that being more restrictive is really a *bad thing*. And about what's nice or ugly, I agree the current way of doing stuff is not too bad, there are a few details that are not *that* nice. But with duck-typing I think the same that with tuples: those little details makes you feel that D doesn't support the concept so well, and make people resistant to use them. When something feels natural in a language, you use it all the time, for me, the current way to do tuples and duck-typing looks very artificial and harder than it should.
 But in terms of functionality it seems we cover pretty much everything
 static interface gives you.

I know that, I started this proposal just saying that =) Again, this proposal is about what I say in the previous paragraphs. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Be nice to nerds Chances are you'll end up working for one
Nov 17 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature.  Whether the code will work is really the minimal
restriction you can place on the interface.  A specific may be too
tight.  For instance, above you don't really care if empty returns
bool or not.  Just if you can test it in an "if".

Another, related way in which the current code is better is that it doesn't care whether empty, front, and popFront are functions or variables. As we know, the standard trick for infinite ranges is to declare empty as an enum, not a function.

Is not that hard to write: bool empty() { return false; } instead of enum bool empty = false;
 BTW, I find it interesting that I see meta.* being mentioned in
 discussions and even used in code snippets all over the NG these
 days. It seems to be a popular proposal. I hope it gets implemented
 too. :)

We all do ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- FALTAN 325 DIAS PARA LA PRIMAVERA -- Crónica TV
Nov 17 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Lars T. Kyllingstad, el 17 de noviembre a las 15:12 me escribiste:
 Leandro Lucarella wrote:
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature.  Whether the code will work is really the minimal
restriction you can place on the interface.  A specific may be too
tight.  For instance, above you don't really care if empty returns
bool or not.  Just if you can test it in an "if".

doesn't care whether empty, front, and popFront are functions or variables. As we know, the standard trick for infinite ranges is to declare empty as an enum, not a function.

Is not that hard to write: bool empty() { return false; } instead of enum bool empty = false;

That's why I mentioned infinite ranges. An infinite range is *defined* as a range where empty is implemented as enum bool empty = false; isInfinite(Range) tests whether this is the case, which it wouldn't be able to do if empty() was a function.

OK, there are way to fix that too, but I see your point now. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- "The Guinness Book of Records" holds the record for being the most stolen book in public libraries
Nov 17 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 17, 2009 at 5:51 AM, Leandro Lucarella <llucax gmail.com> wrote=
:
 Bill Baxter, el 16 de noviembre a las 15:42 me escribiste:
 On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella <llucax gmail.com> wr=


 This topic is actually very close to a discussion last week about
 retrieving error messages from failures of __traits(compiles, xxx).

 My question is: is it really that much of an improvement?

 I've rearranged your code to see the equivalent snippets side-by-side:

 static interface InputRange(T) {
 =A0 =A0 =A0 =A0bool empty();
 =A0 =A0 =A0 =A0T front();
 =A0 =A0 =A0 =A0void popFront();
 }

 template isInputRange(R)
 {
 =A0 =A0enum bool isInputRange =3D is(typeof(
 =A0 =A0{
 =A0 =A0 =A0 =A0R r;
 =A0 =A0 =A0 =A0if (r.empty) {}
 =A0 =A0 =A0 =A0r.popFront;
 =A0 =A0 =A0 =A0auto h =3D r.front;
 =A0 =A0}()));
 }

There's actually not that much difference here. =A0Of course we would like several general improvements that have been discussed before: 1) some kind of template 'this' so we don't have to repeat the template =


 2) something better than is(typeof()) (or __traits(compiles, ...)) to
 check if code is ok. [hoping for meta.compiles(...)]

 In some ways the current code is better, because it actually checks if
 a construct works or not, rather than requiring a specific function
 signature. =A0Whether the code will work is really the minimal
 restriction you can place on the interface. =A0A specific may be too
 tight. =A0For instance, above you don't really care if empty returns
 bool or not. =A0Just if you can test it in an "if".

I think one could argue if being more restrictive is actually good or bad=

 Being more restrictive cold lead to less errors. Maybe if a struct empty(=

 method returns, say, a pointer, I don't want to think it is *really*
 a range. Maybe that method is doing a lot of work and removing stuff, and
 then returning a pointer to some removed stuff. Anyway, I'm not saying
 that that couldn't happen even if empty() return bool (that's a risk when
 duck-typing, always :), I'm just saying I'm not so sure that being more
 restrictive is really a *bad thing*.

If that's what you want, the D way gives you the option of checking is(typeof(R.empty)=3D=3Dbool) But yeh, that is klunkier than just writing out the function signature you're expecting.
 And about what's nice or ugly, I agree the current way of doing stuff is
 not too bad, there are a few details that are not *that* nice. But with
 duck-typing I think the same that with tuples: those little details makes
 you feel that D doesn't support the concept so well, and make people
 resistant to use them. When something feels natural in a language, you us=

 it all the time, for me, the current way to do tuples and duck-typing
 looks very artificial and harder than it should.

Agreed. But as for the duck typing aspect, I think there isn't necessarily an either-or choice here. For instance, in D, we could allow a static interface to have a static assert block: static interface InputRange(T) { static assert (meta.compiles({ if (this.empty) {}; // this is a shortcut for T.init })); T front(); void popFront(); } Or something like that. "Invariant {}" might be better there.
 But in terms of functionality it seems we cover pretty much everything
 static interface gives you.

I know that, I started this proposal just saying that =3D)

Ah. Sorry, I missed that comment. --bb
Nov 17 2009
prev sibling next sibling parent =?UTF-8?B?IuOBruOBl+OBhOOBiyAobm9zaGlpa2EpIg==?= writes:
In order to achieve good completion support by editors (like
IntelliSense) with duck-typed variables, concept-checking code should
contain more type information than that of the code now used in Phobos.

Example:

   static interface InputRange(T) {
     const bool empty();
     T front();
     void popFront();
   }

or in the current D syntax,

   template isInputRange(T, R) {
     enum isInputRange =
       is(const(R).init.empty() == bool) &&
       is(R.init.front() == T) &&
       is(R.init.popFront() == void);
   }

How do you think about this?
Nov 18 2009
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Leandro Lucarella <llucax gmail.com> wrote:

 What do you think?

I was inspired: template staticInterface( T, iface ) { static assert( is( iface == interface ) ); static assert( is( T == struct ) ); alias staticInterfaceImpl!( T, MemberTuple!( iface ) ) staticInterface; } template staticInterfaceImpl( T, U... ) { static if ( U.length ) { enum staticInterfaceImpl = isIn!( U[ 0 ], U[ 1 ], MemberTuple!( T ) ) && staticInterfaceImpl!( T, U[ 2..$ ] ); } else { enum staticInterfaceImpl = true; } } template MemberTuple( T ) { alias allMembersToTypeTuple!( T, __traits( allMembers, T ) ) MemberTuple; } template allMembersToTypeTuple( T, alias U, V... ) { static if( U.length ) { alias allMembersToTypeTuple!( T, U[1..$], U[ 0 ], typeof( mixin( T.stringof ~ "." ~ U[ 0 ] ) ), V ) allMembersToTypeTuple; } else { alias V allMembersToTypeTuple; } } template isIn( string name, T, U... ) { static if ( U.length ) { enum isIn = ( name == U[ 0 ] && is( T == U[ 1 ] ) ) || isIn!( name, T, U[ 2..$ ] ); } else { enum isIn = false; } } Usage: interface I; struct S; static if ( staticInterface!( S, I ) ) {} There may be problems with this, and it might not match everything as nicely as it should, but it's a proof-of-concept. I'm open to suggestions on how to extend/fix it. -- Simen
Nov 19 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Simen kjaeraas, el 19 de noviembre a las 12:47 me escribiste:
 Leandro Lucarella <llucax gmail.com> wrote:
 
What do you think?

I was inspired:

 
 Usage:
 
 interface I;
 struct S;
 static if ( staticInterface!( S, I ) ) {}

Nice! :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- - Los romanos no tenían paz, loco... Necesitaban un poco de chala...
Nov 19 2009