Re: duck!
Kagamin, el 15 de octubre a las 17:16 me escribiste: Andrei Alexandrescu Wrote: I was talking to Walter about Kenji's adaptTo. We both think it's a very powerful enabler, but adaptTo is a bland name. After discussing a few marketing strategies, I proposed duck. It's short, simple, and evokes duck typing. 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't. I agree, just adapt might be an option, it even has a precedence of something similar in Python (even when the PEP[1] was rejected, PEAK has an implementation[2]). But duck is really cryptic (as symbol names invented by Andrei usually are :). [1] http://www.python.org/dev/peps/pep-0246/ [2] http://peak.telecommunity.com/protocol_ref/module-protocols.html -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Sus discipulos se miraron sin entended hasta que uno preguntose: Peperino, soy Daniel Q. de Olivos tengo 54 años y aún soy virgen. A lo que Peperino respondiole: Si sos ganso, ganso ser. Y lo frotó, y lo curó y lo sanó. A lo que todos dijeron: ¡¡¡Peperino se la come, Peperino se la come!!! -- Peperino Pómoro
Re: duck!
On Friday 15 October 2010 23:35:35 Leandro Lucarella wrote: Kagamin, el 15 de octubre a las 17:16 me escribiste: Andrei Alexandrescu Wrote: I was talking to Walter about Kenji's adaptTo. We both think it's a very powerful enabler, but adaptTo is a bland name. After discussing a few marketing strategies, I proposed duck. It's short, simple, and evokes duck typing. 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't. I agree, just adapt might be an option, it even has a precedence of something similar in Python (even when the PEP[1] was rejected, PEAK has an implementation[2]). But duck is really cryptic (as symbol names invented by Andrei usually are :). [1] http://www.python.org/dev/peps/pep-0246/ [2] http://peak.telecommunity.com/protocol_ref/module-protocols.html Considering that no one has presented a term which makes it immediately obvious what the function does and that the programmer is going to have to look it up regardless, I find duck to be a far better name since you're not going to mistake it for anything else. Adapt can and will be used it far more contexts that duck ever would be. duck is therefore more immediately recognizable and will not be ambiguous to the programmer. Sure, they're going to have to look it up, but they're going to have to look it up regardless of the name, so I think that the shorter and more memorable is a better name. - Jonathan M Davis
Re: duck!
auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof
Re: automatic code examples in documentation
Tomek Sowiński wrote:
Lutger napisał:
for reference: http://d.puremagic.com/issues/show_bug.cgi?id=2630
Tomasz Sowiński raises the point that each unittest should test the
preceding declaration. I think that's a little inflexible, instead the
following could work:
- unittests marked with 'ditto' will document the preceding declaration
Well, a unittest making a trial run of the preceding declaration is a
convention, natural and widely adopted. That well-trodden path deserves
to be acknowledged by the doc generator.
That's why I suggested ditto. Any comments can be put as regular code
comments inside the unittest itself, that will be marked up nicely by ddoc.
Good thing about this idea is that *nothing* changes, no extra gimmicks
around unittest blocks, the code's natural flow is intact.
- unittest not marked with ditto will be put in a hardwired macro like
BODY is, so that you have control where it gets put in the generated
documentation.
Hm.. would the hardwired macro name be same for all unittests? If so, the
notion of implicit ownership by the preceding declaration is necessary so
that the names wouldn't mix up.
Not necessarily. It could just be a container.
With this macro:
DDOC_UNITTEST_MEMBERS = h2unittests/h2 $0
/** one plus one*/
unittest { assert(1+1==2); }
/** one minus one */
unittest { assert(1-1==0); }
the above could expand to something like:
h2unittests/h2
$(DDOC_SUMMARY one plus one)
$(D_CODE unittest { assert(1+1==2); } )
$(DDOC_SUMMARY one minus one)
$(D_CODE unittest { assert(1-1==0); } )
Re: New slides about Go
Not sure about their rationale, but here is a Visual C++ team blog entry about it: http://blogs.msdn.com/b/vcblog/archive/2007/10/18/new-intrinsic-support-in-visual-studio-2008.aspx Walter Bright newshou...@digitalmars.com wrote in message news:i9a2t3$26p...@digitalmars.com... Paulo Pinto wrote: Still most modern languages are moving away from inline assembly. It's a pain to write an inline assembler and figure out how to integrate it in with the rest of the compiler. I can see why compiler writers don't want to do it, and look for reasons not to. Most modern languages do not even generate code - they target the JVM or CLI. Even Microsoft has dropped inline assembly support for the 64bit version of Visual C++, pointing developers to MASM. I'd be curious as to their rationale. People will always complain no matter what. Just use the official assembler for the target platform. Microsoft MASM has about 30 different incarnations, all accepting different syntax. It's a *constant* source of grief for customer support. Personally the last time I used inline assembly I was still target MS-DOS, long time ago and actually it is one of the features I don't like in D. I'd be forced to write a standalone assembler if D didn't have inline assembler. In any case, inline assembler in D is a substantial productivity booster for me for anything that needs assembler. The inline assembler is also quite ignorable, if you don't like it.
Re: [nomenclature] systems language
Maybe you should improve your english skills. I was being sarcastic. Next time, please read my email until the end, before hitting the reply button. One of the Juanjo's requirements for a languange to be considered a systems programming language, is for it to include support for inline assembler. I was just making a point that C fails his definition, because the inline assembler you find in most compilers is a vendor extension to the standard. No one in his perfect mind would say that C is not a systems programming language, but it fails the Juanjo's checkpoint list, hence my reply. -- Paulo SK s...@metrokings.com wrote in message news:mailman.628.1287155971.858.digitalmar...@puremagic.com... On Thu, Oct 14, 2010 at 11:39 PM, Paulo Pinto pj...@progtools.org wrote: You just ruled out C as a systems language. No, C is a systems language and fits my definition. 1) C need not overlay software written in another language 2) C allows expression of essential machine independent concepts How did inline assembly become a requirement? For machine dependent code, I can just link C with assembly. But it's still easy to nitpick against C. For example, ANSI C cannot express the family of atomic operations, which one could argue are essential machine independent concepts.
rationale for function and delegate
Hi, while reading TDPL I start wondering what is the background between function and delegate. They seem to provide more or less the same funcionality, except delegate allows the capture of the function declaration environment. Most of the programming languages with support for closures only have one way of doing it. Why is D providing two ways of doing it? For me sounds like a feature similar to register, or inline for doing what should be the compilers work. Deciding the best implementation for the closure. Thanks, Paulo
Re: rationale for function and delegate
On 10/16/10 10:40 AM, Paulo Pinto wrote: while reading TDPL I start wondering what is the background between function and delegate. delegate() is a function pointer amended with a second context pointer, which allows you to have pointers to member functions, closures and so on. function() is a C-style function pointer and can be used to interface with C code, etc., but obviously not for closures, since it its lacking the context part. There is a clear difference between the two types, Ilthough you probably don't need raw function pointers very often if you are working in a D only environment. If you want to have the compiler decide, you could always use auto…
Re: rationale for function and delegate
On Saturday 16 October 2010 01:40:55 Paulo Pinto wrote: Hi, while reading TDPL I start wondering what is the background between function and delegate. They seem to provide more or less the same funcionality, except delegate allows the capture of the function declaration environment. Most of the programming languages with support for closures only have one way of doing it. Why is D providing two ways of doing it? For me sounds like a feature similar to register, or inline for doing what should be the compilers work. Deciding the best implementation for the closure. Thanks, Paulo I believe that the two main reasons are 1. function pointers have less overhead. 2. If you want to use function pointers when calling C functions, you need function pointers rather than delegates. but there are probably others. - Jonathan M Davis
Re: [nomenclature] systems language
On Sat, 16 Oct 2010 10:36:48 +0200, Paulo Pinto pj...@progtools.org wrote: No one in his perfect mind would say that C is not a systems programming language, but it fails the Juanjo's checkpoint list, hence my reply. In my defense I must say that I never used a C compiler without an inline assembler.
Re: What do people here use as an IDE?
Russel Winder wrote: On Wed, 2010-10-13 at 16:24 -0700, Jonathan M Davis wrote: [ . . . ] Proper code completion, correctly jumping to function definitions, and various other features that IDEs generally do well tend to be quite poor in vim. It can do many of them on some level, but for instance, while ctags does give you the ability to jump to function declarations, it does quite poorly in the face of identical variable names across files. There are a number of IDE features that I would love to have and use but vim can't properly pull off. When I have a decent IDE, I'm always torn on whether to use vim or the IDE. vim (well, gvim) generally wins out, but sometimes the extra abilities of the IDE are just too useful. What I'd really like is full-featured IDE with complete and completely remappable vim bindings. Bizarrely the single feature that fails for me in Eclipse, NetBeans and IntelliJ IDEA that I find the single most problematic feature in my programming life -- which means Emacs remains the one true editor -- is formatting comments. I seemingly cannot survive without the ability to reformat the paragraphs of comment blocks to a given width. Emacs handles this trivially in all languages I use for the modes I have. The IDEs seem unable to provide the functionality. Usually they end up reformatting my entire file to some bizarre formatting that is not the one set up for the project. I appreciate that being able to trivially create properly formatted comments is probably uniquely my problem but . . . Same here, no IDE I've seen is able to format code and comments as well as (X)Emacs. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [nomenclature] systems language
so wrote: I asked the similar question on What do people here use as an IDE?, which i suppose the reason of this topic. And asked if anyone can name a language that can replace C (other than these two). I got answers like Haskell, F#, C#, Scala, Ada, and there are many more they say. It looks like people here agree that all languages are system languages. No, you got these answers when you asked for a list of powerful languages. A language may be powerful without being a systems language. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] a good color distance function
Justin Johansson wrote: Can anyone please suggest a decent algorithm for determining a color distance metric between two colors? The requirement is to come up with a good algorithm for contrasting a computed color from another color. Should this algorithm (function) be dependent upon whether the color model be additive (aka RGB) or subtractive (aka CMYK) or other? In the imaging industry (printers, scanners and screens), we usually use the L*a*b* [1] or L*u*v* [2] color spaces. Pythagorean distances in these spaces give reasonably good results, but more advanced measures have been developed [3] if you need more precision. Jerome [1] http://en.wikipedia.org/wiki/Lab_color_space [2] http://en.wikipedia.org/wiki/CIELUV_color_space [3] http://en.wikipedia.org/wiki/Color_difference -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [nomenclature] systems language
Not really, you got to read it again. On Sat, 16 Oct 2010 13:02:17 +0300, Jérôme M. Berger jeber...@free.fr wrote: so wrote: I asked the similar question on What do people here use as an IDE?, which i suppose the reason of this topic. And asked if anyone can name a language that can replace C (other than these two). I got answers like Haskell, F#, C#, Scala, Ada, and there are many more they say. It looks like people here agree that all languages are system languages. No, you got these answers when you asked for a list of powerful languages. A language may be powerful without being a systems language. Jerome -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
On 16/10/2010 6:30 PM, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof This is a totally brilliant suggestion by Christof as anyone who understands the XPath 2.0 type language would tell you also. While finding duck! rather cute, marketing intelligence will confirm that Christof's as! suggestion is the way to go. I feel woeful that I did not think of it myself. Award for naming suggestion definitely goes to Christof. Justin
Re: [nomenclature] systems language
Visual C++ 64bit no longer supports inline assembly, but they do offer intrinsics instead http://blogs.msdn.com/b/vcblog/archive/2007/10/18/new-intrinsic-support-in-visual-studio-2008.aspx Juanjo Alvarez f...@fakeemail.com wrote in message news:almarsoft.3746932674979703...@news.digitalmars.com... On Sat, 16 Oct 2010 10:36:48 +0200, Paulo Pinto pj...@progtools.org wrote: No one in his perfect mind would say that C is not a systems programming language, but it fails the Juanjo's checkpoint list, hence my reply. In my defense I must say that I never used a C compiler without an inline assembler.
Re: [nomenclature] systems language
On 16/10/2010 9:02 PM, Jérôme M. Berger wrote: so wrote: I asked the similar question on What do people here use as an IDE?, which i suppose the reason of this topic. And asked if anyone can name a language that can replace C (other than these two). I got answers like Haskell, F#, C#, Scala, Ada, and there are many more they say. It looks like people here agree that all languages are system languages. No, you got these answers when you asked for a list of powerful languages. A language may be powerful without being a systems language. Jerome Excellent counterpoint. Could not have said it better. Justin
Re: [nomenclature] systems language
No doubt. On Sat, 16 Oct 2010 14:11:12 +0300, Justin Johansson n...@spam.com wrote: On 16/10/2010 9:02 PM, Jérôme M. Berger wrote: so wrote: I asked the similar question on What do people here use as an IDE?, which i suppose the reason of this topic. And asked if anyone can name a language that can replace C (other than these two). I got answers like Haskell, F#, C#, Scala, Ada, and there are many more they say. It looks like people here agree that all languages are system languages. No, you got these answers when you asked for a list of powerful languages. A language may be powerful without being a systems language. Jerome Excellent counterpoint. Could not have said it better. Justin -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [nomenclature] systems language
On 14/10/2010 13:30, Justin Johansson wrote: Touted often around here is the term systems language. May we please discuss a definition to be agreed upon for the usage this term (at least in this community) and also have some agreed upon examples of PLs that might also be members of the set of systems languages. Given a general subjective term like this, one would have to suspect that the D PL is not the only member of this set. Cheers Justin Johansson PS. my apologies for posting a lame joke recently; certainly it was not meant to be disparaging towards the D PL and hopefully it was not taken this way. Something not mentioned so far: The language must be self hostable; i.e. you need to be able to write it's runtime in the language itself. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: [nomenclature] systems language
I'll just help you, because i am so nice! If you go read you will see i asked the question Name one? quoting If it wasn't for C++, there are plenty of other powerfull languages out there. We are good so far? I hope yes! You see that little sentence which is almost the first half of quote? If it wasn't for C++? I hope you do... Now someone with a little reading comprehension (i suppose i do have some) would interpret that line like Powerfull languages that could replace C++. So i did and asked if he could name one, it wasn't hard no? Come on, you can do better than this... Sorry if i am being harsh. On Sat, 16 Oct 2010 13:02:17 +0300, Jérôme M. Berger jeber...@free.fr wrote: so wrote: I asked the similar question on What do people here use as an IDE?, which i suppose the reason of this topic. And asked if anyone can name a language that can replace C (other than these two). I got answers like Haskell, F#, C#, Scala, Ada, and there are many more they say. It looks like people here agree that all languages are system languages. No, you got these answers when you asked for a list of powerful languages. A language may be powerful without being a systems language. Jerome -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
On 2010-10-16 03:30:27 -0400, Christof Schardt csn...@schardt.info said: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); I like as much more than duck. It's a good fit with to. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: duck!
On 10/16/2010 10:30 AM, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof Nice name. It can be confused with the dynamic cast operator by some C# users but that is probably a non-issue.
Re: duck!
On 16/10/2010 11:03 PM, Michel Fortin wrote: On 2010-10-16 03:30:27 -0400, Christof Schardt csn...@schardt.info said: auto d = duck!Drawable(c); // awes What about as auto d = as!Drawable(c); I like as much more than duck. It's a good fit with to. It all comes down to some type of morphism, say, an isomorphism, homomorphism, hetromorphism, polymorphism or other. Maybe I am wrong but me thinks that to fits better with polymorphism than isomorphism, whereas as fits better with what quacks like and therefore asymptotically approaching isomorphism which I think duck typing is all about. To consider the argument further we could ask whether or not there is is a bijective map f such that both f and its inverse f −1 are homomorphisms, i.e., structure-preserving mappings. ..., and from there further consider analogous mappings in the morphology domain with respect to both isomorphisms and polymorphisms. In short as! eats the lunch of to! in the duck typing metaphor. Now we call upon the morphism experts to adjudicate. Cheers Justin
Re: [nomenclature] systems language
so wrote: I'll just help you, because i am so nice! If you go read you will see i asked the question Name one? quoting If it wasn't for C++, there are plenty of other powerfull languages out there. We are good so far? I hope yes! You see that little sentence which is almost the first half of quote? If it wasn't for C++? I hope you do... Now someone with a little reading comprehension (i suppose i do have some) would interpret that line like Powerfull languages that could replace C++. So i did and asked if he could name one, it wasn't hard no? Come on, you can do better than this... Sorry if i am being harsh. plonk -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [nomenclature] systems language
Wow you are hopeless, i give up. On Sat, 16 Oct 2010 15:48:17 +0300, Jérôme M. Berger jeber...@free.fr wrote: so wrote: I'll just help you, because i am so nice! If you go read you will see i asked the question Name one? quoting If it wasn't for C++, there are plenty of other powerfull languages out there. We are good so far? I hope yes! You see that little sentence which is almost the first half of quote? If it wasn't for C++? I hope you do... Now someone with a little reading comprehension (i suppose i do have some) would interpret that line like Powerfull languages that could replace C++. So i did and asked if he could name one, it wasn't hard no? Come on, you can do better than this... Sorry if i am being harsh. plonk -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
On 2010-10-16 08:41:26 -0400, Justin Johansson n...@spam.com said: In short as! eats the lunch of to! in the duck typing metaphor. Yeah, I do agree, and I didn't mean I'd prefer to instead of as. All I said (or I meant to say) is that they look good as a pair, as is in a way a continuity from to, which I like. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: duck!
Justin Johansson wrote: On 16/10/2010 6:30 PM, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof This is a totally brilliant suggestion by Christof as anyone who understands the XPath 2.0 type language would tell you also. While finding duck! rather cute, marketing intelligence will confirm that Christof's as! suggestion is the way to go. I feel woeful that I did not think of it myself. Award for naming suggestion definitely goes to Christof. Justin plus, it's shorter to type. *ducks*
Re: New slides about Go
On 10/15/10 19:18 CDT, Justin Johansson wrote: On 16/10/2010 9:34 AM, Andrei Alexandrescu wrote: On 10/15/10 17:34 CDT, Andrei Alexandrescu wrote: On 10/15/10 16:25 CDT, Nick Sabalausky wrote: I just hope they get serious enough about functional programming to gain some monads to go along with their goroutines. They should call them gonads. Andrei Wait, that was your actual joke. Sig... Andrei Coincidentally, the official mailing list for Go PL is known as go-nuts! :-) Speaking of which, I gave one more read this morning to the reddit discussion (http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressiveness_of_go_pdf/). Boy, that didn't Go well. Andrei
Re: duck!
On 10/16/10 1:35 CDT, Leandro Lucarella wrote: Kagamin, el 15 de octubre a las 17:16 me escribiste: Andrei Alexandrescu Wrote: I was talking to Walter about Kenji's adaptTo. We both think it's a very powerful enabler, but adaptTo is a bland name. After discussing a few marketing strategies, I proposed duck. It's short, simple, and evokes duck typing. 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't. I agree, just adapt might be an option, it even has a precedence of something similar in Python (even when the PEP[1] was rejected, PEAK has an implementation[2]). But duck is really cryptic (as symbol names invented by Andrei usually are :). Walter recognized it instantly, as I think most should. Isn't duck typing really spread out there? Andrei
Re: duck!
On 10/16/10 2:21 CDT, Jonathan M Davis wrote: On Friday 15 October 2010 23:35:35 Leandro Lucarella wrote: Kagamin, el 15 de octubre a las 17:16 me escribiste: Andrei Alexandrescu Wrote: I was talking to Walter about Kenji's adaptTo. We both think it's a very powerful enabler, but adaptTo is a bland name. After discussing a few marketing strategies, I proposed duck. It's short, simple, and evokes duck typing. 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't. I agree, just adapt might be an option, it even has a precedence of something similar in Python (even when the PEP[1] was rejected, PEAK has an implementation[2]). But duck is really cryptic (as symbol names invented by Andrei usually are :). [1] http://www.python.org/dev/peps/pep-0246/ [2] http://peak.telecommunity.com/protocol_ref/module-protocols.html Considering that no one has presented a term which makes it immediately obvious what the function does and that the programmer is going to have to look it up regardless, I find duck to be a far better name since you're not going to mistake it for anything else. Adapt can and will be used it far more contexts that duck ever would be. duck is therefore more immediately recognizable and will not be ambiguous to the programmer. Sure, they're going to have to look it up, but they're going to have to look it up regardless of the name, so I think that the shorter and more memorable is a better name. Besides, it's good marketing. It's one thing to say, hey, D has this function called adaptTo that pretty much does duck typing and a different one to say, gee, D has duck to enact duck typing! Andrei
Re: rationale for function and delegate
On 10/16/10 4:26 CDT, Jonathan M Davis wrote: On Saturday 16 October 2010 01:40:55 Paulo Pinto wrote: Hi, while reading TDPL I start wondering what is the background between function and delegate. They seem to provide more or less the same funcionality, except delegate allows the capture of the function declaration environment. Most of the programming languages with support for closures only have one way of doing it. Why is D providing two ways of doing it? For me sounds like a feature similar to register, or inline for doing what should be the compilers work. Deciding the best implementation for the closure. Thanks, Paulo I believe that the two main reasons are 1. function pointers have less overhead. 2. If you want to use function pointers when calling C functions, you need function pointers rather than delegates. but there are probably others. That's about it. The book mentions 2, whereas 1 is implied. Andrei
Re: What do people here use as an IDE?
On 10/16/10 4:50 CDT, Jérôme M. Berger wrote: Same here, no IDE I've seen is able to format code and comments as well as (X)Emacs. Yah. Emacs' formatting abilities are like real estate prices in Houston: once you got calibrated to them, it's hard to move away. Andrei
Re: duck!
On 10/16/10 2:30 CDT, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Nice too, and evokes to. to was a success in spite of the fact that it's difficult to talk about (e.g. Could you use 'to'? To what? etc). I still prefer duck because it doesn't have this problem. Speaking of which, it looks like std.conv is a good place to put duck in. Andrei
Re: [nomenclature] systems language
On 10/16/10 6:39 CDT, div0 wrote: On 14/10/2010 13:30, Justin Johansson wrote: Touted often around here is the term systems language. May we please discuss a definition to be agreed upon for the usage this term (at least in this community) and also have some agreed upon examples of PLs that might also be members of the set of systems languages. Given a general subjective term like this, one would have to suspect that the D PL is not the only member of this set. Cheers Justin Johansson PS. my apologies for posting a lame joke recently; certainly it was not meant to be disparaging towards the D PL and hopefully it was not taken this way. Something not mentioned so far: The language must be self hostable; i.e. you need to be able to write it's runtime in the language itself. Solid one! Andrei
Re: duck!
On 10/16/10 12:30 AM, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof Forgive my ignorance, but with uniform function syntax, could this be rewritten as: auto d = c.as!Drawable; or will uniform function syntax not work with templates?
Re: duck!
On Sat, 2010-10-16 at 15:25 +0300, Max Samukha wrote:
On 10/16/2010 10:30 AM, Christof Schardt wrote:
auto d = duck!Drawable(c); // awes
What about as ?
auto d = as!Drawable(c);
Christof
Nice name. It can be confused with the dynamic cast operator by some C#
users but that is probably a non-issue.
Groovy uses as as a conversion operator. cf.
def x = [ run : { println ( 'Hello World.' ) } ] as Thread
x.start ( )
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: New slides about Go
On 10/15/2010 08:34 PM, Walter Bright wrote:
Max Samukha wrote:
I don't see why. They're useful enough.
I might have exaggerated. But, for example, this use case:
struct S
{
int x, y, z;
}
ref S foo();
void bar(ref S s);
void baz()
{
auto s = foo();
s.x = 1;
s.y = 2;
s.z = 3;
bar(*s);
}
will not be easy. One will have to use tricks like that unsafe Ref
struct or to move the code accessing the referenced object to another
function. Pretty awkward.
What I like about Go's solution is that it is consistent with
closures. When a group of locals escape with a closure (that is when
the address of the local function using that group is taken) they are
copied to heap. When a local escape by ref (that is when the address
of the local is taken), it is also copied to heap.
I understand how it works.
Of course, you do!
There is a downside to it, though. In D2,
closures get copied to the GC heap if there is a possibility of an
escaping reference. A lot of people complain about this being unexpected
hidden overhead.
Yeah, I don't like these hidden allocations either.
The trouble with copy any ref'd local to the heap automatically
happening is the biggest advantage of passing by ref (efficiency) is
automatically lost. Even if it does not escape, it is copied to the heap
anyway, as you point out below.
Indeed. Why create a stack-allocated local if it is going to be copied
to the heap anyway?
What I don't like about Go's closures/addresses-to-locals and D's
delegates is that stuff is heap-allocated implicitly and by default.
Go has even gone (sorry) as far as allocating copies *every* time the
address of a local is taken.
Exactly. (Though D won't do the copy if it can prove that the delegate
does not escape.)
That reminds me of the argument about new being necessary for
classes because it makes the heap allocation explicit. It is difficult
to say good-bye to new but at the same time we are somehow happy
with implicitly allocated closures.
I think that implicitly allocated closures are a lot less common than
passing a local by reference.
I have no idea how often closures are used. I use them rarely but some
people do crazy things with them.
Re: duck!
On Sat, Oct 16, 2010 at 9:01 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 10/16/10 2:30 CDT, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Nice too, and evokes to. to was a success in spite of the fact that it's difficult to talk about (e.g. Could you use 'to'? To what? etc). I still prefer duck because it doesn't have this problem. Speaking of which, it looks like std.conv is a good place to put duck in. Andrei Hmm.. I was going to suggest /dev/null but I suppose that works too. If we have to have it, I would vote for as over duck simply because duck can be interpreted either a noun with only metaphorical relevance or as a verb with no relevance at all. On the other hand, as is simple and gets the point across.
Re: rationale for function and delegate
== Quote from Paulo Pinto (pj...@progtools.org)'s article Hi, while reading TDPL I start wondering what is the background between function and delegate. They seem to provide more or less the same funcionality, except delegate allows the capture of the function declaration environment. Most of the programming languages with support for closures only have one way of doing it. Why is D providing two ways of doing it? For me sounds like a feature similar to register, or inline for doing what should be the compilers work. Deciding the best implementation for the closure. Thanks, Paulo Yes, it's ugly but in a systems language you need control over details like whether a context pointer is present in addition to the function pointer. Anyhow, one thing that people always seem to fail to notice is that std.functional has a toDelegate() function that can convert just about any function pointer into a delegate with minimal overhead. This mitigates the situation a lot, since if an API requires a delegate and you have a function pointer, you just do a toDelegate(someFunctionPointer).
Re: duck!
On 2010-10-16 09:54:50 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Walter recognized it instantly, as I think most should. Isn't duck typing really spread out there? duck is a misnomer. First, it's dubious whether this duck function implements what most people understand by duck typing. Wikipedia says In duck typing, one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. [...] If the object does not have the methods that are called then the function signals a run-time error. Your duck function isn't concerned about the aspects of an object that are used, it's concerned by the aspects of an objects that can implement a certain interface type. Duck typing is much more synonymous to dynamic dispatch, where errors are reported at runtime, than to the adaptor pattern. The two concepts are not totally unrelated, but they're not the same thing either. Second, you meant duck as a noun, but duck! looks like a verb to me for two reasons: because of the exclamation mark and because it's a function. I fear that in the absence of prior knowledge of that function it gets understood as: duck (verb) - lower the head or the body quickly to avoid a blow making sense only if you're writing some sort of game. Since we're looking for a verb, why not quack!. :-) as! doesn't have the verb ambiguity problem nor the terminology problem, and it's basically a continuation of the to! scheme. Personally, I'd go for as!. But I'd prefer even adaptTo! or adapt! rather than duck!. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: rationale for function and delegate
On Sat, 16 Oct 2010 14:42:13 + (UTC), dsimcha dsim...@yahoo.com wrote: delegate with minimal overhead. This mitigates the situation a lot, since if an API requires a delegate and you have a function pointer, you just do a toDelegate(someFunctionPointer). Sorry for asking here something that should go to D.learn, but how do you do the reverse, that is, getting a function from a delegate? I need that in my project so I can pass it to signal so some Unix signal will trigger a method of an already instantiated object.
Re: duck!
On Sat, 16 Oct 2010 09:30:27 +0200, Christof Schardt csn...@schardt.info wrote: auto d = as!Drawable(c); My turn: auto d = implements!Drawable(c);
Re: What do people here use as an IDE?
Am 14.10.2010 11:46, schrieb Anders F Björklund: Sönke Ludwig wrote: Code::Blocks: Works quite well for Windows and Linux, except for some occasional dependency problems because of single-file compilation. Unusable on Mac because of keyboard shortcut issues. Project and build option configuration is a bit complicated and the toolchain-settings need to be tweaked manually. Some Mac OS X keyboard shortcut issues were fixed in 10.05-p1... If you are talking about the optional-but-default keybinder plugin. --anders Yes, that version indeed fixes the cmd-key issue that was the problem (had to clean my Application Support/codeblocks directory though). I missed that release although I checked the front page and the nightly forum multiple times after the release. Thanks for the hint! Sönke
Re: duck!
On Sat, 16 Oct 2010 03:30:27 -0400, Christof Schardt csn...@schardt.info wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof I like as better than duck. -Steve
Re: What do people here use as an IDE?
On 2010-10-12 21:57:44 -0400, Michael Stover michael.r.sto...@gmail.com said: Elephant appears dead. Poseidon's activity is extremely low and is still alpha after 5 years. LEDS is even less active, and DDT doesn't have a release yet. What do actual D programmers use? I'm using Xcode, with the D plugin for Xcode I made. http://michelf.com/projects/d-for-xcode/ -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Review on amazon.com
On Fri, 15 Oct 2010 16:44:07 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: TDPL received an interesting review on amazon.com from Philip R. Heath (http://tinyurl.com/2daz64k) which mentions among other things: 2. Good code examples - Core Java had fairly extensive examples, and readers could download the code. This is a great service to readers because the code compiled (for the most part) with no errors. I used the examples as a starting point to explore features and modify them the listings to see different behaviors and scenarios. The examples in The D Programming Language are sparse and not available for download. It turns out it would be trivial to make all of TDPL's samples available for download. Do you think this would add value? Yes. Also, considering that there have been many bugs found in the code examples or that the compiler doesn't yet implement the features, this can be fixed/conveyed in the downloaded version. That makes me think -- if you had all the examples compilable in a project, could the project also output the compliance level a compiler has? That would be a good metric to try every beta release against. It would also remind us of what does and doesn't work on a specific compiler regarding TDPL. -Steve
Is mimicking a reference type with a struct reliable?
irst I'd like to say that I don't really like (or rather use) Appender
because it always allocates (at least an internal Data instance) even when
I provide my own buffer.
I mean, why would I use Appender if it still allocates? Okay, you have to
store a reference to an internal representation so that Appender would
feel like a reference type. I'm not sure it's worth the trade-off, and as
such I defined and use my own set of primitives that don't allocate when a
buffer is provided:
void put(T)(ref T[] array, ref size_t offset, const(T) value)
{
ensureCapacity(array, offset + 1);
array[offset++] = value;
}
void put(T)(ref T[] array, ref size_t offset, const(T)[] value)
{
// Same but for an array
}
void ensureCapacity(ref char[] array, size_t minCapacity)
{
// ...
}
And all that functions that use an optional buffer have a signature like
this:
void foo(ubyte[] buffer = null);
Back to my original question, can we mimick a reference behavior with a
struct? I thought why not until I hit this bug:
import std.array;
import std.stdio;
void append(Appender!(string) a, string s)
{
a.put(s);
}
void main()
{
Appender!(string) a;
string s = test;
append(a, s); //
writeln(a.data);
}
I'm passing an appender by value since it's supposed to have a reference
type behavior and passing 4 bytes by reference is an overkill.
However, the code above doesn't work for a simple reason: structs lack
default ctors. As such, an appender is initialized to null internally,
when I call append a copy of it gets initialized (lazily), but the
original one remains unchanged. Note that if you append to appender at
least once before passing by value, it will work. But that's sad. Not only
it allocates when it shouldn't, I also have to initialize it explicitly!
I think far better solution would be to make it non-copyable.
TL;DR Reference semantic mimicking with a struct without default ctors is
unreliable since you must initialize your object lazily. Moreover, you
have to check that you struct is not initialized yet every single function
call, and that's error prone and bad for code clarity and performance. I'm
opposed of that practice.
Re: rationale for function and delegate
On Sat, 16 Oct 2010 11:22:43 -0400, Juanjo Alvarez f...@fakeemail.com wrote: On Sat, 16 Oct 2010 14:42:13 + (UTC), dsimcha dsim...@yahoo.com wrote: delegate with minimal overhead. This mitigates the situation a lot, since if an API requires a delegate and you have a function pointer, you just do a toDelegate(someFunctionPointer). Sorry for asking here something that should go to D.learn, but how do you do the reverse, that is, getting a function from a delegate? I need that in my project so I can pass it to signal so some Unix signal will trigger a method of an already instantiated object. auto dg = obj.method; auto fptr = dg.funcptr; auto context = dg.ptr; Note, you cannot call fptr, you will get a runtime error. Here is the related documentation (search for funcptr): http://www.digitalmars.com/d/2.0/function.html I believe there may be in phobos a type which wraps a function pointer into a delegate. Not sure if it was ever added though... -Steve
Re: duck!
I feel as and to are too similar, they could both be interpreted as simple casting for example.
Re: duck!
Andrei Alexandrescu, el 16 de octubre a las 08:54 me escribiste: On 10/16/10 1:35 CDT, Leandro Lucarella wrote: Kagamin, el 15 de octubre a las 17:16 me escribiste: Andrei Alexandrescu Wrote: I was talking to Walter about Kenji's adaptTo. We both think it's a very powerful enabler, but adaptTo is a bland name. After discussing a few marketing strategies, I proposed duck. It's short, simple, and evokes duck typing. 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't. I agree, just adapt might be an option, it even has a precedence of something similar in Python (even when the PEP[1] was rejected, PEAK has an implementation[2]). But duck is really cryptic (as symbol names invented by Andrei usually are :). Walter recognized it instantly, as I think most should. Isn't duck typing really spread out there? Walter and you have the same convoluted brain, I can understand why he instantly recognize it ;) I already made my point, it make no sense to keep defending my position since, evidently, is a pure subjective matter. I just think auto a_bird = duck!Bird(a_duck) is not obvious at all compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is even cleaner, and I tend to hate long names, specially when camelCase is involved, but since you didn't like it I, as others, suggested simply adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would be as clear as adaptTo is with the current syntax. With adaptTo!Type you even have the precedent of the to!Type template, so it seems like a nice extension. F*ck, I finally kept defending my position... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Si ella es la flor, yo soy la espina Si ella es quien florece, yo quien se marchita Y estamos en eclipse total, y estamos en eclipse total Completamente cruzados, completamente cruzados
Re: New slides about Go
Walter Bright wrote: Nick Sabalausky wrote: Seems a bad idea to force the overhead of that, but it should definitely be available as an option. Contrary to what Walter and Andrei seem to think, 32-bit systems are still very much alive and will be for quite awhile longer. Especially when you remember that there are more computers out there than just desktops and servers. (Ex: When is a phone ever going to need 64-bit? Eventually maybe, but certainly not anytime soon.) 16 bit processors died around 15 years after the introduction of 32 bit ones, even for embedded systems. If history repeats itself, figure 32 bit ones have about 5 years to go! Funny thing is we still use some 8-bit microcontrollers in some situations :) But you're right, as soon as we need something more we go directly to 32 bits without stopping in the 16 bits square. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: duck!
On 16/10/10 4:24 PM, Juanjo Alvarez wrote: On Sat, 16 Oct 2010 09:30:27 +0200, Christof Schardt csn...@schardt.info wrote: auto d = as!Drawable(c); My turn: auto d = implements!Drawable(c); That doesn't really work. If I saw that, I would assume that implements returns a boolean true when c implements the Drawable interface, rather than returning an object that does implement the interface. Out of all of them, I like as the best, although people might confuse it with the as casting operator in C#.
Re: duck!
On Sat, 16 Oct 2010 00:37:10 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed duck. It's short, simple, and evokes
duck typing.
class C
{
int draw(){ return 10; }
}
interface Drawable
{
long draw();
}
...
auto c = new C;
auto d = duck!Drawable(c); // awes
Kenji, I'll be looking forward to your submission :o). Would be great to
allow structs to duck, too!
Andrei
There is a lot in common between to and adaptTo (even the original names
are similar). 'to' converts one type to another (unless the two are
implicitly castable) and 'adaptTo' does the same. 'adaptTo' can transform
some types that 'to' can't, and vice versa.
In my opinion, they don't compete but supplement each other. As such I
would prefer merging the two together:
auto c = to!(Drawable)(c); // try casting to Drawable first, return
adaptTo(Drawable) if it fails.
The difference between 'as' and 'to' is subtle yet both names are short
and might be confusing for many people, not only novices. Yet 'as' is
better than 'duck' imo.
Re: Is mimicking a reference type with a struct reliable?
On Sat, 16 Oct 2010 20:16:40 +0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sat, 16 Oct 2010 11:52:29 -0400, Denis Koroskin 2kor...@gmail.com
wrote:
First I'd like to say that I don't really like (or rather use) Appender
because it always allocates (at least an internal Data instance) even
when I provide my own buffer.
I mean, why would I use Appender if it still allocates? Okay, you have
to store a reference to an internal representation so that Appender
would feel like a reference type.
Appender needs to be a reference type. If it's not then copying the
appender will stomp data. Let's say appender is not a reference type,
you might expect the data members to look like:
struct Appender(T)
{
uint capacity;
T[] data;
}
Now, if you copy an appender to another instance, it gets its *own* copy
of capacity. You append to a1, no problems. You then append to a2 and
it overwrites the data you put in a1.
It might be possible to do an unsafe appender that uses a pointer to a
stack variable for its implementation. But returning such an appender
would escape stack data. This would however obviate the need to
allocate extra data on the heap.
A final option is to disable the copy constructor of such an unsafe
appender, but then you couldn't pass it around.
What do you think? If you think it's worth having, suggest it on the
phobos mailing list, and we'll discuss.
Note that Appender is supposed to be fast at *appending* not
initializing itself. In that respect, it's very fast.
I'm not sure it's worth the trade-off, and as such I defined and use
my own set of primitives that don't allocate when a buffer is provided:
void put(T)(ref T[] array, ref size_t offset, const(T) value)
{
ensureCapacity(array, offset + 1);
array[offset++] = value;
}
void put(T)(ref T[] array, ref size_t offset, const(T)[] value)
{
// Same but for an array
}
void ensureCapacity(ref char[] array, size_t minCapacity)
{
// ...
}
I'm not sure what ensureCapacity does, but if it does what I think it
does (use the capacity property of arrays), it's probably slower than
Appender, which has a dedicated variable for capacity.
No, it doesn't use capacity, it uses length as a capacity instead:
void ensureCapacity(T)(ref T[] array, size_t minCapacity)
{
size_t capacity = array.length;
if (minCapacity capacity) {
return;
}
// need resize
capacity *= 2;
if (capacity 16) {
capacity = 16;
}
if (capacity minCapacity) {
capacity = minCapacity;
}
array.length = capacity;
}
The usage pattern is as follows:
dchar[] toUTF32(string s, dchar[] buffer = null)
{
size_t size = 0;
foreach (dchar d; s) {
buffer.put(size, d);
}
return buffer[0..size];
}
Back to my original question, can we mimick a reference behavior with a
struct? I thought why not until I hit this bug:
import std.array;
import std.stdio;
void append(Appender!(string) a, string s)
{
a.put(s);
}
void main()
{
Appender!(string) a;
string s = test;
append(a, s); //
writeln(a.data);
}
I'm passing an appender by value since it's supposed to have a
reference type behavior and passing 4 bytes by reference is an overkill.
However, the code above doesn't work for a simple reason: structs lack
default ctors. As such, an appender is initialized to null internally,
when I call append a copy of it gets initialized (lazily), but the
original one remains unchanged. Note that if you append to appender at
least once before passing by value, it will work. But that's sad. Not
only it allocates when it shouldn't, I also have to initialize it
explicitly!
I think far better solution would be to make it non-copyable.
TL;DR Reference semantic mimicking with a struct without default ctors
is unreliable since you must initialize your object lazily. Moreover,
you have to check that you struct is not initialized yet every single
function call, and that's error prone and bad for code clarity and
performance. I'm opposed of that practice.
This is a point I've brought up before. As of yet there is no
solution. There have been a couple of ideas passed around, but there
hasn't been anything decided. The one idea I remember (but didn't
really like) is to have the copy constructor be able to modify the
original. This makes it possible to allocate the underlying
implementation in Appender for example, even on the data being passed.
There are lots of problems with this solution, and I don't think it got
much traction.
I think the default constructor solution is probably never going to
happen. It's very nice to always have a default fast way to initialize
structs, and there is precedence (C# has the same
Re: duck!
I'm not a native English speaker, so you are well about naming than I.
But, by two reasons, I think 'duck' isn't good.
1.
'Duck Typing' is phenomenon, not doing.
- auto d = adaptTo!Drawable(c)
- auto d = duck!Drawable(c)
Which is more explainable that this statement does?
I think adaptTo is more better.
2.
I'm now implementing function getting original object from
interface(like Drawable).
auto c = new C();
auto d = adaptTo!Drawable(c);
...
auto c2 = = XXX!C(d)
assert(c2 is c);
In this case, XXX's name may be antonym of adaptTo.
What is the antonym of 'duck'?
I hope helpful.
Kenji Hara
2010/10/16 Andrei Alexandrescu seewebsiteforem...@erdani.org:
I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed duck. It's short, simple, and evokes
duck typing.
class C
{
int draw(){ return 10; }
}
interface Drawable
{
long draw();
}
...
auto c = new C;
auto d = duck!Drawable(c); // awes
Kenji, I'll be looking forward to your submission :o). Would be great to
allow structs to duck, too!
Andrei
Re: Is mimicking a reference type with a struct reliable?
On Sat, 16 Oct 2010 12:23:50 -0400, Denis Koroskin 2kor...@gmail.com
wrote:
No, it doesn't use capacity, it uses length as a capacity instead:
void ensureCapacity(T)(ref T[] array, size_t minCapacity)
{
size_t capacity = array.length;
if (minCapacity capacity) {
return;
}
// need resize
capacity *= 2;
if (capacity 16) {
capacity = 16;
}
if (capacity minCapacity) {
capacity = minCapacity;
}
array.length = capacity;
}
The usage pattern is as follows:
dchar[] toUTF32(string s, dchar[] buffer = null)
{
size_t size = 0;
foreach (dchar d; s) {
buffer.put(size, d);
}
return buffer[0..size];
}
Oh, ok. So you are keeping track of the length in a local variable. That
certainly works for specific applications, but Appender is supposed to be
generally useful.
Like I said, An unsafe appender could be added to phobos which does the
same.
-Steve
Re: duck!
Kagamin wrote: Andrei Alexandrescu Wrote: I was talking to Walter about Kenji's adaptTo. We both think it's a very powerful enabler, but adaptTo is a bland name. After discussing a few marketing strategies, I proposed duck. It's short, simple, and evokes duck typing. 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't. 2. I don't think it's duck typing, I'm affraid duck name is misleading. Both make duck a very good name for it, considering some other name choices in D... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: duck!
kenji hara k.hara...@gmail.com wrote: I'm now implementing function getting original object from interface(like Drawable). auto c = new C(); auto d = adaptTo!Drawable(c); ... auto c2 = = XXX!C(d) assert(c2 is c); In this case, XXX's name may be antonym of adaptTo. What is the antonym of 'duck'? goose? -- Simen
Re: Is mimicking a reference type with a struct reliable?
Sorry, I misclicked a button and send the message preliminary.
On Sat, 16 Oct 2010 20:16:40 +0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
A final option is to disable the copy constructor of such an unsafe
appender, but then you couldn't pass it around.
What do you think? If you think it's worth having, suggest it on the
phobos mailing list, and we'll discuss.
It's still possible to pass it by reference, or even by pointer. You know,
that's what you actually do right now - you are passing a Data* (a pointer
to an internal state, wrapped with an Appender struct).
Passing by pointer might actually be a good idea (because you can default
it to null). One of the reasons I use T[] buffer = null as a buffer is
because you aren't force to provide one, null is also a valid buffer. Many
function would benefit of passing optional Appender (e.g. converting from
utf8 to utf16 etc), but we shouldn't force them to do so.
Note that Appender is supposed to be fast at *appending* not
initializing itself. In that respect, it's very fast.
This makes it useless for appending small amount of data.
I'm not sure it's worth the trade-off, and as such I defined and use
my own set of primitives that don't allocate when a buffer is provided:
void put(T)(ref T[] array, ref size_t offset, const(T) value)
{
ensureCapacity(array, offset + 1);
array[offset++] = value;
}
void put(T)(ref T[] array, ref size_t offset, const(T)[] value)
{
// Same but for an array
}
void ensureCapacity(ref char[] array, size_t minCapacity)
{
// ...
}
I'm not sure what ensureCapacity does, but if it does what I think it
does (use the capacity property of arrays), it's probably slower than
Appender, which has a dedicated variable for capacity.
Back to my original question, can we mimick a reference behavior with a
struct? I thought why not until I hit this bug:
import std.array;
import std.stdio;
void append(Appender!(string) a, string s)
{
a.put(s);
}
void main()
{
Appender!(string) a;
string s = test;
append(a, s); //
writeln(a.data);
}
I'm passing an appender by value since it's supposed to have a
reference type behavior and passing 4 bytes by reference is an overkill.
However, the code above doesn't work for a simple reason: structs lack
default ctors. As such, an appender is initialized to null internally,
when I call append a copy of it gets initialized (lazily), but the
original one remains unchanged. Note that if you append to appender at
least once before passing by value, it will work. But that's sad. Not
only it allocates when it shouldn't, I also have to initialize it
explicitly!
I think far better solution would be to make it non-copyable.
TL;DR Reference semantic mimicking with a struct without default ctors
is unreliable since you must initialize your object lazily. Moreover,
you have to check that you struct is not initialized yet every single
function call, and that's error prone and bad for code clarity and
performance. I'm opposed of that practice.
This is a point I've brought up before. As of yet there is no
solution. There have been a couple of ideas passed around, but there
hasn't been anything decided. The one idea I remember (but didn't
really like) is to have the copy constructor be able to modify the
original. This makes it possible to allocate the underlying
implementation in Appender for example, even on the data being passed.
There are lots of problems with this solution, and I don't think it got
much traction.
I think the default constructor solution is probably never going to
happen. It's very nice to always have a default fast way to initialize
structs, and there is precedence (C# has the same rule).
I think there is, but it goes far beyond default ctors problem (it solves
many other issues, too).
Currently, a struct is initialized with T.init/T.classinfo.init
Pros:
simple initialization - malloc, followed by memcpy
there is always an immutable instance of an object in memory, and you can
use it as default/not initialized state
Cons:
you can't initialize class/struct variables with runtime values
increased file size (every single class/struct now has a copy of its own)
In Java, they use another approach. Instead of memcpy'ing T.init on top of
allocated data, they invoke a so-called cctor (as opposed to ctor). This
is a method that initializes memory so that a ctor can be called.
memcpy'ing T.init has the same idea, however it is not moved into a
separate method. In general, cctor can be implemented the way it is in D
without sacrificing anything. However, a type-unique method is a lot
better than that:
1) most structs initialize all of its members with 0. For these compiler
can use memset instead.
2) killer-feature in my opinion. It allows initializing values to
non-constant expressions:
Re: rationale for function and delegate
On Sat, 16 Oct 2010 11:57:36 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sat, 16 Oct 2010 11:22:43 -0400, Juanjo Alvarez f...@fakeemail.com
wrote:
On Sat, 16 Oct 2010 14:42:13 + (UTC), dsimcha dsim...@yahoo.com
wrote:
delegate with minimal overhead. This mitigates the situation a
lot, since if an
API requires a delegate and you have a function pointer, you just
do a
toDelegate(someFunctionPointer).
Sorry for asking here something that should go to D.learn, but how do
you do the reverse, that is, getting a function from a delegate? I need
that in my project so I can pass it to signal so some Unix signal will
trigger a method of an already instantiated object.
auto dg = obj.method;
auto fptr = dg.funcptr;
auto context = dg.ptr;
Note, you cannot call fptr, you will get a runtime error.
Here is the related documentation (search for funcptr):
http://www.digitalmars.com/d/2.0/function.html
I believe there may be in phobos a type which wraps a function pointer
into a delegate. Not sure if it was ever added though...
-Steve
Actually, you can use funcptr for simple functions. Here's an example how:
void main(string[] args) {
auto foo = (int x){ writeln(x); };
void function(int,void*) bar = foo.funcptr;
bar(5,foo.ptr);
foo(5);
return;
}
Structs larger than 8 bytes require a hidden return pointer, so instead of
LargeStruct function(int,void*) bar;
you'd have
void function(int,LargeStruct*,void*) bar;
However, if Unix code needs to call the function, it needs to do so using
the C calling conventions, which are platform/compiler specific.
Re: New slides about Go
On 10/15/2010 11:26 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:i9akvf$1jl...@digitalmars.com... On 10/15/10 17:34 CDT, Andrei Alexandrescu wrote: On 10/15/10 16:25 CDT, Nick Sabalausky wrote: I just hope they get serious enough about functional programming to gain some monads to go along with their goroutines. They should call them gonads. Andrei Wait, that was your actual joke. Sig... Well it was a bit opaque. I was actually wondering if anyone would make the connection at all. :) Much obliged to play Captain Obvious' role. Andrei
Re: rationale for function and delegate
On Sat, 16 Oct 2010 11:57:36 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: auto dg = obj.method; auto fptr = dg.funcptr; auto context = dg.ptr; Note, you cannot call fptr, you will get a runtime error. Thanks, I'll play with it to see if I can make this work in my code.
Re: duck!
On 10/16/2010 11:35 AM, kenji hara wrote: I'm not a native English speaker, so you are well about naming than I. But, by two reasons, I think 'duck' isn't good. 1. 'Duck Typing' is phenomenon, not doing. - auto d = adaptTo!Drawable(c) - auto d = duck!Drawable(c) Which is more explainable that this statement does? I think adaptTo is more better. The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. I think the feature is going to be _big_. We can't leave a big feature to a name like adaptTo. The New York Times won't have a headline like adaptTo changes the name of the game. This is also part of my beef with as or to for the feature. As is difficult to talk about. Oh my God, D has 'as'! Has ass? I'd go with the longer ducktype. Length is not as important as evocative power and brand name! auto d = ducktype!Drawable(obj); 99.99% of programmers will have an idea of what's going on. 2. I'm now implementing function getting original object from interface(like Drawable). auto c = new C(); auto d = adaptTo!Drawable(c); ... auto c2 = = XXX!C(d) assert(c2 is c); In this case, XXX's name may be antonym of adaptTo. What is the antonym of 'duck'? No need for an antonym. Just apply again. It is its own inverse and makes everything simple for everyone: auto c = new C(); auto d = ducktype!Drawable(c); ... auto c2 = = ducktype!C(d) assert(c2 is c); Boom! You're done. Andrei
Re: Is mimicking a reference type with a struct reliable?
On Sat, 16 Oct 2010 12:59:46 -0400, Denis Koroskin 2kor...@gmail.com
wrote:
Sorry, I misclicked a button and send the message preliminary.
On Sat, 16 Oct 2010 20:16:40 +0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
A final option is to disable the copy constructor of such an unsafe
appender, but then you couldn't pass it around.
What do you think? If you think it's worth having, suggest it on the
phobos mailing list, and we'll discuss.
It's still possible to pass it by reference, or even by pointer. You
know, that's what you actually do right now - you are passing a Data* (a
pointer to an internal state, wrapped with an Appender struct).
Yes, doing it this way forces you to use a pointer, since you can't pass
by value. That is the point. To create a type with the property if you
don't pass it around correctly, it might blow up in your face doesn't
make much sense. This is why I'd recommend using class for Appender,
which also forces reference semantics, but does not use lazy construction.
Note that Appender is supposed to be fast at *appending* not
initializing itself. In that respect, it's very fast.
This makes it useless for appending small amount of data.
Any generally usable appender is going to have some startup cost, so yes
the overhead is going to make it non-optimal for small appends. Use ~=
for small amounts of data or use your method (writing directly to a
buffer). Appender is for appending large amounts of data.
This is a point I've brought up before. As of yet there is no
solution. There have been a couple of ideas passed around, but there
hasn't been anything decided. The one idea I remember (but didn't
really like) is to have the copy constructor be able to modify the
original. This makes it possible to allocate the underlying
implementation in Appender for example, even on the data being passed.
There are lots of problems with this solution, and I don't think it got
much traction.
I think the default constructor solution is probably never going to
happen. It's very nice to always have a default fast way to initialize
structs, and there is precedence (C# has the same rule).
I think there is, but it goes far beyond default ctors problem (it
solves many other issues, too).
Currently, a struct is initialized with T.init/T.classinfo.init
Pros:
simple initialization - malloc, followed by memcpy
there is always an immutable instance of an object in memory, and you
can use it as default/not initialized state
Cons:
you can't initialize class/struct variables with runtime values
increased file size (every single class/struct now has a copy of its own)
In Java, they use another approach. Instead of memcpy'ing T.init on top
of allocated data, they invoke a so-called cctor (as opposed to ctor).
This is a method that initializes memory so that a ctor can be called.
memcpy'ing T.init has the same idea, however it is not moved into a
separate method. In general, cctor can be implemented the way it is in D
without sacrificing anything. However, a type-unique method is a lot
better than that:
1) most structs initialize all of its members with 0. For these compiler
can use memset instead.
2) killer-feature in my opinion. It allows initializing values to
non-constant expressions:
class Foo
{
ubyte[] buffer = new ubyte[BUFFER_SIZE];
}
This also solves an Appender issue:
struct Appender
{
Data* data = new Data();
}
3) it allows getting rid of T.init, significantly reducing resulting
file size
I'm not sure Walter will agree to such a radical change, but it can be
achieved in small steps. D doesn't even have to get rid of T.init, it
can still be there (but I'd like to get rid of it eventually)
a) Keep T.init/T.classinfo.init, introduce compiler-generated cctor what
memcpy'ies T.init over the object
(Optionally) Make cctor more smart, and generate proper class/struct
initialization code that doesn't rely on T.init
b) Allow non-constant expressions as initializers and initialize such
members in the cctor
(Optionally) Get rid of T.init altogether
This does sound promising. I think we would need to try and make the
'cctor' in D be very simple (low cost) otherwise you'll see issues when
you for example allocate an array of structs.
So for example, you might only allow memory allocation and assignment.
That would probably be enough for most cases, and would be (hopefully)
fast enough to be not-noticable. Not only that, but since the compiler is
in charge of creating the cctor, it might be able to do some
optimizations, like if you are allocating an array of Appenders, it can
bulk construct all the data members required (i.e. take the GC lock only
once).
Andrei, Walter?
-Steve
Re: duck!
On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. Wait, really? This statement has no place in a programming language decision IMO. Nobody is going to start using D because it has a function *named* duck. Let's change writef to shazam! Let's call File BitLocker! And 'to' really should be called transformationVehicle! If you want to help market D, come up with some better logos, help redesign the web site, and maybe write a book (oh wait, you already did that :) -Steve
Re: New slides about Go
Jérôme M. Berger wrote: Walter Bright wrote: Nick Sabalausky wrote: Seems a bad idea to force the overhead of that, but it should definitely be available as an option. Contrary to what Walter and Andrei seem to think, 32-bit systems are still very much alive and will be for quite awhile longer. Especially when you remember that there are more computers out there than just desktops and servers. (Ex: When is a phone ever going to need 64-bit? Eventually maybe, but certainly not anytime soon.) 16 bit processors died around 15 years after the introduction of 32 bit ones, even for embedded systems. If history repeats itself, figure 32 bit ones have about 5 years to go! Funny thing is we still use some 8-bit microcontrollers in some situations :) But you're right, as soon as we need something more we go directly to 32 bits without stopping in the 16 bits square. I can tell 16 bits is dead as a doornail because the 16 bit tools biz has dried up to nothing.
Re: duck!
Leandro Lucarella wrote: Walter and you have the same convoluted brain, I can understand why he instantly recognize it ;) I already made my point, it make no sense to keep defending my position since, evidently, is a pure subjective matter. It certainly is a glorious bikeshed. I just think auto a_bird = duck!Bird(a_duck) is not obvious at all compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is even cleaner, and I tend to hate long names, specially when camelCase is involved, but since you didn't like it I, as others, suggested simply adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would be as clear as adaptTo is with the current syntax. With adaptTo!Type you even have the precedent of the to!Type template, so it seems like a nice extension. Microsoft has a tradition of naming their products after what they do: Windows, Word, Office, etc. It's obvious why they do it, and it works, but it is just so generic and dull. Being the upstart language, D needs now and then something a little more attention-getting than generic terms. The duck feature is important for two reasons: 1. duck typing is all the rage now 2. being able to implement duck typing as a library feature (rather than a language one) is a great demonstration of what D can do Label it adaptTo and few will even notice it. Label it duck and people will click on the link to see what it does. It's important that people notice that D has these things, and duck helps with that. I've been in this business a long time, and while you'd think that programmers are above what's in a name, we are just like everyone else. A catchy name gets results. Borland, for example, added a trivial and boring feature to their linker, called it smart linking, and managed to get an unbelievable amount of hoopla from the computer press out of it. They did it again with another feature they called zoom. Which blog article would you click on? Interface Adapter for D or Duck Typing for D? duck is a great name for the feature. It's short sweet, fits right in with the popularity of duck typing, stands out, isn't boring, etc. Heck, as proof, look at all the interest in this thread!!
Re: duck!
Russel Winder wrote: Groovy uses [...] !!!
Re: [nomenclature] systems language
Would that make Smalltalk, Lisp, Oberon, Modula-3, Component Pascal, Ada, Mac Pascal system programming languages? All of them were used to write operating systems, in some of them the operating system and language are the same, kind of. -- paulo div0 d...@sourceforge.net wrote in message news:i9c2ue$30f...@digitalmars.com... On 14/10/2010 13:30, Justin Johansson wrote: Touted often around here is the term systems language. May we please discuss a definition to be agreed upon for the usage this term (at least in this community) and also have some agreed upon examples of PLs that might also be members of the set of systems languages. Given a general subjective term like this, one would have to suspect that the D PL is not the only member of this set. Cheers Justin Johansson PS. my apologies for posting a lame joke recently; certainly it was not meant to be disparaging towards the D PL and hopefully it was not taken this way. Something not mentioned so far: The language must be self hostable; i.e. you need to be able to write it's runtime in the language itself. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
std.algorithm.remove and principle of least astonishment
Hello all,
I decided to have a go at solving some easy programming puzzles with
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work
out in simple real-world use cases (the puzzle in question is from
hacker.org, by the way).
The following code is a direct translation of a simple problem
description to D (it is horrible from performance point of view, but
that's certainly no issue here).
---
import std.algorithm;
import std.conv;
import std.stdio;
// The original input string is longer, but irrelevant to this post.
enum INPUT = 93752xxx746x27x1754xx90x93x238x44x75xx087509;
void main() {
uint sum;
auto tmp = INPUT.dup;
size_t i;
while ( i tmp.length ) {
char c = tmp[ i ];
if ( c == 'x' ) {
tmp = remove( tmp, i );
i -= 2;
} else {
sum += to!uint( [ c ] );
++i;
}
}
writeln( sum );
}
---
Quite contrary to what you would expect, the call to »remove« fails to
compile with the following error messages: »std/algorithm.d(4287):
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error:
front(tgt) is not an lvalue«.
I am intentionally posting this to this NG and not to d.…D.learn, since
this is a quite gross violation of the principle of least surprise in my
eyes.
If this isn't a bug, a better error message via a template constraint or
a static assert would be something worth looking at in my opinion, since
one would probably expect this to compile and not to fail within Phobos
code.
David
Re: duck!
Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. Wait, really? This statement has no place in a programming language decision IMO. One would think programmers are above all that, but we are not. Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. People will search on duck typing in D and with the duck template, they'll drop right in on it. With adaptTo, it'll be on page 67 of the results, they'll never find it, and will conclude that D cannot do duck typing. Let's change writef to shazam! Let's call File BitLocker! And 'to' really should be called transformationVehicle! Think of it another way. Remember zip files? What a great name, and yes, it seemed silly at first, but zip entered the lexicon and D has a zip module and it never occurs to anyone it might be better named std.compressedArchive. Phil Katz renamed arc files zip files, called his compressor pkzip and blew away arc so badly that most people are unaware it even existed. I think the catchy, silly zip name was a significant factor in getting people to notice his program. In contrast, the superior lharc with its lzh files never caught on. If you want to help market D, come up with some better logos, help redesign the web site, and maybe write a book (oh wait, you already did that :) We are working on all of that. It's all important.
Re: std.algorithm.remove and principle of least astonishment
On Sat, 16 Oct 2010 14:29:59 -0400, klickverbot s...@klickverbot.at wrote:
Hello all,
I decided to have a go at solving some easy programming puzzles with
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work
out in simple real-world use cases (the puzzle in question is from
hacker.org, by the way).
The following code is a direct translation of a simple problem
description to D (it is horrible from performance point of view, but
that's certainly no issue here).
---
import std.algorithm;
import std.conv;
import std.stdio;
// The original input string is longer, but irrelevant to this post.
enum INPUT = 93752xxx746x27x1754xx90x93x238x44x75xx087509;
void main() {
uint sum;
auto tmp = INPUT.dup;
size_t i;
while ( i tmp.length ) {
char c = tmp[ i ];
if ( c == 'x' ) {
tmp = remove( tmp, i );
i -= 2;
} else {
sum += to!uint( [ c ] );
++i;
}
}
writeln( sum );
}
---
Quite contrary to what you would expect, the call to »remove« fails to
compile with the following error messages: »std/algorithm.d(4287):
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error:
front(tgt) is not an lvalue«.
My guess is that since INPUT is a string, phobos has unwisely decided to
treat strings not as random access arrays of chars, but as a bidirectional
range of dchar. This means that even though you can randomly access the
characters (phobos can't take that away from you), it artificially imposes
restrictions (such as making front an rvalue) where it wouldn't do the
same to an int[] or ubyte[].
Andrei, I am increasingly seeing people struggling with the decision to
make strings bidirectional ranges of dchar instead of what the compiler
says they are. This needs a different solution. It's too
confusing/difficult to deal with.
I suggest wrapping a char[] or wchar[] (of all constancies) with a special
range that imposes the restrictions. This means people will have to use
these ranges when they want to treat them as bidir ranges of dchar, but
the current situation is at least annoying, if not a complete turn-off to
D. And it vastly simplifies code that uses ranges, since they now don't
have to contain special cases for char[] and wchar[].
-Steve
Re: duck!
On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. I think the feature is going to be _big_. We can't leave a big feature to a name like adaptTo. The New York Times won't have a headline like adaptTo changes the name of the game. It's risky in my opinion to bet that it's going to be a feature big enough that everyone will remember what it means. Also, duck is a misnomer. The commonly-accepted meaning of duck typing is basically dynamic dispatch based on function names, and when the function doesn't exist it's a runtime error. I bet you'll get a ton of negative feedback for misrepresentation or deformation of the concept. That said, it could bring attention, but perhaps not the kind of attention you'd like. Programmers like automated things. That feature should be called magic adapters or cheap adapters (or some variation of that) because it's an adapter and it's magic/cheap, and people can search adapter and immediately get hundreds of results explaining the concept. And the function name could be adaptTo, or adapt (or magic if you want it to look funny). And I think I agree with your arguments about as having problems. I'd go with the longer ducktype. Length is not as important as evocative power and brand name! auto d = ducktype!Drawable(obj); At this point, why not call it ducktape™. Now that's a brand name. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: duck!
On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: duck!
On 10/16/2010 09:16 PM, Walter Bright wrote: Leandro Lucarella wrote: Walter and you have the same convoluted brain, I can understand why he instantly recognize it ;) I already made my point, it make no sense to keep defending my position since, evidently, is a pure subjective matter. It certainly is a glorious bikeshed. I just think auto a_bird = duck!Bird(a_duck) is not obvious at all compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is even cleaner, and I tend to hate long names, specially when camelCase is involved, but since you didn't like it I, as others, suggested simply adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would be as clear as adaptTo is with the current syntax. With adaptTo!Type you even have the precedent of the to!Type template, so it seems like a nice extension. Microsoft has a tradition of naming their products after what they do: Windows, Word, Office, etc. It's obvious why they do it, and it works, but it is just so generic and dull. Being the upstart language, D needs now and then something a little more attention-getting than generic terms. The duck feature is important for two reasons: 1. duck typing is all the rage now 2. being able to implement duck typing as a library feature (rather than a language one) is a great demonstration of what D can do Label it adaptTo and few will even notice it. Label it duck and people will click on the link to see what it does. It's important that people notice that D has these things, and duck helps with that. I think that is a wrong approach to marketing. Even microsoft avoids giving fancy names to API functions. It is ok to give a fancy name to an API (Windows Presentation Foundation, etc) or a product but the mundane function names should be as boring and factual as they deserve it. It is poor programmers and not marketing folks who will be using them. As other people said, there are better ways of marketing D. For example, you may want to hire a professional web designer to make D's web site look less amateurish.
Re: duck!
As as looks sweet, you have rather compelling points, duck sure grabs too much attention. On Sat, 16 Oct 2010 21:16:08 +0300, Walter Bright newshou...@digitalmars.com wrote: Leandro Lucarella wrote: Walter and you have the same convoluted brain, I can understand why he instantly recognize it ;) I already made my point, it make no sense to keep defending my position since, evidently, is a pure subjective matter. It certainly is a glorious bikeshed. I just think auto a_bird = duck!Bird(a_duck) is not obvious at all compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is even cleaner, and I tend to hate long names, specially when camelCase is involved, but since you didn't like it I, as others, suggested simply adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would be as clear as adaptTo is with the current syntax. With adaptTo!Type you even have the precedent of the to!Type template, so it seems like a nice extension. Microsoft has a tradition of naming their products after what they do: Windows, Word, Office, etc. It's obvious why they do it, and it works, but it is just so generic and dull. Being the upstart language, D needs now and then something a little more attention-getting than generic terms. The duck feature is important for two reasons: 1. duck typing is all the rage now 2. being able to implement duck typing as a library feature (rather than a language one) is a great demonstration of what D can do Label it adaptTo and few will even notice it. Label it duck and people will click on the link to see what it does. It's important that people notice that D has these things, and duck helps with that. I've been in this business a long time, and while you'd think that programmers are above what's in a name, we are just like everyone else. A catchy name gets results. Borland, for example, added a trivial and boring feature to their linker, called it smart linking, and managed to get an unbelievable amount of hoopla from the computer press out of it. They did it again with another feature they called zoom. Which blog article would you click on? Interface Adapter for D or Duck Typing for D? duck is a great name for the feature. It's short sweet, fits right in with the popularity of duck typing, stands out, isn't boring, etc. Heck, as proof, look at all the interest in this thread!! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
Michel Fortin wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. If you make an interface that consists solely of the 'quack' function, then duck!quack(object) satisfies the requirement if object has a 'quack' function. It's like saying D is a dynamic language, people will know you're bullshitting them.
Re: duck!
Walter Bright Wrote: One would think programmers are above all that, but we are not. Ask people what they think about cross-platform .net ad campaign.
Re: duck!
On Sat, 16 Oct 2010 14:32:10 -0400, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. Wait, really? This statement has no place in a programming language decision IMO. One would think programmers are above all that, but we are not. We are not talking about a feature name, we are talking about a *function* name. I personally think 'as' is better than 'adaptTo' or 'duck'. Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. People will search on duck typing in D and with the duck template, they'll drop right in on it. With adaptTo, it'll be on page 67 of the results, they'll never find it, and will conclude that D cannot do duck typing. I would expect them to search for it and find the 'duck typing' section of the D marketing documents, and see that 'D does duck typing, see adaptTo'. Or find it on wikipedia. Unless you plan on handing people a full copy of the phobos docs as 'marketing material'... Let's change writef to shazam! Let's call File BitLocker! And 'to' really should be called transformationVehicle! Think of it another way. Remember zip files? What a great name, and yes, it seemed silly at first, but zip entered the lexicon and D has a zip module and it never occurs to anyone it might be better named std.compressedArchive. Phil Katz renamed arc files zip files, called his compressor pkzip and blew away arc so badly that most people are unaware it even existed. I think the catchy, silly zip name was a significant factor in getting people to notice his program. In contrast, the superior lharc with its lzh files never caught on. These are completely unsubstantiated statements focused on a very narrow set of variables. It's like all those studies that say X causes cancer because look most people who use X have cancer. Well, yeah, but they are all 40-70 yr old people, who freaking knows how many factors went into them getting cancer!!! And it proves itself again and again when the next year, they say, 'well that study was flawed, we now *know* that it was really Y'. Besides, duck isn't the compiler name, it's a very very small part of the library. I think you associate more weight to this than there actually is. Let's concentrate on finding the name that best describes the function. This might be 'duck', but let's leave marketing considerations out of it. If duck was a verb that meant 'walk like a...' then I'd agree it was a fine term. How about if we can say D's functions are named intuitively instead of after some colloquial term that describes the function? And yeah, I agree zip is now a de-facto term, so much so that I think std.range.Zip should be renamed :) But was it zip that made the tool famous or the tool that made zip famous? Let's also not forget the hundreds, probably thousands, of 'cute' names that didn't save their respective products because the marketing material sucked. -Steve
Re: std.algorithm.remove and principle of least astonishment
In case it was not clear, this is what I want to achive: »tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];«
Re: duck!
Reading wikipedia, definition and the examples exactly match adaptTo. Before naming it, i think we should first be clear about if it is really duck-typing or not. On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin michel.for...@michelf.com wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
Walter Bright Wrote: Which blog article would you click on? Interface Adapter for D or Duck Typing for D? You are somewhat right. The right place for marketing is an article, not the library source, right? What would you click on? Duck typing for D or dsource.org/phobos/src/trunk?
Re: duck!
Michel Fortin Wrote: The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. Isn't that dynamic typing?
Re: duck!
I think it's safe to say this is pretty much duck-typing in D (?) So then, if duck! is used, it puts emphasis on what the function allows D to do (duck-typing), while if as! is used, it sounds more intuitive (kinda like .respond_to? in Ruby) . So going with my previous statement, if you keep using duck!, or adaptTo!, or whatever this becomes, it will eventually stick and will sound intuitive no matter what. In that way, I think as! is not necessarily such a good choice. Also, I really agree with Kagamin and Walter's argument, that simply the name duck! would raise awareness for this features. 2010/10/16 so s...@so.do Reading wikipedia, definition and the examples exactly match adaptTo. Before naming it, i think we should first be clear about if it is really duck-typing or not. On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin michel.for...@michelf.com wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
What's all this arguing about anyway? import std.conv : duck; alias duck as; alias duck adaptTo; Done deal. On 10/16/10, Jimmy Cao jcao...@gmail.com wrote: I think it's safe to say this is pretty much duck-typing in D (?) So then, if duck! is used, it puts emphasis on what the function allows D to do (duck-typing), while if as! is used, it sounds more intuitive (kinda like .respond_to? in Ruby) . So going with my previous statement, if you keep using duck!, or adaptTo!, or whatever this becomes, it will eventually stick and will sound intuitive no matter what. In that way, I think as! is not necessarily such a good choice. Also, I really agree with Kagamin and Walter's argument, that simply the name duck! would raise awareness for this features. 2010/10/16 so s...@so.do Reading wikipedia, definition and the examples exactly match adaptTo. Before naming it, i think we should first be clear about if it is really duck-typing or not. On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin michel.for...@michelf.com wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
According to wikipedia, duck typing is a style of dynamic typing where an object's methods/properties determine what i can do. On Sat, Oct 16, 2010 at 2:14 PM, Kagamin s...@here.lot wrote: Michel Fortin Wrote: The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. Isn't that dynamic typing?
Re: duck!
On 10/16/2010 12:38 PM, Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. Wait, really? This statement has no place in a programming language decision IMO. Nobody is going to start using D because it has a function *named* duck. Let's change writef to shazam! Let's call File BitLocker! And 'to' really should be called transformationVehicle! I think ducktype is an important feature of D. I want to give it a name that is correspondingly resounding. The likes of files, writef, and conversions are commonplace. That's all. Andrei
Re: duck!
The problem is that D doesn't have duck-typing.
But it does and it has for a long time:
void func(A)(A a) {
a.quack();
}
This new thing looks to me to be more like Go typing (lol?), where objects
fulfill
interfaces without explicit templates on the functions nor decorations on the
class. Here's a name!
go!IWhatever(myclass)
hahaha.
Re: Feature discussion: __traits(getSource, function)
Well, it sounds like I'm not the only one who'd find this useful, so I took a look at the compiler. It seems to only store file and line internally (I might have missed something though) so the path of least resistance seems to be exposing that, and then pulling the source with a library function. But I'll keep looking, since avoiding the library function would be nice (no -J and no bugs!).
Re: duck!
Haha!
But many people consider the interface system in Go as duck-typing,
so imo duck! is a very suitable name.
On Sat, Oct 16, 2010 at 2:25 PM, Adam D. Ruppe destructiona...@gmail.comwrote:
The problem is that D doesn't have duck-typing.
But it does and it has for a long time:
void func(A)(A a) {
a.quack();
}
This new thing looks to me to be more like Go typing (lol?), where objects
fulfill
interfaces without explicit templates on the functions nor decorations on
the
class. Here's a name!
go!IWhatever(myclass)
hahaha.
Re: duck!
'Duck Typing' is a very broad concept.
adaptTo is supported only in part.
For example, you can not adapt class from class.
It has semantic problem of object states, so I never support it.
// this is invalid example
class C{ draw(){ return 10; } }
class X{ draw(){ return value; } int value; }
X x = adaptTo!X(new C());
// x.value == ??, cannot provide generally.
If you call it a duck, it will tell a lie!
Kenji Hara.
2010/10/17 Walter Bright newshou...@digitalmars.com:
Leandro Lucarella wrote:
Walter and you have the same convoluted brain, I can understand why he
instantly recognize it ;)
I already made my point, it make no sense to keep defending my position
since, evidently, is a pure subjective matter.
It certainly is a glorious bikeshed.
I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
even cleaner, and I tend to hate long names, specially when camelCase is
involved, but since you didn't like it I, as others, suggested simply
adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
be as clear as adaptTo is with the current syntax. With adaptTo!Type you
even have the precedent of the to!Type template, so it seems like a nice
extension.
Microsoft has a tradition of naming their products after what they do:
Windows, Word, Office, etc. It's obvious why they do it, and it works, but
it is just so generic and dull.
Being the upstart language, D needs now and then something a little more
attention-getting than generic terms. The duck feature is important for
two reasons:
1. duck typing is all the rage now
2. being able to implement duck typing as a library feature (rather than a
language one) is a great demonstration of what D can do
Label it adaptTo and few will even notice it. Label it duck and people
will click on the link to see what it does. It's important that people
notice that D has these things, and duck helps with that.
I've been in this business a long time, and while you'd think that
programmers are above what's in a name, we are just like everyone else. A
catchy name gets results. Borland, for example, added a trivial and boring
feature to their linker, called it smart linking, and managed to get an
unbelievable amount of hoopla from the computer press out of it. They did it
again with another feature they called zoom.
Which blog article would you click on? Interface Adapter for D or Duck
Typing for D?
duck is a great name for the feature. It's short sweet, fits right in
with the popularity of duck typing, stands out, isn't boring, etc. Heck, as
proof, look at all the interest in this thread!!
Re: std.algorithm.remove and principle of least astonishment
On 10/16/2010 01:29 PM, klickverbot wrote:
Hello all,
I decided to have a go at solving some easy programming puzzles with
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work
out in simple real-world use cases (the puzzle in question is from
hacker.org, by the way).
The following code is a direct translation of a simple problem
description to D (it is horrible from performance point of view, but
that's certainly no issue here).
---
import std.algorithm;
import std.conv;
import std.stdio;
// The original input string is longer, but irrelevant to this post.
enum INPUT = 93752xxx746x27x1754xx90x93x238x44x75xx087509;
void main() {
uint sum;
auto tmp = INPUT.dup;
size_t i;
while ( i tmp.length ) {
char c = tmp[ i ];
if ( c == 'x' ) {
tmp = remove( tmp, i );
i -= 2;
} else {
sum += to!uint( [ c ] );
++i;
}
}
writeln( sum );
}
---
Quite contrary to what you would expect, the call to »remove« fails to
compile with the following error messages: »std/algorithm.d(4287):
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error:
front(tgt) is not an lvalue«.
I am intentionally posting this to this NG and not to d.…D.learn, since
this is a quite gross violation of the principle of least surprise in my
eyes.
If this isn't a bug, a better error message via a template constraint or
a static assert would be something worth looking at in my opinion, since
one would probably expect this to compile and not to fail within Phobos
code.
David
Thanks for the input. This is not a bug, it's what I believe to be a
very intentional feature: strings are not ordinary arrays because
characters have variable length. As such, assigning to the first
character in a string is not allowed because the assignment might mess
up the next character.
It's a good test bed. Simply replacing this:
auto tmp = INPUT.dup;
with this:
auto tmp = cast(ubyte[]) INPUT.dup;
makes the program work and print 322 (you also must include std.conv).
How do you all believe we could improve this example?
1. remove() could be specialized for char[] and wchar[] because it can
be made to work with some effort and is a worthwhile algorithms for
strings.
2. to!(ubyte[]) should work for char[] by making a copy and casting it
to ubyte[]. So this should have worked:
auto tmp = to!(ubyte[])(INPUT);
to! is better than cast because it always does the right thing and never
undermines type safety.
Whadday'all think?
Andrei
Re: std.algorithm.remove and principle of least astonishment
On 10/16/2010 01:39 PM, Steven Schveighoffer wrote: My guess is that since INPUT is a string, phobos has unwisely decided to treat strings not as random access arrays of chars, but as a bidirectional range of dchar. s/un// :o) Andrei
Re: std.algorithm.remove and principle of least astonishment
On 10/16/2010 01:39 PM, Steven Schveighoffer wrote: Andrei, I am increasingly seeing people struggling with the decision to make strings bidirectional ranges of dchar instead of what the compiler says they are. This needs a different solution. It's too confusing/difficult to deal with. I'm not seeing that. I'm seeing strings working automagically with most of std.algorithm without ever destroying a wide string. Andrei
Re: std.algorithm.remove and principle of least astonishment
On 10/16/2010 01:39 PM, Steven Schveighoffer wrote: I suggest wrapping a char[] or wchar[] (of all constancies) with a special range that imposes the restrictions. I did so. It was called byDchar and it would accept a string type. It sucked. char[] and wchar[] are special. They embed their UTF affiliation in their type. I don't think we should make a wash of all that by handling them as arrays. They are not arrays. Andrei
Re: duck!
Adapter-Pattern! I'd have forgotten the name. It is NOT equals to duck-typing. adaptTo supports Adapter-Pattern. Thanks Michel. Kenji Hara 2010/10/17 Michel Fortin michel.for...@michelf.com: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: std.algorithm.remove and principle of least astonishment
On 10/16/10 9:47 PM, Andrei Alexandrescu wrote: Thanks for the input. This is not a bug, it's what I believe to be a very intentional feature: strings are not ordinary arrays because characters have variable length. As such, assigning to the first character in a string is not allowed because the assignment might mess up the next character. I see that there is a problem due the difference of code units and code points, but why does the following work then? tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ]; This is equivalent to my (naïve?) mental model of remove(), and thus it seems very counter-intuitive to me that one works, but the other doesn't.
Re: duck!
On 10/16/2010 01:43 PM, Michel Fortin wrote:
On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
The problem with adaptTo is that, just like itoa or printf, it is
too boring to have marketing value. I think the feature is going to be
_big_. We can't leave a big feature to a name like adaptTo. The New
York Times won't have a headline like adaptTo changes the name of the
game.
It's risky in my opinion to bet that it's going to be a feature big
enough that everyone will remember what it means. Also, duck is a
misnomer. The commonly-accepted meaning of duck typing is basically
dynamic dispatch based on function names, and when the function doesn't
exist it's a runtime error. I bet you'll get a ton of negative feedback
for misrepresentation or deformation of the concept. That said, it could
bring attention, but perhaps not the kind of attention you'd like.
interface Duck
{
void walk();
void quack();
}
class Whatsthis
{
void walk();
void quack();
}
auto a = duck!Duck(new Whatsthis);
It's duck typing all right. The term does not have an academic canonical
name. I doubt this is ever going to cause a rumpus or be a source of
confusion.
Programmers like automated things. That feature should be called magic
adapters or cheap adapters
*yawn*
(or some variation of that) because it's
an adapter and it's magic/cheap, and people can search adapter and
immediately get hundreds of results explaining the concept. And the
function name could be adaptTo, or adapt (or magic if you want it
to look funny).
Please substitute: X does duck typing in the D programming language.
What is X?
FWIW this was the story with immutable. Walter got tired of
explaining: Invariant implements immutable types in the D programming
language.
And I think I agree with your arguments about as having problems.
I'd go with the longer ducktype. Length is not as important as
evocative power and brand name!
auto d = ducktype!Drawable(obj);
At this point, why not call it ducktape™. Now that's a brand name.
Meh.
Andrei
Re: std.algorithm.remove and principle of least astonishment
Andrei Alexandrescu napisał: On 10/16/2010 01:39 PM, Steven Schveighoffer wrote: I suggest wrapping a char[] or wchar[] (of all constancies) with a special range that imposes the restrictions. I did so. It was called byDchar and it would accept a string type. It sucked. Why it sucked? -- Tomek
Re: duck!
Max Samukha wrote: I think that is a wrong approach to marketing. Even microsoft avoids giving fancy names to API functions. It is ok to give a fancy name to an API (Windows Presentation Foundation, etc) or a product but the mundane function names should be as boring and factual as they deserve it. It is poor programmers and not marketing folks who will be using them. If it's a cringeworthy name, I'd agree. But duck is not cringeworthy. As other people said, there are better ways of marketing D. For example, you may want to hire a professional web designer to make D's web site look less amateurish. We're doing that, too.
