www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - wrap/unwrap vs Go-style duck typing

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hello,

I was curious how our fledgling wrap and unwrap routines compare with 
Go's duck typing - similarities, distinctions, performance. Please share 
any thoughts, thanks!

Andrei
Oct 24 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 25 October 2013 at 05:45:53 UTC, Andrei Alexandrescu 
wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines 
 compare with Go's duck typing - similarities, distinctions, 
 performance. Please share any thoughts, thanks!

 Andrei


Are there some examples somewhere of when using wrap/unwrap is a 
good design choice? I can imagine it's convenient in some cases, 
but what's the "killer use".
Oct 25 2013
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines compare with
 Go's duck typing - similarities, distinctions, performance. Please share
 any thoughts, thanks!

 Andrei


What are you referring to by wrap/unwrap, functions like inputRangeObject?

Martin
Oct 26 2013
parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Saturday, 26 October 2013 at 14:39:31 UTC, Martin Nowak wrote:

 On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines 
 compare with
 Go's duck typing - similarities, distinctions, performance. 
 Please share
 any thoughts, thanks!

 Andrei


 What are you referring to by wrap/unwrap, functions like 
 inputRangeObject?

 Martin
Oct 26 2013
next sibling parent "Meta" <jared771 gmail.com> writes:
For the second example, can you pass x.wrap!(A, B) to functions 
expecting either A or B?
Oct 26 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/26/13 7:55 AM, Nicolas Sicard wrote:

 On Saturday, 26 October 2013 at 14:39:31 UTC, Martin Nowak wrote:

 On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines compare with
 Go's duck typing - similarities, distinctions, performance. Please share
 any thoughts, thanks!

 Andrei


 What are you referring to by wrap/unwrap, functions like
 inputRangeObject?

 Martin






Yes, sorry for being unclear.

I wonder whether specifying "Go-style wrap/unwrap" would be a fair 
characterization when announcing 2.064.

Also, is it correct that Linux dynamic library support is really 
starting with this release? There was some before but not quite usable.


Andrei
Oct 26 2013
next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Saturday, 26 October 2013 at 15:08:23 UTC, Andrei Alexandrescu 
wrote:

 On 10/26/13 7:55 AM, Nicolas Sicard wrote:

 On Saturday, 26 October 2013 at 14:39:31 UTC, Martin Nowak 
 wrote:

 On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines 
 compare with
 Go's duck typing - similarities, distinctions, performance. 
 Please share
 any thoughts, thanks!






 I wonder whether specifying "Go-style wrap/unwrap" would be a 
 fair characterization when announcing 2.064.


Since Go's "duck typing" is implicit and automatic, and 
highlighted as such, "Go-style wrap/unwrap" sounds a bit 
paradoxical... What about "wrap/unwrap for Go-style structural 
typing"?

Nicolas
Oct 26 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-26 17:09, Andrei Alexandrescu wrote:


 Also, is it correct that Linux dynamic library support is really
 starting with this release? There was some before but not quite usable.


Yes, I think so. In the current release you can statically link with a 
dynamic library written in D. In the upcoming release dlopen and similar 
functions should work.

There's just a couple of regressions delaying the release.

-- 
/Jacob Carlborg
Oct 27 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 27 October 2013 at 10:25:02 UTC, Jacob Carlborg wrote:

 On 2013-10-26 17:09, Andrei Alexandrescu wrote:


 Also, is it correct that Linux dynamic library support is 
 really
 starting with this release? There was some before but not 
 quite usable.


 Yes, I think so. In the current release you can statically link 
 with a dynamic library written in D. In the upcoming release 
 dlopen and similar functions should work.

 There's just a couple of regressions delaying the release.


If we want to mention shared library support in the release 
notes, I think we really ought to make clear (with a big red 
warning) that D doesn't make any guarantees about ABI stability 
right now.

David
Oct 27 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 27 October 2013 at 11:49:38 UTC, David Nadlinger wrote:

 If we want to mention shared library support in the release 
 notes, I think we really ought to make clear (with a big red 
 warning) that D doesn't make any guarantees about ABI stability 
 right now.


Also, there is the big unresolved topic of symbol visibility, see 
e.g. http://wiki.dlang.org/DIP45 and the associated discussion.

