Re: Goodbye
"Nick B" wrote in message news:hb03jf$24d...@digitalmars.com... > Jarrett Billingsley wrote: >> "Jarrett Billingsley" wrote in message >> news:mailman.175.1255377931.20261.digitalmar...@puremagic.com... >>> I'm done. After seeing how Andrei is behaving, I really am done. Bye. >> >> Just to clarify, yes, I will still maintain my current projects. But as >> far as D and its development goes, I am well and truly finished. You do >> your thing, Andrei. Have fun. > For the record, and before you go off into the sunset, what exactly, are > you objecting to ? Hm, could it be years of constant, repeated disappointment with the leadership? The utter lack of community input on many important features? The antiquated, closed development model? Or maybe just the shitty toolchain, shitty rift between "standard" libraries, and shitty third-party libraries? But what's really been chafing my ass for the past year or so has been Andrei and his astronomical ego. This is the post that broke *this* camel's back: http://digg.com/d3170vV You might also be interested in these self-written bios by a man who might as well describe himself as the goddamn savior of modern programming practice. http://pastie.org/652008 http://pastie.org/private/iyj51x5gjjr3qp6ipatta I can't, in good conscience, support a language that has someone like this at the wheel. Sorry.
Re: Goodbye
"Jarrett Billingsley" wrote in message news:mailman.175.1255377931.20261.digitalmar...@puremagic.com... > I'm done. After seeing how Andrei is behaving, I really am done. Bye. Just to clarify, yes, I will still maintain my current projects. But as far as D and its development goes, I am well and truly finished. You do your thing, Andrei. Have fun.
Re: Goodbye
"Ary Borenszweig" wrote in message news:hb02kk$259...@digitalmars.com... > Jarrett Billingsley wrote: >> I'm done. After seeing how Andrei is behaving, I really am done. Bye. > > Eveyrone knows you'll be peeking the newsgroup anyway. :-P I've removed my mailing list subscriptions. I'll respond a couple times on this thread and that's it. I'm done having my blood pressure raised to dangerous levels every time I check my email.
Goodbye
I'm done. After seeing how Andrei is behaving, I really am done. Bye.
Re: dmd support for IDEs
On Mon, Oct 12, 2009 at 3:31 PM, Andrei Alexandrescu wrote: > Walter, please avoid all distractions and make bringing D in sync with the > book your sole preoccupation. I am working *extremely* hard on the book, and > I wish I were seeing the same level of commitment in you. You're writing a book about a language that doesn't exist and then complaining that Walter isn't writing it for you? Wow. Just wow. I'm out of here.
Re: dmd support for IDEs
On Mon, Oct 12, 2009 at 3:23 PM, Ary Borenszweig wrote: > Jarrett Billingsley wrote: >> >> On Mon, Oct 12, 2009 at 3:39 AM, Don wrote: >>> >>> Are you talking about FF 3.5? It's a really poor product. Crashes all the >>> time, has some terrible UI misfeatures. I'm really amazed they shipped it >>> in >>> that condition. >>> >> >> I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY >> unresponsive, uses 3-4 times as much memory as FF3, flash videos don't >> play without hiccuping every five seconds, and it would just go into >> infinite loops or something and become completely unresponsive. I >> actually downgraded to 3.0 and it was like a new browser again! :P > > Me too. And when clicking a tab sometimes it will make a whole new window > out of it. There's even an extension to fix that! :-P > Yes OMG I hate that. Sometimes I don't even have to click the tab, just middle-click-scrolling will do that. I wasn't aware there was even an extension :P
Re: Array literals' default type
On Mon, Oct 12, 2009 at 1:21 PM, language_fan wrote:
> Mon, 12 Oct 2009 13:04:03 -0400, Jarrett Billingsley thusly wrote:
>
>> On Mon, Oct 12, 2009 at 10:47 AM, Don wrote:
>>
>>>> Wasn't the comma operator to be supposed to be important for automatic
>>>> code generation?
>>>
>>> It's used frequently in in the compiler internals. EG, given
>>>
>>> int foo(X x = default_value) { return 0; } then foo(); becomes: (X
>>> tmp = default_value, foo(tmp));
>>
>> There doesn't need to be any *syntactic* reservation for something
>> that's used internally by the compiler. I mean, we don't have to
>> explicitly mark which brace blocks introduce scopes, but ScopeStatements
>> are alive and well inside the compiler. CommaExp could just become
>> "SequenceExp" or something and it would have the exact same effect. I
>> really don't think there will be a lot of moaning if comma expressions
>> disappeared. And yes, for loop increments can be special-cased, geez..
>
> But it breaks the holy C compatibility. When a C veteran with 40+ years
> of C development experience under their belt studies D by porting a 1
> MLOC library to D 2.0, his code will fail as the precious old comma does
> not compute sequencing, but instead will produce a nasty compile error.
> Porting the code in a single go will not be possible anymore and reddit
> commentators will literally crush D.
>
Fuck C.
Re: Array literals' default type
On Mon, Oct 12, 2009 at 10:47 AM, Don wrote:
>> Wasn't the comma operator to be supposed to be important for automatic
>> code generation?
>
> It's used frequently in in the compiler internals. EG, given
>
> int foo(X x = default_value) { return 0; }
> then foo(); becomes: (X tmp = default_value, foo(tmp));
There doesn't need to be any *syntactic* reservation for something
that's used internally by the compiler. I mean, we don't have to
explicitly mark which brace blocks introduce scopes, but
ScopeStatements are alive and well inside the compiler. CommaExp could
just become "SequenceExp" or something and it would have the exact
same effect. I really don't think there will be a lot of moaning if
comma expressions disappeared. And yes, for loop increments can be
special-cased, geez..
Re: dmd support for IDEs
On Mon, Oct 12, 2009 at 3:39 AM, Don wrote: > > Are you talking about FF 3.5? It's a really poor product. Crashes all the > time, has some terrible UI misfeatures. I'm really amazed they shipped it in > that condition. > I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY unresponsive, uses 3-4 times as much memory as FF3, flash videos don't play without hiccuping every five seconds, and it would just go into infinite loops or something and become completely unresponsive. I actually downgraded to 3.0 and it was like a new browser again! :P
Re: A safer switch?
On Mon, Oct 12, 2009 at 5:14 AM, Vladimir Panteleev wrote: > This was discussed before. IIRC, someone suggested to force using a > control-flow keyword (break/continue/goto) at the end of a case. Using > "continue" to fall through was rejected because it changes its meaning when > there's a switch in a loop. You'd use goto to jump to the particular > (next) switch case. "goto case;" already exists and jumps to the next case in the switch. So bam, you're already set ;)
Re: dmd support for IDEs
On Mon, Oct 12, 2009 at 12:22 AM, Nick Sabalausky wrote: > Jeremie Pelletier" wrote in message > news:hats2b$as...@digitalmars.com... >> Lutger wrote: >>> Jacob Carlborg wrote: >>> ... As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. >>> >>> Qt used to try and look like native controls, but now it uses them >>> directly. >> >> It has pros and cons, Firefox too has the native look and feel without >> using the native controls, so it saves on the overhead of tons of GDI >> handles and can render the entire GUI in cairo. > > I use FF a lot and umm...no it doesn't. Not remotely. It's always stood out > as every bit of a blatant GTK app as GAIM, GIMP, or Thunderbird. As soon as > I can find a browser with equivilents too all my essential hacks (*cough* > extensions) and *real* controls (which rules out IE and Opera. And > Chrome/Safari... AH HA HA HA!), then I'm ditching this garbage. ..huh? What OS are you on? It looks perfectly native on XP, Ubuntu, and Kubuntu for me..
Re: Importing, and visibility
On Sun, Oct 11, 2009 at 3:05 PM, Matt wrote:
> In C++ I see a lot of defining an enum, struct, or other values before
> #including another header which then uses these values. I understand why this
> works in C++, but does the same thing work in D? I'd assume not, since the
> import mechanism is a little more advanced than C++'s "copy this file into
> this location".
Not.. really. If module A imports module B, B does not see A's symbols at all.
However, it's possible to use mixins of various types to emulate
this. For instance, module B could define all of its members inside a
template, like so:
module B;
template BMembers()
{
some declarations
more declarations
}
Then in module A:
module A;
import B;
// define structs and stuff
mixin BMembers; // mixes in B's definitions into A, and they use A's symbols
You could also use the 'mixin(import("somefile"))' idiom at module
scope in A, but that's a bit hacky, and won't get you as decent error
messages.
Re: Array literals' default type
On Sat, Oct 10, 2009 at 7:33 AM, Yigal Chripun wrote: > > You keep calling these literals "constructor calls' and I agree that that's > what they are. My question is then why not make them real constructors? > > auto a = new int[](x, y, z); Teehee, that syntax already has meaning in D. Well, that right there would give you a semantic error, but "new int[][][](x, y, z)" creates a 3-D array with dimensions x, y, and z. That brings up another point. If you *did* use a class-style ctor syntax, how would you list the arguments for a multidimensional array? That is, what would be the equivalent of [[1, 2], [3, 4]]?
Re: CTFE vs. traditional metaprogramming
On Fri, Oct 9, 2009 at 4:57 PM, Sean Kelly wrote: > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article >> Thanks! >> I plan to add more text at the end of the chapter that discusses the >> opportunities of CTFE. Walter revealed to me that CTFE, particularly now >> after it's been improved by leaps and bounds by Don and by Walter >> himself, could obviate a lot of the traditional metaprogramming >> techniques developed for C++. >> One question that bugs me is, where do you draw the line? Say there's a >> metaprogramming problem at hand. How to decide on solving it with CTFE >> vs. solving it with templates? It would be great to have a simple >> guideline that puts in contrast the pluses and minuses of the two >> approaches. > > CTFE is great for working with values while template metaprogramming is > great for working with types. String mixins make CTFE good at working > with types as well, but I wouldn't consider them a novice-level feature. Throw templates in there. Boom! Goodbye, CTFE. (.stringof and templates do not get along.)
Re: CTFE vs. traditional metaprogramming
On Fri, Oct 9, 2009 at 3:49 PM, Andrei Alexandrescu
wrote:
> Thanks!
>
>
> I plan to add more text at the end of the chapter that discusses the
> opportunities of CTFE. Walter revealed to me that CTFE, particularly now
> after it's been improved by leaps and bounds by Don and by Walter himself,
> could obviate a lot of the traditional metaprogramming techniques developed
> for C++.
>
> One question that bugs me is, where do you draw the line? Say there's a
> metaprogramming problem at hand. How to decide on solving it with CTFE vs.
> solving it with templates? It would be great to have a simple guideline that
> puts in contrast the pluses and minuses of the two approaches.
>
> It is quite possible that templates get relegated to parameterized functions
> and types, whereas all heavy lifting in metaprogramming should be carried
> with CTFE.
God, I wish we had a real forum with table capabilities. I can't even
rely on monospaced fonts..
Where templates win at metaprogramming:
Templates have pattern-matching capabilities for picking apart types.
CTFE is forced to reimplement part of the D lexer/parser to do so (and
combined with buggy/incompletely specified .stringof, you can't really
depend on your parsing to work right).
With templates, you write "real code", whereas with CTFE you have to
quote everything. D2's token strings improve this somewhat but D1
users are stuck in escaping hell. Not that you care, since you don't
believe D1 even exists anymore, but whatever. Quoting things is still
irritating.
Templates have a definite advantage when it comes to alias parameters
and the instantiation mechanism. CTFE mixins have to worry about
exactly when and where some piece of code is mixed-in, or else you
could be evaluating it somewhere where a given symbol isn't defined.
Oops, you mixed in your code in a different module than the one it was
accessed from, suddenly all the imports are different and you don't
have access to a bunch of functions. With templates, it .. just works.
You can give a template a symbol from some module that it normally
wouldn't have access to and it's perfectly happy. CTFE that deals with
this gets very tedious very quickly.
Templates are much more transparent. Mixin statements/expressions
always look something like a hack. Greppable? Sure. But many times I
don't *want* greppable, I want *clean*.
Meta-metaprogramming. You can't easily write a CTFE map() function.
You *can* write a simple Map template. Reduce!(Cat, Map!(SomeList,
SomeTemplate)) is just.. it brings tears to my eyes. It's so
beautiful.
Where CTFE wins at metaprogramming:
Liiists. If you have a list of something, it's far easier to
deal with in an imperative CTFE function than in an awkwardly
recursive template. Edge cases (first, last items) are also easier to
deal with imperatively.
DSLs, and more generally, parsing. Doing DSL parsing with templates is
possible but not fun. You end up with a ton of templates. Not that I'm
advocating parsing lots of things with CTFE either.. you already know
how I feel about that.
Verbosity. Templates require you to add a lot of silly cruft to do
even really simple things. "template SomeListProcessingTemplate(T...)
{ static if(T.length == 0) alias Tuple!() SomeListProcessingTemplate;
else { pragma(msg, T[0].stringof); alias Tuple!(T[0],
SomeListProcessingTemplate!(T[1 .. $])) SomeListProcessingTemplate; }"
Notice the template name is repeated three times within the template..
all the cruft starts to make it difficult to see what's actually going
on. CTFE functions are generally shorter and easier to follow, if for
no other reason than D is mostly an imperative language and that's
what its syntax optimizes for.
Those things being said, please, PLEASE consider __ident. Many times
I'd like to do something with templates because I'd be able to avoid
the CTFE mess with symbol visibility, but I can't because I need to
dynamically generate one stinking identifier from a string. S many
of my CTFE metaprogramming functions could be replaced by simple
templates if I only had __ident. You remember the "finalize" template
thing I wrote once? How it was about 150 lines of hard-to-follow,
terribly hackish CTFE .stringof parsing and bullshit when it could
have been reduced to about 8 lines with __ident? Really. It comes up a
LOT. Consider it.
But one other thing that I want to bring up is that I really, really
hope that this newfound love for CTFE doesn't shift the mindset
towards "why bother adding features to the language when you could
simulate it with CTFE?" For some things, that's fine. But I don't want
to look at D code in 6 or 7 years, see half the source encased in q{},
and see the other half composed almost entirely of mixin(). That's
just awful.
Re: CTFE vs. traditional metaprogramming
On Fri, Oct 9, 2009 at 4:28 PM, Lutger wrote: > Jarrett Billingsley wrote: > >> The second someone suggests parsing D code with CTFE, I'm out of here. >> I mean I'm leaving the community. Period. > > Here, for you: > > http://www.addletters.com/pictures/bart-simpson-generator/bart-simpson- > generator.php?line=I+will+not+parse+D+code+with+CTFE! > Loled!
Re: CTFE vs. traditional metaprogramming
On Fri, Oct 9, 2009 at 3:49 PM, Andrei Alexandrescu wrote: > Thanks! > > > I plan to add more text at the end of the chapter that discusses the > opportunities of CTFE. Walter revealed to me that CTFE, particularly now > after it's been improved by leaps and bounds by Don and by Walter himself, > could obviate a lot of the traditional metaprogramming techniques developed > for C++. > > One question that bugs me is, where do you draw the line? Say there's a > metaprogramming problem at hand. How to decide on solving it with CTFE vs. > solving it with templates? It would be great to have a simple guideline that > puts in contrast the pluses and minuses of the two approaches. > > It is quite possible that templates get relegated to parameterized functions > and types, whereas all heavy lifting in metaprogramming should be carried > with CTFE. The second someone suggests parsing D code with CTFE, I'm out of here. I mean I'm leaving the community. Period.
Re: Use of first person in a book
On Thu, Oct 8, 2009 at 4:30 PM, Lutger wrote: >> I guess it just goes in the ever growing bag of rules we all blindly >> apply and never understand why. For one, I couldn't imagine this >> newsgroup if the first-person was banned from use :) > > The texts I find most inspirational are mostly witty or lively in one way or > another, even if they are very technical. I believe it is because the author > is passionate about the subject and cannot help but convey the pleasure they > take in it. Precisely. For the very same reason, those same people make excellent lecturers and professors.
Re: Use of first person in a book
On Thu, Oct 8, 2009 at 12:37 PM, Andrei Alexandrescu wrote: > Jarrett Billingsley wrote: >> >> On Thu, Oct 8, 2009 at 10:50 AM, Jeremie Pelletier >> wrote: >> >>> What the first person does to me is make it easier to make links with >>> authors since it makes it much easier to convey emotion, the third person >>> just sounds like a robot making statements. I know there isn't much room >>> for >>> emotions in programming books as opposed to the general roman, but there >>> is >>> still a lot of passion to convey, programming IS an art after all! >> >> I think why's Poignant Guide to Ruby seriously bucks THAT trend ;) Of >> course why just up and deleted everything a month or two ago, so >> getting your hands on it isn't quite as easy as it once was.. > > (For those not in the know: if you have trouble parsing the above sentences, > please note that "why" is actually used as a proper noun. It's the > self-chosen nickname of a former Ruby big wig.) > > I think I need to give a read to that book, although I've heard it's rather > controversial due to the gratuitous sexual references. Sexual references? I don't know if it was ever finished - I only managed to get hold of it after he disappeared, and it was only the first.. 5 or 6 chapters - but I didn't encounter any sexual references. At least I don't remember any. I was in no short supply of incongruous whimsical humor though :)
Re: Use of first person in a book
On Thu, Oct 8, 2009 at 10:50 AM, Jeremie Pelletier wrote: > What the first person does to me is make it easier to make links with > authors since it makes it much easier to convey emotion, the third person > just sounds like a robot making statements. I know there isn't much room for > emotions in programming books as opposed to the general roman, but there is > still a lot of passion to convey, programming IS an art after all! I think why's Poignant Guide to Ruby seriously bucks THAT trend ;) Of course why just up and deleted everything a month or two ago, so getting your hands on it isn't quite as easy as it once was..
Re: Use of first person in a book
On Thu, Oct 8, 2009 at 12:04 AM, Andrei Alexandrescu wrote: > I'd decided to not use the first person at all in TDPL, but now I find > myself a bit constrained by that decision. I personally think a small amount > of meta-references and asides prevents boredom and brings a more personal > note to the communication, but such devices should be used very sparingly > and with care. > > So I thought I'd ask a candid question in here. How do you feel about > moderate use of the first person in a technical book? Do you find it > comfortable, neutral, or cringeworthy? I totally prefer reading something where I feel like the author is having a conversation with me, so go ahead - use it!
Re: Eliminate class allocators and deallocators?
On Tue, Oct 6, 2009 at 12:01 PM, Andrei Alexandrescu wrote: > Hello, > > > D currently allows defining class allocators and deallocators. They have a > number of problems that make them unsuitable for D 2.0. The most obvious > issue is that D 2.0 will _not_ conflate destruction with deallocation > anymore: invoking delete against an object will call ~this() against it but > will not recycle its memory. In contrast, class deallocators are designed > around the idea that invoking delete calls the destructor and also > deallocates memory. > > So I'm thinking of removing at least class deallocators from the language. > Class allocators may be marginally and occasionally useful if the user takes > the matter of deallocation in her own hands. > > A much better way to handle custom allocation of classes would be in the > standard library. ..How? Without a custom allocator to do even a simple placement new, how would you handle such a thing in the library?
Re: null references redux + Looney Tunes
On Sun, Oct 4, 2009 at 5:58 PM, Andrei Alexandrescu
wrote:
> bearophile wrote:
>>
>> opIf sounds strange :-) Why don't you like the idea of the implicit
>> conversion to bool followed by the testing of the bool? (someone may
>> have already answered a similar question, please bear with me).
>
> Try this:
>
> void * p;
> if (p) {}
>
> Then try this:
>
> void * p;
> bool b = p;
Okay, how about if if() used the result of an *explicit* cast to bool?
Barring the silly opCast operator (and maybe providing something
else), would this be consistent?
Re: Sugar around string mixins (was: Why not move cast to the standard library?)
On Sat, Oct 3, 2009 at 9:22 PM, Sergey Gromov wrote:
> While I like and support the idea, I think that hijacking the "macro"
> keyword now will make it very hard to re-design later. It would be much
> better to reuse the "mixin" keyword for this since it's exactly what's
> happening: defining a function for mixing in:
>
> mixin max(int a, int b) {...}
>
> It could be problematic from the grammar perspective though.
Newp. 'mixin' could be followed by one of four things:
- '(', it's a string mixin.
- 'ident' '!', it's a template mixin.
- 'ident' ';' it's also a template mixin.
- 'ident' '(', it's a mixin declaration.
Not tough. But then you're really overloading the keyword by using it
for three very different purposes.
Re: What does Coverity/clang static analysis actually do?
On Sat, Oct 3, 2009 at 4:00 AM, Nick Sabalausky wrote: > "Christopher Wright" wrote in message > news:ha5mtp$f3...@digitalmars.com... >> BCS wrote: >>> >>> This is true of any long document if you are willing to string together >>> enough quotes and ignore enough of it. I'd bet you could get the >>> Declaration of Intendance out of Playboy if you wanted to. >> >> What is this Declaration of Intendance you speak of? >> > > That's the one they meant to write. Nicely played.
Re: Should certain abstract classes be instantiable?
On Fri, Oct 2, 2009 at 1:34 PM, Andrei Alexandrescu wrote: > > It was a question, you one-liner-asker you. What? ;)
Re: Should certain abstract classes be instantiable?
On Fri, Oct 2, 2009 at 11:00 AM, Andrei Alexandrescu wrote: > > No. I think it would help going back to my original message instead of > asking one-liner questions. This would work much better in real life, but > it's a time sink in a newsgroup. You spend five seconds on asking a question > with a foregone answer just because you don't want to invest fifteen seconds > in re-reading my initial post, and then you have me spend five minutes > explain things again. It's counter-productive. > > If a class defines an abstract method and also provides a body for it, it > still requires the derived class to override the method. So abstract still > has some meaning. Yes, I see now the parenthesized "requires overriding in derivees" now. > On the other hand, technically such a class would become instantiable > because it defines all of its methods. I wanted to explain that, however, > that wouldn't be a good idea because... and here's where 1-2 good examples > would have helped. I guess I'm going to drop it. Speaking of counterproductive timesinks, why would you bring up a proposal only to argue that it's a bad idea?
Re: null references redux + Looney Tunes
On Fri, Oct 2, 2009 at 8:13 AM, Justin Johansson wrote: > For the interest of newsgroups readers, I dropped in at the Cafe the other > day and > the barista had this to say > > http://cafe.elharo.com/programming/imagine-theres-no-null/ > > Disclaimer: YMMV > > Cheers > > -- Justin Johansson I always think it's funny when people are like "so, I had this idea, lemme throw this out there. I know it sounds weird, but just bear with me - what if there were _no null_? Did I just _blow your mind?_" And the perspective of languages with better type systems, it's like.. and? data Maybe T = Just T | Nothing The whole null/nonnull debate is a complete nonissue in languages like Haskell because _they actually treat it formally and correctly_. And they've _been_ doing this for years. For all the Java-ites to be like "OMG PARADIGM SHIFT" it's just funny.
Re: Should certain abstract classes be instantiable?
On Thu, Oct 1, 2009 at 11:48 PM, Andrei Alexandrescu wrote: >> >> But.. you mark something abstract when you want it to be .. abstract. >> How would you argue that abstract is basically a no-op when used on >> methods with bodies? > > It's not a no-op. Try it. Yeah, not *currently*, but isn't that what you're proposing?
Re: Should certain abstract classes be instantiable?
On Thu, Oct 1, 2009 at 8:49 PM, Andrei Alexandrescu
wrote:
> Jarrett Billingsley wrote:
>>
>> On Thu, Oct 1, 2009 at 4:30 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Consider:
>>>
>>> class A {
>>> abstract void fun() {}
>>> }
>>>
>>> The class defines a function that is at the same time abstract (so it
>>> requires overriding in derivees) and has implementation.
>>>
>>> Currently the compiler disallows creation of objects of type A, although
>>> technically that is feasible given that A defines the abstract method.
>>>
>>> Should A be instantiable? What designs would that help or hinder?
>>
>> Uh... why?
>
> Because I want to give a good argument one way or another in TDPL. FWIW, "I
> can't imagine why you'd ever..." or "Never needed that" are not strong
> enough arguments.
But.. you mark something abstract when you want it to be .. abstract.
How would you argue that abstract is basically a no-op when used on
methods with bodies? And there's a reasonable use for it, so why
suddenly allow something that.. doesn't really make all that much
sense to begin with?
Re: Should certain abstract classes be instantiable?
On Thu, Oct 1, 2009 at 4:30 PM, Andrei Alexandrescu
wrote:
> Consider:
>
> class A {
> abstract void fun() {}
> }
>
> The class defines a function that is at the same time abstract (so it
> requires overriding in derivees) and has implementation.
>
> Currently the compiler disallows creation of objects of type A, although
> technically that is feasible given that A defines the abstract method.
>
> Should A be instantiable? What designs would that help or hinder?
Uh... why?
Re: Can D compile for PowerPC Architecture?
On Thu, Oct 1, 2009 at 4:16 PM, Snake wrote: > For some reason, about an hour ago I was googling stuff about X86 and PowerPC > and right now I'm not even sure if this is a serious question nor do I know > if I know what I'm talking about or if the question is even valid. > > If that doesn't make sense, I want to know if you guys are developing D for > use with the PowerPC Instruction Set > > The question: Can you program for PowerPC architecture using D? In my mind > I'm having these crazy ideas about things that are remotely relevant to > programming but...whatever <_< This is me rambling at this point. > AFAIK yes. I think GDC can do it, but it's long been out-of-date. I haven't heard much about LDC on that front.
Re: Defining some stuff for each class in turn
On Thu, Oct 1, 2009 at 12:25 PM, Andrei Alexandrescu
wrote:
> I am becoming increasingly aware that we need to provide some means to
> define certain members (data and functions) for each class as if they were
> pasted there.
>
> Right now that right is reserved to the compiler, which generates e.g. one
> static classinfo object for each class. But users would want to also define
> members for each class automatically. This is often the case with
> contravariant-argument functions (that we discussed recently) and other
> important cases such as factories and cloning.
>
> For starters, assume I want to define one static int for each class in a
> hierarchy.
>
> class Counted {
> static uint counter;
> ...
> }
>
> Then subclasses of Counted would all share counter, something I don't want.
> I want each subclass to have its own counter, so I need to ask derived
> classes to *also* define counter:
>
> class A : Counted {
> static uint counter;
> ...
> }
>
> With the suggested feature, there would be the ability to define counter
> for each class in turn.
>
> class Counted {
> mixin(Derived)
> {
> // Insert here stuff that must be "pasted" for each subclass
> // of Counted (including Counted itself).
> // Use "Derived" as the name of the current subtype of Counter
> static uint counter;
> static if (is(Counted == Derived))
> ref uint getCounter() { return counter; }
> else
> override ref uint getCounter() { return counter; }
> }
> ...
> }
>
> The code above does something quite neat - it defines an overridable
> function Counted.getCounter in the base class, and then overrides it in
> *every* class inheriting that base class, to return that class' own counter.
>
> The same should go in interface definitions - the feature should allow you
> to
>
> There are quite a few immediate applications of this: opEquals, opCmp,
> clone, various factories and object pools, and most importantly reflection.
> To enable custom reflection with today's D, we'd have to require each class
> to insert some code inside the class body. With the mechanism described
> above, we allow the base class or an interface (e.g. Reflectable) to inject
> the code into the derived class' body.
>
> What do you think?
I think it sounds interesting enough, but I can't help but wonder if
this is a feature that you've really thought through (especially wrt.
how it interacts with mechanisms such as template mixins and normal
symbol inheritance), or if you just want it to support some pattern
you want to use in Phobos 2.
Re: Null references redux
On Wed, Sep 30, 2009 at 3:30 PM, Denis Koroskin <2kor...@gmail.com> wrote: > Note that C stdlib (and other libraries/bindings) will need to be updated to > reflect changes, e.g. > > extern(C) void*? malloc(size_t size); // may return null! > > which is great because it will provide additional safety. I've seen quite a > lot of code that don't test returned value against null (which is a mistake, > I believe). Wonderful. Don't you love self-documenting code that forces you to use it correctly? :P
Re: Null references redux
On Wed, Sep 30, 2009 at 12:44 PM, bearophile wrote: > Max Samukha: > >> Don't get confused by 'new' in struct initializers. Structs in C# are >> value types. > > Yes, you are right. > > But in D structs can be allocated on the heap too, so I think having optional > nonnull struct pointers can be useful. The syntax and usage is similar to > normal struct pointers. I don't know why a struct pointer would be different than any other pointer. That is, you'd have S* and S*? as well as int* and int*?.
Re: Comparing apples and oranges
On Tue, Sep 29, 2009 at 11:17 AM, Denis Koroskin <2kor...@gmail.com> wrote: > > I believe Java and C# took bool Object.equals(Object other); way because > they lacked generics intially and stored all the instances as Objects in > containers (having equals method in Object allowed them proper ordering > etc). > > D doesn't suffer from that problem and doesn't have to follow the same way > those languages took. I agree, opEquals and opCmp in Object feel like out-of-date relics. It's particularly annoying how, if you want your classes to behave with arrays/AAs, you must override opEquals(Object), meaning you have to do silly downcasts at runtime. > BTW, nowadays, they define IComparable interface, which is a recommended > way to implement comparison functions. I think D, with its much better generic support, could basically use duck typing and achieve the same effects without the penalty of an interface.
Re: opApply ref and "const" iterators
On Mon, Sep 28, 2009 at 6:58 PM, gzp wrote:
> Hello,
>
> Iám new to D so i might be all wrong. Given the code:
>
> class Foo {
> int opApply( int delegate(ref real) dg ) {...} //A.
> int opApply( int delegate(real) dg ) {...} // B,
> }
>
> ...
> Foo foo = new Foo;
> foreach( a; foo ) {...} // 1.
> foreach( ref a; foo ) {...} // 2,
>
> Is it normal that, the A. version (with ref) is called for both cases and if
> the A is eliminated, only the 2. foreach loop will compile ? The second case
> works as i expected but what about the first case - the B. function won't be
> called ever ?
Yes. For some reason the delegate that opApply takes must always take
ref params, even if you don't iterate as such. This isn't really
documented anywhere.
Re: Interesting GCC extensions
On Mon, Sep 28, 2009 at 1:27 PM, Steven Schveighoffer wrote: > On Mon, 28 Sep 2009 12:58:57 -0400, bearophile > wrote: > >> Jarrett Billingsley: >> >>> Which do you want? Do you want new features, or do you want things to be >>> fixed?< >> >> The ideas shown in that post are low priority, so they can wait. But >> things can be planned for the future too, you can start thinking/planning >> about them even years before they are implemented (see vector operations of >> D). >> (The triple point syntax is probably out of time). > > Just so you know. In 5 months, (i.e. the future) nobody is going to > remember that you posted this. I've noticed you replied to many a thread > with "well, that's exactly what I suggested X months ago, but nobody > listened to me." When you make 2 posts a week suggesting changes, you can't > expect them all to be considered, most are lost in the noise. > > If you want something to be considered to be an enhancement, go through the > proper channel -- bugzilla. Then it won't get lost. > > Mark it as an enhancement if necessary. Hahahahaha. Hahahahahaha! You really think he's gonna do it? He won't. He won't even explain *why* he won't.
Re: Interesting GCC extensions
On Mon, Sep 28, 2009 at 12:35 PM, bearophile wrote:
> Beside the known ones, like computed gotos and __builtin_expect(), GCC has
> other less known extensions, you can find some of them here:
> http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
>
> They are used by Linux. If D wants to be a system language, such small things
> may be useful if you want to build a kernel with D.
>
> One of them is the Range extension, it seems GCC devs think that 3 points are
> better after all:
>
> switch (major_idx) {
> case 0:
> return SCSI_DISK0_MAJOR;
> case 1 ... 7:
> return SCSI_DISK1_MAJOR + major_idx - 1;
> case 8 ... 15:
> return SCSI_DISK8_MAJOR + major_idx - 8;
> default:
> BUG();
> return 0;
> }
>
>
> Triple points can be used for initializations too:
> int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
>
>
> The __builtin_return_address() looks interesting, but I don't understand
> where it can be useful.
>
>
> The Constant detection done with __builtin_constant_p(exp) is what I was
> asking for in one of my recent posts here. It seems I was "right" again.
>
>
> The article also shows some of the function attributes, in truth in GCC there
> are many other of such attributes. Some of them are useful for D too.
>
> The good thing of adding some of those things to D is that they can be put in
> the specs, so they don't become nonstandard extensions as in GCC, this avoids
> several troubles.
I think it's kind of silly that you constantly whine to Walter
whenever he adds new features saying "why don't we fix the problems
that already exist in D like the module system," and then turn around
suggesting we add a bunch of features.
Which do you want? Do you want new features, or do you want things to be fixed?
Re: Null references redux
On Sun, Sep 27, 2009 at 3:42 PM, Jeremie Pelletier wrote:
> Jarrett Billingsley wrote:
>> Nonnull types do not create implicit null checks. Nonnull types DO NOT
>> need to be checked. And nullable types WOULD force explicit null
>> checks.
>
> Forcing checks on nullables is just as bad, not all nullables need to be
> checked every time they're used.
You don't get it, do you. If you have a reference that doesn't need to
be checked every time it's used, you make it a *nonnull reference*.
You *only* use nullable variables for references where the nullness of
the reference should change the program logic.
And if you're talking about things like:
Foo? x = someFunc();
if(x is null)
{
// one path
}
else
{
// use x here
}
and you're expecting the "use x here" clause to force you to do
(cast(Foo)x) every time you want to use x? That's not the case. The
condition of the if has *proven* x to be nonnull in the else clause,
so no null checks - at compile time or at runtime - have to be
performed there, nor does it have to be cast to a nonnull reference.
And if you have a nullable reference that you know is not null for the
rest of the function? Just put "assert(x !is null)" and everything
that follows will assume it's not null.
>> hash_t foo(Object o) { return o.toHash(); }
>> foo(null); // bamf, I just killed your function.
>>
>> Forcing initialization of locals does NOT solve all the problems that
>> nonnull references would.
>
> You didn't kill my function, you shot yourself in the foot. Something
> trivial to debug.
You're dodging. You claim that forcing variable initialization solves
the same problem that nonnull references do. It doesn't.
Re: Null references redux
On Sun, Sep 27, 2009 at 2:07 PM, Jeremie Pelletier wrote:
>> Yes and no. It introduces an "if" statement for null checking, but only
>> for nullable references. If you know your reference can't be null it should
>> be non-nullable, and then you don't need to check.
>
> I much prefer explicit null checks than implicit ones I can't control.
Nonnull types do not create implicit null checks. Nonnull types DO NOT
need to be checked. And nullable types WOULD force explicit null
checks.
> What about non-nan floats? Or non-invalid characters? I fear nonnull
> references are a first step in the wrong direction. The focus should be
> about implementing variable initialization checks to the compiler, since
> this solves the issue with any variable, not just references. The flow
> analysis can also be reused for many other optimizations.
hash_t foo(Object o) { return o.toHash(); }
foo(null); // bamf, I just killed your function.
Forcing initialization of locals does NOT solve all the problems that
nonnull references would.
Re: Null references redux
On Sat, Sep 26, 2009 at 11:23 PM, Jeremie Pelletier wrote: > There is no such thing as "not being able to happen" :) > > Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null; > > I seem to be the only one who sees Walter's side of things in this thread > :o) Why the hell would the compiler allow that to begin with? Why bother implementing nonnull references only to allow the entire system to be broken?
Re: Dispatching on a variant
On Sat, Sep 26, 2009 at 11:16 PM, Jeremie Pelletier wrote: > string switch actually walks the case strings and compares with the source > string until it finds a match, a binary search is much faster if you don't > care about the order of the tests. FWIW the runtime does perform a binary search of the strings in a switch. The compiler outputs the string table as a sorted list.
Re: Null references redux
On Sat, Sep 26, 2009 at 11:06 PM, Jeremie Pelletier wrote: > > I don't want the language to force me to check nullable references before > using them, that just takes away a lot of optimization cases. You don't design tight loops that dereference pointers with the intention that those pointers will ever be null. Those loops always expect nonnull pointers, and therefore you'd use a nonnull reference. The number of null references in your program are far less than you'd think. For those that really could be legitimately null (like an optional callback or something), you have to check for null at runtime anyway. Most of your code wouldn't really change. You'd instead just get more errors at compile time for things that are obviously illegal or just very potentially dangerous. > You could just use the casting system to sneak null into a nonnull reference > and bam, undefined behavior. No, you couldn't. That would be a pretty shitty nonnull reference type if the compiler let you put null in it. > And you could have nullables which are always > nonnull at some point in time within a scope but your only way out of the > compiler errors about using a nullable without first testing it for nullity > is to use excessive casting. The argument of verbosity that comes up with nonnull references holds some weight, but it's far more a matter of designing your code not to do something like that.
Re: Null references redux
On Sat, Sep 26, 2009 at 10:59 PM, Jeremie Pelletier wrote: > The compiler won't be able to enforce *every* nonnull reference and > segfaults are bound to happen, especially with casting. While it may prevent > most of them, any good programmer would too, I don't remember the last time > I had a segfault on a null reference actually. > > I can see what the point is with nonnull references, but I can also see its > not a bulletproof solution. ie "Object foo = cast(Object)null;" would easily > bypass the nonnull enforcement, resulting in a segfault the system is trying > to avoid. > > What about function parameters, a lot of parameters are optional references, > which are tested and then used into functions whose parameters aren't > optional. It would result in a lot of casts, something that could easily > confuse people and easily generate segfaults. You haven't read my reply to your post yet, have you. Nullable. References. Exist. Too.
Re: Null references redux
On Sat, Sep 26, 2009 at 10:41 PM, Walter Bright wrote: >> And what about the people who AREN'T complete idiots, who maybe >> sometimes just accidentally trip and would quite welcome a safety rail >> there? > > Null pointer seg faults *are* a safety rail. They keep an errant program > from causing further damage. If you haven't crawled out from under your rock in the last twenty years, I'd like to point out that the accepted definition of safety and program correctness has changed since then.
Re: Null references redux
On Sat, Sep 26, 2009 at 7:21 PM, Jeremie Pelletier wrote: > That's exactly the point with nonnull references, they turn access > violations or segfaults into undefined behavior, or worse into generic > behavior that's much harder to track to its source. > > I think nonnull references are a nice concept for languages that have a > higher level than D. If I expect references to never be null I just don't > check for null before using them, and let the code crash which gives me a > nice crash window with a backtrace in my runtime. You're missing the point. You wouldn't have "undefined behavior at runtime" with nonnull references because there would be NO POINT in having nonnull references without ALSO having nullable references. Could your reference be null? Use a nullable reference. Is your reference never supposed to be null? Use a nonnull reference. End of problem. You do not create "null objects" and store them in a nonnull reference which you then check at runtime. You use a nullable reference which the language *forces* you to check before use.
Re: putting more smarts into a == b
On Sat, Sep 26, 2009 at 9:32 PM, Andrei Alexandrescu
wrote:
> Consider two objects a and b with a of class type. Currently, the expression
> a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten
> into a call to an (imaginary/inlined) function equalObjects(a, b), with the
> following definition:
>
> bool equalObjects(T, U)(T a, U b) if (is(T == class))
> {
> static if (is(U == class))
> {
> if (b is null) return a is null;
> if (a is null) return b is null;
> }
> else
> {
> enforce(a !is null);
> }
> return a.opEquals(b);
> }
>
> This hoists the identity test outside the opEquals call and also deals with
> null references. What do you think?
I'm almost sure that C# does this already, and it's a useful behavior.
Of course, with nonnull types, the check for null wouldn't even need
to exst ;)
Re: Null references redux
On Sat, Sep 26, 2009 at 6:10 PM, Walter Bright wrote: > Jarrett Billingsley wrote: >> >> It wouldn't. The compiler wouldn't allow it. It would force you to >> initialize it. That is the entire point of nonnull references. > > Initialize it to what? > > A user-defined default object? What should happen if that default object is > accessed? Throw an exception? The point of using a nonnull type is that you *never expect it to be null ever*. So you would be initializing it to some useful object. If you *want* null, you'd use a nullable reference. > How would you define an "empty" slot in a data structure? A nullable reference.
Re: Null references redux
On Sat, Sep 26, 2009 at 5:59 PM, Jeremie Pelletier wrote:
>
> How would you do this then?
>
> void foo(int a) {
> Object foo;
> if(a == 1) foo = new Object1;
> else if(a == 2) foo = Object2;
> else foo = Object3;
> foo.doSomething();
> }
>
> The compiler would just die on the first line of the method where foo is
> null.
Either use Object? (a nullable reference), or factor out the object
creation - use a separate method or something.
> What about "int a;" should this throw an error too? Or "float f;".
Those are not reference types. But actually, the D spec says it's an
error to use an uninitialized variable, so a compliant D compiler
wouldn't be out of line by diagnosing such things as errors if they
are used before they're intialized. Such a compiler would break a lot
of existing D code, but that's what you get for not following the
spec..
> What about standard pointers? I can think of so many algorithms who rely on
> pointers possibly being null.
Again, you have both nonnull (void*) and nullable (void*?) types.
> Maybe this could be a case to add in SafeD but leave out in standard D. I
> wouldn't want a nonnull reference type, I use nullables just too often.
You probably use them far less than you'd think.
Re: Null references redux
On Sat, Sep 26, 2009 at 5:29 PM, Jeremie Pelletier wrote: > I actually side with Walter here. I much prefer my programs to crash on > using a null reference and fix the issue than add runtime overhead that does > the same thing. In most cases a simple backtrace is enough to pinpoint the > location of the bug. There is NO RUNTIME OVERHEAD in implementing nonnull reference types. None. It's handled entirely by the type system. Can we please move past this? > Null references are useful to implement optional arguments without any > overhead by an Optional!T wrapper. If you disallow null references what > would "Object foo;" initialize to then? It wouldn't. The compiler wouldn't allow it. It would force you to initialize it. That is the entire point of nonnull references.
Re: Dispatching on a variant
On Sat, Sep 26, 2009 at 4:50 PM, Jeremie Pelletier wrote: > Oh, that makes sense, but I don't see why you need language support for > that, a variant type should be able to get most of it using type tuples, > maybe just add support to switch on type tuples along with an opSwitch() > method: I'm pretty sure D2's std.typecons has something that almost does just that. I don't know how it handles dispatching though.
Re: Dispatching on a variant
On Sat, Sep 26, 2009 at 4:18 PM, Jeremie Pelletier wrote:
>> type Event = Mouse | Key | Move;
>
> This can be confusing, for example the first thing that comes to mind for me
> is that Event is the bitwise OR result of 3 constants, not an enumerated
> type.
>
> Besides, how is it any different than:
>
> enum { Mouse, Key, Move };
It's not an enumerated constant. Mouse, Key, and Move are all types,
and Event is a discriminated union of the three. See more below.
> match(event) is no different than switch(event), except that pattern
> matching often implies runtime semantics and is often slower than a straight
> jump table generated from a switch.
Not in this case. See, when you would do "type Event = Mouse | Key |
Move", it's actually more like doing:
struct Event
{
enum Type { Mouse, Key, Move }
Type type;
union
{
Mouse m;
Key k;
Move v;
}
}
Then, when you do "match(e) { Mouse m => ... }" it's actually being turned into:
switch(e.type)
{
case Event.Type.Mouse: alias e.m m; ...
case Event.Type.Key: alias e.k k; ...
}
Basically discriminated unions get rid of this annoying boilerplate
that you have to use every time you want a tagged union.
Re: Dispatching on a variant
On Sat, Sep 26, 2009 at 10:36 AM, Justin Johansson wrote: > I've got about 2 dozen types in the variant so the O(n) really hurts. > The variant thing seemed like a really cool idea at the time but now ... > Without something like suggested above or a computed goto on typeid or > Andrei's visitator, > it almost pushes me to backout from using variants and having to redesign > around some common base class or interface and using virtual function > dispatch. :-( Ouch. 2 dozen types? No offense, but that sounds like "you're doing it wrong." Revising your strategy is probably for the best. What are you doing, anyway?
Re: Pure dynamic casts?
On Fri, Sep 25, 2009 at 7:31 PM, Jeremie Pelletier wrote: > language_fan wrote: >> A used 2.5 GHz Athlon XP with 1GB of RAM and 100GB of disk costs about >> $100. Anything below that is obsolete these days. Good luck selling anything >> to people who use older computers, they are probably broke anyways. >> Otherwise I just see it cheaper to build your apps slower and require >> hardware updates. Just imagine - a highly optimized $400 program is way too >> expensive for most users, a $50 program + $200 hw upgrade sounds just fine. > > But a $40 optimized program will flush the competition of either $400 > optimized equivalents or $40 slow equivalents, making you the winner in the > end. People are so crazy about money they care more about their profits than > the satisfaction of their customers. > This. I don't have a problem with making money off software, but don't know why so many companies make it so expensive. Take Alias Sketchbook Pro. It's a fine program. It's got an intuitive interface, makes clean lines, is fast and resource-conscious. At one time it was priced at $200 [1]. For what? It has something like 3 drawing tools and a simple layering scheme. No custom brushes, no effects, no special integration with other programs, nothing. Compare that to Paint Tool Sai, which does everything it does, as well as having vectorized inks, custom brushes, patterns, complex layering and layer blending, accurate digital painting etc. for all of $53. Guess which one I bought. [1]It's now only $100, but Sai still beats it for half the price.
Re: should protected imply package?
On Thu, Sep 24, 2009 at 1:38 PM, Andrei Alexandrescu wrote: > In Java, "protected"-level protection implies package-level protection (see > e.g. > http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html). > Should we copy that behavior in D, or take advantage of the package keyword > and require it as in "package protected"? Under the current implementation, if protected implied package, all protected methods would suddenly become nonvirtual, since for some reason, package is treated as a kind of 'private'. Not really what you'd want, I think ;) 'package' should not conflate visibility and virtuality. If it didn't do that, having protected imply package would be just fine.
Re: Is typedef an alien?
On Thu, Sep 24, 2009 at 2:36 PM, Aenigmatic wrote: > No further response to any responses to my previous post's responses is a > both swift and non-invasive. > > Now my deeply thought question is ... > > Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a > first-class citizen in the US of D? It's a different beast, and in my experience, pretty useless. Most of the time you want typedef'ed types to interact with other types a little more richly. Say you want to use a double as a time. Okay, what do you get when you subtract two points in time? Not a time, that's for sure. You get a time _span_ instead. So you end up implementing them as structs. Virtually every time I've tried to use typedef, it hasn't sufficed and I've ended up using a struct instead. It seems like a failed idea, or at the very least, yet another half-thought-out abandoned feature.
Re: Why not move cast to the standard library?
On Thu, Sep 24, 2009 at 12:35 PM, downs wrote: > With all the neat template tricks we have in 2.0, and since we're widely > redefining the syntax anyway, why not deprecate the current cast syntax and > move it into object.d as a library function? > > So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save on a > keyword and demonstrate language power at the same time. > > What sez ye? > std.conv.to is more or less a proof-of-concept of this already. :>
Re: Function template parameter inference from class template
On Wed, Sep 23, 2009 at 6:17 PM, Justin Johansson
wrote:
>
> Wow Jarret!!! So many words on my part to explain what I wanted and you came
> up with this just so, so coolly concise solution. It doesn't exactly look
> like a textbook solution so me thinks I can forgive myself for not figuring
> it out. (hey only 3 weeks into D now).
>
> I don't know if it would be pushing my luck or not, but is your concept
> generalizable to more parameters. In particular I want to be able to extend
> this so than bar() can return a generic type.
>
> So now I have this:
>
> class Foo(T)
> {}
>
> T2 bar(T : Foo!(U), U)(T t)
> {
> T2 x = ...
> return x;
> }
>
> void main()
> {
> auto foo = new Foo!(float)();
> auto chu = bar!(double, float)( foo);
> // type of chu is double
> }
>
> and by analogy with the first problem I would like to instantiate like so:
>
> void main()
> {
> auto foo = new Foo!(float)();
> auto chu = bar!(double)( foo); // be nice if float could be deduced
> from foo parameter
> // type of chu is double
> }
>
class Foo(T)
{}
R bar(R, T : Foo!(U), U)(T t)
{
R r;
return r;
}
void main()
{
auto foo = new Foo!(float)();
auto chu = bar!(double)(foo);
pragma(msg, typeof(chu).stringof);
}
Make sure you have a newer compiler, though, as partial template
specialization with IFTI was only introduced in DMD 1.038.
Re: memset and related things
On Wed, Sep 23, 2009 at 10:52 AM, Jeremie Pelletier wrote: > I would love to see such a feature added in D, would make object composition > much more convenient and faster. > > You'd just need the compiler to force a call into C1's constructor within > C2's and generate a call to C1's destructor in the epilog of C2's. I can't > see how implementing idea that could be any harder, other than the parser > related support. > You are really hung up on parsing, aren't you ;) Parsing is a tiny, tiny, tiny fraction of the complexity of implementing a language, and most language features do not require any change to it. Really.
Re: Function template parameter inference from class template argument
On Wed, Sep 23, 2009 at 9:55 AM, Justin Johansson
wrote:
> D1.0
>
> If you have a function template of one type parameter, T, that takes a class
> template of the same type parameter, T, as an argument, then typical template
> usage scenario goes like this:
>
> /* Class template definition */
> class Foo(T) {
> }
>
> /* Function template definition */
> void bar(T)( Foo!(T) arg) {
> // ...
> }
>
> /* Instantiation usage */
> main()
> {
> auto foo = new Foo!(float)(); /* line A */
> bar!(float)( foo); /* line B */
> }
>
>
> Now since in the main function the compiler knows that T is float at line A,
> it occurs to me that code noise could be reduced a bit if the compiler could
> somehow deduce at line B that the function template parameter, T, is float
> without it having to be explicitly written.
>
> The instantiation usage would now look like this:
>
> /* Less-noisy instantiation usage */
> main()
> {
> auto foo = new Foo!(float)(); /* line A */
> bar( foo); /* line B */
> }
>
>
> The only problem is how then to write the function template definition so
> that T can be defaulted to the class parameter, T, that accompanies Foo.
>
> One idea I had, which of course doesn't work, is to define the function
> template's argument with the auto keyword and then somehow figure out T from
> the argument like so:
>
> /* Function template definition */
> void bar(T = typeof( arg))( auto arg) {
> // ...
> }
>
>
> Since I'm getting used to finding cool features in D that always lets you do
> stuff you never dreamed of,
> and since I have a lot of template instantiation code,
> it would be really neat to be able to reduce the noise a bit as outlined
> above.
>
> Any ideas anybody? (Note D1.0)
>
> Perhaps this is a no brainer and I just goofed up but have given up after a
> spending way too much time on it thus far.
>
> Thanks all.
>
> Justin Johansson
>
>
class Foo(T) {}
void bar(T : Foo!(U), U)(T t) {}
void main()
{
auto foo = new Foo!(float)();
bar(foo);
}
:)
Re: Pure dynamic casts?
On Tue, Sep 22, 2009 at 8:48 PM, Steven Schveighoffer
wrote:
> Why have pure functions at all? Seriously, all pure function reorderings
> and reuse can be rewritten by human optimization. If we aren't going to
> look for places that pure functions can help optimize, why add them to the
> language, it seems more trouble than its worth?
>
> If all it takes to optimize dynamic casts is to put pure on the function
> signature, have we wasted that much time?
But dynamic downcasting *isn't* pure, unless you can prove that the
reference that you're downcasting is unique.
class Base {}
class Derived : Base {}
struct S
{
Object o;
Derived get()
{
return cast(Derived)o;
}
}
void main()
{
S s;
s.o = new Base();
writeln(s.get());
s.o = new Derived();
writeln(s.get());
}
Dynamic downcasts are not pure. Simply. That's why they're *dynamic*.
Without some kind of uniqueness typing, you cannot prove anything
about the validity of such casts until runtime.
Re: Pure dynamic casts?
On Tue, Sep 22, 2009 at 4:13 PM, Steven Schveighoffer
wrote:
>> Dynamic downcasts do usually indicate a weakness in the design. But an
>> even more fundamental matter of style is to not repeat yourself. You
>> don't use "x + y" if you need the sum of x and y in ten places; you do
>> "sum = x + y" and then use "sum." The same applies here. You're not
>> just working around a deficiency in the compiler, you're saving
>> yourself work later if you need to change all those values, and you're
>> giving it some kind of semantic attachment by putting it in a named
>> location.
>
> What if x and y are possibly changing in between calls to x + y?
>
> I'm thinking of a situation where o *might* be changing, but also might not,
> the compiler could do some optimization to avoid the dynamic-cast calls in
> the cases where it doesn't change. These would be hard to code manually.
> My understanding of pure function benefits (and it's not that great) is
> that you can express yourself how you want and the compiler fixes your code
> to be more optimized knowing it can avoid calls.
Realistically, how often is this going to come up? Why the hell are we
looking at what amounts to CSEE on a rarely-used construct when there
are far more important performance issues? I understand wanting to
solve this problem for pedagogical reasons, but practically, I don't
see the benefit.
>> Besides, you're probably going to be doing:
>>
>> if(auto d = cast(Derived)baseRef)
>> {
>> // ..
>> }
>>
>> so you've already bound the result of the dynamic cast to a variable.
>> *shrug*
>
> Probably. But even then, if this statement is in a loop that might not
> change baseRef, the compiler can avoid dynamic casting again.
Then you'd hoist the conditional out of the loop. Again, not specific
to dynamic downcasts.
Re: Pure dynamic casts?
On Tue, Sep 22, 2009 at 3:35 PM, Steven Schveighoffer
wrote:
> On Tue, 22 Sep 2009 14:03:28 -0400, Jarrett Billingsley
> wrote:
>
>>
>> Or you could - I dunno - cache the result of the dynamic cast in a
>> local, since doing multiple dynamic casts is terrible style anyway.
>>
>> Just saying. ;)
>
> Yes, this is true of many optimizations :P
>
> Are you saying it's bad style because of the expense of dynamic casting or
> for some other reason? If dynamic cast were pure, that takes away that
> argument.
Dynamic downcasts do usually indicate a weakness in the design. But an
even more fundamental matter of style is to not repeat yourself. You
don't use "x + y" if you need the sum of x and y in ten places; you do
"sum = x + y" and then use "sum." The same applies here. You're not
just working around a deficiency in the compiler, you're saving
yourself work later if you need to change all those values, and you're
giving it some kind of semantic attachment by putting it in a named
location.
Besides, you're probably going to be doing:
if(auto d = cast(Derived)baseRef)
{
// ..
}
so you've already bound the result of the dynamic cast to a variable. *shrug*
Re: Pure dynamic casts?
On Tue, Sep 22, 2009 at 1:19 PM, Steven Schveighoffer wrote: > On Tue, 22 Sep 2009 05:24:11 -0400, Daniel Keep > wrote: > >> >> >> Jason House wrote: >>> >>> Dynamic casts are pure. They don't use global state, and have the same >>> output for the same reference as input. Interestingly, dynamic cast results >>> are independent of intervening mutable calls... So there's even greater >>> opportunity for optimization. >> >> What if the GC just happens to re-use that address for a different object? > > That's only if memoization is used. > > I think what Jason said is correct -- you can view dynamic cast as taking 2 > arguments, one is the reference which is simply echoed as the return value, > and one is the classinfo, which is an immutable argument that causes a > decision to be made. > > In fact, you could use memoization on a dynamic cast subfunction that > memoizes on the target type and the classinfo of the source, regardless of > the reference value, and returns an offset to add to the return value. > > It's pretty easy for the compiler to prove that o has not be reassigned, so > even without memoization, the compiler can logically assume that the result > from the first dynamic cast can be reused. I think this is the major > optimization for pure functions anyways, not memoization. Or you could - I dunno - cache the result of the dynamic cast in a local, since doing multiple dynamic casts is terrible style anyway. Just saying. ;)
Re: Pure dynamic casts?
On Tue, Sep 22, 2009 at 8:40 AM, bearophile wrote: > Daniel Keep: >>What if the GC just happens to re-use that address for a different object?< > > I don't understand. Can you explain me an example where this problem may > happen? > > Bye, > bearophile > Object is allocated at 0x10001000, that object is collected, its memory is put back on the freelist, another object of the same size is allocated, and that block of memory is used again, allocating a new object at 0x10001000.
Re: .init property for char[] type
On Tue, Sep 22, 2009 at 8:07 AM, Justin Johansson
wrote:
> In a templated class (D1.0) along lines ...
>
> class Foo(T) {
> //..
> static T bar() { return T.init; }
> //..
> }
>
> Foo!(int).bar() returns 0 and Foo!(char[]).bar() returns nil.
>
> I'd much prefer (at least for my purposes) that (char[]).init returned an
> empty string rather than effectively a null pointer. Is there a convenient
> solution for this, e.g. by specializing just the bar method of class Foo when
> T is char[], or by some other means?
>
> Maybe this type of question best be asked on D.learn, but I do wonder if an
> empty string is a more reasonable initializer for char[] .. well maybe not ..
> I don't know .. I yield to your sensibilities.
>
> Thanks to all.
There's no real difference between an empty string and a null
reference. Both have 0 length.
Re: XML ecosystem wrt D
On Sat, Sep 12, 2009 at 8:34 PM, div0 wrote: > It seems on causal thought that it ought to be possible to machine > translate it into D, unless Java has under gone massive change since the > last time I played with it. > > So who's up for writing a Java to D translator? You mean Tioport? http://www.dsource.org/projects/tioport
Re: Template Metaprogramming Made Easy (Huh?)
On Tue, Sep 8, 2009 at 8:40 PM, Justin Johansson wrote: > Got into OO with Smalltalk and with birth of C++ compilers, notably Zortech > C++. Then you've had experience with Walter's compilers before ;) He wrote Zortech.
Re: D 2.00 official spec
On Mon, Sep 7, 2009 at 8:12 AM, Justin Johansson wrote: > Now is this blurry vision to blame or a typo at line 23 into the first > example this page? > > http://www.digitalmars.com/d/2.0/index.html > > // Improved typesafe printf > writeln(cl.argnum, cl.suffix, " arg: ", cl.argv); > // Automatic or explicit memory management > delete cl; > } > > writeln should be writefln ? No, in Phobos 2 there's a function called writeln as well. It's like writefln but doesn't do formatting. > Ditto on D1.0 intro page > http://www.digitalmars.com/d/1.0/index.html Now that *is* a legitimate mistake. There's no writeln in Phobos 1, and that should be writefln.
Re: D naming style?
On Fri, Sep 4, 2009 at 10:14 PM, bearophile wrote: > Jarrett Billingsley: >> I'm consistently confused by D (and Java and C#) code that doesn't >> indicate member names, especially when they're named really common >> things that often conflict with local variables, like "len" or "src" >> or such. Unless the type is small enough to fit on a single screen, >> it's easy to forget the member names. > > I usually follow Python usage, and use this.fieldName. Is this bad practice > in D? It's not bad practice, but it's somewhat unusual for a C-style language, and not enforced by the language, so it's more likely that people won't follow it.
Re: D naming style?
On Fri, Sep 4, 2009 at 9:18 PM, Ali Cehreli wrote: > Thank you! > > Jarrett Billingsley Wrote: >> Many people don't indicate class members with any kind of decoration > > I noticed that too. :) > > The justification that I've come up with is that, we need the decoration in > e.g. C++, because the member declaration is not visible in the implementation > file, so the decoration communicates that the member is in the header file. > > That's not the case in D, so there is no need for the decoration; but I miss > them too. :) I'm consistently confused by D (and Java and C#) code that doesn't indicate member names, especially when they're named really common things that often conflict with local variables, like "len" or "src" or such. Unless the type is small enough to fit on a single screen, it's easy to forget the member names.
Re: D naming style?
On Fri, Sep 4, 2009 at 8:42 PM, Ali Cehreli wrote: > Is there a common(-ish) naming style for D? > > - camel case or underscores within words of names? > > - type names begin with capital? > > - underscore before or after member names? > > - enum values lowercase? > > - constant names? > > - etc.? :) > > Do you have a document that you would like to share? There is a "D style guide" in the D spec that briefly mentions naming conventions, but I'm not sure how many people use it / are aware of its existence. Most D libraries seem to use camel casing for multi-word names, start types with a capital, start functions/methods with lowercase, and don't put braces on the same line as code. Beyond that, there's a lot of variation. Sometimes enums have ALL_CAPS members, sometimes CamelCased, sometimes lowercased, sometimes even varied within the same library. Constant names are similarly varied. Many people don't indicate class members with any kind of decoration, which .. really irks me ;) but those that do, I've seen _foo, foo_, m_foo, mFoo, and some others. Personally? I hate underscores and use any naming scheme that doesn't use them. I name all types and constants with CapitalNames and members with mFoo.
Re: Compiled dmd2.032 in VC++ 2009!
On Fri, Sep 4, 2009 at 3:19 PM, Jeremie Pelletier wrote:
> Jarrett Billingsley Wrote:
>
>> On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier wrote:
>> > Jason House Wrote:
>> >
>> >> Don Wrote:
>> >>
>> >> > Interestingly since DMD has extern(C++), it ought to be possible to
>> >> > convert a single module to D, and still link it in...
>> >>
>> >> extern(C++) support in D is nearly a joke. There are some big areas for
>> >> improvement, such as support for non-virtual functions, or allowing use
>> >> of new, ... It's unusable to the point that I can't connect D code to
>> >> existing C++ or even write efficient wrappers. I've resorted to simply
>> >> using extern(C) code in C++ and then wrappers in D to use those
>> >> functions...
>> >
>> > From what I know it was mostly intended for interfaces, and it works
>> > wonders when binding to COM code in Windows. A lot of the new features of
>> > recent windows versions are only available through COM, extern(C++) makes
>> > it dead easy to write their bindings.
>>
>> You've been able to bind to COM interfaces in D for years. extern(C++)
>> hasn't changed that, as far as I know.
>
> True, but it has not always been that simple, now I can take the IDL file,
> run it through a few regular expressions and I got my D binding :)
>
> extern(C++):
> interface ID2D1Factory : IUnknown { ... }
>
> I don't remember what the syntax in D1 looks like for COM interfacing, but I
> remember having some issues writing bindings.
It's basically the same. I think you just have to put extern(Windows):
inside each interface, but that's it.
Re: Compiled dmd2.032 in VC++ 2009!
On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier wrote: > Jason House Wrote: > >> Don Wrote: >> >> > Interestingly since DMD has extern(C++), it ought to be possible to >> > convert a single module to D, and still link it in... >> >> extern(C++) support in D is nearly a joke. There are some big areas for >> improvement, such as support for non-virtual functions, or allowing use of >> new, ... It's unusable to the point that I can't connect D code to existing >> C++ or even write efficient wrappers. I've resorted to simply using >> extern(C) code in C++ and then wrappers in D to use those functions... > > From what I know it was mostly intended for interfaces, and it works wonders > when binding to COM code in Windows. A lot of the new features of recent > windows versions are only available through COM, extern(C++) makes it dead > easy to write their bindings. You've been able to bind to COM interfaces in D for years. extern(C++) hasn't changed that, as far as I know.
Re: The Linker is not a Magical Program
On Fri, Sep 4, 2009 at 12:15 AM, Jeremie Pelletier wrote: > Christopher Wright Wrote: > >> Walter Bright wrote: >> > A rant I wrote a few months ago: >> > >> > http://programmer.97things.oreilly.com/wiki/index.php/The_Linker_Is_not_a_Magical_Program >> >> For reference, GNU ld has to be compiled with -linvisible-pink-unicorn. > > How can you know its pink if its also invisible? Colorless green dreams sleep furiously.
Re: How Nested Functions Work, part 1
On Thu, Sep 3, 2009 at 7:10 PM, grauzone wrote: > > Probably the same type as .ptr? void*? That's just silly. Let's just throw all static typing out the window. :P > And by the way, I find it really strange, that .funcptr results into an > incorrectly typed function pointer, that basically has the wrong calling > convention for the destination code, which usually is a method. It'd be > different if signature of the .funcptr included an explicit argument for the > hidden pointers. So that you could write: dg.funcptr(dg.ptr, arguments); Yeah. There probably needs to be an extern(this) or so for functions that take a context pointer, like __thiscall in VC++. The way it works now is rather unsafe. > And that's about the only reason to keep them. > > But wouldn't it be possible for the compiler to allow assignment of a > function pointer to a delegate? All the compiler had to do is to generate a > hidden dispatch method to "translate" the different calling conventions. The > delegate's .funcptr points to that dispatch function, and the dispatch > function call the actual function. If the assigned function pointer is not a > statically known function (but from a variable), the function address could > be stored in the delegate's .ptr. Would this work? Of course it'd work. And D APIs would take delegates and everyone would be happy. But it still doesn't really justify getting rid of raw function pointers.
Re: How Nested Functions Work, part 1
On Thu, Sep 3, 2009 at 6:48 PM, Edward Diener wrote: > What I imagine will happen in D is that when an updated delegate type allows > itself to be initialized with a function pointer, the vast majority of D > programmers will use delegate for all callables and the function pointer > will remain simply an artefact of the language. Then D can eventually get > rid of it ! There's no real reason to get rid of function pointers. What type would the .funcptr property of a delegate be, if function pointers didn't exist? You also need them for C compatibility.
Re: Nullable or Optional? Or something else?
On Thu, Sep 3, 2009 at 12:02 PM, Steven
Schveighoffer wrote:
> On Wed, 02 Sep 2009 15:39:28 -0400, Andrei Alexandrescu
> wrote:
>
>> I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's
>> Optional).
>>
>> Apparently a good design is to define Optional!T with a minimum of member
>> functions (ideally none) and have it use the "alias this" feature to
>> masquerade as a T. That way Optional!T looks and feels much like a T, except
>> that it supports a function
>>
>> bool isNull(T)(Optional!T value);
>>
>> Am I on the right track? If so, what is the name you'd prefer for this
>> artifact?
>
> I like nullable, but optional will work.
>
> ---
>
> I noticed that in some of your responses, you refer to OptionalRef, Can you
> elaborate on that? I looked up Nullable for C#, and it specifically says
> that you can't apply the Nullable struct to a non-value type (because
> reference types are nullable).
>
> Since we are in D and not C# and have vastly better template mechanisms, I
> was assuming that Optional!T would simply alias to T if T is a reference
> type already (such as a class or pointer).
>
> This is also going to be better looking if the compiler helps. Having to do
> isNull(x) all the time instead of x !is null is going to be a pain when you
> aren't sure whether x is an Optional!T or a true reference type (such as a
> class).
>
> It would also solve some other problems. For instance being able to test if
> Rebindable is null...
>
> I wonder if the compiler could do something nifty like this:
>
> struct S
> {
> int n;
> alias n this;
> static S opNull() { return S(int.min); }
> }
>
> S s;
>
> s = null; // translates to s = S.opNull();
> if(s !is null); // translates to if(s !is S.opNull())
>
> Now you have a "nullable" int type that works for most cases and only
> requires an int storage space.
>
> I don't understand the ramifications on the context-free grammar, but does
> something like this seem feasible?
The semantics here have nothing to do with the grammar. It's not
really that different from operator overloading.
Re: OT - Which Linux?
On Thu, Sep 3, 2009 at 1:49 AM, Nick Sabalausky wrote: > And if anyone knows how to edit a system-settings text file without > dropping to the command-line and doing "sudo gedit blahfile &" (and without > having to start out with "sudo pwd" or "sudo echo" just so the "sudo gedit > &" does something useful instead of creating a background process that sits > and waits for input that'll never come from a prompt that I'll never see), > then *please*, let me know. That's what gksu - or on KDE, kdesu - is for. ;)
Re: Nullable or Optional? Or something else?
On Wed, Sep 2, 2009 at 8:20 PM, Jeremie Pelletier wrote:
> Andrei Alexandrescu Wrote:
>
>> I plan to add a Nullable struct to Phobos (akin to C#'s Nullable,
>> Boost's Optional).
>>
>> Apparently a good design is to define Optional!T with a minimum of
>> member functions (ideally none) and have it use the "alias this" feature
>> to masquerade as a T. That way Optional!T looks and feels much like a T,
>> except that it supports a function
>>
>> bool isNull(T)(Optional!T value);
>>
>> Am I on the right track? If so, what is the name you'd prefer for this
>> artifact?
>>
>>
>> Andrei
>
>
> I just recently converted tons of COM headers in win32 to D (gotta love
> extern(C++)) and I really like how they hint the compiler of what parameters
> are used for. They have all sorts of macros like __in, __inout, __out,
> __in_opt, __inout_opt, __out_opt.
>
> Why can't these be used in D too and implicitly add the appropriate contracts
> to the function:
>
> void foo(in_opt int* a) { ... }
>
> can be the same as
>
> void foo(in int* a)
> in { assert(a); }
> body { ... }
>
> I know I'm trying to push a lot of library stuff to the language spec, but it
> would just be so much more convenient that way. in_opt would be semantically
> the same as in, with the added contract.
Hmm, you know this could be handled raather nicely with attributes.
void foo(@in_opt int* a) { ... }
But they don't have any compelling use cases, right?
they just keep showing up, huh
Re: Nullable or Optional? Or something else?
On Wed, Sep 2, 2009 at 4:20 PM, Andrei Alexandrescu wrote: > Great. Now, before we get all jolly about Maybe, let me point out that we > also need the "ref" corresponding type. And OptionalRef and NullableRef may > sound better to some than MaybeRef. But reference types already are nullable. Unless you mean for something like NullableRef!int.
Re: How Nested Functions Work, part 1
On Wed, Sep 2, 2009 at 4:53 PM, Nick Sabalausky wrote:
>> void foo(bool delegate() dg) {
>> dg();
>> }
>> foo({return true;});
>>
>
> Sure, when there's no parameters (...does that work in D1, or just D2?...),
> but even then, I still always end up going though a process like this when
> defining foo:
No, you can do it with params too.
foo((int x) { return x; });
Re: Nullable or Optional? Or something else?
On Wed, Sep 2, 2009 at 4:13 PM, Simen Kjaeraas wrote: > Danny Wilson wrote: > >> Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu >> : >> >>> I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's >>> Optional). >>> >>> Apparently a good design is to define Optional!T with a minimum of member >>> functions (ideally none) and have it use the "alias this" feature to >>> masquerade as a T. That way Optional!T looks and feels much like a T, except >>> that it supports a function >>> >>> bool isNull(T)(Optional!T value); >>> >>> Am I on the right track? If so, what is the name you'd prefer for this >>> artifact? >>> >>> >>> Andrei >> >> >> How about: Maybe!T >> >> >> Got that from Haskell :-) > > I also feel the bikeshed should be colored 'Maybe'. Thirded!
Re: How Nested Functions Work, part 1
On Wed, Sep 2, 2009 at 3:29 PM, Don wrote:
> Michiel Helvensteijn wrote:
>>
>> Rainer Deyke wrote:
>>
I still find it silly that it was built that way. Seems to me you should
be able to forward-reference *any* symbol that has a value that can't
change over its lifetime. Functions, const/immutable vars, typedefs,
classes, etc.
>>>
>>> That can lead to subtle problems in the case of functions:
>>>
>>> int i = f();
>>> int f() { return i; }
>>
>> You're right, I forgot about that. You can conservatively statically
>> forbid
>> this. But I admit it makes the 'constant data should obviously be
>> forward-referenceable' thing less convincing. :-)
>>
> I can't see how it can be done in the general case, other than by
> constructing a dependency tree of top-level symbols.
> Pass over the tree, evaluating everything which is a leaf of the tree.
> If you have a pass where you don't succeed in removing any leaf nodes, you
> have a circular dependency.
> DMD sort of does this, I think, but it only does two passes, and it's not
> very good at backing out when it discovers something is not a leaf.
> It'd be hard to make that efficient when there are potentially infinite
> passes.
It wouldn't even be that difficult. Basically if you treat
forward-referenced nested functions as a sort of goto, the same rules
should apply: a call to a nested function may not skip the
initialization of any variables it depends on. When i's initializer is
evaluated, it has not been declared yet, so the call to f is illegal.
It also prevents other invalid use.
Re: How Nested Functions Work, part 1
On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescu wrote: > Jarrett Billingsley wrote: >> >> Well repeat should probably always take a delegate since most likely, >> you're going to be passing it a lambda. However I agree that it would >> be very, very nice to be able to make APIs take just delegates and >> allow functions to be implicitly cast to them. You can already make >> your own thunks, but they're not going to be as efficient as something >> that actually works on an ABI level. > > Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that "Function pointers and delegates may merge into a common syntax and be interchangeable with each other," so I just assume that no one has found it necessary to make a report. Maybe there should be.
Re: How Nested Functions Work, part 1
On Wed, Sep 2, 2009 at 9:49 AM, Daniel Keep wrote:
>
> Jarrett Billingsley wrote:
>> Well repeat should probably always take a delegate since most likely,
>> you're going to be passing it a lambda. However I agree that it would
>> be very, very nice to be able to make APIs take just delegates and
>> allow functions to be implicitly cast to them. You can already make
>> your own thunks, but they're not going to be as efficient as something
>> that actually works on an ABI level.
>
> The problem is that function pointers and delegates have different
> calling conventions. You *might* be able to rig up an asm stub that
> compensated for the difference... not sure.
Which is why I suggest that the ABI be changed ;) I suppose one method
of making their calling conventions compatible would be to pass the
delegate's context in what would normally be a scratch register.
Delegates/member funcs would store that immediately upon entry, and
normal functions wouldn't care if anything were passed.
> As it stands, you can just use a function to create the delegate stub
> for you; doesn't even require a heap allocation!
>
> http://gist.github.com/140507
Wow. What a horrible mess of code to do something that should be
straightforward. If this is what Andrei is thinking of when he says
"introspection", well heh, I'll have no part of it.
The comment about tuples not being allowed to contain out and ref is
actually not entirely true. Internally type tuples are represented as
parameter type tuples, which include the refness, and you can even get
.stringofs that include the ref qualifiers. It instead seems that the
compiler is buggy and _whether or not the refness of the params in a
param tuple is preserved depends on the code using it_. Consider this
gem:
void foob(T: Ret function(Args), Ret, Args...)(T func)
{
pragma(msg, ParameterTupleOf!(T).stringof);
static void wtf(ParameterTupleOf!(T) args) {}
pragma(msg, ParameterTupleOf!(T).stringof);
}
void blah(int, ref float) {}
void aojkjas()
{
foob(&blah);
}
Okay, look at foob's body. Both pragmas should print out the same thing, no?
They don't.
They print:
(int, ref float)
(int _param_0, float _param_1)
WHAT. For one, where did the 'ref' go? For two, where did the names
come from? Also, if you look at typeof(&wtf), it's also missing the
ref.
I'd really, really like to replace your entire module with this:
Ret delegate(Args) toDg(T: Ret function(Args), Ret, Args...)(T func)
{
struct Wrap
{
T mFunc;
Ret call(Args args)
{
return (cast(T)this)(args);
}
}
Ret delegate(Args) dg;
Wrap wrap;
dg.ptr = func;
dg.funcptr = &wrap.call;
return dg;
}
But I can't. :C
Re: How Nested Functions Work, part 1
On Wed, Sep 2, 2009 at 6:07 AM, Nick Sabalausky wrote:
> Umm, yea. If you don't already know what I'm getting at with that, then...
> Quick! For each of these, valid or invalid?:
> // D
> void repeat(int n, void delegate(int i) dg)
> {
> foreach(int i; 0..n)
> dg(i);
> }
> repeat(5, delegate void(int i) { writefln("hi"); });
Only valid one! I've been doing this too long ;)
> And now the secondary question: Which, if any, of those instances of
> "delegate" should be changed to "function"? (I know it's not a real serious
> problem, but the thing is, 99.9% of the time, I don't care, and more
> importantly, I don't *want* to care whether or not there's a scope being
> passed around with the...whatever it is.)
Well repeat should probably always take a delegate since most likely,
you're going to be passing it a lambda. However I agree that it would
be very, very nice to be able to make APIs take just delegates and
allow functions to be implicitly cast to them. You can already make
your own thunks, but they're not going to be as efficient as something
that actually works on an ABI level.
Re: type switch
On Tue, Sep 1, 2009 at 7:39 PM, Paul D.
Anderson wrote:
> I came across Lava, an experimental programming language ("What's hotter than
> Java?") http://lavape.sourceforge.net/LavaHomePage.htm Lava has some curious
> features (they claim to have no syntax, but the syntax is just hidden by the
> "programming environment").
>
> One of the evils of other programming languages, according to the website, is
> the infamous type cast: "Type casts are not only ugly, nasty, and annoying
> but much worse: their justification can only be assessed on the basis of a
> more comprehensive understanding of the dynamic program behavior in general."
>
> While I don't feel quite that strongly about type casts, one use case for
> casting does bother me: Using a generic object as the type of a member, and
> then specializing the object when you use it.
>
> A good example is a Token type in a lexer. The token typically has a line and
> column number, a string (the text of the token), a token type (an enumeration
> or int) and a value. The value is an integer for an integer token, a string
> for a string, an enum for a symbol or keyword, etc. So the type of the value
> field is "object", and you use the token type to tell you how to cast the
> value field when you use it.
>
> The Lava solution to this problem is to allow an explicit type switch:
>
> switch (value.type) {
>
> case int: // value is an int
> value += 3;
> break;
>
> case string: // value is a string
> string sub = substring(value, 1, 5);
> break;
>
> case symbol: // value is a symbol type
> int index = value.getSymbolIndex;
> break;
>
> }
>
> (Lava doesn't actually give an example of a type switch -- I just guessed at
> what it would look like.)
>
> Anyone else think this is a good idea?
>
> Does anyone know of another language that does this? (I don't have much
> knowledge of functional or logical languages.)
Just looks like simple pattern matching. It's very common in
functional languages.
Re: How Nested Functions Work, part 1
On Mon, Aug 31, 2009 at 6:30 PM, Jeremie Pelletier wrote: > Andrei Alexandrescu Wrote: > >> Jarrett Billingsley wrote: >> > On Mon, Aug 31, 2009 at 1:14 PM, Walter >> > Bright wrote: >> >> Thanks! >> >> >> > >> > I don't mean to pull a Stewart, but please be sure to quote a bit of >> > the post you're responding to. If you don't, it's virtually impossible >> > to tell who you're talking to when viewing the mailing lists. >> >> Same happened to me, but I've been brought back to order by others who >> pointed out that turning "threaded" on in your newsreader clarifies what >> the parent message is. >> >> Andrei > > Am I the only one here using web-news? Probably. It's full of fail.
Re: How Nested Functions Work, part 1
On Mon, Aug 31, 2009 at 4:11 PM, Andrei Alexandrescu wrote: > Jarrett Billingsley wrote: >> >> On Mon, Aug 31, 2009 at 1:14 PM, Walter >> Bright wrote: >>> >>> Thanks! >>> >> >> I don't mean to pull a Stewart, but please be sure to quote a bit of >> the post you're responding to. If you don't, it's virtually impossible >> to tell who you're talking to when viewing the mailing lists. > > Same happened to me, but I've been brought back to order by others who > pointed out that turning "threaded" on in your newsreader clarifies what the > parent message is. I said I'm using the mailing lists ;)
Re: How Nested Functions Work, part 1
On Mon, Aug 31, 2009 at 1:14 PM, Walter Bright wrote: > Thanks! > I don't mean to pull a Stewart, but please be sure to quote a bit of the post you're responding to. If you don't, it's virtually impossible to tell who you're talking to when viewing the mailing lists.
Re: How Nested Functions Work, part 1
On Sun, Aug 30, 2009 at 10:54 PM, Jeremie Pelletier wrote: > > I need to try that out, its most likely a bug since 'in' means 'const scope' > now. > > Check my second code bit, the delegate is declared as scope and it doesn't > optimize, maybe the compiler only checks if the closure is being dereferenced > and if so switches to memory storage instead of stack storage without > checking the storage class of the closure's delegate. And even without > 'scope' in this case the compiler could detect that the delegate doesn't > leave the function scope and optimize away. The compiler currently doesn't do anything with local delegates declared with 'scope'. It only seems to do anything special if 'scope' is used as a parameter storage class. > Better yet, allow forward references for nested functions. The need to assign > closures to delegates to get a nested function is so C# ;) Oh indeed ;)
Re: How Nested Functions Work, part 1
On Sun, Aug 30, 2009 at 9:00 PM, Jeremie Pelletier wrote:
> Walter Bright Wrote:
>
>> http://www.reddit.com/r/programming/comments/9fk6g/how_nested_functions_work_part_1/
>
> I really like the way nested functions and closures are done in D. Especially
> because they are the same thing as delegate and closures.
>
> But speaking of closures, I did notice something that could be optimized:
>
> void foo {
> int a;
> void foo2() { a++;}
> bar(&foo2);
> }
> void bar(in void delegate() dg) { dg(); }
>
> Here foo() is using _d_allocmemory to get storage for the stack frame. I
> understand it is for cases where the closure is executed long after the owner
> method has returned, but if the delegate has a scope storage class it could
> use the thread's stack instead.
It already is optimized if you use "void bar(scope void delegate()
dg)". If it doesn't optimize it when you use 'in', it's probably a
bug. :)
Re: Reference value of structs not optimized or inlined?
On Sat, Aug 29, 2009 at 3:42 PM, Walter Bright wrote: > Jarrett Billingsley wrote: >> >> On Sat, Aug 29, 2009 at 4:56 AM, Walter >> Bright wrote: >>> >>> Ary Borenszweig wrote: >>>> >>>> Walter Bright escribió: >>>>> >>>>> Ary Borenszweig wrote: >>>>>> >>>>>> Walter Bright escribió: >>>>>>> >>>>>>> There are a lot of D specific optimization opportunities that are >>>>>>> left >>>>>>> undone for now. >>>>>> >>>>>> Why? >>>>> >>>>> Which of the thousand things people want done in D should be done >>>>> first? >>>> >>>> Those that you feel like doing first. >>>> >>>> Ok, you win. :-) >>>> >>>> (I use the same reasoning most of the time when coding Descent) >>> >>> But I'm not kidding about the thousand things. There are more than >>> that >>> in Bugzilla. >> >> So uh, how's the Bugzilla voting system working out then? > > Inlining of functions with ref arguments has gotten 0 votes. > You said "which of the thousand things people want done should be done first?" And we already tried to solve this problem with the Bugzilla voting feature. Has it been working out well? Have the issues that people want to get fixed been getting more attention than the others?
Re: Reference value of structs not optimized or inlined?
On Sat, Aug 29, 2009 at 4:56 AM, Walter Bright wrote: > Ary Borenszweig wrote: >> >> Walter Bright escribió: >>> >>> Ary Borenszweig wrote: Walter Bright escribió: > > There are a lot of D specific optimization opportunities that are left > undone for now. Why? >>> >>> Which of the thousand things people want done in D should be done first? >> >> Those that you feel like doing first. >> >> Ok, you win. :-) >> >> (I use the same reasoning most of the time when coding Descent) > > But I'm not kidding about the thousand things. There are more than that > in Bugzilla. So uh, how's the Bugzilla voting system working out then?
Re: Reference value of structs not optimized or inlined?
On Fri, Aug 28, 2009 at 4:20 PM, Walter Bright wrote: > Jarrett Billingsley wrote: >> >> You're addressing the 'const' issue, but you haven't addressed the >> OP's issue: that 'ref', for whatever reason, prevents inlining. Const >> aside, why is this so? > > Because I never updated the inlining code to handle it. Well I'm glad it's that simple, and I'm sure Jeremie is too ;)
Re: Reference value of structs not optimized or inlined?
On Thu, Aug 27, 2009 at 8:17 PM, Walter Bright wrote: > Jeremie Pelletier wrote: >> >> Isn't there a way to implement RVO to work on parameters (PVO?) too >> if the storage is const? > > No, and it doesn't work for C++ either. Consider: > You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?
Re: D should disallow forward references
On Wed, Aug 26, 2009 at 8:47 PM, Stewart Gordon wrote: > Robert Fraser wrote: >> >> Stewart Gordon wrote: >>> >>> Have you written a compiler for a superset of C in which arbitrary >>> forward references are allowed? How did you do with overcoming the >>> difficulty that is C's context-sensitive grammar? >> >> C (minus preprocessor, of course) is only context-sensitive with regards >> to casts AFAIK. Since casts are always expressions, you can rewrite >> parenthesized expressions to casts (or vice versa) in a second pass but >> still allow forward references. > > > > Not quite. For example, is > > qwert * yuiop; > > a declaration of yuiop as a pointer to a qwert, or an instruction to > multiply qwert by yuiop but do nothing with the result? It's grammatically ambiguous, but not semantically. No-op statements are illegal. Thus, it's perfectly fine to always parse this as a pointer decl, since the other possible parse tree is always semantically invalid.
Re: D should disallow forward references
On Tue, Aug 25, 2009 at 10:54 AM, grauzone wrote: > Jarrett Billingsley wrote: >> >> For two, NO. Disallowing forward references sucks. It's entirely >> possible to implement a compiler that resolves forward refs correctly. >> If W doesn't want to do it, that's on him. > > I agree; but: I'm just saying that disallowing it would actually be better > for the programmer, than leaving it half-broken. Then let's drop every buggy feature. :P The best solution would be to *fix it*, or *make a new compiler that works right.*
