Re: Dispatching on a variant
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. :-(
You can use a hash literal as a jump table but it's an unsafe hack and
probably not performant depending on what you need to do. Maybe it's easier
still to write the visitation code yourself or generate code with ctfe than
to redesign to common base classes.
a hash literal works like this, index with the typeid to get a function ptr
you can call:
Algebraic!(int, Foo) a;
a = 3;
[ typeid(int) : function { writeln("a is int"); },
typeid(Foo) : function { writeln("a is Foo"); }
] [a.type] ();
Re: Rich Hickey's slides from jvm lang summit - worth a read?
Walter Bright wrote: > Executive summary: pure functions and immutable data structures help > manage program complexity. I think so too, but you left out the time and identity part related to stm and multiversion concurrency. You could argue these notions are a possible consequence of immutable data structures and pure functions. But the time thingy somehow seems more fundamental than that. Anyhow it nicely hints at what we can do with these concepts. It seems to me that this is the fundamental part of functional programming, and not functions as first class citizens. This is also the part that most modern languages that claim to be hybrid OO / functional do not support.
Re: contravariant argument types: wanna?
Andrei Alexandrescu wrote: ... > I am considering discussing all of the above in detail in TDPL, but I am > afraid that some refugees from other languages will be shocked. Please, it's much more important to write a good book than to avoid possibly offending the sensibilities of potential readers. Besides, anymore willing to take a risk with D will surely be open to learning something new.
Re: D 1.0: std.regexp incredibly slow!
Some regexes are very slow with phobos, I believe this is due to backtracking. I'm not familiar enough with the issue, whether some other regex engine might be able to avoid backtracking or not or how to rewrite it. I found this link though, perhaps it is useful to you: http://www.regular-expressions.info/catastrophic.html
Re: Does dmd have SSE intrinsics?
Jeremie Pelletier wrote: ... > Why would you declare void variables? The point of declaring typed > variables is to know what kind of storage to use, void means no storage > at all. The only time I use void in variable types is for void* and > void[] (which really is just a void* with a length). > > In fact, every single scope has an infinity of void variables, you just > don't need to explicitly declare them :) > > 'void foo;' is the same semantically as ''. exactly: thus 'return foo;' in generic code can mean 'return;' when foo is of type void. This is similar to how return foo(); is already allowed when foo itself returns void.
Re: How Nested Functions Work, part 2
language_fan wrote: ... > "Computer science (or computing science) is the study of the theoretical > foundations of information and computation, and of practical techniques > for their implementation and application in computer systems." > > I am not talking about getting a degree from some university. I have > already said that you can read it all yourself if you do not like the > pace they use to teach the same stuff. But still, it *is* computer > science. You cannot really invent it all by yourself without studying > existing work. I think you forget one thing: software engineering is not exactly a science. Being able to prove the complexity of a certain algorithm doesn't mean you can architect a good domain model. For example, I have two books here lying at my desk. One is Programming language pragmatics, because I wanted to have more background on language design (out of interest, trying to follow the discussions here...). The other is Patterns of Enterprise Application Architecture because my employer was kind enough to organize a course on design patterns. Now the Fowler one isn't exactly CS while PLP is. Which one do you think weights more in a professional context?
Re: Rich Hickey's slides from jvm lang summit - worth a read?
Hell yeah, super interesting! Also extremely well presented. I found the conclusion of the presentation on youtube, anybody knows if the full presentation is (or will be) on the internet? http://www.youtube.com/watch?v=zRTx1oGG_1Y&feature=channel_page
Re: How Nested Functions Work, part 2
language_fan wrote: > Sun, 20 Sep 2009 01:09:56 +, language_fan thusly wrote: > >> Sat, 19 Sep 2009 11:44:33 -0700, Walter Bright thusly wrote: >> >>> Lutger wrote: >>>> Cool article, I posted a comment. Reddit seems to be going downhill >>>> fast though, it's even worse than slashdot. >>> >>> I know, the negative comments don't even make any sense. >>> >>>> Are locally instantiated templates used in phobos? >>> >>> Yes. >> >> I read the comments and I think some of them are justified. You cannot >> really expect the way you built dmd to be the only alternative. >> Efficient closures can be implemented differently if you have a VM that >> supports precise generational gc, region inference, and the language is >> a bit more value oriented (= functional). Where does it say that the article describes the one true method? > Another thing is that often when an article about D is released, the only > positive comments come from the members of the existing (smallish) > community. There is no real interest in D outside the community (IMHO). > Reddit's programming section is full of language fanatics, thus it is a > bit hard to impress folks with tiny tricks as they daily work with > various programming languages and concepts. The majority of the negative comments on this post follow one of two lines of attacks: 1) D sucks or 2) Glaringly obvious straw man. From most of these, it's quite clear they haven't even read the article but responded anyway.
Re: How Nested Functions Work, part 2
Cool article, I posted a comment. Reddit seems to be going downhill fast though, it's even worse than slashdot. Are locally instantiated templates used in phobos?
Re: Elliotte Rusty Harold's take on Java
Yigal Chripun wrote:
> On 17/09/2009 16:15, Justin Johansson wrote:
>>> making primitives full objects is the right design and has nothing to do
>>> with bloat which just means the implementation sucks.
>>>
>>> consider:
>>>
>>> struct Integer(int bits, signed = true) {...}
>>> with specializations for 8, 16, 32, 64
>>>
>>> Integer!(32) will have the same size as an int since structs don't have
>>> vtables in D.
>>>
>>> of course, for this to be truly useful the compiler needs to understand
>>> "123.methodName()" kind of code.
>>
>> And I'm guessing you didn't mean auto-boxing either?
>>
>
> of course not. auto boxing is a patch for a broken design.
>
> it's already possible to define in D:
> void func(type[] arr, params) {}
> and use it as:
> type[] arr;
> arr.func(params);
>
> applied to strings (which are just regular arrays in D), you can do:
>
> string str = "Hello World";
> str.toUpper(); // assume to upper is defined as above.
>
> next step would be to allow the same for literals:
> "hello World".toUpper();
>
> now let's take the above one step further. why limit this to arrays? why
> not make it work for numbers as well?
> 123.next(); could be understood by the compiler as
> Integer.next(123);
>
> No bloat required.
This is already supposed to be in D under the name of extension methods. But
it is just another syntax for a function call, what has this to do with OOP?
Re: Non-moving generational GC [was: Template Metaprogramming Made Easy (Huh?)]
Jeremie Pelletier wrote: ... > > I just posted my memory manager to pastebin: > http://pastebin.com/f7459ba9d > > I gave up on the generational feature, its indeed impossible without write > barriers to keep track of pointers from old generations to newer ones. I > had the whole tracing algorithm done but without generations, a naive scan > and sweep is faster because it has way less cache misses. > > I'd like to get some feedback on it if possible. I think that it deserves a new thread...
Re: Template Metaprogramming Made Easy (Huh?)
language_fan wrote: > Tue, 15 Sep 2009 00:25:46 +0200, Lutger thusly wrote: > >> That's a fancy way of saying that anyone who has not studied CS is a >> moron and therefore cannot understand what is good about languages, thus >> they lose any argument automatically. Am I right? > > I just recommend learning basic concepts until terms like generational > garbage collection, closure, register allocation, immutability, loop > fusion, term rewriting, regular languages, type constructor, virtual > constructor, and covariance do not scare you anymore. > Right right, I don't disagree with that. It was more the 'ruby/python programmers make apps no-one uses using amateur tools | c-family users worship FOO and the rest are academics that use pure functional languages' part that tripped me up. You know, the majority of software isn't built by academics, NASA uses C mostly, etc. A little nuance wouldn't hurt here.
Re: Writing a language parser in D
APaGeD can do LL parsers: http://apaged.mainia.de/ There is a fork: http://www.dsource.org/projects/apaged2 Not a recommendation perse, but just wanted to mention it as an option.
Re: Template Metaprogramming Made Easy (Huh?)
language_fan wrote: > Mon, 14 Sep 2009 07:33:59 -0400, bearophile thusly wrote: > >> But lot of people will judge D against more modern languages like C#, >> Scala or Java) and not against C. > > Programmers often belong to three kinds of groups. First come the fans of > traditionally weakly typed compiled languages (basic, c, c++). They have > tried some "dynamic" or "academic" languages but did not like them. They > fancy efficiency and close to metal feel. They think compilation to > native code is the best way to produce programs, and think types should > reflect the feature set of their cpu. They believe the syntax C uses was > defined by their God. > > The second group started with interpreted languages built by amateurs > (php, ruby, python, some game scripting language etc). They do not > understand the meaning the types or compilation. They prefer writing > short programs that usually seem to work. They hate formal specifications > and proofs about program properties. They are usually writing simple web > applications or some basic shareware utilies no one uses. They also hate > trailing semicolons. > > The members of the last group have studied computer science and > languages, in particular. They have found a pet academic language, > typically a pure one, but paradigms may differ. In fact this is the group > which uses something other than the hybrid object-oriented/procedural > model. They appreciate a strong, orthogonal core language that scales > cleanly. They are not scared of esoteric non-C-like syntax. They use > languages that are not ready to take a step to the "real world" during > the 70 next years. > That's a fancy way of saying that anyone who has not studied CS is a moron and therefore cannot understand what is good about languages, thus they lose any argument automatically. Am I right?
Re: Template Metaprogramming Made Easy (Huh?)
Jeremie Pelletier wrote: > Tom S Wrote: ... >> Sweet :D As for a place, there are plenty of options, e.g. >> http://dsource.org/projects/scrapple/ or a separate dsource project. > > I thought of that, but I don't feel like opening a project for just a few > random code snippets or standalone classes. I think I'll just post it in > this forum and let interested people grab it for now. That's cool, but scrapple is exactly that: an assortment of small(ish) projects / pieces of code that otherwise don't warrant a full project. If you feel like putting it online, just ping BCS and I'm sure he'll give you access right away. Stacktrace is a feature highly desired by lots of people, you will many developers happy :)
Re: Simple bolt-on unittest improvement
Justin Johansson wrote: ... > If I haven't misread you, sounds we are on the same track. For sure, one thing I have come to appreciate is how Walter made things so simple: one file containing related code, documentation and the testsuite. As soon as you have more than one of anything there is bound to be some hassle involved :)
Re: Simple bolt-on unittest improvement
I'm rewriting my testing stuff at the moment, I hoped to use the runtime
features to be able to user regular asserts too but that didn't work out.
Do you know you can get rid of the need to pass __FILE__ and __LINE__?
Define the functions this way:
void expectEquals(T)(T some_x, T some_y,
string file = __FILE__,
int line = __LINE__);
Default parameter initialization does the right thing here (in D2, dunno
about D1).
I like the testing overhead to be as minimal as possible, for that purpose I
have something hackish right now. Basically something like this:
void test(string testname)(void delegate () testClosure,
int LineNumber = __LINE__,
string FileName = __FILE__)
{
writeln("running test ", name, " in ", FileName,"(", LineNumber,")");
try
testClosure();
catch(Exception ex)
// print test failure
/* print test success. (actually first checks some flag set by expect***
functions to see if test passed)*/
}
And this:
void expectTrue(lazy bool exp, int LineNumber = __LINE__,
string FileName = __FILE__)
{
if (!exp())
writeln("not true! ", FileName,"(", LineNumber,")");
}
usage:
unittest
{
int a = 42;
test!"foo" = {
auto b = 42;
expectEquals( a, b );
expectTrue( a == a );
throw new Exception("fail!");
};
}
Re: Template Metaprogramming Made Easy (Huh?)
language_fan wrote: (...) > > For what's it worth, I have not seen any firmware projects that use D, > either. Not that it's impossible, no one in the firmware industry just is > not interested in D. When you have limited amount of memory resources, > the bloaty executables that dmd generates (all firmware uses x86 opcodes, > right), the typeinfos, and the garbage collector are a nuisance. > If you don't mind me asking, what is your interest in D?
Re: D features - wanna start project
Steven Schveighoffer wrote: > On Fri, 21 Aug 2009 10:18:04 -0400, toki > wrote: > >> 4. I often use HashMap, HashSet, TreeMap, TreeSet. Do they have >> counterparts in D ? > > As an alternative to the already suggested Tango libs, you can use > dcollections (http://www.dsource.org/projects/dcollections) which has all > those. Should work with Phobos 1 and Tango, I haven't yet ported to D2. > > -Steve A little offtopic, but are you planning to support D2? And use ranges? Thanks.
Re: D features - wanna start project
toki wrote: > Hi, > I love D, and after using Java for years I want to switch back to D. > I'm too lazy to google, and so wanna ask you. > 1. Is D still under development ? Is it still supported ? > 2. Which GUI lib would you suggest - which is the most robust > implementation ? 3. Are there any OpenGL bindings ? Are they stable ? > 4. I often use HashMap, HashSet, TreeMap, TreeSet. Do they have > counterparts in D ? > > Best Regards > Thorsten 1) D is under heavy development and has branched into a stable (frozen) version D1 and alpha, backwards incompatible D2. For D1 there is the dmd compiler and ldc compiler (supports also 64 bit but not windows). 4) For D1 there is an alternative library incompatible with phobos: tango. It is comprehensive and has high performance, also a good collections library. 2) The big ones are dwt (port of swt), wxWindows, gtkd and qtd. I think most stable is currently gtkd, but I'm not sure. Hybrid might also be interesting for a game. 3) Yes, derelict offers a plethora of game-oriented bindings to common c libraries and is very popular. It also has an ODE binding. links: www.dsource.org/projects/ldc www.dsource.org/projects/derelict www.dsource.org/projects/tango http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries Happy hacking!
Re: OT - Which Linux?
Paul D. Anderson wrote: > I'm going to add Linux to my PC to get a dual-boot configuration. (I'm > tired of slw start ups and want to tap into the great tools > available.) The tutorial I'm looking at suggests Ubuntu. Is there a > significant difference in Linux implementations? Is Ubuntu one of the > better ones? Does it make a difference for running D2? > > Thanks in advance for your hellp. > > Paul The gnome and kde desktops are quite different, and some distros focus more on one of these. There is also fluxbox window manager for example if you want a lightweight desktop. Some more differences are: - how the distro deals with patented and closed source software. (mp3, dvd, flash, video drivers, etc) - relation with upstream: whether the distro does a lot of modification or not to the software, more focus on stability or up to date packages - polish (gui tools for example) and how user friendly the distro is - the community and documentation - method of packaging and selection of packages available. Also: updates and security. A great way to see for yourself what's available is to burn a couple of live cd's and take them for a spin. Here are some of my observations for what it's worth: - Mandriva: hands down the most user friendly distro I have seen (more so than Ubuntu). Mandriva One comes with binary video drivers and media codecs out of the box and has a lot of tools to assist migration from windows. Sometimes buggy though. - OpenSuse: very solid, lot's of polish and gui tools. The best installer ever. Does a lot of modification; don't step to far out of the box. - Fedora: bleeding edge, focused on free software and innovation. - Ubuntu: I have tried this one but never cared much for gnome and at the time a lot of packages were buggy. Kubuntu is not as good for a kde distro as one of the above imho. I want to balance this thread a little ;) - Linux Mint: this is based on ubuntu but more polished. For example: codecs out of the box, a nice start menu and a bunch of configuration tools. Almost as friendly as mandriva. In conclusion: if you want, you can spend a lot of time finding something that suits your need and preferences...
Re: The future of D 1.x
Dominik wrote: ... > thanks for reply - what attracted me to D was D1/Tango combination and I > think I wouldn't use D without Tango at all - I have no idea what Phobos2 > brings to the table in practice yet, but from what I can see it does not > look like a suitable replacement. Though they overlap, phobos and tango do have different scopes and somewhat different programming styles. Would you consider using D2 if Tango was available for it?
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig wrote: > In C# when you define a function that takes an out or ref parameter, > when invoking that function you must also specify ref or out. For example: > > void fun(ref uint x, double y); > > uint a = 1; > double b = 2; > fun(ref a, b); > > When I first started using C# it really annoyed me that I had to put > that keyword there just to get my program compiled. "I know what I'm > doing", I thought. But later, when reading the code, I found it very > helpful to know that my "a" could be changed when invoking "fun". As > always, code is read much more times than written, and I think this > little tips help better understand the code. > > What do you think? I'm not sure. However, you could implement something like this in descent without having to type all that or change D ;) Change the color of the parameter or something like that...
Re: GPU/CPU roadmaps
bearophile wrote: > D2/D3 may become a good language to create video games, this is a new > interesting document that shows some of the things D2 users may want to > use it for: > http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf > > I don't know how D2 can adapt itself to help in such regards. > > Bye, > bearophile Do you think the D language needs to adapt more for this market? From my limited perspective, I see numerous things D does, especially in the concurrency department, that is on the list of requirements put forth in that presentation. Furthermore, it's interesting to note some of the numbers pertaining to GOW 2: 250K LoC for the game and 2000K LoC for the engine, excluding loads of libraries like speedtree, openal, etc. So middleware is key right? Especially by providing easier ways to program difficult architectures. Now this again is something that D can do well, it's very suitable for building good libraries. Now here is the problem too, they have to be build. Concluding remark of the presentation says that if you start building an engine now, you finish in 2014. I don't think D has a chance on this scale of game development when it faces competition from such monster engines in C++. To return to your original question: what about the systems programming aspects of D? For example, cutting out the GC and typeinfo bloat, dealing with arrays, whatever. Is this something that good library developers can do just on their own or do we need some more support for this? I was thinking what it would take to develop a specialized component in D that can be used from within a demanding C/C++ ecosystem.
Re: overloading functions against function templates
My intuition would be that functions are more concrete than templates, and thus will be checked first. Will implicit conversions match the same way as exact type matches?
Re: The XML module in Phobos
language_fan wrote: > Tue, 28 Jul 2009 11:38:36 -0400, Adam D. Ruppe thusly wrote: > >> On Tue, Jul 28, 2009 at 12:23:50PM -0300, Ary Borenszweig wrote: >>> But *why* use or make another one when the Tango one is already >>> excellent? :( >> >> Copyright. > > There are most likely several issues that prevent the reuse of that code. > First, the indentation, module boundaries, and naming conventions may > differ (tabs vs spaces, 4 vs 8 spaces, camelCase vs foo_bar etc.). Naming conventions by Tango is quite similar to the style guidelines that Walter Bright has written, probably closer than phobos. As for formatting, you know, there are tools for that and descent even has the best formatter ever. > Next, does it use the slow object oriented approach like the rest of > Tango (and unlike Phobos, which uses a very lightweight procedural > model). Are there any benchmark results that show the approach Tango uses > is any good, i.e. more performant than the ones for Java and C++ (even > with larger xml documents). If it is, then the idea can be copied to > Phobos as well. Object-oriented does not mean slow. Tango's XML library outperforms the fastest C++ libraries, here are some benchmarks: http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs- with-rapidxml/ > Finally, the copyright is a problem unless it is handed over to > digitalmars. Otherwise it might get troublesome to sell D later for > commercial use when Phobos becomes the Standard library for D 2.0. I don't think (and hope) that walter bright & co will sell the standard library commercially, if that's even possible with current copyright owners. All that is needed is a license Walter Bright can live with, such as the boost one. Seems like an excellent opportunity for leveraging open source, no?
Re: D Framework
teo wrote: > I have a proposal. The idea isn't new and is perhaps a bit boring, but > anyway. > > In the newsgroups there are many comments like: "Can't just Phobos > disappear?" and similar. From other side the .NET Framework has a dull > name, but everyone can tell you that this is _the_ framework for the .NET > languages. No mistakes here! > > And now the idea: why not name the standard D library after the language > itself - "D Framework"? > > I can contribute the dframework.org domain. IMPORTANT! I can transfer it > to whoever wants to own it! So, Walter, just give me a sign. > > I dream about a modern, multi-platform framework for D. I dream about a > tiny Runtime which can be used in embedded systems and a rich, modular > framework that can fulfill programmer's needs. You may call me a dreamer, > but the .NET Framework makes .NET successful... And it doesn't matter how > nice the language is, but without libraries you are always at reinventing > the wheel... > > I love to hear your thoughts. I don't see that many comments about wanting phobos to disappear. Frankly, I find the .NET framework not as good as everybody saying it is. It is comprehensive and easy to use for sure, but not always as consistent as advertised. It is sometimes quite verbose too for such a high-level enterprise. The .NET framework is supposed to be 'progressive', meaning easy to get into for simple things and open for more advanced needs. In practice I find often times I need to redo lot's of things in a different way when my needs change. Sorry for the rant, I just think phobos as is developing is superior to the .NET framework and has a much cooler name too :) Same goes for Tango, albeit quite different design than phobos, it's very good too and beats .NET hands down. Also, Tango has a better name. That being said, I agree with the gist of your post. But your best bet to find a comprehensive, multi-platform, quality framework for D is the qtd library. Just look at it, it's way larger than just gui! Database programming, webbrowser components, high quality graphics, networking stuff, etc. etc: http://www.dsource.org/projects/qtd http://doc.qtsoftware.com/4.5/index.html
Re: Reddit: why aren't people using D?
Andrei Alexandrescu wrote:
> Lutger wrote:
>> python:
>> (x * x for x in xrange(10, 20) if x & 1)
>>
>> D as of now:
>> map!("a * a")( filter!("a & 1")( range!(10,20) ) )
>>
>> D with extension methods:
>> range!(10,20).filter!("a & 1").map!("a * a")
>>
>> Not too bad right?
>>
>> (the range function is fictional, I forgot if and which one exists in
>> phobos)
>
> (It's called iota.)
>
> Andrei
Oh yes, I remember being freaked out reading about the APL after that one:
(~R∊R∘.×R)/R←1↓⍳R
(this finds all prime numbers from 1 to R in the APL)
Re: Reddit: why aren't people using D?
python:
(x * x for x in xrange(10, 20) if x & 1)
D as of now:
map!("a * a")( filter!("a & 1")( range!(10,20) ) )
D with extension methods:
range!(10,20).filter!("a & 1").map!("a * a")
Not too bad right?
(the range function is fictional, I forgot if and which one exists in
phobos)
Re: Reddit: why aren't people using D?
bearophile wrote: > Lutger: > >> Adding random features to a language just because they look cool is a >> terrible thing to do. > >>Isn't this a bit contradictory?< > > I don't see a contradiction. For example list comprehensions and unit > testing module aren't random features, they are known to be quite useful. Sure, I was referring to your suggestion of adding features to see how they pan out and then removing them, not any particular feature. >>list comprehensions are only worth it if you add tuples imho.< > > Nope. Lazy/eager sequence comprehensions can be useful in many situations > even if you don't have tuples. list comprehensions don't do anything useful over map & friends but make them look better. They are super handsome in python in combination with tuples. So my point was, if you go for list comprehensions as a sweetener, you really should have some tuples with them too.
Re: Reddit: why aren't people using D?
Andrei Alexandrescu wrote: ... > At the end of the day, a property is a notational convenience. That sums up the discussion pretty nicely. Except for one thing: what do you think of the ability of tools ( I include metaprogramming with this ) to recognize properties as such?
Re: Reddit: why aren't people using D?
bearophile wrote: > Lutger: > >>It's interesting why unittest (and assert) are such big success. My idea >>is that it's not in spite of, but because of their utter simplicity. I >>speculate that if it would have been different, for example if you would >>had to create a new file for a unittest, it would not have been used so >>much.< > > It's another example of scaling. A good unit test system is the one that > allows you to write quickly and in a very simple way simple tests. And to > use them later to build more and more complex unit testing as the program > gets bigger. At the moment D unit testing is fit for small purposes only, > but not for the larger ones (Python docstests are fit for even small > purposes, you can use it for unit testing even if your program is 15 lines > long). Yes, but practically every other language implements testing in libraries. My suggestion was not build a big unit testing system in the language, but just to add those one or two changes in order to build such a testing library on top of the existing system. ... > Walter Bright: > >>It may indeed be the syntax, but consider that no other language adopted >>those constructs. There was a proposal to add contracts to C++0x which >>died. I added them to Digital Mars C++ and nobody cared.< > > A way to solve this problem is to add features (to D2), and then later > remove them (to D3) if they aren't appreciated. This breaks backward > compatibility, as D2 does on D1. Or even (silly idea) adding features to > D1 may be good to test such features to see if they are worth addign to D2 > :-) Using D1 as experimental field... > > --- > > Michiel Helvensteijn: > >>I don't know a compelling use-case either. But that doesn't mean there >>isn't any. Nor are there any real dangers. Arbitrarily restricting the >>possibilities of D doesn't seem like the right way to go.< > > Adding random features to a language just because they look cool is a > terrible thing to do. > Isn't this a bit contradictory? ... > > Andrei Alexandrescu: > >>I think D should also visibly obviate some use of Python or Perl for >>prototyping.< > > A good language works well with others, like Python, it doesn't try to > fully "obviate" them. But I agree that D may grow some features that allow > it to "scale down". Syntax support for tuples and list comprehensions are > two of the things that can help a lot in such regard. > list comprehensions are only worth it if you add tuples imho. Otherwise I think we can get by just fine with map/filter/reduce plus extension methods.
Re: DIP4: Properties
Daniel Keep wrote: > > > Lutger wrote: >> I do think this proposal is better than what we have since it meets the >> major requirements, but have one minor point of critique: >> >> Offering a mixin is not a good enough argument to address the DRY >> shortcoming. While it may be acceptable in many cases, it is ugly and >> messes with reporting of errors, debugging, code coverage and profiling. > > Very true. We really need to come up with a way to fix this. That > said, I sometimes think that string mixins will NEVER get fixed unless > Walter has a strong impetus to do so: i.e., people are using them and > hurting. > > But that's another DIP for another day. :P I'm very curious when that day arrives what it could bring. AST macros may help with some issues, but this kind of trickery seems to me inherently unfriendly for tools and maintainers alike. Not that it's a bad thing though, you have to make some trade-offs somewhere.
Re: DIP4: Properties
I do think this proposal is better than what we have since it meets the major requirements, but have one minor point of critique: Offering a mixin is not a good enough argument to address the DRY shortcoming. While it may be acceptable in many cases, it is ugly and messes with reporting of errors, debugging, code coverage and profiling.
Re: Reddit: why aren't people using D?
Michel Fortin wrote: > On 2009-07-24 22:58:33 -0400, Andrei Alexandrescu > said: > >> This is pretty clean, and in keep with the opXxx approach. Actually how >> about defining property foo by defining opGet_foo and opSet_foo. > > The problem with this is that it's ugly. What about this > > int foo.opGet();// getter > void foo.opAssign(int); // setter > > with some support from the compiler. > > It could even be exteded to support more: > > int foo.opIndex(int); // foo[1]; > void foo.opAddAssign(int); / foo += 1; > void foo.invert(); // special function attached to property > > There is a thread discussing the proposal which is also linked to by the wiki. Posting there would be useful, for future reference too.
Re: Reddit: why aren't people using D?
Walter Bright wrote: > Michiel Helvensteijn wrote: >> That's just a few reasons right there. D's properties lack elegance and >> they lack potential. > > Let's start with: > > 1. What is a property? A property contains information describing some object, which may or may not be mutable. > 2. How is that different from, say, a pure function? A pure function is a computation without side effects: - does not have to relate to any one object - a mutable counterpart may not make any sense - it cannot have any side effects while that may make sense even for a getter (lazy load for example) - it does not have to *describe* an object in the sense that a property does The mechanism may be exactly the same, but a property gives a big hint to the programmer (and tools) as to what kind of thing you are dealing with. Extremely dumb example, all very much the same going from less to more nice: color(corvette, Color.Red); assert(color(corvette) == Color.Red); corvette.color(Color.Red); assert(corvette.color() == Color.Red) corvette.color = Color.Red; assert(corvette.color == Color.Red);
Re: DIP4: Properties
Am I right in thinking that the automated storage is mainly to cut down
verbosity? What other purpose could it serve? It looks to me the proposal
could be much simplified by cutting this feature.
I think the "int foo {get;set;}" syntax may be sufficient and useful for
keeping simple properties simple though. The advantage over plain fields in
this case is primarily to keep interface compatibility. Speaking of which,
how should properties behave in interfaces?
Re: Reddit: why aren't people using D?
Bill Baxter wrote: > Not a big issue, but introducing 3 keywords for this one > feature will be a tough sell. > --bb At least it's not 5 like vb.net, but that beast already has 150 keywords so I guess a couple more doesn't matter that much :)
Re: Reddit: why aren't people using D?
Walter Bright wrote: > Michiel Helvensteijn wrote: ... >> * No control over their use by class designer: ANY member function with >> one or zero parameters may be called using 'property syntax'. This is not >> a good thing. > > Why not? Seriously, what is the semantic difference? The major point about properties is imo not a semantic issue at all, it's about signalling the intention (much like the debug version statement is). This is also key to integration with tools like IDE and it's usefulness in gui programming.
Re: Reddit: why aren't people using D?
Eldar Insafutdinov wrote: > Ary Borenszweig Wrote: ... >> For instance properties seem to be a fundamental thing in Delphi and C#. >> When you are debugging and you watch some varaible, the debugger >> automatically allows you to expand a node and see the varaible's >> properties. You can't do that with D because any function that has zero >> parameters could be a property, even though some functions aren't >> properties. > > While working on QtD I have also come up with the conclusion that D needs > proper properties. Qt itself greatly relies on properties and it makes a > lot of cool things possible. Of course C++ doesn't support them, it is > done via Qt metatype system. When D goes popular, IDEs will severely lack > this functionality from the language. There have been a lot of discussions on this topic in the past but I can't recall any conclusions. Perhaps some brave soul would dare to write a DIP on properties?
Re: OS X Installer
Bill Baxter wrote:
> On Thu, Jul 23, 2009 at 12:09 PM, Lutger
> wrote:
>> Andrei Alexandrescu wrote:
>>
>>> Lutger wrote:
>>>> Jarrett Billingsley wrote:
>>>>
>>>>> On Thu, Jul 23, 2009 at 1:59 PM, Walter
>>>>> Bright wrote:
>>>>>> Michel Fortin wrote:
>>>>>>> If I'm not mistaken, both your D1 and D2 installer install at the
>>>>>>> same location and they will overwrite each other. I'd much prefer if
>>>>>>> D2 and D1 could coexist without having to go with a special
>>>>>>> installer or custom installation instructions. Otherwise it'll be
>>>>>>> hard for me to offer the choice between D1 and D2 in Xcode (and I
>>>>>>> certainly do want that choice to be available).
>>>>>>>
>>>>>>> Thoughts?
>>>>>> I've been switching the directories to {dmd, dmd2} so they can
>>>>>> coexist.
>>>>> Will you rename the DMD2 compiler to 'dmd2' as well?
>>>>
>>>> That would be very convenient, please consider this.
>>>>
>>>
>>> I think moving forward D2 will be the norm, so I suggest going with dmd1
>>> and dmd dir names and dmd1 and dmd binary names.
>>>
>>>
>>> Andrei
>>
>> Also fine, as long as they are different to ease more complex setups,
>> plus it will make it much more convenient to create linux packages for
>> this.
>
> Shouldn't the strategy taken be something more akin to what
> multi-version packages like python and perl already do?
> They don't just automatically rename old python to be
> python after every new version comes out.
>
> On windows they call it python.exe but put it in a different directory.
>
> On versions of linux I think there are some fancy schemes for setting
> up symlinks to particular versions to be the default. Can't recall
> what that system was called. "Defaults" or something like it.
> Anyway, seems like on linux dmd should work with that rather than just
> going and changing the names of exes according to whim.
>
> --bb
Yes, I admit this is the preferred and in the end only sane way of doing it.
(i have set it up like this come to think of it, don't know why). For people
for which there is no default because they do work with both it is less nice
though, imho.
Re: Reddit: why aren't people using D?
Walter Bright wrote:
> Knud Soerensen wrote:
...
>>
>> I think one of D's strongest points for people to make the switch is
>> build in unit testing. (at least this is the strongest point for me)
>> But the very simple implementation of unit testing in D nearly ruin the
>> advantage it gives. (see suggestion from the wishlist below)
>
> Even at its very simple support, it's a huge win. It raises the bar on
> what is minimally acceptable, and has been responsible for a big
> improvement in the quality of Phobos.
It's interesting why unittest (and assert) are such big success. My idea is
that it's not in spite of, but because of their utter simplicity. I
speculate that if it would have been different, for example if you would had
to create a new file for a unittest, it would not have been used so much.
...
>
>> ** Unit test isolation
>> I would like to be able to isolate the unit test,
>> so that if one fail the next still runs.
>
> You can do this by simply not using "assert" for the actual test. Use:
>if (!x) writeln("test for x failed");
> instead of:
>assert(x);
> You can, of course, make a template like Andrei's enforce() to make the
> if test and message a bit more convenient.
But within sight there is something much better. druntime defines a function
setAssertHandler to configure a user defined function for handling
assertions! Combine this with version(unittest) and the
Runtime.moduleUnitTester callback et voila!: profit*
I still see two major points of improvement:
- unittests are anonymous things. It would be a big improvement to be able
to say unittest("Test foobar") { } and retrieve the named test via the
runtime provided hooks
- all unittests from one module are lumped together in it's ModuleInfo
object. I would rather like to see an array of named unittests instead.
The rationale for these improvements is that the language and standard
library only defines very minimal, low impact ways of writing tests. At the
same time, the building blocks are provided to create more advanced tools.
This way you can also start out writing simple tests, and then not have to
rewrite those again when you want to use some fancy continuous integration
suite for D. At the moment, it's simply not possible to progress to more
elaborate testing without breaking everything and starting from scratch.
* Well I think so, I haven't been able to make use of it (segfaults) but it
would be sweet.
Re: OS X Installer
Andrei Alexandrescu wrote:
> Lutger wrote:
>> Jarrett Billingsley wrote:
>>
>>> On Thu, Jul 23, 2009 at 1:59 PM, Walter
>>> Bright wrote:
>>>> Michel Fortin wrote:
>>>>> If I'm not mistaken, both your D1 and D2 installer install at the same
>>>>> location and they will overwrite each other. I'd much prefer if D2 and
>>>>> D1 could coexist without having to go with a special installer or
>>>>> custom installation instructions. Otherwise it'll be hard for me to
>>>>> offer the choice between D1 and D2 in Xcode (and I certainly do want
>>>>> that choice to be available).
>>>>>
>>>>> Thoughts?
>>>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>>> Will you rename the DMD2 compiler to 'dmd2' as well?
>>
>> That would be very convenient, please consider this.
>>
>
> I think moving forward D2 will be the norm, so I suggest going with dmd1
> and dmd dir names and dmd1 and dmd binary names.
>
>
> Andrei
Also fine, as long as they are different to ease more complex setups, plus
it will make it much more convenient to create linux packages for this.
Re: OS X Installer
Jarrett Billingsley wrote:
> On Thu, Jul 23, 2009 at 1:59 PM, Walter
> Bright wrote:
>> Michel Fortin wrote:
>>>
>>> If I'm not mistaken, both your D1 and D2 installer install at the same
>>> location and they will overwrite each other. I'd much prefer if D2 and
>>> D1 could coexist without having to go with a special installer or custom
>>> installation instructions. Otherwise it'll be hard for me to offer the
>>> choice between D1 and D2 in Xcode (and I certainly do want that choice
>>> to be available).
>>>
>>> Thoughts?
>>
>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>
> Will you rename the DMD2 compiler to 'dmd2' as well?
That would be very convenient, please consider this.
Re: C faults, etc
Oh shit I forgot to redirect. That made my timings useless.
This one is about 8x faster than writefln, flushing seems to be quite
expensive:
const int N = 2_000_000;
for (int i; i < N; i++)
writef("test %d\n", i);
Re: C faults, etc
bearophile wrote:
> Daniel Keep:
>>Why on earth should the D compiler special-case a function that's not even
>>supposed to be used?!<
>
> What's the purpose of being able to use the C std lib in D programs if
> then such functions aren't supposed to be used?
>
>
>> Actually, let's check... (Goes off to test.)<
>
> This is a first little test, with DMD V.2.031, on Windows, Phobos2:
>
> import std.stdio: printf;
> void main() {
> const int N = 2_000_000;
> for (int i; i < N; i++)
> printf("test %d\n", i);
> }
>
>
> A second version that uses writefln:
>
> import std.stdio: writefln;
> void main() {
> const int N = 2_000_000;
> for (int i; i < N; i++)
> writefln("test %d", i);
> }
>
> I have redirected their output to a file (26.2 MB file).
> The timings are: 1.16 seconds for the version with printf, and 14.93
> seconds for the version with writefln.
>
writefln does a flush where writef doesn't. On my system (fedora 11) all
timings are nearly the same however, while writef is actually a bit faster
than printf. What OS are you on?
Re: Changes in the D2 design to help the GC?
I'm worried too about this, but haven't a clue as to what is needed to overcome the performance gap. I don't think extending the type system in a major way for some extra performance is worth it. Still, there may be some ways to make less drastic adjustments so that a (more) precise GC can be built. Or to put it another way: to not make a high performance GC for D impossible in the future.
Re: Conditional compilation inside asm and enum declarations
grauzone wrote: > Walter Bright wrote: >> Bill Baxter wrote: >>> On Tue, Jul 14, 2009 at 5:13 PM, Walter >>> Bright wrote: Why do C and C++ (and D) make it difficult to do: char *p; p |= 1; ? There's no implementation difficulty in accepting such and generating correct code for it. It's purely a matter of making what is generally considered to be bad practice harder to do. I've never heard anyone argue that this was a bad decision. >>> >>> I've never ever needed to do that, or been the slightest bit tempted >>> to. The operation doesn't make sense. So I think the analogy is >>> inappropos. > > Often I wanted to write p &= ~3 in low level code. And that does make > sense, because it aligns the pointer. > >> The #ifndef NO_DEBUGGING is awful. The #ifndef __GNUC__ means compile >> for every unknown compiler ever, except gcc. Can't possibly be right. > > The #ifndef NO_DEBUGGING causes the code to be compiled in debugging > mode, if it isn't explicitly deactivated. This is a good thing. I think > dmd should compile in debug mode too, and force the user to pass > -nodebug to disable it. So that reads as: if not not actived then if not defined no debugging then do stuff nice!
Re: Developing a plan for D2.0: Getting everything on the table
bearophile wrote: > Lutger: >>Can't nullable / non-nullable be done in library?< > > Yes, of course, people in the Scheme language have shown that you can do > almost everything in library code. But to do that you need (beside fixing > D library code, because the default now becomes non-null object > references) a "pluggable type system", that is you must be able to plug-in > a new piece of type system. > > You can do that with a meta (programmable) type-system like Haskell one, > or with some kind of true plug-in (think about the "neutral" > function/argument type annotations of Python3, that are a simple example > of machinery that can be used to plug-in a library defined type system). I > don't see both such things to be added to D2 anytime soon because they are > complex, quite more complex than nonnullable object references. > > So I'm looking for just the ""small"" change in the type system plus the > short leading "?" syntax. > > If D developers aren't interested in such thing, then a DEP can be written > and then marked as officially refused, to avoid wasting future time > discussing about this idea (this is another quite important purpose of > Python PEPs, to mark ideas as refused and avoid discussing something > hopeless over and over again). > > Bye, > bearophile Isn't .C#'s Nullable a library thing? (It's quite useful for database crap) I mean, it's not as ambitious as non-nullable by default, but couldn't we develop a Nullable and NonNullable template with the tools we have today in D? (I'm not sure). Would that be good enough?
Re: Developing a plan for D2.0: Getting everything on the table
bearophile wrote: > Andrei Alexandrescu: >> This is a great initiative. Let me add a few small points. >> [...] > > Please you or someone else add those points to this page, so they don't > get lost (I can't add them myself? It doesn't accept my name): > http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2 You can also > split that list in two parts, "core language" and "library". > > Another thing missing in that list is non-nullable classes/nullable: > http://delight.sourceforge.net/null.html > It's important for such list because it's a non backward-compatible > change, this means you can't add that to the language and keep > backward-compatibility too. If people what to add that, then it has to be > done before D2 comes out of alpha state. (Otherwise if D3 will want to > keep backward-compatibility to D2 then it will be not possible to be added > again). I think it's an important enough thing. > > Bye, > bearophile Can't nullable / non-nullable be done in library?
What will happen after D2?
Has it been planned how D will proceed after D2 is finalized? I'm curious to know whether the D designers intent to develop new features in a backwards-compatible manner (if possible) or that there will be a third branch. This is assuming that the language will not be considered finished of course when D2 final arrives...
Re: Compiler Page - Request for review
... > About GDC, iirc the latest (which is quite old) version can be used with a > version of D, although I don't remember which one. a version of *D2*
Re: Compiler Page - Request for review
Some comments:
dil is not yet able to compile D as far as I know, which is what the page
suggest ("There are a number of compilers that can be used for D")
The dmd table could suggest that it supports D2 with Tango, I recommend
formatting it like this:
language version D1.x D2.x
runtime libraryphobos, tango phobos
LDC comes with Tango by default, but I assume phobos or at least tangobos
can be used with it?
About GDC, iirc the latest (which is quite old) version can be used with a
version of D, although I don't remember which one.
Perhaps it would be useful to enumerate which OS and arch the various
compilers support?
Re: Patronizing Language Design?
Reminds me of this from Bartosz' site: "If you're a fan of object-oriented programming, you might find this quotation from the MFC's official Guidelines for Writing Class Library Extensions pretty amusing. Limit the Use of "Private" in Your Classes. It is important that your users be able to use your MFC-friendly classes in ways that you might not have originally intended. By keeping the majority of member functions, data members, and operators public, you allow for flexibility in their use. In MFC, even functions declared in the //Implementation section of a class are usually public or protected. " http://www.relisoft.com/resource/libs.html
Re: phobos unstable builds
Yes, interested.
Re: Oh Dear
Steve Teale wrote: > D Friends/Enemies, > > Looking at the current crop of postings, it seems like people are staying > off the subject of where D is going (we've had a lot of that lately, > without any result), and concentrating on less and less important > particulars. > > So we are we doomed, like the Oomigooly bird, to fly around in ever > decreasing circles, until we eventually disappear up our own asshole? > > As per the current fashion, I apologize profusely for any offense I may > cause to anyone as a result of this message. But we do need to arrive at > conclusions. D2 should be stabilized and D1 deprecated, there should be > one standard library, there should be a new linker and object file format, > and there should be a change made to the acceptable content of the primary > newsgroup (the learn suggestion is the best we have so far). > > Steve Again, what's up with the doom and gloom people? We just had a very good D release, lots of bugs fixed and some lovely new features. Happy days! You are not asking the right questions I think. There *is* 1 standard library for D2 which is phobos and could be complemented with Tango if it will be ported to D2. But D1 is stable where D2 is in development and Tango the library of choice for many. I see no problems here. D2 will be stabilized as planned, current date is set for november this year already! (Way too soon, probably). The question is, HOW will it be stabilized (D3 backwards compatible with D2?) But come on, take a look at the changelog for example to see how fast D is developing, which platforms DMD already support, look at LDC becoming awesome, Descent's power, full D support in slickedit, GtkD, QtD etc. etc. What exactly do you expect? Replacing C++/C# within the next year?
Re: Case Range Statement ..
Daniel Keep wrote: > > Valery wrote: >> I think that inclusive ranges more intuitive for beginner programmers >> because statements: >> >> case 1..10, >> array [1..10], >> foreach (int item; 1..10), >> foreach_reverse (int item; 1..10) (now foreach_reverse range is too >> dificult to understand it: item begins with 10 or 9, ends 1 or 2?) >> >> will not require an explanation of their actions. Thanks. > > I can say from personal experience that this is true. > > 1-based indexing is also easier for beginners. > > So are BASIC and LOGO. > > You may notice a trend here... :P > > Inclusive ranges are easier for naive programmers to grok, but are > fundamentally mismatched to programming. It's harder to split an > inclusive range, and it complicates the math. Just try writing anything > which involves manipulating ranges in Lua; it's considerably harder than > with exclusive ranges. > > The question is which you would rather: help naive programmers work > inefficiently or prevent competent programmers from working efficiently? > > I say screw the beginners; learning will do them good. Besides, when learning programming the concept of zero-based indexing and exclusive ranges is amongst the most trivial of concerns you need worry about these days.
Re: Can we fix reverse operator overloading (opSub_r et. al.)?
"Jérôme M. Berger" wrote:
(...)
>>
>> BLADE has already shown that it is possible to do stuff like this in a
>> library, but I think it goes without saying that if it was built into
>> the language the syntax could be made considerably nicer. Compare:
>>
>> auto m = MatrixOp!("a*A*B + b*C")(aVal, bVal, aMtrx, bMtrx, cMtrx);
>>
>> auto m = a*A*B + b*C;
>>
>> If D could do this, I think it would become the next FORTRAN. :)
>>
>> -Lars
>
> Actually, this has already been done in C++:
> http://flens.sourceforge.net/ It should be possible to port it to D...
>
> Jerome
Someone correct me if I'm wrong, but I think what Blade does is a bit more
advanced than FLENS. Blade performs optimizations on the AST level and
generates (near) optimal assembly at compile time. I couldn't find info on
what FLENS does exactly beyond inlining through template expressions, but
from the looks of it it doesn't do any of the AST level optimizations Blade
does. Anyone care to provide more info? Can Blade also generate better asm
than is possible with libraries such as FLENS?
Re: Have language researchers gotten it all wrong?
David B. Held wrote: > Derek Parnell wrote: >> [...] >> This I suspect is why dynamic typed languages are proving popular, >> because you can get a 99% correct program shipped without having to spend >> 200% of the money available. > > The main problem I see with dynamically typed languages is simply that > they are too concise. That is fine for small-scale development with > just one or two programmers on a team who own the software for its > entire lifetime. When it comes to enterprise software, the author might > own the code for less than 6 months before they move on to another team > or get reorganized into a different area. Not only that, the software > most likely has to interact with other software, and people on other > teams must then understand its interfaces. > > Because dynamic languages explicitly leave out the details from the > interface, you have to rely on the documentation that the original > author didn't write to figure out how to use that software. You also > have to rely on the tests they didn't write to verify that it works > correctly. Static typing doesn't fix any of this by itself, but it does > prevent the stupid-but-all-too-common errors where you call a function > with the wrong number of arguments, transpose some arguments, etc. It > also self-documents what is generally expected for each function in the > interface and what kinds of objects will get constructed and passed > around. Software written in dynamic languages won't scale without some more strict development process. Mandatory testing compensates for the lack of static typing and more. With testing you cover that part which the compiles does in static languages, but do it at runtime. > The more dynamic languages cater to large-scale development, the more > they begin to look like statically-typed languages. So the argument > that "it's faster to prototype with dynamic languages" is only relevant > for small-scale software, IMO. In every case I've seen where there is a > large system written in a dynamically typed language, I see a push by > the newer engineers to rewrite it in a statically typed language, for > all the reasons I stated above. > > The economics of large-scale software engineering are such that writing > the code constitutes only a small portion of the time creating the > software. All that "burden" of writing types and making sure they match > is very, very small compared to the additional safety they provide in an > environment that will eventually be full of bugs by the time it hits > production. I have participated briefly in one large project written in Ruby (on Rails). For every bit of code tests must be written. Code coverage verifies that 100% of code is covered by these tests. The writing of tests and creating fixtures were maybe half the work. When you'd check in code that breaks testing, you had to stay in until you fixed it. When you do have a runtime bug, it is much easier to debug a dynamic language than a static language. Dynamic languages don't do type checking at compile time, but they usually do way more of it at runtime. This is point often not mentioned by it's critics. I think productivity was much better than it would have been in a static language, but testing was essential and considered part of the code. One of the benefits of this kind of development is that it becomes very easy to refactor and adapt to new demands. > Of course, that implies that for tasks which do not require a lot of > engineering, it is entirely appropriate and even advantageous to use a > dynamic language. This tends to be utility/infrastructure coding to > automate things in 1,000 lines or less. Perl is great as long as the > user of the Perl script is a programmer. > > So I think the whiner in the original article is missing the point. > Dynamic languages are not, as far as I can tell, taking over the > world... They mostly take up a small-scale niche where they can press > their strengths. I would be very surprised to hear about a large-scale > project in Python/Ruby/etc. (100k+ lines). > > Dave A large scale project in Ruby/Python of 100K+ lines is equivalent to say 1000K+ lines of Java/C# code. I'm not saying dynamic languages do scale as good as static languages, but you have to take these two points into account: 1) development in these languages must have a different methodology and 2) it's not just writing less lines of code that makes it more productive.
Re: Give me a break
Tom S wrote: > Yigal Chripun wrote: (snip) >> IMHO, the Tango vs. Phobos licensing issue is the biggest bikeshed color >> problem in the D realm and the only people that can solve it are the >> tango devs and walter and co. of which Neither are willing to budge. > > Uhhh... try listening to Tango folks sometimes. They really have tried. > If you can forgive my ignorance, what is the current Tango/Phobos problem you see and refer to here? Is it related to D1 or also concerns a possible future Tango D2?
Re: At a crossroad
Ary Borenszweig wrote: ... > > Yes, two main-purpose libraries are indeed a problem. I thought druntime > was supposed to solve this, but if you are developing a library you'll > end up using one of the two, and then another library developed in the > other main-purpose library will not be compatible, unless you throw a > lot of version conditions all over the place. A real mess. :-P > > Why can't Tango be a library instead of a standard library? > > (I'm just saying Tango here because phobos was the original standard > library, it could be the other way around, but Tango seems also more of > a higher-level API.) People more involved with Tango should be better able to answer this, but I believe it's pretty simple to explain: Tango evolved out of Ares and Mango to offer an alternative to *both* the runtime and 'user-level' parts of Phobos. Back then, phobos was seen as not adequate for serious development, stale and hard to participate in. Obviously, a lot of people were motivated enough to develop in D as to embark on such a time-consuming project. Whether it could be called 'standard' or not is really not an interesting debate. The facts are: - it (claims to) solve various issues with phobos D1, including the runtime - is widely adopted and indeed the most successful D library ever - has an incompatible runtime with phobos D1 Now that D2 has druntime (essentially the Tango runtime) Tango can be made compatible again when it is eventually ported to D2. So druntime is still supposed to solve this issue, but only when Tango becomes D2. Another way of looking at it is that the Tango runtime part has already merged with phobos, thus solving some problems (at least the ones which the original Tango runtime was intended to solve). D is still in development because the authors have decided it was not nearly finished with D1. You can agree with that or not, fact is that D has taken that ambitious road. One of the consequences is the continued incompatibility between Phobos and Tango, but this is imho merely a reflection of the incompatibility between D1 and D2. Well that was a verbose way to say this topic is not so interesting anymore, at least until Tango is going D2. Now, who is going to write that linker? ;) (I can't, I'm not smart enough)
Re: Windows DMD installer
Vladimir Panteleev wrote: > As recently posted by WB, we should get a Windows installer project going. > I think we should first discuss what this installer would contain, which > installer framework to use, etc. > > In my opinion, the Windows installer's goal is somewhat different than a > Linux installer. I've heard many people say that they'd love a simple > installer that installs them everything including a build tool, IDE, > debugger, etc., so perhaps it should allow installing more than just the > barebones DMD. However, we don't want to include things that many people > won't use either. Therefore, I was thinking that the installer could > download and install components (libraries, text editors/IDEs or plugins > for them, build tools) from the web if the user ticks some corresponding > checkboxes. > > Further ideas: > * support Windows' "change" option in Add/Remove Programs to allow > removing, reinstalling and updating components > * when installing an editor, associate .d files with it > * adjust PATH to include DMD and any selected build tools > * adjust DMD search paths to point to any additional libraries (Tango, > DSSS etc.) > * DSSS "net install" integration? (show a checkbox list of libraries) ... Wouldn't it be sweet to go further and use dsss as that part of the installer which handles the libraries or more? There's probably a good bit of useful code in there, or even better dsss could be updated as required by the installer project. That will leverage dsss user base and revive dsss at once. Plus the way dsss works, it makes it easy to extend the list of components in the future.
Re: The proper case for D.
grauzone wrote: >> So the better direction according to some is to stagnate language design >> for D2 so Walter Bright can reinvent the linker? So that years later when >> asked > > No, but to use a real linker instead of that piece of crap. And this real linker is going to magically appear from nowhere? >> why D didn't do more for concurrency when it was needed, you'd have to >> reply: "well there wasn't any time to deal with such trivial issues, the >> language designer had to work on the toolchain." > > Eh, you seriously think D2 would still be in use at that time? We will > have D325858 which broke backwards compatibility for the 325858th time. > This issue (multithreading) seriously could wait a bit longer. The most > hilarious thing is that multithreading support in Phobos was incredibly > buggy, and even today, basic multithreading primitives like condition > variables are lacking from Phobos. Oh yeah, we got builtin mutexes so > that we can say "D supports multithreading on the language level". Funny. D1 is stable and actively supported. Tango has the functionality. LDC has the linker and work is being done that other OS. Now, what is problem? Really I don't understand. But ok, if you don't think of multithreading to be a big deal and find existing solutions perfectly adequate, generic programming a niche functionality and functional programming overrated, then the whole D2 deal certainly looks like a wasted effort better spend on writing a linker.
Re: The proper case for D.
grauzone wrote: >>> D2 is in danger of becoming a camel i.e. a horse designed by a >>> committee... >>> >>> Frank. >> >> ? >> >> As far as I know, the 'committee' consists of a gang of three, with >> Walter firmly at the driving seat, all working very hard to flesh out a >> language, create an innovative library and quality compiler. All the >> tools and libraries you mention are being created. In addition there's >> also LDC which is shaping up nicely. Not to say everything is already >> here, but that is a question of time and manpower, not direction. >> >> What's up with all the negativity lately? Impatience? > > Some people think D2 tries too much, and neglects the really important > things at the same time. For example, D2 tries to solve the concurrency > issue (which is a hot topic which makes D look good at sites like > stackoverflow), while still relying on a 20 years old linker written in > assembler. So the better direction according to some is to stagnate language design for D2 so Walter Bright can reinvent the linker? So that years later when asked why D didn't do more for concurrency when it was needed, you'd have to reply: "well there wasn't any time to deal with such trivial issues, the language designer had to work on the toolchain."
Re: Ranges
Yigal Chripun wrote: > Lutger wrote: >> Not sure what that would do, but C++ concepts are not exactly compile >> time interfaces. This is very important: in C++0X, a type T which >> satisfies the concept Comparable does not implement the concept >> explicitly, whereas languages with explicit constraints on generics do >> require T to be inherited from IComparable. The consequence is a bit of >> bloat and more rigid demands on what is supposed to relax the inflexible >> regime of the static type system. This bloat and rigidity is also a >> cognitive burden in it's own right, for example when it requires >> workarounds when the system is not expressive enough. > > regarding the consequences - i agree that this is a bit more rigid. I > don't see the bloat though. can you provide an example? can you also > explain what kinds of workarounds are you talking about that would be > required? Ok, I sort of assumed you talked about explicit instantiation like in C#. For any type that implements a clone operation for example, you have to derive it from ICloneable if you are to use it as a generic parameter. In addition, in your template, you have to explicitly bring all operations under in an interface. (This is the bloat part). Now say I have a type from another library that supports cloning, has the same interface as ICloneable, but doesn't derive from it. You are forced to create a wrapper for it that derives from ICloneable. (the workaround). Also, there is the complication of what to do with arithmetic types. >> >> Concepts provide two benefits in this context: documentation and extra >> type checking for templates. But they do retain structural typing. In D, >> we already have this covered with template constraints.* If you look at >> std.range, this is exactly what you see: all the interfaces (and even >> semantics) are nicely named and documented explicitly. So would we have >> had compile time interfaces, they would add next to nothing about the >> documentation or understanding of ranges. >> > > there are several problems with the template constraints currently used. > 1. the constraints are specified on the client code which means you need > to either duplicate those constraints everywhere or call some template > like isForwardRange manually to check that you got the correct type. Yes that is the way to go I believe. Phobos already defines a lot of these concepts so that makes it easier. > 2. The syntax for this is completely alien and unreadable, at least for > me. I agree, but this is a syntax detail. It has no bearing on the type system. > documentations and type-checking are indeed the two main benefits I'd > like to get. > the current way it is done with is() expression is unreadable. this > needs to be specified IMO with the same (or almost the same) syntax as > interfaces. I don't get why D needs two completely different syntaxes > for the same thing (specifying an interface). this will give us a more > readable documentation aspect. > the type-checking aspect of this is that the checks will be done on the > template definition instead of the instantiation in the client code > which will also prevent cases when bugs in a library template only > manifest when the client programmer compiles *his* code. this happened > to tango in the past. I agree. This is point where concepts in C++ may prove more powerful. >>> templates are hard for users to understand and one of the main reasons >>> for this is that templates are essentially a completely different >>> language with different syntax and semantics which to me looks like >>> mis-design. >> >> I don't think it is hard to understand because of structural typing. >> Generics are inherently somewhat difficult in a static typing language, >> because of it's abstract nature. You don't have this problem in dynamic >> languages. (or you can't escape it, depending on your POV) >> >> I don't agree that templates are a completely different language though. >> When used purely for parametric polymorphism, it does integrate nicely in >> the normal type system. When you do use it for meta-programming, which is >> relatively rare, then the above also applies: this is an inherently >> difficult way of programming. Just look at something like lisp where you >> can metaprogram in the same language. Does that make it easy to >> understand? Or CTFE and string mixins in D, same language, but it's also >> difficult. Adding more constraints can never solve the fact that humans >> don't easily grok programs which generate programs. >> > I was talking mostly about meta-pr
Re: The proper case for D.
Lutger wrote: ... > What's up with all the negativity lately? Impatience? Or is everybody drunk, am I missing a party?
Re: The proper case for D.
Frank Rundell wrote: > superdan Wrote: > >> Steve Teale Wrote: >> >> > Can this group come up with a proper, sober (OK, I'm not) >> >> den pretty please explain why anyone should give a flyin' fuck fer yer >> drunken rant. > > > And your response is why D is never going to be more than a beta compiler > and interesting discussion piece between a small number of programmers. > > If it wants to compete with the 'big boys' it needs an IDE, a GUI library > that can compile and work, a debugger that understands D, a proper linker, > packaged releases for linux, an installer for Windows, etc. > > D2 is in danger of becoming a camel i.e. a horse designed by a > committee... > > Frank. ? As far as I know, the 'committee' consists of a gang of three, with Walter firmly at the driving seat, all working very hard to flesh out a language, create an innovative library and quality compiler. All the tools and libraries you mention are being created. In addition there's also LDC which is shaping up nicely. Not to say everything is already here, but that is a question of time and manpower, not direction. What's up with all the negativity lately? Impatience?
Re: Ranges
Yigal Chripun wrote: > dsimcha wrote: >> == Quote from bearophile (bearophileh...@lycos.com)'s article >>> Yigal Chripun: point in case, look how much unnecessary confusion Ranges cause which would be eliminated had D allowed for compile-time interfaces. >>> What are interfaces from the point of view of the compiler? >> >> Abstract classes with only pure virtual functions. In other words, >> basically under the hood, an interface is just the layout of a vtable. > > That's run-time interfaces. compile-time interfaces are like C++ concepts. >> >> This actually leads to a comment I want to make in the wider debate: I >> personally find explicit interfaces really, really annoying and I think >> that duck typing is >> by far the most intuitive type system there is. I used to program >> primarily in >> duck typed languages and resort to every kludge imaginable for speed. >> What attracted me to D was that the templates and type inference are so >> powerful that I almost feel like it's still a duck typed language, but >> much faster and with more >> error checking. I guess that's why I like ranges so much. > > duck-typing has its benefits, that's for sure. it all boils down to is > style issues I guess - do you prefer implicit or explicit interfaces. > > either are fine by me, even though it seems to me that duck-typing is > more of a dynamically typed language feature but maybe my feeling here > is wrong. > either way, the language needs to be consistent about it in order to not > confuse users unnecessarily. It's called structural typing in static languages which is almost the same but not quite. In duck typing, you can pass an object which does not implement the 'required' interface and this is not checked until a missing method is actually called. Another way of looking at it is that the interface is determined by the path of execution, which is even more flexible than structural typing.
Re: Ranges
Yigal Chripun wrote:
> Lutger wrote:
>> Yigal Chripun wrote:
>> ...
>>> IMHO, duck-typing in D is a tragic mistake... This should have been
>>> implemented with compile time interfaces.
>>
>> Care to provide arguments?
>>
>>
>
> duck typing makes more sense in dynamic languages like Ruby which is
> famous for it.
>
> in static languages I as a user prefer to trade flexibility due to
> duck-typing for compile time checks.
>
> yes, at compile time, duck typing and (compile-time) interfaces are
> basically the same thing, but since the rest of the language uses formal
> interfaces, it is more consistent (and easier to understand) to use the
> same approach at compile-time as well. point in case, look how much
> unnecessary confusion Ranges cause which would be eliminated had D
> allowed for compile-time interfaces.
> i.e.
> Interface I { .. }
> struct S : I { ... }
> this is basically the same as C++ concepts only without redundant and
> confusing syntax.
Not sure what that would do, but C++ concepts are not exactly compile time
interfaces. This is very important: in C++0X, a type T which satisfies the
concept Comparable does not implement the concept explicitly, whereas
languages with explicit constraints on generics do require T to be inherited
from IComparable. The consequence is a bit of bloat and more rigid demands
on what is supposed to relax the inflexible regime of the static type
system. This bloat and rigidity is also a cognitive burden in it's own
right, for example when it requires workarounds when the system is not
expressive enough.
Concepts provide two benefits in this context: documentation and extra type
checking for templates. But they do retain structural typing. In D, we
already have this covered with template constraints.* If you look at
std.range, this is exactly what you see: all the interfaces (and even
semantics) are nicely named and documented explicitly. So would we have had
compile time interfaces, they would add next to nothing about the
documentation or understanding of ranges.
> templates are hard for users to understand and one of the main reasons
> for this is that templates are essentially a completely different
> language with different syntax and semantics which to me looks like
> mis-design.
I don't think it is hard to understand because of structural typing.
Generics are inherently somewhat difficult in a static typing language,
because of it's abstract nature. You don't have this problem in dynamic
languages. (or you can't escape it, depending on your POV)
I don't agree that templates are a completely different language though.
When used purely for parametric polymorphism, it does integrate nicely in
the normal type system. When you do use it for meta-programming, which is
relatively rare, then the above also applies: this is an inherently
difficult way of programming. Just look at something like lisp where you can
metaprogram in the same language. Does that make it easy to understand? Or
CTFE and string mixins in D, same language, but it's also difficult. Adding
more constraints can never solve the fact that humans don't easily grok
programs which generate programs.
* I don't think the extra type checking is done, but perhaps it could be.
Re: Ranges
superdan wrote: > Lutger Wrote: > >> Yigal Chripun wrote: >> ... >> > >> > IMHO, duck-typing in D is a tragic mistake... This should have been >> > implemented with compile time interfaces. >> >> Care to provide arguments? > > ignorance 'n' arrogance should do. Those I hold I high esteem, you convinced me.
Re: Ranges
Yigal Chripun wrote: ... > > IMHO, duck-typing in D is a tragic mistake... This should have been > implemented with compile time interfaces. Care to provide arguments?
Re: Ranges
Steve Teale wrote: ... > Robert Fraser Wrote: >> As others have mentioned, it's just a struct (or other type) that >> happens to support certain operations. > > So does this mean that interfaces are just a tragic mistake. I'd always > thought that what you said was a pretty good description of what an > interface is! Could you explain why that makes interfaces a mistake? Interfaces (as in classes implementing an interface) do provide dynamic polymorphism which these compile time constraints (or 'concepts' in STL terms) don't.
Re: Andrei writes "The Case for D"
Andrei Alexandrescu wrote: ... > Speaking of reddit, I noticed there are forty-something negative votes > but only one negative comment. From direct experience (sigh) I know that > people who think an article sucks usually are also very inclined to > voice their opinion (even more so than people who think an article was > good!) There must be a study in behavioral psych somewhere. So these > votes seem to reflect a prior dislike to anything D and the immediate > negative voting of anything related to it. I wonder how such this could > be addressed. > > > Andrei. Somebody at work put up a poster, I believe it was from Red Hat linux, with a famous Gandhi quote: "first they ignore you, then they fight you, then you win..." Probably normal part of the process, I think it's best to avoid being defensive and continue business as usual :) I *really* liked your article, it's nice to read such an well written piece with unreserved enthousiasm and passion about D.
Re: OT: on IDEs and code writing on steroids
Yigal Chripun wrote: ... >> > this I completely disagree with. those are the same faulty reasons I > already answered. > an IDE does _not_ create bad programmers, and does _not_ encourage bad > code. it does encourage descriptive names which is a _good_ thing. > > writing "strcpy" ala C style is cryptic and *wrong*. code is read > hundred times more than it's written and a better name would be for > instance - "stringCopy". > it's common nowadays to have tera-byte sized HDD so why people try to > save a few bytes from their source while sacrificing readability? ... This is not what I was saying. I'm not talking about strcpy vs stringCopy. stringCopy is short. I'm talking about things like SetCompatibleTextRenderingDefault. And this example isn't even so bad. Fact is, it is easier to come up with long identifiers and there is no penalty in the form of typing cost for doing so. It's not about bad programmers (or saving bytes, that's just ridiculous), but IDE does encourage some kind of constructs because they are easier in that environment. Good programmers come up with good, descriptive names, whether they program in an IDE or not. At work I must program in VB.NET. This language is pretty verbose in describing even the most common things. It's easier to parse when you're new to the language, but after a while I find all the verbosity gets in the way of readability.
Re: "with" still sucks + removing features + adding features
Andrei Alexandrescu wrote: ... > > So we're looking at a number of problems here. One is that we'd need to > change the language in several places to accommodate an ill-conceived > feature. Another is that I can't seem to get some very simple points > across such as the difference between a token and a non-terminal, in > spite of having tried repeatedly and in various forms. Another is that I > am becoming suffocated with self-righteousness and therefore am losing > goodwill in this thread at an exponentially-increasing rate. Finally, it > looks like such discussions necessitate more than a full-time job. > > > Andrei You could ask Walter for advice on most of these matters ;)
Re: OT: on IDEs and code writing on steroids
Andrei Alexandrescu wrote: ... > I've repeatedly failed to figure out the coolness of C#, and would > appreciate a few pointers. Or references. Or delegates :o). It's not in the language. C# only has to do 'better' than C++ and Java to be cool and in that it succeeds: Besides many smaller improvements, it provides delegates / events, lambda's and true generics compared to java. Compared to C++ it provides, well, lots of the same stuff that make people prefer Java over C++. It does this while still being familiar. Take F# for example, probably a much cooler language: I suspect this is too alien for most people. The real attraction of C# is the framework and the IDE. A lot of programmers don't program in a language, but in an ecosystem where the language is just a part of it alongside the framework, toolchain and documentation.
Re: OT: on IDEs and code writing on steroids
Andrei Alexandrescu wrote: ... >> What the heck do you need generics for when you have real templates? To me, >> generics seem like just a lame excuse for templates. > > I agree. Then, templates aren't easy to implement and they were > understandably already busy implementing the using statement. > > Andrei While I don't fully understand how generics work under the hood in .NET, there are some benefits to how it is done. For example, you can use runtime reflection on generic types. And the jit compiler instantiates them at runtime. They may serve a different purpose than templates: "Anders Hejlsberg: To me the best way to understand the distinction between C# generics and C++ templates is this: C# generics are really just like classes, except they have a type parameter. C++ templates are really just like macros, except they look like classes." It seems that lack of structural typing is seen as a feature: "When you think about it, constraints are a pattern matching mechanism. You want to be able to say, "This type parameter must have a constructor that takes two arguments, implement operator+, have this static method, has these two instance methods, etc." The question is, how complicated do you want this pattern matching mechanism to be? There's a whole continuum from nothing to grand pattern matching. We think it's too little to say nothing, and the grand pattern matching becomes very complicated, so we're in- between." From: http://www.artima.com/intv/genericsP.html
Re: Bit fields in struct, why doesn't D support them?
Jeremie Pelletier wrote: > I know this is an old subject, as this has been stated in the struct > reference page ever since D1, but I'm really wondering why the bit fields > aren't supported (or purposely not implemented?) in D. > > Having this feature would greatly simplify a lot of code, and allow easier > interfacing with C structs using it. In D2 it is supported by phobos: http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html
Re: OT: on IDEs and code writing on steroids
BCS wrote: ... > > all LINQ is is a set of standard nameing conventions and sugar. I Add a > "Where" > function to some SQL tabel object and you get the above as well. > ... Not really, LINQ is 'sugar' for the underlying libraries that implements querying. Instead of calling it just sugar, it is more proper to call it a language in it's own right. LINQ to SQL is just one thing, the power of LINQ is that you separate queries from source of data. You can write one query (ideally) that works with SQL, XML or plain Arrays. It's not only that you don't have to write SQL queries anymore, a lot of messy for/while/etc. loops can be totally replaced with LINQ queries too.
Re: OT: on IDEs and code writing on steroids
Yigal Chripun wrote: ... > IMO, designing the language to support this better work-flow is a good > decision made by MS, and D should follow it instead of trying to get > away without an IDE. I'm not sure about this. D is designed to be easier to parse than C++ (but that's saying nothing) to allow better tools made for it. I think this should be enough. C# & friends not only better supports working inside an IDE, but makes it a pain to do without. Autocomplete dictates that related functions should be named with the exact same prefix - even when this isn't logical. It also encourages names to be as descriptive as possible, in practice leading to a part of the api docs encoded in the function name. Extremely bloated names are the consequence of this. It doesn't always make code more readable imho. The documentation comments are in xml: pure insanity. I tried to generate documentation for my stuff at work once, expecting to be done in max 5 min. like ddoc. Turns out nobody at work uses documentation generation for a reason: it isn't really fleshed out and one-click from the IDE, in fact it is a pain in the arse compared to using ddoc. I should stop now before this turns into a rant.
Re: Please Vote: Exercises in TDPL?
Anders F Björklund wrote: ... > So, would there be any such libraries available for D2/Phobos ? > Or maybe that can't be until the spec (or the book) is out... > > --anders GtkD works with D2
Re: Please Vote: Exercises in TDPL?
Brad Roberts wrote: > BCS wrote: >> Hello Nick, >> >>> (and double the >>> price (or more) from what would typically be reasonable) >> >> I have been told (without supporting evidence) that the price of text >> books is so high because about 10 times as many are printed as sold. >> This is because they don't have time between when they know what they >> need and when they need it, to print what they need. The other 90% of >> the books you end up paying for get pulped. (That and the fact most >> profs never worry about what a book costs when they spend your money) > > The cost of printing, shipping, etc.. on a per-book basis is actually very > very > low. In the neighborhood of a few dollars. No where near the around $100 > that > a lot of textbooks sell for. One of the reasons they cost so much is that > many > of them are rev'ed every couple years, meaning that they have to make whatever > profit they want to make _fast_. They're rev'ed so fast at least in part to > kill off the used market. > > There's also an awful lot of effort that goes into producing them. Authors, > Editors, fact checking, copy setting, etc. > > Anyway, it's an ugly cycle that's bound to implode eventually. > > Later, > Brad Another contributing factor is that experts typically not want to write textbooks (boring), so they get paid very well to do it.
Re: Please Vote: Exercises in TDPL?
Sean Kelly wrote: > I never bother to solve the exercises either, but then I've read most > tech books on my own time. I think if you're hoping this might be used > in an academic setting at some point (and I have no idea what the > requirements are for that) then it would be good to have exercises. By > the way, does TCPL have them? I'm pretty sure TC++PL doesn't. That's a good point, it will be helpful for courses. (but not a requirement) TC++PL does have exercises - at least the 3rd edition does, although they are not so prominent. I like to use exercises as review questions or summary, looking at them helps to get a feel for how much you've understood. Also, fun or really good exercises I will take, like the ones in SICP.
Re: std.string and std.algorithm: what to do?
Michiel Helvensteijn wrote: > dsimcha wrote: > >>> Hm.. I suppose a project could import any Boolean combination of tags: >>> import algorithm & string; >>> import algorithm | string; >>> import algorithm & !string; >> >> This seems like overkill. Module/package/import/whatever management >> should not require a Ph.D. in Boolean logic. It should be dead simple >> (i.e. like the current system is, esp. after 314 gets fixed) and allow >> people to get on with solving real problems. > > Hey, just because the system is available, doesn't mean that every > programmer should use it. For most people, imports would become even > simpler than they are now: > > import string; > > would import every symbol with the `string' tag. If you only want the > std.string functions, > > import std & string; > > or even > > import std.string; > > would do. And no one would notice the difference, except those Boolean PhD > types who want to use the system to its fullest. ;-) > > Mostly it would make life easier for the library writers. Is > std.string.find() a string function xor an algorithm? Nope. It's both. > It has it's advantages, but misses the simplicity of matching symbols to the filesystem. You will also become more and more reliant on (specialized) tools with these kinds of systems, like .NET.
Re: Fun with allMembers
Andrei Alexandrescu wrote:
> Shin Fujishiro wrote:
>> Hi,
>>
>> I've had fun with the allMembers traits over the past few days and found
>> it more powerful than I thought.
>>
>> __traits(allMembers, T) returns the member names of T. As some might
>> already know, T is not restricted to a class or struct; it can also be
>> an enum, template, or even module. Try this:
>>
>> enum E { a, b, c }
>> template T() { int x, y, z; }
>> import std.stdio;
>> pragma(msg, __traits(allMembers, E).stringof);
>> pragma(msg, __traits(allMembers, T).stringof);
>> pragma(msg, __traits(allMembers, std.stdio).stringof);
>>
>> You'll like the result :). It must be usable!
>>
>> For example, using allMembers with enums, I could implement
>> enumToString and enumFromString without defineEnum.
>> Code: http://codepad.org/HVvPjoI7
>>
>> So, what other uses could there be?
>
> Wow, I didn't know about this! It might as well be everything needed for
> a full-blown compile-time reflection package!
>
> To answer your question: for starters, try to implement BlackHole and
> WhiteHole as explained here:
>
> http://erdani.dreamhosters.com/cranking-policies-up.pdf
>
>
> Andrei
See also this article from the author of PyD:
http://kirkmcdonald.blogspot.com/2007/07/inadequacies-of-traits.html
(Not that it isn't very powerful as is.)
Re: std.partition is fucked
Sean Kelly wrote: > == Quote from Lutger (lutger.blijdest...@gmail.com)'s article >> >> Some time ago I reinvented these wheels for study purpose. A custom stack >> was a little faster but not > that much. std.swap can't be inlined because it uses ref params, that cost > also a bit since it's called >> many times. Switching to another sort if a certain recursion depth is >> reached helped, but mostly in > degenerate cases. >> I still have the thing somewhere, it is about twice as fast as builtin sort. >> It's not a lot of work but I could > dig it up and provide some timings if you want. > > The sort I wrote for Tango uses the same basic heuristics, thanks to > a ticket that either you or Stewart Gordon submitted long ago. I've > been meaning to compare it against the sort routine in std.algorithm > to see whether the Phobos routine could benefit from any of the same > tweaks. It wasn't me, I used the Tango code as one the sources to study this algorithm :)
Re: std.partition is fucked
fwiw, I found the code and attached it with a benchmark found in the bugreport
(2966). It works only on arrays, might be buggy too. But it does sort ;)
Timings based on 1000_000 elements:
std.algorithm: 624 // modified with the fix posted in this thread
Builtin sort: 540
iterative introsort: 244
module introsort;
import std.functional;
import std.stdio;
import std.c.string;
import std.math;
import std.conv;
import std.perf;
import std.random;
import std.algorithm;
void main() {
enum N = 1000_000;
uint[] foo = new uint[N];
foreach(ref elem; foo) {
elem = uniform(0U, 4_000_000_000U);
}
auto bar = foo.dup;
scope pc = new PerformanceCounter;
pc.start;
std.algorithm.sort(bar);
pc.stop;
writeln("std.algorithm: ", pc.milliseconds);
bar[] = foo[];
pc.start;
bar.sort; // Builtin.
pc.stop;
writeln("Builtin sort: ", pc.milliseconds);
bar[] = foo[];
pc.start;
introsort(bar);
pc.stop;
writeln("iterative introsort: ", pc.milliseconds);
}
/** assumes partion is located at array[$-1] */
size_t partition(T)(T[] array)
{
size_t front = 0;
foreach( i; 0 .. array.length - 1)
{
if(array[i] < array[$-1]) // if value < pivot
{
ptrSwap(&array[front], &array[i]); // move value to the front
front++;
}
}
ptrSwap( &array[front], &array[$-1] ); // move pivot back to the front
return front; // return new position of pivot
}
/** select pivot and move it to a[$-1 ]*/
void shiftPivot(T)(T[] a)
{
size_t r = a.length - 1;
size_t m = r / 2;
if(a[0] < a[m])
{
if(a[m] < a[r])
ptrSwap(&a[m], &a[r]);
else
{
if (a[r] < a[0])
{
ptrSwap(&a[0], &a[r]);
}
}
}
else
{
if( a[0] < a[r] )
ptrSwap(&a[0], &a[r]);
else
if (a[r] < a[m])
ptrSwap(&a[m], &a[r]);
}
}
unittest
{
assert( [1,2,3].selectPivot() == 1 );
assert( [1,3,2].selectPivot() == 2 );
assert( [2,1,3].selectPivot() == 0 );
}
private enum QSORT_MIN_SIZE = 20;
private enum MAX_STACK_SIZE = 80;
T[] insertionSortInplace ( alias less = "a < b", T ) ( T[] array )
{
alias binaryFun!(less) cmp;
for ( int current = 1; current < array.length; ++current )
{
auto value = array[current];
auto insertPos = current - 1;
while ( insertPos >= 0 && !cmp( array[insertPos], array[current]) )
insertPos--;
array[insertPos + 1 .. current].move_to( array[insertPos + 2 .. current + 1] );
array[insertPos + 1] = value;
}
return array;
}
auto introsort(T)(T[] collection)
{
// determine max size of stack as function of collection size + constant
size_t maxDepth = to!size_t( std.math.log2( collection.length ) + 10 );
maxDepth = maxDepth > MAX_STACK_SIZE ? MAX_STACK_SIZE : maxDepth;
size_t stackLength = ( maxDepth + 1 ) * 2 * size_t.sizeof;
T[]* stack;
stack = cast( T[]* )std.c.stdlib.alloca( stackLength );
stack[0] = collection;
size_t p = 0;
size_t i = 1;
while( i > 0 )
{
auto current = stack[--i];
if(current.length < QSORT_MIN_SIZE)
{
insertionSortInplace(current);
}
else if( i >= maxDepth )
{
insertionSortInplace(current);
}
else
{
current.shiftPivot();
p = 0;
foreach( j; 0 .. current.length - 1)
{
if(current[j] < current[$-1])
{
ptrSwap(¤t[p], ¤t[j]);
p++;
}
}
ptrSwap( ¤t[p], ¤t[$-1] );
stack[i++] = current[0..p];
stack[i++] = current[p+1..$];
}
}
return collection;
}
auto move_to(T)(const T[] src, T[] dest)
in
{
assert(src.length >= dest.length, "can't do that!");
}
body
{
memmove(dest[].ptr, src.ptr, dest.length * T.sizeof);
return dest;
}
void ptrSwap(T)(T a, T b)
{
typeof(*T) tmp;
tmp = *a;
*a = *b;
*b = tmp;
}
Re: std.partition is fucked
Andrei Alexandrescu wrote: > Sean Kelly wrote: >> Andrei Alexandrescu wrote: >>> >>> The performance of std.sort is back to normal - still slower than the >>> built-in sort (but not by orders of magnitude), probably because >>> bumping ranges is at a disadvantage. >> >> The built-in sort uses an internal stack rather than recursion, which >> makes its performance on a best-case dataset hard to beat. I finally >> satisfied myself by having a constant time overhead vs. the built-in >> sort for best-case and beat it by polynomial time for worst-case (the >> built-in sort doesn't adapt to worst-case datasets very well). > > Yeah, I saw that fixed-size stack. I'm not sure whether that's > responsible for much of its performance, one of these days I need to > measure. My speculation is that the depth of the stack is small enough > to not really contribute much to the running time. > > Andrei Some time ago I reinvented these wheels for study purpose. A custom stack was a little faster but not that much. std.swap can't be inlined because it uses ref params, that cost also a bit since it's called many times. Switching to another sort if a certain recursion depth is reached helped, but mostly in degenerate cases. I still have the thing somewhere, it is about twice as fast as builtin sort. It's not a lot of work but I could dig it up and provide some timings if you want.
Re: Real Close to the Machine: Floating Point in D
At www.digitalmars.com/d it's not listed in the articles section.
Re: Iterators Must Go
Congratulations, glad to hear it was so well received. These are very inspiring slides, helped me to understand the benefits of ranges much better. You are a very good writer, looking forward to read more of your publications on D.
Re: What's the current state of D?
Simen Kjaeraas wrote: > Lutger wrote: > >> - these other languages go out of their way to make new releases >> backwards >> compatible, sometimes at great costs. They almost never completely >> succeed >> though. > > And D1 makes an effort to follow the spec, and will not incorporate > breaking changes. D2 is, in many ways, a whole new language. Sure, > you could argue that D1 code should be compilable in D2, but it > would matter no more than the argument that C code should be > compilable in D1. > > -- > Simen I'm certainly not making that argument. In the talk Andrei and Walter gave at the D conference they mentioned the design goal 'no issue left behind' This is what makes D evolution so much more interesting. Yet it has a price. Looking at C# for comparison, it is about the same age (C is not fair, too old): you can easily upgrade from 2.0 to 3.5 and beyond. Most important part of that ease is the ability to use older libraries in a newer environment. Still, lots of issues in C# are already beyond fixing.
Re: What's the current state of D?
Walter Bright wrote: > grauzone wrote: >> But C++ programs still compile and run correctly with C++0x compilers. > > True enough, but that wasn't true for C++98, or C89. Nobody refused to > use C or C++ because of that. > >> I bet none of the projects on dsource are even compilable with dmd2 (even >> if they were written for D2.0). > > Take any C++ project from 15 years ago and I bet it won't compile today, > either. > >> And _many_ projects probably need minor >> fixes, before they compile with the latest dmd1 compiler. > > Nearly all of those are due to inadvertent reliance on bugs in D1. You > see this quite a bit in the C++ world. Every time g++ gets updated, I > have to tweak something in my sources. > > Every binary release of dmd is available for download. If you require an > unchanging compiler, it's trivial to operate that way. dmd isn't going > to auto-update itself and break your compiles. That's a really good thing imho. I remember when I got the Civilization 4 C++ SDK, it would only compile with the MS 2003 compiler. Which at the time was outdated and unavailable for download in a legal way. It was also 130K LoC and beyond my ability to fix of course, very frustrating.
Re: What's the current state of D?
Walter Bright wrote: > Steve Teale wrote: >> This is the sort of answer that will kill D. The guy comes back after >> 2 years, asks a straight question, and get's told "business as usual, >> we're still arguing among ourselves about what it should be". >> >> Maybe Tiobe is right! Lots of others may not even bother to ask. They >> just visit the newsgroup, read a page of it, and conclude "same old, >> same old", and go away. >> >> D should be D, not maybe 1.043, or let's wait a while and see what >> happens with D2. Potential real users hate uncertainty. If they are >> going to commit, then D must do so too. > > What bothers me about this sentiment is that every other mainstream > language undergoes revision, sometimes major ones, but that never seems > to be an excuse for people to not use it. > > For example, C++ is quite in flux with C++0x. > > The only languages that are not undergoing revision are dead ones. There are some differences though: - other mainstream languages release new compilers and features every couple of years, you do so every couple of months! - these other languages go out of their way to make new releases backwards compatible, sometimes at great costs. They almost never completely succeed though. To be clear, I do think these are good things for D evolution, but most people are wary to invest energy in change. Reflecting back on the commitment to D1, I think this was a good move in two ways: it allowed larger programs and libraries to rely on it and may have freed the way for D2 to incorporate bolder changes.
Re: when will D2 be stable?
zsxxsz wrote: > I found D is a wonderful programming language and start to use it in my > projects. I use D2 now, but which is still unstable although it's version > is D2.029. Can anyone tell me when D2 will be stable? Although D's using > rate suffers sharp fall(shown in tiobe), I'll still believe that D will be > better in future. But why does D fall down so much? > > Thanks Tiobe is like the astrology weekly news snippets: you know it's bullshit but you can't resist wanting to believe - until it brings bad news of course ;)
Re: I wish I could use D for everything
Steve Teale wrote: ... > Sadly, in the absence of decent development tools for D, many of us depend on a plain old editor, and writefln() for debugging. I notice that in Phobos, Walter tends to prefer printf(...) - go figure! I'm quite sure Walter does not prefer printf. He uses it to not depend on a working phobos for 'printf' debugging.
Re: Splitter quiz / survey
eh, x = a and x = b
Re: Comparison chart worries
Vincenzo Romano wrote: ... > It's 2009Q2 now. > The comparison is still not a comparison at all by just showing the D features. > If you want to attract more programmers to D you need to show HIGH QUALITY code (snippets) in, say, > D, C++, Java ... you choose. > You need to show the value. Did you not find them? Throughout the articles on digitalmars.com/d, in the spec and phobos library documentation you find lot's of examples and illustrations.
Re: temporary objects are not allowed to be pass by ref anymore
Andrei Alexandrescu wrote: ... > Now onto why ref was disallowed to bind to an rvalue. This is because > some functions take things by ref intending to change them. Passing an > rvalue is in such cases a bug. > > I agree there are functions that only want to use ref for speed > purposes. I suggested Walter to use ref? for those. ref? means it could > be an rvalue or an lvalue. > > > Andrei Since passing by const ref cannot change the parameter, is it possible to allow that for rvalues?
Re: The new, new phobos sneak preview
Jason House wrote: ... > There's no need for imported names to be unambiguous. Users can give aliases to imports or import specific members. I hate how Tango puts stuff in structs for no good reason I agree. It's not that hard to alias / static import. It may just be a matter of preference, but more verbose declarations do not tend to be more readable imho. You have import std.range and the one hand and on the other (the parameter) you are also operating on a range, what more information would one need? If isInfinity would be a member of the range, then even in Java one would not think of writing such constructs: std.range.Range.isInfinityRange()
Re: Multithreaded I/O in the DMD compiler (DDJ article by Walter)
Steven Schveighoffer wrote: > On Tue, 07 Apr 2009 13:56:34 -0400, grauzone wrote: > >>> only thing it lacks is iTunes (yeah, screw you, I like iTunes :) and it >> >> There are lots of iTunes clones. Maybe you should try to get used to one >> of them? > > I'm sorry, but I'm ignorant of such issues. Do they allow downloading > music from iTunes, and syncing with an iPod? > > -Steve Amarok is the big one, it does have ipod support of sorts but I wouldn't know what that means exactly. What's really awesome though is that it has wikipedia support ;)