I'm afraid we will repeat C++'s mistakes here and shoot ourselves 
in the foot big time if we keep symbols visible (i.e. exported 
from shared libraries) by default. The impact of that on (link 
time) optimization opportunities and, for big libraries, load 
times is absolutely non-negligible.

David
Oct 27 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, October 26, 2013 08:09:13 Andrei Alexandrescu wrote:

 Also, is it correct that Linux dynamic library support is really
 starting with this release? There was some before but not quite usable.


It was there in 2.063, but we explicitly decided not to announce it due to how 
alpha it was. So, it makes some sense to say that it's new in this release, 
though I don't know how ready it is even now. I haven't been paying a lot of 
attention, but it's my impression from what I've read that it still needs a 
lot of work. I expect that it's plenty ready for folks to play around with, 
but if it's anyone's expectation that it's finished as-is, then I expect that 
they'll be in for a rude surprise, and I don't know how many of those changes 
risk being non-backwards compatible. Martin would really be the one to ask 
about all that though, since he's the one doing most of the work. But we are 
getting there, regardless of whether it's really ready yet in this release or 
not.

- Jonathan M Davis
Oct 30 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 31/10/13 05:35, Jonathan M Davis wrote:

 On Saturday, October 26, 2013 08:09:13 Andrei Alexandrescu wrote:

 Also, is it correct that Linux dynamic library support is really
 starting with this release? There was some before but not quite usable.


 It was there in 2.063, but we explicitly decided not to announce it due to how
 alpha it was. So, it makes some sense to say that it's new in this release,
 though I don't know how ready it is even now.


How ready is it vis-à-vis other compilers?  I remember reading that the
dynamic 
library support was DMD-only.
Nov 03 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 25 October 2013 at 05:45:53 UTC, Andrei Alexandrescu 
wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines 
 compare with Go's duck typing - similarities, distinctions, 
 performance. Please share any thoughts, thanks!

 Andrei


This is what I've come up with.

It doesn't look like it works with structures? Go doesn't have 
classes so structures are going to provide the most "Go" like 
feel.

I expect it doesn't work with pseudo members. Go adds methods to 
a struct similar to C++ friend methods or the UFCS provided by D. 
Thus, it would feel more natural to a Go programmer to add 
"friend" functions and expect them to be usable by the 
typecons.wrap(). And on a D related note:

It would be nice to support UFCS during the wrapping, this comes 
back to the example of arrays. An array is only a range because 
std.range was imported, if a function checks to see 
if(isInputRange!R) then arrays would fail if that same module 
didn't import std.range. If wrap worked with the current scoped 
"friend" functions, then the caller could easily just 
arr.wrap!InputRange and move on. This just seems like the main D 
use-case for this type of feature.

I'm also not sure why this code is giving me linker errors. I've 
gotten the examples to work, but trying to mimic a Go blog isn't 
working:
http://blog.jessta.id.au/2011/06/golang-interfaces.html

     interface Writer { void Write(string); }

     void SomeFunction(Writer w){
         w.Write("pizza");
     }

     class Human {
         void Write(string s) {
             import std.stdio;
             writeln(s);
         }
     }
     void main() {
         Human h = new Human();;

         import std.typecons;
         SomeFunction(h.wrap!Writer);
     }

undefined reference to 
`_D3std8typecons24__T4wrapTC5write6WriterZ23__T4wrapTC5write5HumanZ4Impl308__T8mixinAllVAyaa143_6f766572726964652052657475726e5479706521...
Oct 26 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 25 October 2013 at 05:45:53 UTC, Andrei Alexandrescu 
wrote:

 Hello,

 I was curious how our fledgling wrap and unwrap routines 
 compare with Go's duck typing - similarities, distinctions, 
 performance. Please share any thoughts, thanks!

 Andrei


It may have been really good if it worked with structs and could 
have been decently optimized away by compiler. Right now though 
similar built-in language implementation in Rust (I don't know 
how it is in go but assume similarity) is totally superior. Key 
point of this feature for me is being able to adapt existing 
non-polymorphic duck-typed aggregates (structs) to some external 
polymorphic binary interfaces. `wrap` does not seem to help here.
Oct 29 2013