Re: Code Poet, an IDE for D
Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Here is the (very simple) website of the project, with a screenshot of the program so far, the content is hard coded for now to test the custom editor painting routines. http://codepoet.sourceforge.net Jeremie Though I don't use an IDE myself, I think this is great. It is often mentioned on the NG that one of the things keeping people away from D is the fact that there are so few IDEs with good D support. Are you strictly targeting Windows, or will this be available for other platforms as well? -Lars
Re: Metaprogramming in D : Some Real-world Examples
Andrei Alexandrescu wrote:
grauzone wrote:
Lars T. Kyllingstad wrote:
Jacob Carlborg wrote:
On 11/10/09 01:27, Bill Baxter wrote:
On Mon, Nov 9, 2009 at 4:09 PM, Walter Bright
newshou...@digitalmars.com wrote:
Looks like Bill Baxter is giving a presentation on D Nov. 18!
http://www.nwcpp.org/
Yep, that's right, and I'd be quite grateful to you smart folks here
if you could share your meta-programming favorites with me! If
you've got a real-world example of meta-programming in D that you
think is particularly handy, then please send it my way
I'm looking for small-but-useful things that are easy to explain, and
make something easier than it would be otherwise. Things like places
where static if can save your butt, or loop unrolling, and passing
code snippets to functions like in std.algorithm.
Things like a compile-time raytracer or regexp parser (though quite
cool!) are not what I'm after. Too involved for a short talk.
--bb
This is invaluable to me, which makes it possible to do some form of
duck typing at compile time:
static if (is(typeof({
/* does this compile */
})))
There are forces at work (Don, that is) attempting to get rid of that
very construct and replace it with something better:
http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html
In my humble opinion, is(typeof({...})) is an ugly creature. I really
don't think it should be put under a spotlight as a good example of D
metaprogramming. If anything, please use __traits(compiles, {...})
instead.
Who cares about ugly syntax, if the idea is bad in the first place?
I think testing types during compilation isn't bad. Under what
circumstances is it?
You're not testing for types, you're testing if it compiles. Inside the
tested block of code, all sorts of things could go wrong. You can't know
if is(typeof(...)) really did what you wanted, or if something broke. At
least when you're doing more complex stuff with is(typeof), the danger
of silent failures increases. Suppose the user makes an error in his
custom range type by specifying a wrong return type (or whatever), and
the range library just ignores his range-related function. Maybe that
range function was optional, which will end in the range library
seemingly ignoring his function. Can this be good? (I don't know if that
case I described can even happen in your ranges lib, but I think this is
a typical failure that could happen with is(typeof).)
This isn't even compiletime duck typing anymore, it's try-and-error
built into the compiler. Even worse, now having semantically incorrect
code in D sources is perfectly fine for weird reasons, and the compiler
has to swallow some kinds of semantics errors.
Really, wouldn't some mechanism to explicitly check for compile time
contracts better?
For me, this is some sort of metaprogramming WTF. This all makes me
cringe. Sorry about that.
Andrei
Re: Code Poet, an IDE for D
Jeremie Pelletier wrote: Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. ... Jumping back in C++ was refreshing, I now make very little use of macros, feel much more comfortable with templates and generic programming, basically I write C++ as if I was writing D, and it only makes me love the little conveniences of D even more. The IDE will also be cross-platform, I'm using wxWidgets for all the user interface and boost for everything else. Sounds like a good approach for a new fresh DMD2 IDE, the oldskool stuff with GDC and wxD and Code::Blocks is not very likely to make it there... I think Walter writes DMD the same way (D in C++) and Andrei is a fan of Boost, so I don't think you can go wrong there... Hope it gets released! --anders
Re: Code Poet, an IDE for D
Lars T. Kyllingstad wrote: Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Here is the (very simple) website of the project, with a screenshot of the program so far, the content is hard coded for now to test the custom editor painting routines. http://codepoet.sourceforge.net Jeremie Though I don't use an IDE myself, I think this is great. It is often mentioned on the NG that one of the things keeping people away from D is the fact that there are so few IDEs with good D support. Are you strictly targeting Windows, or will this be available for other platforms as well? Forget it, I see you've already answered this in another post. :) -Lars
Re: Metaprogramming in D : Some Real-world Examples
Christopher Wright wrote: grauzone wrote: You're not testing for types, you're testing if it compiles. Inside the tested block of code, all sorts of things could go wrong. You can't know if is(typeof(...)) really did what you wanted, or if something broke. You're testing, is everything inside that OK?. If you want to know WHY it's wrong, you'd better make sure you're testing something simple. So it requires caution, and you want to keep the contents small. It's useful, but it requires caution. I don't even think it particularly requires caution. If it passes, you know everything is OK. It's just that it's an all-or-nothing test. IMHO, one of the best features of it, is that you can have negative compile-time unit tests. You can create tests which must be rejected at compile time. I don't know of any other clean way to do that.
Re: Code Poet, an IDE for D
On Wed, 11 Nov 2009 17:15:09 +0300, Jeremie Pelletier jerem...@gmail.com wrote: Denis Koroskin wrote: On Wed, 11 Nov 2009 06:22:42 +0300, Jeremie Pelletier jerem...@gmail.com wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell Try to integrate C++ DMD front-end into your IDE, and it will leak a lot more. If I detect any leaks with DMD I'll just make it use boost's shared_ptr, then bye bye leaks! It's just DMD never ever deletes anything (but duplicates instances a lot!). You'll have to wrap everything with smart pointers. The debug runtime library that comes with visual studio already detects memory leaks and allows me to put breakpoints on them to see the call stack and local variable values of the leaked allocation. Its pretty easy to keep memory leaks around none with that, even if C++ requires more careful programming than D does, more destructor work than D also. Jeremie Good luck with that!
Re: Code Poet, an IDE for D
Denis Koroskin wrote: On Wed, 11 Nov 2009 06:22:42 +0300, Jeremie Pelletier jerem...@gmail.com wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell Try to integrate C++ DMD front-end into your IDE, and it will leak a lot more. If I detect any leaks with DMD I'll just make it use boost's shared_ptr, then bye bye leaks! The debug runtime library that comes with visual studio already detects memory leaks and allows me to put breakpoints on them to see the call stack and local variable values of the leaked allocation. Its pretty easy to keep memory leaks around none with that, even if C++ requires more careful programming than D does, more destructor work than D also. Jeremie
Re: Code Poet, an IDE for D
grauzone wrote: Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Oh dear, that's not good publicity for D... I know the implementation language doesn't really matter, but it's just not good publicity. Here is the (very simple) website of the project, with a screenshot of the program so far, the content is hard coded for now to test the custom editor painting routines. http://codepoet.sourceforge.net Jeremie My choice of C++ was based on the wxWidgets library, not the language itself. I don't mean to do bad publicity to D, and I believe a good IDE will do D more good than it being written in C++ would do harm. Jeremie
Re: Code Poet, an IDE for D
Nick B wrote: Jeremie Pelletier wrote: Nick B wrote: Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. [snip] The IDE will also be cross-platform, I'm using wxWidgets for all the user interface and boost for everything else. Some things I have in mind for later in the development cycle are tasks, semantic analysis, version control for projects, automake and autoconf integration on unix, etc... Jeremie Sounds really interesting. When do you expect it to be ready for beta testing ? Nick B At the rate this is going, I expect to have an usable editor within a month or two with a very basic set of features (project manager, syntax highlighting and compiler support only) and then from that I'll start adding features. It should also be cross platform from the start, the only windows-dependent code I have right now is the resource manager which loads embedded resources manually to create wxBitmap objects instead of using the heavyweight wxRC approach. Jeremie
Re: Code Poet, an IDE for D
Denis Koroskin wrote: On Wed, 11 Nov 2009 17:15:09 +0300, Jeremie Pelletier jerem...@gmail.com wrote: Denis Koroskin wrote: On Wed, 11 Nov 2009 06:22:42 +0300, Jeremie Pelletier jerem...@gmail.com wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell Try to integrate C++ DMD front-end into your IDE, and it will leak a lot more. If I detect any leaks with DMD I'll just make it use boost's shared_ptr, then bye bye leaks! It's just DMD never ever deletes anything (but duplicates instances a lot!). You'll have to wrap everything with smart pointers. Well then that will make a good patch to submit to Walter :) I too would like to see DMD's memory consumption drop down. The debug runtime library that comes with visual studio already detects memory leaks and allows me to put breakpoints on them to see the call stack and local variable values of the leaked allocation. Its pretty easy to keep memory leaks around none with that, even if C++ requires more careful programming than D does, more destructor work than D also. Jeremie Good luck with that! So far so good!
Re: Metaprogramming in D : Some Real-world Examples
grauzone wrote: Don wrote: Christopher Wright wrote: grauzone wrote: You're not testing for types, you're testing if it compiles. Inside the tested block of code, all sorts of things could go wrong. You can't know if is(typeof(...)) really did what you wanted, or if something broke. You're testing, is everything inside that OK?. If you want to know WHY it's wrong, you'd better make sure you're testing something simple. Andrei's range lib uses it more in a way does this type support this and that range interface?. Example: http://dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L58 Then different isXxxRange are used by higher-order ranges in defining refined interfaces depending on the interfaces offered by their inputs. I fail to see how that's terrible. I am very happy D has that feature - no other statically-typed language has it, and it can be used to great effect. Look e.g. at Chain: http://dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L799 There, the uses of static if (is(...)) allow Chain to define as capable an interface as its inputs allow. Andrei
Re: Metaprogramming in D : Some Real-world Examples
Andrei Alexandrescu wrote:
grauzone wrote:
Don wrote:
Christopher Wright wrote:
grauzone wrote:
You're not testing for types, you're testing if it compiles. Inside
the tested block of code, all sorts of things could go wrong. You
can't know if is(typeof(...)) really did what you wanted, or if
something broke.
You're testing, is everything inside that OK?. If you want to know
WHY it's wrong, you'd better make sure you're testing something simple.
Andrei's range lib uses it more in a way does this type support this
and that range interface?. Example:
http://dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L58
Then different isXxxRange are used by higher-order ranges in defining
refined interfaces depending on the interfaces offered by their inputs.
That means if one isXxxRange fails because the user maybe made a typo in
the needed range function, the code will silently do something else.
But my main problem is that the user just gets a does not match
template declaration compiler error when he messes up his range
interface. He's neither told that e.g. his range-related function
returns the wrong type, nor is there any other refined error message.
Now what if we'd introduce some sort of interfaces for type checking at
compile time?
interface InputRange(T) {
void popFront();
bool empty();
T front();
}
struct MyRange : InputRange!(int) {
void popFront() { ... }
//compiler error goes here...
void empty() { ... }
int front() { ... }
}
(or something like this)
PS: there are two aspects to the problem: 1. even compile time duck
typing shares some of the problems of runtime duck typing, and 2.
utterly unhelpful error messages. If you wouldn't explicitly check the
interface with is(typeof()), the compiler's error messages would be even
worse because of 1.
I fail to see how that's terrible. I am very happy D has that feature -
no other statically-typed language has it, and it can be used to great
effect. Look e.g. at Chain:
http://dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L799
There, the uses of static if (is(...)) allow Chain to define as capable
an interface as its inputs allow.
Andrei
Re: Code Poet, an IDE for D
what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad Jeremie Pelletier Wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Here is the (very simple) website of the project, with a screenshot of the program so far, the content is hard coded for now to test the custom editor painting routines. http://codepoet.sourceforge.net Jeremie
Re: Code Poet, an IDE for D
watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad I really don't think so, the very purpose of this IDE I'm developing is to make D easier to use and develop large scale projects with. The only thing still in the way of using D with graphical applications right now is the lack of proper bindings to cross-platform GUI toolkits for D2.
Re: Code Poet, an IDE for D
Nick B wrote: Jeremie Pelletier wrote: watching wrote: [snip] I really don't think so, the very purpose of this IDE I'm developing is to make D easier to use and develop large scale projects with. The only thing still in the way of using D with graphical applications right now is the lack of proper bindings to cross-platform GUI toolkits for D2. Jeremie Not sure if you know this, but Adam D Ruppe has just started developing a cross platform (linux windows) 'D Windowing System'. See here for details: http://arsdnet.net/dws/ In particular read the section titled Why I got started. cheers Nick B I wasn't aware of it, this is great news! Jeremie
Re: Code Poet, an IDE for D
Jeremie Pelletier wrote: watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad I really don't think so, the very purpose of this IDE I'm developing is to make D easier to use and develop large scale projects with. The only thing still in the way of using D with graphical applications right now is the lack of proper bindings to cross-platform GUI toolkits for D2. Out of curiosity, did you consider GtkD and QtD? Have you thought about how to do plugins / extensions already? Of all the best software I'm using it seems a large part comes from the extensions. I wish you all the best with this project, great to see something started again on this front.
Re: Code Poet, an IDE for D
Lutger wrote: Jeremie Pelletier wrote: watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad I really don't think so, the very purpose of this IDE I'm developing is to make D easier to use and develop large scale projects with. The only thing still in the way of using D with graphical applications right now is the lack of proper bindings to cross-platform GUI toolkits for D2. Out of curiosity, did you consider GtkD and QtD? Have you thought about how to do plugins / extensions already? Of all the best software I'm using it seems a large part comes from the extensions. I wish you all the best with this project, great to see something started again on this front. I did consider a gtk/gdk approach but not Qt since I never used that API. However, wxWidgets abstracts both the entire native widgets and drawing tookits and extends them quite a lot, especially with wxAUI, that therefore seemed like the best road. I have a basic draft for plugins already. I made a base Component class template to define abstract factories for the different component types such as Language, Compiler, Linker, Librarian and Plugin which each define a specific interface. It's a really simple API but it works great, components will be able to register observers at different points in the IDE to implement their functionalities. Jeremie
Re: Code Poet, an IDE for D
On Wed, Nov 11, 2009 at 05:13:39PM -0500, Jeremie Pelletier wrote: I wasn't aware of it, this is great news! Aye :) I have to say, having an IDE available as a dws app would be several kinds of awesome. Imagine running it on a central server and letting random people connect* and use it for instant demo... that has some fun potential. * The dws is network transparent. If you're familiar with X on Linux, think that, but better. But I still have a lot of work to do before it is ready to do something like an IDE. Maybe in a couple months we can look at each other's code and see how feasible a port is then. Jeremie -- Adam D. Ruppe http://arsdnet.net
Re: Code Poet, an IDE for D
watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad +1 Totally agreed
Re: Code Poet, an IDE for D
Why don't you post on d.D.ide?
Re: Code Poet, an IDE for D
hasenj wrote: watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad +1 Totally agreed I really like that Adam and Jeremie are doing something about shortcomings they perceive. That's what this is all about.
Re: Code Poet, an IDE for D
Jeremie Pelletier Wrote: Lutger wrote: Jeremie Pelletier wrote: watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad I really don't think so, the very purpose of this IDE I'm developing is to make D easier to use and develop large scale projects with. The only thing still in the way of using D with graphical applications right now is the lack of proper bindings to cross-platform GUI toolkits for D2. Out of curiosity, did you consider GtkD and QtD? Have you thought about how to do plugins / extensions already? Of all the best software I'm using it seems a large part comes from the extensions. I wish you all the best with this project, great to see something started again on this front. I did consider a gtk/gdk approach but not Qt since I never used that API. However, wxWidgets abstracts both the entire native widgets and drawing tookits and extends them quite a lot, especially with wxAUI, that therefore seemed like the best road. I have a basic draft for plugins already. I made a base Component class template to define abstract factories for the different component types such as Language, Compiler, Linker, Librarian and Plugin which each define a specific interface. It's a really simple API but it works great, components will be able to register observers at different points in the IDE to implement their functionalities. Jeremie Well, QtD works well for D2, and I must say that Qt is a very easy API to learn.
Re: typedef: what's it good for?
Justin Johansson n...@spam.com wrote: Walter Bright Wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? Early on (2 months ago) when I was just getting into D I asked about typedefs on this forum and some discussion transpired. http://www.digitalmars.com/d/archives/digitalmars/D/ Is_typedef_an_alien_96658.html#N96658 (btw. There are a few responses from blasts from recent pasts in that thread.) Anyway, grepping for typedef over my current scripting-language in D project source shows only old versions of my project using typedefs. Accordingly it looks like I have since managed to convert *all* of my previous typedef incarnations to structs so as to take advantage of struct's support for static opCall so as to synthesize constructors (as well enabling use of struct methods). Maybe I didn't know enough about D back then, but the big problem with D typedefs (for me at least) was there was no support for typedef constructors and code otherwise blotted with cast-to-typedef-type is yuk in my way of thinking. I think there are only two sensible courses of action for D: support typedef constructors (and methods???) or remove 'em. I'm not sure which option I prefer (is the first even an option?) Cheers Justin Johansson I like typedef for making header files for c libraries. For example, so that you can't just pass an int to a function expecting an id.
Re: thank's ddmd !
dolive дµ½: thank's ddmd ! it¡¯s too great ! http://www.dsource.org/projects/ddmd dolive hope them make determined and persistent efforts thank's again dolive
Re: typedef: what's it good for?
rmcguire Wrote: Justin Johansson n...@spam.com wrote: Walter Bright Wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? Early on (2 months ago) when I was just getting into D I asked about typedefs on this forum and some discussion transpired. http://www.digitalmars.com/d/archives/digitalmars/D/ Is_typedef_an_alien_96658.html#N96658 (btw. There are a few responses from blasts from recent pasts in that thread.) Anyway, grepping for typedef over my current scripting-language in D project source shows only old versions of my project using typedefs. Accordingly it looks like I have since managed to convert *all* of my previous typedef incarnations to structs so as to take advantage of struct's support for static opCall so as to synthesize constructors (as well enabling use of struct methods). Maybe I didn't know enough about D back then, but the big problem with D typedefs (for me at least) was there was no support for typedef constructors and code otherwise blotted with cast-to-typedef-type is yuk in my way of thinking. I think there are only two sensible courses of action for D: support typedef constructors (and methods???) or remove 'em. I'm not sure which option I prefer (is the first even an option?) Cheers Justin Johansson I like typedef for making header files for c libraries. For example, so that you can't just pass an int to a function expecting an id. Yep; I agree that's a good use for typedefs too .. but in the current D formulation, you still need to use a cast don't you?
Re: Do we really need @unsafe?
Walter Bright wrote: @unsafe was suggested (I think by Don) to provide symmetry with @safe and @trusted. This is a good point, but I'm starting to think that @unsafe is not a good idea. For example, one could make an entire module safe with: --- module foo; @safe: [...] --- And an observer could conclude that foo only contains safe and trusted code. But if @unsafe could override, he has to delve into it looking for @unsafe as well. Furthermore, why would a safe module wish to expose unsafe functions? Shouldn't the programmer instead be obliged to produce trusted functions in it? I'm thinking from a library developers viewpoint. Unsafe functions are required to allow users to write their own trusted functions. It's possible to make these functions private, but that's at the expense of functionality. If we don't have @unsafe, then an unlabelled function means the function is either not checked for safety _or_ known to be unsafe. Those are two radically different things. Even if not using SafeD, marking functions as unsafe is valuable documentation. Actually, I'd hope for a way of checking that @unsafe functions are called only from @trusted functions, and NOT from unmarked ones -- that's the way I'd proceed in moving a codebase over to 'safe'. Based on the idea that the most common cause of safety violation is via passing incorrect parameters. (contracts are based on the same idea).
Re: Semantics of toString
On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu seewebsiteforem...@erdani.org:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing
toString()
is much, much worse than useless. People think you can do
something
with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is an
over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around: are there plans (or rejections thereof) to change
toString() before
D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design.
Straw man:
void toString(void delegate(const(char)[]) sink, string fmt) {
// fmt holds the format string from writefln/formatln.
// call sink() to print partial results.
}
I think the best option for toString is to take an output range and
write
to it. (The sink is a simplified range.)
Andrei
It means toString() must be either a template, or accept an abstract
InputRange interface?
It should take an interface.
So yet another type in object.d?
Or require users in import something specific in every module that's
going to use toString?
--bb
I am not sure. Opinions as always are welcome.
Andrei
Some ranges may be polymorphic, so having base interface hierarchy in
Phobos would be useful anyway.
BTW, save() is already implemented and used throughout the Phobos under a
different name - opSlice (i.e. auto copy = range[]). It's a bikeshed
discussion, but why save() and not opSlice(), or even clone()?
Re: Go: A new system programing language
Knud Soerensen wrote: Google have made a new language. Interestingly there was already a Go! language, much like when Sun introduced their D language. http://code.google.com/p/go/issues/detail?id=9 http://www.lulu.com/content/paperback-book/lets-go/641689 --anders
Re: Do we really need @unsafe?
Don wrote: Actually, I'd hope for a way of checking that @unsafe functions are called only from @trusted functions, and NOT from unmarked ones -- that's the way I'd proceed in moving a codebase over to 'safe'. Based on the idea that the most common cause of safety violation is via passing incorrect parameters. (contracts are based on the same idea). That's something I hadn't thought of!
Re: Do we really need @unsafe?
Don wrote: Actually, I'd hope for a way of checking that @unsafe functions are called only from @trusted functions, and NOT from unmarked ones -- that's the way I'd proceed in moving a codebase over to 'safe'. That would be fairly viral. I'm concerned it would make it an impediment to use.
Re: CPAN for D
Leandro Lucarella wrote: Knud Soerensen, el 11 de noviembre a las 04:57 me escribiste: Walter Bright wrote: http://www.reddit.com/r/programming/comments/a2nfz/guido_people_want_cpan/ http://search.cpan.org/ Over and over, I hear that CPAN is one of the great reasons people use Java. Such for D would be a tremendous boost to the D community. What about have the D compiler check online if it can't find a module on the local computer. ex. import foo.bar; would first check locally for foo/bar.d and the try online at http://www.digitalmars.com/d/modules/foo/bar.d or something like that. You are not much of a security guy, are you? ;) No, I mostly chose freedom over security ;-) How does CPAN solve the security problem ? I doesn't suggest that any url can be used in import, I suggest that it look on a specific trused server http://www.digitalmars.com/d/modules/ or something similar. -- Join me on CrowdNews http://crowdnews.eu/users/addGuide/42/ Facebook http://www.facebook.com/profile.php?id=1198821880 Linkedin http://www.linkedin.com/pub/0/117/a54 Mandalahttp://www.mandala.dk/view-profile.php4?profileID=7660
Re: What is an ANNOTATION?
Lars T. Kyllingstad wrote:
So, it seems that @annotations will become a part of D. But which of the
existing attributes should become annotations, and which should remain
as they are? What is the rule for determining whether a new feature
should be introduced in terms of annotations?
@safe @pure @nothrow @immutable int foo() { ... }
-Lars
Sorry, bit of a typo in the message subject there. ;)
-Lars
What is an attribute?
So, it seems that @annotations will become a part of D. But which of the
existing attributes should become annotations, and which should remain
as they are? What is the rule for determining whether a new feature
should be introduced in terms of annotations?
@safe @pure @nothrow @immutable int foo() { ... }
-Lars
Re: Go: A new system programing language
Anders F Björklund a...@algonet.se wrote in message news:hddph6$2r9...@digitalmars.com... Justin Johansson wrote: Anyway I think the speaker (Rob Pike) said something along the lines that no new systems programming language has been developed in the last ten years and there was no mention of D (at least that I picked up). Wonder if they ever looked at D or if Walter knows any of these people apart from just name? They started the project in late 2007, which is one year after D was released. So I guess D is not considered a new major systems language. By mid 2008 the language was mostly designed and the implementation (compiler, run-time) starting to work. --from the Go Tech talk slides --anders I was using D well before late 2006 (and never had any sort of special non-public access). From some of the stuff I saw on the tutorial page, I noticed a few things that seemed like they could easily have been inspired from D. Of course, being a longtime D user, that no new systems programming language has been developed in the last ten years kinda pisses me off...Although not as pissed as I'll be if the connection with google causes its use and popularity to soar past D...from the example code it looks like D but with a really garbled and annoying syntax.
Re: CPAN for D
Bill Baxter wrote: On Tue, Nov 10, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: http://www.reddit.com/r/programming/comments/a2nfz/guido_people_want_cpan/ http://search.cpan.org/ Over and over, I hear that CPAN is one of the great reasons people use Java. Such for D would be a tremendous boost to the D community. CPAN is so bad that people run away from Perl in horror over to comfortable but boring old Java? :-P DSSS was supposed to be a sort of CPAN for D. I think it's still the easiest way to get the Derelict library installed. Unfortunately it's really only a very humble start. It lacks any sort of versioning, and has no web face. And now it's unmaintained. --bb It would be great if there could be a new DSSS maintainer, or someone to fix DSSS. Then I'd imagine a site like dsource.org could easily add CPAN like functionality, however it would need to make sure to only search for completed / near completed projects.
Re: Go: A new system programing language
Nick Sabalausky wrote: They started the project in late 2007, which is one year after D was released. So I guess D is not considered a new major systems language. ... I was using D well before late 2006 (and never had any sort of special non-public access). I meant the 1.0 release, in case that wasn't obvious ? The D project was started ten years ago (1999), I think. Started in 2004 myself, when GDC was first released... DMD didn't run on my Mac, so never noticed it earlier. --anders
Re: Go: A new system programing language
Nick Sabalausky Wrote: Anders F Björklund a...@algonet.se wrote in message news:hddph6$2r9...@digitalmars.com... Justin Johansson wrote: Anyway I think the speaker (Rob Pike) said something along the lines that no new systems programming language has been developed in the last ten years and there was no mention of D (at least that I picked up). Wonder if they ever looked at D or if Walter knows any of these people apart from just name? They started the project in late 2007, which is one year after D was released. So I guess D is not considered a new major systems language. By mid 2008 the language was mostly designed and the implementation (compiler, run-time) starting to work. --from the Go Tech talk slides --anders I was using D well before late 2006 (and never had any sort of special non-public access). From some of the stuff I saw on the tutorial page, I noticed a few things that seemed like they could easily have been inspired from D. Of course, being a longtime D user, that no new systems programming language has been developed in the last ten years kinda pisses me off...Although not as pissed as I'll be if the connection with google causes its use and popularity to soar past D...from the example code it looks like D but with a really garbled and annoying syntax. Did you read the FAQ? This will really piss you off :-( What is the purpose of the project? http://golang.org/doc/go_faq.html Slashdotters are pretty quick to the announcement as well, just today ... http://developers.slashdot.org/story/09/11/11/0210212/Go-Googles-New-Open-Source-Programming-Language How many comments to you think this story got over there?
Re: What is an ANNOTATION?
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article
Lars T. Kyllingstad wrote:
So, it seems that @annotations will become a part of D. But which of the
existing attributes should become annotations, and which should remain
as they are? What is the rule for determining whether a new feature
should be introduced in terms of annotations?
@safe @pure @nothrow @immutable int foo() { ... }
-Lars
Sorry, bit of a typo in the message subject there. ;)
-Lars
a) Things that shows up in the reflection
b) When added to stuff it doesn't create a new type or overload.
c) Annotations provide data about a software program that is not part of the
program itself. They have no direct effect on the operation of the code they
annotate. (wikipedia)
Pick one, ... or two.
Re: Go: A new system programing language
Nick Sabalausky wrote: I meant the 1.0 release, in case that wasn't obvious ? The D project was started ten years ago (1999), I think. Ah. Since 1.0 was just an arbitrary stake-in-the-ground some time after D was already perfectly usable,so I've never thought of 1.0's release as being anything special. Sure, I think the official web site http://d-programming-language.org/ and the 1.0 release that followed was mostly to generate some interest ? I guess the next line-in-the-sand will be the book release, and whatever version of DMD 2.x (compiler and specification) that will come with it ? --anders
Re: typedef: what's it good for?
Walter Bright wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? There are typedefs in D?
Re: typedef: what's it good for?
On Wed, 11 Nov 2009 07:45:26 +0100, BCS n...@anon.com wrote:
Hello Walter,
When I originally worked out ideas for D, there were many requests
from the C and C++ community for a 'strong' typedef, and so I put one
in D. I didn't think about it too much, just assumed that it was a
good idea.
Now I'm not so sure. Maybe it should be removed for D2.
Does anyone use typedef's?
What do you use them for?
Do you need them?
I'd use them more if they were stronger. particularly, I'd love it if
they could be used to add/overide stuff basic types:
typedef int TD
{
TD opAdd(TD that) { assert(this that); return cast(int)this +
cast(int)that; }
...
}
or even better
typedef int TD(T)
{
TD!(T) opAdd(TD!(T) that) if (Pred!(T)) = default; // use the default
but restrict the operation
...
}
We can already do that in D2:
struct myInt {
int _payload;
alias _payload this;
myInt opAdd( myInt that ) {
assert( this._payload that._payload );
return this._payload + that.payload;
}
}
And I would believe this is why removing typedef is now being discussed.
I like typedefs for when I need a separate type with no bells and
whistles, and so suggest that
typedef int foo;
be kept as it is, and
typedef int bar {
/* stuffs */
}
be sugar for
struct bar {
int _payload;
alias _payload this;
/* stuffs */
}
--
Simen
Re: The Thermopylae excerpt of TDPL available online
On Thu, Oct 29, 2009 at 05:38, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: It's a rough rough draft, but one for the full chapter on arrays, associative arrays, and strings. http://erdani.com/d/thermopylae.pdf Any feedback is welcome. Thanks! Well, if that's a rough rough draft, I'll happily read the entire book... I'm reading the AA part, and found that .dup doesn't exist for associative arrays (D2.036). It's bug 816, I guess. What's strange is that it's not listed as a bug in your text (red markings and such). Did you define a dup(K,V) function somewhere else? Philippe
Re: Go: A new system programing language
Looks interesting. * Uses a module system * Built-in arrays are value types. * Python like slice syntx a[lo:hi] * immutable strings * switch has no break. Use fallthrough to fallthrough. * Nested functions * First class tuples ( a,b = func(), a,b=b,a ) * := for assignment * Uses var to declare variables (this was chapmpioned by some here instead of auto) * varible type comes after declaration and is optional * return type of functions comes after parameters * No Windows port yet. That's going to be a bit of a roadblock to widespread adoption. * Iota!? * ... There's a lot there that looks either like D or like things people in the D community have argued for. And it's got the billion dollar backing of a major company. --bb On Tue, Nov 10, 2009 at 6:21 PM, Knud Soerensen 4tuu4k...@sneakemail.com wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s -- Join me on CrowdNews http://crowdnews.eu/users/addGuide/42/ Facebook http://www.facebook.com/profile.php?id=1198821880 Linkedin http://www.linkedin.com/pub/0/117/a54 Mandala http://www.mandala.dk/view-profile.php4?profileID=7660
Re: foreach syntax, std.mixin
On Sun, Nov 8, 2009 at 22:43, dsimcha dsim...@yahoo.com wrote: Hot off the press and VERY prototype-ish: Code: http://pastebin.com/m2087e524 Docs: http://cis.jhu.edu/~dsimcha/unpackEnumerate.htmlhttp://cis.jhu.edu/%7Edsimcha/unpackEnumerate.html Cool! Thanks a lot. I looked at opApply for D1 maybe two years ago, but never used it myself. I'll go and read this part of the docs. *test it* Hmm, I can get enumerate to work, but the Unpack part doesn't compile. It complains elem.at!(0) is not an lvalue. You know, the Proxy part of std.range.zip is really annoying. I'd prefer zip to return std.typecons.Tuples, even if that means stopping at the shortest range. That's what other languages do and it seems enough for most uses. Does this look like a good addition to std.range? The elegance of it is it solves the problem of providing syntactic sugar to ranges w/ zero ripple effects either in the compiler or in the rest of Phobos. I'll file it somewhere more official after people review it a little and refine the idea, but I definitely think something similar to this has a legit place in std.range. If you're wondering how unpack works and don't want to grovel through all the code, it's tons of string mixin magic. That's about the only way I was able to make it work. I'll read it with pleasure(!). I'm there to learn anyway.Heck, I can't read my own string mixins a week after writing them, so it'll be a good exercise. As to making it an addition to std.range, I'm all for it. If people don't want to use it because they are leery of using opApply, too bad for them. Your small benchmark was interesting: overhead exists, but it's not awful. Philippe
Re: bug #2607 building DMD against and older version of glibc [was: objdump src]
dsimcha wrote: == Quote from Spacen Jasset (spacenjas...@yahoo.co.uk)'s article Spacen Jasset wrote: I am trying to build dmd such that it will work on older versions of ...stuff Given that there will be a book out in the fairly near future, and people may therefore want to run dmd on GNU/Linux. Perhaps bug #2607 would be useful to fix. That is; ensure that dmd will run on a respectable set of GNU/linux versions easily. (and perhaps this applies to FreeBSD too) I'm forced to use Linux caveman edition (kernel 2.6.8 or something) on some of the computers I deal with for my research because my sysadmin refuses to upgrade. Before DMD came with buildable source this was problematic because I was constantly searching for one of the few nodes that DMD would run on. However, now I don't see it as much of a problem, as it takes approximately 2 minutes to just compile from source. Furthermore, I think I asked Walter about this back when it was still a problem and he said changing the glibc version would break people with a newer version. Ok. glibc is forward compatible, on purpose. We build stuff for redhat 2 at our workplace, which works on 5 (and ubuntu and suse) without any trouble. Drepper goes into a lot of detail here: http://people.redhat.com/drepper/dsohowto.pdf The problem Walter had was First with glibc, which was fixed by building on an older platform (there are other ways but this is easiest). Then Second, with the older libc++ which was missing on the newer systems. The latter is fixed by either: a) static link in only libc++ and libgcc b) ship libc++ and change the link loader path with the -L options (requires a startup stub I think if you don't always use the same installation location i.e. /usr/local/dmd Which is a very similar way you fix missing msvcr71.dll problems on windows.
Re: Semantics of toString
Bill Baxter wrote:
On Tue, Nov 10, 2009 at 5:27 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu seewebsiteforem...@erdani.org:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing
toString()
is much, much worse than useless. People think you can do something
with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is an
over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around: are there plans (or rejections thereof) to change toString()
before
D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design.
Straw man:
void toString(void delegate(const(char)[]) sink, string fmt) {
// fmt holds the format string from writefln/formatln.
// call sink() to print partial results.
}
I think the best option for toString is to take an output range and
write
to it. (The sink is a simplified range.)
Andrei
It means toString() must be either a template, or accept an abstract
InputRange interface?
It should take an interface.
So yet another type in object.d?
Or require users in import something specific in every module that's
going to use toString?
--bb
I am not sure. Opinions as always are welcome.
That's why my opinion is that the delegate idea is nice. :-)
But I guess toString is already defined by Object, right? So it would
make sense for an interface needed by an Object method to be defined
in object.d. I suppose it could be an interface defined inside the
Object class itself? (Does that work? can you define interfaces
inside classes?)
It also needs to be used by structs, which aren't inherited from Object.
So I don't see how a nested interface could work.
I suggest a design acceptance criterion: the simplest case should be
about as simple as:
return xxx;
or
put(xxx);
Re: foreach syntax, std.mixin
== Quote from Philippe Sigaud (philippe.sig...@gmail.com)'s article --0016e6d99ba70494130478196284 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 8, 2009 at 22:43, dsimcha dsim...@yahoo.com wrote: Hot off the press and VERY prototype-ish: Code: http://pastebin.com/m2087e524 Docs: http://cis.jhu.edu/~dsimcha/unpackEnumerate.htmlhttp://cis.jhu.edu/%7Edsimcha/unpackEnumerate.html Cool! Thanks a lot. I looked at opApply for D1 maybe two years ago, but never used it myself. I'll go and read this part of the docs. *test it* Hmm, I can get enumerate to work, but the Unpack part doesn't compile. It complains elem.at!(0) is not an lvalue. Argh. That's because I was hacking around with Zip in my copy of Phobos right before I wrote this lib and forgot to change some stuff back to stock when testing. If you uncomment a /*ref*/ in there somewhere, which was leftover from a compiler bug a long time ago, it seems to work. The real problem is that that bit of cruft hasn't been removed from Phobos yet.
Re: Semantics of toString
Denis Koroskin wrote:
On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu seewebsiteforem...@erdani.org:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing
toString()
is much, much worse than useless. People think you can do
something
with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is an
over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around: are there plans (or rejections thereof) to change
toString() before
D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design.
Straw man:
void toString(void delegate(const(char)[]) sink, string fmt) {
// fmt holds the format string from writefln/formatln.
// call sink() to print partial results.
}
I think the best option for toString is to take an output range
and write
to it. (The sink is a simplified range.)
Andrei
It means toString() must be either a template, or accept an abstract
InputRange interface?
It should take an interface.
So yet another type in object.d?
Or require users in import something specific in every module that's
going to use toString?
--bb
I am not sure. Opinions as always are welcome.
Andrei
Some ranges may be polymorphic, so having base interface hierarchy in
Phobos would be useful anyway.
BTW, save() is already implemented and used throughout the Phobos under
a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed
discussion, but why save() and not opSlice(), or even clone()?
It can't be clone() because it doesn't clone. For example say you have a
T[] - one would expect clone() actually copies the content. But using
opSlice is a good idea.
Andrei
Re: Go: A new system programing language
Bill Baxter wrote: Looks interesting. * Uses a module system * Built-in arrays are value types. * Python like slice syntx a[lo:hi] * immutable strings * switch has no break. Use fallthrough to fallthrough. * Nested functions * First class tuples ( a,b = func(), a,b=b,a ) * := for assignment * Uses var to declare variables (this was chapmpioned by some here instead of auto) * varible type comes after declaration and is optional * return type of functions comes after parameters * No Windows port yet. That's going to be a bit of a roadblock to widespread adoption. * Iota!? * ... There's a lot there that looks either like D or like things people in the D community have argued for. It's also missing quite a few things that people in the D community take for granted. And it's got the billion dollar backing of a major company. That part I missed. Andrei
Re: Go: A new system programing language
On Wed, 11 Nov 2009 09:59:36 -0500, Bill Baxter wbax...@gmail.com wrote: Looks interesting. * Uses a module system * Built-in arrays are value types. * Python like slice syntx a[lo:hi] * immutable strings * switch has no break. Use fallthrough to fallthrough. * Nested functions * First class tuples ( a,b = func(), a,b=b,a ) * := for assignment * Uses var to declare variables (this was chapmpioned by some here instead of auto) * varible type comes after declaration and is optional * return type of functions comes after parameters * No Windows port yet. That's going to be a bit of a roadblock to widespread adoption. * Iota!? * ... There's a lot there that looks either like D or like things people in the D community have argued for. And it's got the billion dollar backing of a major company. --bb On Tue, Nov 10, 2009 at 6:21 PM, Knud Soerensen 4tuu4k...@sneakemail.com wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s -- Join me on CrowdNews http://crowdnews.eu/users/addGuide/42/ Facebook http://www.facebook.com/profile.php?id=1198821880 Linkedin http://www.linkedin.com/pub/0/117/a54 Mandalahttp://www.mandala.dk/view-profile.php4?profileID=7660 * := isn't used for assignment, it's used for automatic type deduction and assignment: In Go: t := T(5); In D: auto t = T(5); * var is also required for standard, typed variable declaration in addition to automatic deduction In Go: var t float; In D: float t; * Uses '+' for concatenation
Re: Semantics of toString
On Wed, 11 Nov 2009 18:50:47 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu seewebsiteforem...@erdani.org:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing
toString()
is much, much worse than useless. People think you can do
something
with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is
an
over-my-dead-body.
Since you are in the know and probably the biggest toString()
hater
around: are there plans (or rejections thereof) to change
toString() before
D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design.
Straw man:
void toString(void delegate(const(char)[]) sink, string fmt) {
// fmt holds the format string from writefln/formatln.
// call sink() to print partial results.
}
I think the best option for toString is to take an output range
and write
to it. (The sink is a simplified range.)
Andrei
It means toString() must be either a template, or accept an abstract
InputRange interface?
It should take an interface.
So yet another type in object.d?
Or require users in import something specific in every module that's
going to use toString?
--bb
I am not sure. Opinions as always are welcome.
Andrei
Some ranges may be polymorphic, so having base interface hierarchy in
Phobos would be useful anyway.
BTW, save() is already implemented and used throughout the Phobos
under a different name - opSlice (i.e. auto copy = range[]). It's a
bikeshed discussion, but why save() and not opSlice(), or even clone()?
It can't be clone() because it doesn't clone. For example say you have a
T[] - one would expect clone() actually copies the content. But using
opSlice is a good idea.
Andrei
Well, range doesn't own any of the contents it covers, so deep copy is
impossible.
Yet, there is also .dup array property which is pretends to be a standard
way of creating instance copies.
Re: Semantics of toString
Denis Koroskin wrote: Well, range doesn't own any of the contents it covers, so deep copy is impossible. Yet, there is also .dup array property which is pretends to be a standard way of creating instance copies. Well so the second sentence contradicts the first. Let me put it another way: you have the entire vocabulary at your disposal to define save(). Wouldn't you think clone() may be a bit more confusing than others? Andrei
Re: typedef: what's it good for?
rmcguire wrote: Justin Johansson n...@spam.com wrote: Walter Bright Wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? Early on (2 months ago) when I was just getting into D I asked about typedefs on this forum and some discussion transpired. http://www.digitalmars.com/d/archives/digitalmars/D/ Is_typedef_an_alien_96658.html#N96658 (btw. There are a few responses from blasts from recent pasts in that thread.) Anyway, grepping for typedef over my current scripting-language in D project source shows only old versions of my project using typedefs. Accordingly it looks like I have since managed to convert *all* of my previous typedef incarnations to structs so as to take advantage of struct's support for static opCall so as to synthesize constructors (as well enabling use of struct methods). Maybe I didn't know enough about D back then, but the big problem with D typedefs (for me at least) was there was no support for typedef constructors and code otherwise blotted with cast-to-typedef-type is yuk in my way of thinking. I think there are only two sensible courses of action for D: support typedef constructors (and methods???) or remove 'em. I'm not sure which option I prefer (is the first even an option?) Cheers Justin Johansson I like typedef for making header files for c libraries. For example, so that you can't just pass an int to a function expecting an id. Today's typedef allows you to pass an arbitrary int literal as a typedef. typedef int ID; void fun(ID); fun(42); // compiles and runs Andrei
Re: foreach syntax, std.mixin
On Wed, Nov 11, 2009 at 16:48, dsimcha dsim...@yahoo.com wrote: *test it* Hmm, I can get enumerate to work, but the Unpack part doesn't compile. It complains elem.at!(0) is not an lvalue. Argh. That's because I was hacking around with Zip in my copy of Phobos right before I wrote this lib and forgot to change some stuff back to stock when testing. How do you deal with successive version of DMD? Do you have parallel installations? I know I hacked around Zip, Chain and such a few times, forgot about it, only to have it crushed by my next download :-( If you uncomment a /*ref*/ in there somewhere, which was leftover from a compiler bug a long time ago, it seems to work. The real problem is that that bit of cruft hasn't been removed from Phobos yet. OK, thanks. I get the impression that ref is viral... Either you have it everywhere or it'll block some compositions (chain(map() ...) . I'm wrong? Thanks again for your code, I'll test it and tell you how it went. Philippe
Re: Go: A new system programing language
Bill Baxter wrote: Looks interesting. And the go compiler isn't written in go because of the difficulties of bootstrapping. There's a lot there that looks either like D or like things people in the D community have argued for. And it's got the billion dollar backing of a major company. --bb It isn't clear to me whether google is explicitly endorsing go, or those 5 engineers are just working on it in their 20% time.
Re: typedef: what's it good for?
Walter Bright wrote:
When I originally worked out ideas for D, there were many requests from
the C and C++ community for a 'strong' typedef, and so I put one in D. I
didn't think about it too much, just assumed that it was a good idea.
Now I'm not so sure. Maybe it should be removed for D2.
Does anyone use typedef's?
What do you use them for?
Do you need them?
One good way to figure out how well-defined something is would be to
attempt explaining it to someone. That's what happened as I was writing
about typedef in TDPL. I realized the following:
* typedef is hopelessly broken in very many ways
* nobody noticed (i.e. no bugzilla reports), so probably nobody uses it
* fixing it to do anything remotely useful would be a major effort and
would complicate the language
* even if fixed to do something useful, the usefulness would be very limited
* it's unclear which of two different fixes would make it more useful
and less confusing
The last point was revealed by a conversation between Walter and me last
night. I pointed out that typedef should create a *subtype* of a type, e.g.:
typedef int ID;
ID id;
int x;
id = x; // no
x = id; // yes
He pointed out that typedef should create a *supertype*, e.g.:
typedef int ID;
ID id;
int x;
id = x; // yes
x = id; // no
I still think that subtype would be a better choice than supertype, but
I also could see cases in which you want the supertype case. So I expect
that whatever we choose, some may expect the opposite and get confused.
One alternative is to make typedef a completely separate type, with
explicit casts:
typedef int ID;
ID id;
int x;
id = x; // no
x = id; // no
id = ID(x); // yes
x = int(id); // yes
Then everybody would complain that the right direction is not implicit.
Subtype vs. supertype is only the beginning of problems. Consider some
choice has been made, and then look at this orthogonal problem:
struct A {
A foo();
void bar(A);
A baz(A);
}
typedef A B;
What should that do? After much thinking, I concluded the most
reasonable thing it could do is to replace A with B throughout the
definition, e.g.:
struct B {
B foo();
void bar(B);
B baz(B);
}
I found some examples for the usefulness of that, but then also examples
in which some or all of those functions should use an A sometimes.
Today, typedef does essentially nothing notable or even correct and
consistent for structs, classes, pointers, and arrays. It even has some
egregious errors, for example when defining binary operators. Nobody
noticed them probably because nobody used them.
Walter's and my interim conclusion last night was that fixing typedef
would be difficult, and that the usefulness of typedef is too little for
its complexity. It may be a good idea to just remove it from the
language. We already have a host of other abstraction-building
mechanisms, and typedef does not seem to build a good abstraction.
Andrei
Re: typedef: what's it good for?
Walter Bright wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? One _actual_ use of typeof is to force a different array initializer (for performance reasons): typedef int Foo = 1; Foo[] arr; arr.length = 567; //with int[] arr, you now had to do arr[] = 1; Also, you can easily define new exception classes: //no need to write a ctor which just calls the super ctor typedef Exception MyException; But these are just symptoms of other problems of the language. Can typedef be the same as alias, if the current functionality goes?
Re: Semantics of toString
Denis: BTW, save() is already implemented and used throughout the Phobos under a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()? 2009/11/11 Andrei Alexandrescu seewebsiteforem...@erdani.org It can't be clone() because it doesn't clone. For example say you have a T[] - one would expect clone() actually copies the content. But using opSlice is a good idea. I don't get it. Shouldn't save() copy the content? Do you mean we could use opSlice() (the parameterless version) as a save function and write auto r2 = r1[];? But, again maybe I don't get something: for dyn. arrays (aka the range archetype) opSlice is not a save, it's just an alias. So using opSlice doesn't work for remembering positions with arrays. Philippe
Re: typedef: what's it good for?
On Wed, Nov 11, 2009 at 9:04 AM, grauzone n...@example.net wrote: Walter Bright wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? One _actual_ use of typeof is to force a different array initializer (for performance reasons): typedef int Foo = 1; Foo[] arr; arr.length = 567; //with int[] arr, you now had to do arr[] = 1; Also, you can easily define new exception classes: //no need to write a ctor which just calls the super ctor typedef Exception MyException; Does this actually work now? Long ago this was one of the things I first thought I could use typedefs for, but it didn't work. I think it was because the compiler no longer recognizes MyException as a subtype of Exception anymore, but it was a long time ago, so I don't recall for sure. --bb
Re: typedef: what's it good for?
On Wed, Nov 11, 2009 at 10:54:27AM -0600, Andrei Alexandrescu wrote: The last point was revealed by a conversation between Walter and me last night. I pointed out that typedef should create a *subtype* of a type, e.g.: I was thinking about this a while ago and had a half baked proposal, but ditched it exactly because it was half baked. My thought was to have two kinds of typedef: typedef int ID; // supertype typedef ID : int; // subtype - the syntax is based on class inheritance But I also kinda wanted no implicit conversion static typedef int ID; // :-P But however it is created, it would be useful for completely opaque types - useful for talking to C libraries. You can copy it, store it, and pass it around, but nothing else. Subtype vs. supertype is only the beginning of problems. Consider some choice has been made, and then look at this orthogonal problem: Disallow it. I don't think I've ever wanted to use typedef on anything other than primitives (and void*) anyway - structs and classes have their own ways to do the job. -- Adam D. Ruppe http://arsdnet.net
Re: Semantics of toString
On Wed, 11 Nov 2009 20:08:52 +0300, Philippe Sigaud philippe.sig...@gmail.com wrote: Denis: BTW, save() is already implemented and used throughout the Phobos under a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()? 2009/11/11 Andrei Alexandrescu seewebsiteforem...@erdani.org It can't be clone() because it doesn't clone. For example say you have a T[] - one would expect clone() actually copies the content. But using opSlice is a good idea. I don't get it. Shouldn't save() copy the content? Do you mean we could use opSlice() (the parameterless version) as a save function and write auto r2 = r1[];? But, again maybe I don't get something: for dyn. arrays (aka the range archetype) opSlice is not a save, it's just an alias. So using opSlice doesn't work for remembering positions with arrays. Philippe It remembers array bounds, not contents.
Re: typedef: what's it good for?
Bill Baxter wrote: On Wed, Nov 11, 2009 at 9:04 AM, grauzone n...@example.net wrote: Walter Bright wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? One _actual_ use of typeof is to force a different array initializer (for performance reasons): typedef int Foo = 1; Foo[] arr; arr.length = 567; //with int[] arr, you now had to do arr[] = 1; Also, you can easily define new exception classes: //no need to write a ctor which just calls the super ctor typedef Exception MyException; Does this actually work now? Long ago this was one of the things I first thought I could use typedefs for, but it didn't work. I think it was because the compiler no longer recognizes MyException as a subtype of Exception anymore, but it was a long time ago, so I don't recall for sure. I think it does. There was a bug that prevented this from working, but it was fixed: http://d.puremagic.com/issues/show_bug.cgi?id=1285 Anyway, D should do something about those annoying ctors semantics. I propose we use exactly the same model as Object Pascal / Delphi did. --bb
Re: Go: A new system programing language
On 11/11/2009 9:59 AM, Bill Baxter wrote: Looks interesting. * ... There's a lot there that looks either like D or like things people in the D community have argued for. The important thing about Go is its concurrency model. Combine the CSP model with Bartosz’s type system and D wins. —Joel Salomon
Re: Semantics of toString
2009/11/11 Andrei Alexandrescu seewebsiteforem...@erdani.org: Denis Koroskin wrote: Well, range doesn't own any of the contents it covers, so deep copy is impossible. Yet, there is also .dup array property which is pretends to be a standard way of creating instance copies. Well so the second sentence contradicts the first. Let me put it another way: you have the entire vocabulary at your disposal to define save(). Wouldn't you think clone() may be a bit more confusing than others? makeBreadCrumb() ? :-) --bb
Re: typedef: what's it good for?
Andrei Alexandrescu wrote: * typedef is hopelessly broken in very many ways * nobody noticed (i.e. no bugzilla reports), so probably nobody uses it No Bugzilla reports? Here're just a few: http://d.puremagic.com/issues/show_bug.cgi?id=632 http://d.puremagic.com/issues/show_bug.cgi?id=1335 http://d.puremagic.com/issues/show_bug.cgi?id=1344 http://d.puremagic.com/issues/show_bug.cgi?id=1595 I use typedefs of integral types in one project, mostly because I read the D spec when I started out and thought it'd be a good idea, but because of 1335 and 1344 I eventually realized it wasn't such a good idea after all. I do still use them, but I wouldn't miss them much if they were gone.
Re: Go: A new system programing language
On Wed, Nov 11, 2009 at 7:56 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Bill Baxter wrote: Looks interesting. * Uses a module system * Built-in arrays are value types. * Python like slice syntx a[lo:hi] * immutable strings * switch has no break. Use fallthrough to fallthrough. * Nested functions * First class tuples ( a,b = func(), a,b=b,a ) * := for assignment * Uses var to declare variables (this was chapmpioned by some here instead of auto) * varible type comes after declaration and is optional * return type of functions comes after parameters * No Windows port yet. That's going to be a bit of a roadblock to widespread adoption. * Iota!? * ... There's a lot there that looks either like D or like things people in the D community have argued for. It's also missing quite a few things that people in the D community take for granted. It's harder to find those when you're skimming through trying to get the highlights with a 5 minute limit. :-) What are some things is it missing? (Also recall that D lacked even templates until long after its inception -- so if the language can muster some level of acceptance, probably popular demand will eventually lead to adding more of those missing features.) And it's got the billion dollar backing of a major company. That part I missed. I should have said backing of a billion-dollar company not billion-dollar backing. Certainly it doesn't have the latter. But it has backing in some sense, anyway. Even if it's the 20% time of five guys, Google's paying them for that time. And whether or not they *have* any deep pocket backing, people will perceive a tie between the company and the language, which means it can ride on the wave of Google's excellent mind-share, esp. among programmers. Ken Thompson is also a very well-known and respected name from Unix and Plan 9 (and Rob Pike too?). These are all very strong marketing advantages. Looking to the future, I suspect if Google does adopt a new systems language, it's much more likely to come from within than be NIH. Because that way they'll have much more control over it if, and not have to worry so much about IP issues (not that Google spends much time worrying about IP...), etc. And if it becomes widely used in Google, then that's a very bouncy spring board from which to foist it on the rest of the world. It's definitely going to be a strong competitor for D's audience. --bb
Re: Do we really need @unsafe?
On Wed, 11 Nov 2009 06:04:16 -0500, Don nos...@nospam.com wrote: Walter Bright wrote: Don wrote: Actually, I'd hope for a way of checking that @unsafe functions are called only from @trusted functions, and NOT from unmarked ones -- that's the way I'd proceed in moving a codebase over to 'safe'. That would be fairly viral. I'm concerned it would make it an impediment to use. Hopefully such functions would be really rare. It would be a strong encouragement to wrap them in an @trusted wrapper. I have a feeling people would throw on a @trusted wrapper just to save the work on propagating @unsafe attributes all through their code.
Re: typedef: what's it good for?
== Quote from grauzone (n...@example.net)'s article Walter Bright wrote: When I originally worked out ideas for D, there were many requests from the C and C++ community for a 'strong' typedef, and so I put one in D. I didn't think about it too much, just assumed that it was a good idea. Now I'm not so sure. Maybe it should be removed for D2. Does anyone use typedef's? What do you use them for? Do you need them? One _actual_ use of typeof is to force a different array initializer (for performance reasons): Yes, but this is a **massive** kludge. The right answer is to allow custom array initializers. If this is the best we can come up with then typedef is really worthless.
Re: typedef: what's it good for?
Hello Simen,
[...] suggest that
typedef int foo;
be kept as it is, and
typedef int bar {
/* stuffs */
}
be sugar for
struct bar {
int _payload;
alias _payload this;
/* stuffs */
}
One important aspect of what I proposed is that operators that aren't overridden
still exist and use the same codegen as the base type (or are guarantied
to generate the same machine code in all cases).
Re: CPAN for D
Clay Smith wrote: Bill Baxter wrote: On Tue, Nov 10, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: http://www.reddit.com/r/programming/comments/a2nfz/guido_people_want_cpan/ http://search.cpan.org/ Over and over, I hear that CPAN is one of the great reasons people use Java. Such for D would be a tremendous boost to the D community. CPAN is so bad that people run away from Perl in horror over to comfortable but boring old Java? :-P DSSS was supposed to be a sort of CPAN for D. I think it's still the easiest way to get the Derelict library installed. Unfortunately it's really only a very humble start. It lacks any sort of versioning, and has no web face. And now it's unmaintained. --bb It would be great if there could be a new DSSS maintainer, or someone to fix DSSS. Then I'd imagine a site like dsource.org could easily add CPAN like functionality, however it would need to make sure to only search for completed / near completed projects. I agree very much, DSSS has so much potential it's not funny. If I wouldn't be too stuffed with work as is, I might attempt to fix it myself. Hopefully somebody steps in.
Re: typedef: what's it good for?
Matti Niemenmaa wrote: Andrei Alexandrescu wrote: * typedef is hopelessly broken in very many ways * nobody noticed (i.e. no bugzilla reports), so probably nobody uses it No Bugzilla reports? Here're just a few: http://d.puremagic.com/issues/show_bug.cgi?id=632 http://d.puremagic.com/issues/show_bug.cgi?id=1335 http://d.puremagic.com/issues/show_bug.cgi?id=1344 http://d.puremagic.com/issues/show_bug.cgi?id=1595 I use typedefs of integral types in one project, mostly because I read the D spec when I started out and thought it'd be a good idea, but because of 1335 and 1344 I eventually realized it wasn't such a good idea after all. I do still use them, but I wouldn't miss them much if they were gone. Yeah sorry for exaggerating. I was mostly thinking that nobody seems to have noticed the problems with typedef for structs, built-in arrays, and pointers. Andrei
Re: What is an ANNOTATION?
sclytrack wrote:
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article
Lars T. Kyllingstad wrote:
So, it seems that @annotations will become a part of D. But which of the
existing attributes should become annotations, and which should remain
as they are? What is the rule for determining whether a new feature
should be introduced in terms of annotations?
@safe @pure @nothrow @immutable int foo() { ... }
-Lars
Sorry, bit of a typo in the message subject there. ;)
-Lars
a) Things that shows up in the reflection
b) When added to stuff it doesn't create a new type or overload.
c) Annotations provide data about a software program that is not part of the
program itself. They have no direct effect on the operation of the code they
annotate. (wikipedia)
Pick one, ... or two.
(c) is the one.
Re: Go: A new system programing language
On Wed, Nov 11, 2009 at 3:14 AM, Nick Sabalausky a...@a.a wrote: Of course, being a longtime D user, that no new systems programming language has been developed in the last ten years kinda pisses me off... No new *major* systems language is what they said. Major is a marketing word that can mean whatever you want it to. If you define major as say a user base at least 5% of C or C++'s, then yeh, D probably isn't there. Or you could measure the number of D books in your local bookstore vs C++ books. --bb
Re: typedef: what's it good for?
Andrei Alexandrescu: Walter's and my interim conclusion last night was that fixing typedef would be difficult, and that the usefulness of typedef is too little for its complexity. It may be a good idea to just remove it from the language. An usage of typedef: alias int[5][20] TyMat; typedef Mat TyMatA; typedef Mat TyMatB; Now a function can take both a TyMatA and TyMatB matrix, and the type system helps you to not confuse one for the other when you pass them around. If typedef gets removed from D, will the typedef keyword removed from the D language? Bye, bearophile
Re: CPAN for D
Clay Smith wrote: Bill Baxter wrote: On Tue, Nov 10, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: http://www.reddit.com/r/programming/comments/a2nfz/guido_people_want_cpan/ http://search.cpan.org/ Over and over, I hear that CPAN is one of the great reasons people use Java. Such for D would be a tremendous boost to the D community. CPAN is so bad that people run away from Perl in horror over to comfortable but boring old Java? :-P DSSS was supposed to be a sort of CPAN for D. I think it's still the easiest way to get the Derelict library installed. Unfortunately it's really only a very humble start. It lacks any sort of versioning, and has no web face. And now it's unmaintained. --bb It would be great if there could be a new DSSS maintainer, or someone to fix DSSS. Then I'd imagine a site like dsource.org could easily add CPAN like functionality, however it would need to make sure to only search for completed / near completed projects. Yes DSSS is/was good. It probably needs more than one point of contact / maintainer. I'd also suggest using bzr/hg/git (in that order) such that users could more easily contribute changes, and it may help provide more visibility to exactly who and what is happening on the project, if branches can be registered. As for CPAN. It's the only thing that is good about Perl.
Re: typedef: what's it good for?
bearophile wrote: Andrei Alexandrescu: Walter's and my interim conclusion last night was that fixing typedef would be difficult, and that the usefulness of typedef is too little for its complexity. It may be a good idea to just remove it from the language. An usage of typedef: alias int[5][20] TyMat; typedef Mat TyMatA; typedef Mat TyMatB; Now a function can take both a TyMatA and TyMatB matrix, and the type system helps you to not confuse one for the other when you pass them around. You may want to test what happens when you mix TyMatA and TyMatB in some operation. If typedef gets removed from D, will the typedef keyword removed from the D language? I would think so. Andrei
Re: Go: A new system programing language
Bill Baxter wrote: It's harder to find those when you're skimming through trying to get the highlights with a 5 minute limit. :-) What are some things is it missing? Off the top of my head, some major ones: . exception handling . generic programming . metaprogramming . inline assembler . interface to C . RAII . immutability for anything but strings . vector operations . operator overloading . purity . CTFE . unit testing . documentation generation . ability to write systems code like implement a GC . conditional compilation . contracts . 80 bit floating point . introspection (runtime or compile time) . delegates . reference parameters Not sure if it has closures or not. And of course a lot of minor ones, . no _ in integer literals . no nesting comments . no entities etc.
Re: typedef: what's it good for?
bearophile wrote: If typedef gets removed from D, will the typedef keyword removed from the D language? Eventually, yes, though there will be much time when it exists as a deprecated feature.
Re: Go: A new system programing language
Bill Baxter wrote: On Wed, Nov 11, 2009 at 7:56 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Bill Baxter wrote: Looks interesting. * Uses a module system * Built-in arrays are value types. * Python like slice syntx a[lo:hi] * immutable strings * switch has no break. Use fallthrough to fallthrough. * Nested functions * First class tuples ( a,b = func(), a,b=b,a ) * := for assignment * Uses var to declare variables (this was chapmpioned by some here instead of auto) * varible type comes after declaration and is optional * return type of functions comes after parameters * No Windows port yet. That's going to be a bit of a roadblock to widespread adoption. * Iota!? * ... There's a lot there that looks either like D or like things people in the D community have argued for. It's also missing quite a few things that people in the D community take for granted. It's harder to find those when you're skimming through trying to get the highlights with a 5 minute limit. :-) What are some things is it missing? (Also recall that D lacked even templates until long after its inception -- so if the language can muster some level of acceptance, probably popular demand will eventually lead to adding more of those missing features.) And it's got the billion dollar backing of a major company. That part I missed. I should have said backing of a billion-dollar company not billion-dollar backing. Certainly it doesn't have the latter. But it has backing in some sense, anyway. Even if it's the 20% time of five guys, Google's paying them for that time. And whether or not they *have* any deep pocket backing, people will perceive a tie between the company and the language, which means it can ride on the wave of Google's excellent mind-share, esp. among programmers. Ken Thompson is also a very well-known and respected name from Unix and Plan 9 (and Rob Pike too?). These are all very strong marketing advantages. Looking to the future, I suspect if Google does adopt a new systems language, it's much more likely to come from within than be NIH. Because that way they'll have much more control over it if, and not have to worry so much about IP issues (not that Google spends much time worrying about IP...), etc. And if it becomes widely used in Google, then that's a very bouncy spring board from which to foist it on the rest of the world. It's definitely going to be a strong competitor for D's audience. Possibly, but IMHO not on technical merit at all. It is many years behind becoming usable for a real system. It will be interesting how it plays out. Andrei
Re: Go: A new system programing language
Bill Baxter wrote: On Wed, Nov 11, 2009 at 7:56 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Bill Baxter wrote: Looks interesting. I should have said backing of a billion-dollar company not billion-dollar backing. Certainly it doesn't have the latter. But it has backing in some sense, anyway. Even if it's the 20% time of five guys, Google's paying them for that time. And whether or not they *have* any deep pocket backing, people will perceive a tie between the company and the language, which means it can ride on the wave of Google's excellent mind-share, esp. among programmers. Ken Thompson is also a very well-known and respected name from Unix and Plan 9 (and Rob Pike too?). These are all very strong marketing advantages. Looking to the future, I suspect if Google does adopt a new systems language, it's much more likely to come from within than be NIH. Because that way they'll have much more control over it if, and not have to worry so much about IP issues (not that Google spends much time worrying about IP...), etc. And if it becomes widely used in Google, then that's a very bouncy spring board from which to foist it on the rest of the world. It's definitely going to be a strong competitor for D's audience. --bb Bill - you are absolutely correct. It will be targeting the _same_ audience as D. It can be said that D now have a serious competitor. Will Walter increase the marketing for D ? Even though the current D developers will likely NOT move to Go, it is possible that new developers may not come to the D community in the future, in the same numbers. Of course this all depends on how good Go actually is, and how easily they can build a community, and what leadership, - and the quality of the leadership - they have. Nick B
Re: Go: A new system programing language
On Wed, Nov 11, 2009 at 10:55 AM, Walter Bright newshou...@digitalmars.com wrote: Bill Baxter wrote: It's harder to find those when you're skimming through trying to get the highlights with a 5 minute limit. :-) What are some things is it missing? Off the top of my head, some major ones: . exception handling . generic programming . metaprogramming . inline assembler . interface to C He does say there is a FFI that lets you call C that coming along nicely or something like that. Not sure how cumbersome it's gonna be though. . RAII . immutability for anything but strings . vector operations . operator overloading . purity . CTFE . unit testing . documentation generation They have a godoc tool written in go already, though. . ability to write systems code like implement a GC . conditional compilation . contracts . 80 bit floating point . introspection (runtime or compile time) . delegates . reference parameters Not sure if it has closures or not. Yes, he says in the video that funcs are full closures. And of course a lot of minor ones, . no _ in integer literals . no nesting comments . no entities Also . no pointer arithmetic Not sure what I think about that. Can you even have a systems language that doesn't allow pointer manipulation? But that's a good list. In the video he makes it sound like generics will probably happen eventually, they're just not sure how best to do it yet. Lack of operator overloading is annoying. I guess that's not unexpected given that their mission was to write a good language for writing servers. But if they don't do something about it (among other things) they'll miss out on the game and numerics audience. --bb
Re: Go: A new system programing language
On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter wbax...@gmail.com wrote: But that's a good list. In the video he makes it sound like generics will probably happen eventually, they're just not sure how best to do it yet. Just noticed, The Language FAQ[1] says the same thing about exceptions. They're interested, just not sure how to do it. [1] http://golang.org/doc/go_lang_faq.html#exceptions --bb
Re: Go: A new system programing language
On 11/11/2009 18:35, Bill Baxter wrote: It's harder to find those when you're skimming through trying to get the highlights with a 5 minute limit.:-) What are some things is it missing? (Also recall that D lacked even templates until long after its inception -- so if the language can muster some level of acceptance, probably popular demand will eventually lead to adding more of those missing features.) No OOP, a NoGo language for me.
Re: Go: A new system programing language
Bill Baxter wrote: Not sure what I think about that. Can you even have a systems language that doesn't allow pointer manipulation? If you cannot implement a GC in a language, then it ain't a systems language. I'm pretty sure that's a necessary criteria, less sure it is a sufficient one. But that's a good list. In the video he makes it sound like generics will probably happen eventually, they're just not sure how best to do it yet. Lack of operator overloading is annoying. I guess that's not unexpected given that their mission was to write a good language for writing servers. But if they don't do something about it (among other things) they'll miss out on the game and numerics audience. I was talking to David Held (if you haven't met him yet, you should at the next NWCPP meeting!). He has a lot of corporate experience with Java. Something he said piqued my interest when we were talking about IDEs. He said that IDEs for Java were necessary, and one reason why was because with one click the IDE will automatically generate hundreds of lines of boilerplate. It seems that the Java IDE is serving the need that other languages have macros, templates, metaprogramming and other generative programming features for. If D needed an IDE to generate such boilerplate, I'd consider D to have a severe lack of expressive power. Go doesn't seem to have any generative abilities.
Re: Go: A new system programing language
Bill Baxter wrote: On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter wbax...@gmail.com wrote: But that's a good list. In the video he makes it sound like generics will probably happen eventually, they're just not sure how best to do it yet. Just noticed, The Language FAQ[1] says the same thing about exceptions. They're interested, just not sure how to do it. [1] http://golang.org/doc/go_lang_faq.html#exceptions Exceptions are a fair amount of work to implement. I wouldn't expect it soon.
Re: typedef: what's it good for?
BCS n...@anon.com wrote:
Hello Simen,
[...] suggest that
typedef int foo;
be kept as it is, and
typedef int bar {
/* stuffs */
}
be sugar for
struct bar {
int _payload;
alias _payload this;
/* stuffs */
}
One important aspect of what I proposed is that operators that aren't
overridden still exist and use the same codegen as the base type (or are
guarantied to generate the same machine code in all cases).
struct foo {
float f;
alias f this;
}
void main( ) {
foo f;
f = 3;
f *= 4;
f /= 8;
f += 4/5;
f -= sqrt( f );
}
This compiles and runs beautifully, so it seems alias this
does what you want.
--
Simen
Re: static static
bearophile wrote:
Yigal Chripun:
Regardless of usefulness (or good design) of such variables, this sounds
extremely dangerous. The compiler must not change semantics of the
program based on optimization. optimizing away such variables most
definitely alters the semantics.
Maybe you have misunderstood, or I have explained the things badly. So I
explain again.
I have seen that LDC (when it performs link-time optimization, that's not done
in all situations) keeps just one copy of constants inside the binary even if
such constants are present in more than one template instance. In the
situations where LTO is available I think this doesn't cause problems.
Then I am half-seriously proposing a syntax like:
T foo(T)(T x) {
static static int y;
// ...
}
Where the y is now static to (shared among) all instances of the templated
function foo. This may be a little error-prone and maybe not that useful, but
again here the compiler doesn't change the semantics of the program, because
using a double static keyword the programmer has stated such intention.
Bye,
bearophile
Oh. ok. I seems I completely misunderstood you. It wasn't clear to me
before that your were talking about constants. Of course it's perfectly
OK to optimize _constants_ like that.
IMO, static is harmful and should be avoided. some newer languages
recognize this and completely remove this from the language. I'd like to
see D going in that path rather than adding even more ways to use static.
regarding your concrete proposal - as others said, you can use global
variables for that or put this inside a struct if you want to limit the
scope.
Re: Go: A new system programing language
Anders F Björklund a...@algonet.se wrote in message news:hde8r9$134...@digitalmars.com... Nick Sabalausky wrote: I meant the 1.0 release, in case that wasn't obvious ? The D project was started ten years ago (1999), I think. Ah. Since 1.0 was just an arbitrary stake-in-the-ground some time after D was already perfectly usable,so I've never thought of 1.0's release as being anything special. Sure, I think the official web site http://d-programming-language.org/ and the 1.0 release that followed was mostly to generate some interest ? I guess the next line-in-the-sand will be the book release, and whatever version of DMD 2.x (compiler and specification) that will come with it ? Perhaps, but this time around there seems to be a major effort to get as many details as possible worked out before drawing that line. (Yay! :) )
Re: typedef: what's it good for?
Hello Simen,
BCS n...@anon.com wrote:
One important aspect of what I proposed is that operators that aren't
overridden still exist and use the same codegen as the base type (or
are guarantied to generate the same machine code in all cases).
struct foo {
float f;
alias f this;
}
void main( ) {
foo f;
f = 3;
f *= 4;
f /= 8;
f += 4/5;
f -= sqrt( f );
}
This compiles and runs beautifully, so it seems alias this does what
you want.
Hmm, I missed that bit. OTOH it still dosn't cover the use the base ops
but redefine the types asspect. I so want that so that I can redo my Unit
checking type with guarantied zero runtime overhead.
Re: static static
Yigal Chripun wrote:
bearophile wrote:
Yigal Chripun:
Regardless of usefulness (or good design) of such variables, this sounds
extremely dangerous. The compiler must not change semantics of the
program based on optimization. optimizing away such variables most
definitely alters the semantics.
Maybe you have misunderstood, or I have explained the things badly. So
I explain again.
I have seen that LDC (when it performs link-time optimization, that's
not done in all situations) keeps just one copy of constants inside
the binary even if such constants are present in more than one
template instance. In the situations where LTO is available I think
this doesn't cause problems.
Then I am half-seriously proposing a syntax like:
T foo(T)(T x) {
static static int y;
// ...
}
Where the y is now static to (shared among) all instances of the
templated function foo. This may be a little error-prone and maybe not
that useful, but again here the compiler doesn't change the semantics
of the program, because using a double static keyword the programmer
has stated such intention.
Bye,
bearophile
Oh. ok. I seems I completely misunderstood you. It wasn't clear to me
before that your were talking about constants. Of course it's perfectly
OK to optimize _constants_ like that.
IMO, static is harmful and should be avoided. some newer languages
recognize this and completely remove this from the language. I'd like to
see D going in that path rather than adding even more ways to use static.
regarding your concrete proposal - as others said, you can use global
variables for that or put this inside a struct if you want to limit the
scope.
One option that hasn't been mentioned:
private ref int myInt() {
static int theInt;
return theInt;
}
void fun(T)(T arg) {
... use myInt() ...
}
Andrei
Re: static static
On Wed, Nov 11, 2009 at 1:16 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
One option that hasn't been mentioned:
private ref int myInt() {
static int theInt;
return theInt;
}
void fun(T)(T arg) {
... use myInt() ...
}
Is that a joke? That just replaces global symbol theInt with global
symbol myInt. I don't see the win.
--bb
Re: Go: A new system programing language
Bill Baxter wrote: On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter wbax...@gmail.com wrote: But that's a good list. In the video he makes it sound like generics will probably happen eventually, they're just not sure how best to do it yet. Just noticed, The Language FAQ[1] says the same thing about exceptions. They're interested, just not sure how to do it. [1] http://golang.org/doc/go_lang_faq.html#exceptions So they are roughly where D was eleven years ago. One thing I dislike about Go is the incult attitude it fosters. Apparently its creators weren't aware about the existence of D, which is quite difficult in this day and age (D is the *second* result when searching for system programming language with Google after the obligatory Wikipedia entry, so it takes a lot of effort to dismiss it as not being major and essentially pretend it doesn't exist). The authors failed to even exercise due diligence - there's a language called Go! that has even a book written about (the news is all over http://www.reddit.com/r/programming/). Also, the language does not make use of many advances that PL technology has made in the recent years. These things combined are quite indicative of an attitude towards language design that I highly disapprove of. Funny detail - one goal is to avoid stuttering (one of the first examples in the video). Yet Hello, World defines package main and function main in the main file, and imports fmt fmt. Andrei
Re: static static
Bill Baxter wrote:
On Wed, Nov 11, 2009 at 1:16 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
One option that hasn't been mentioned:
private ref int myInt() {
static int theInt;
return theInt;
}
void fun(T)(T arg) {
... use myInt() ...
}
Is that a joke? That just replaces global symbol theInt with global
symbol myInt. I don't see the win.
--bb
Forgot to mention that the function gives you the opportunity to
initialize the object in the general case.
Andrei
@safe leak fix?
Consider the code:
@safe:
T[] foo(T[] a) { return a; }
T[] bar()
{
T[10] x;
return foo(x);
}
Now we've got an escaping reference to bar's stack. This is not memory
safe. But giving up slices is a heavy burden.
So it occurred to me that the same solution for closures can be used
here. If the address is taken of a stack variable in a safe function,
that variable is instead allocated on the heap. If a more advanced
compiler could prove that the address does not escape, it could be put
back on the stack.
The code will be a little slower, but it will be memory safe. This
change wouldn't be done in trusted or unsafe functions.
Re: static static
On Wed, Nov 11, 2009 at 1:36 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
On Wed, Nov 11, 2009 at 1:16 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
One option that hasn't been mentioned:
private ref int myInt() {
static int theInt;
return theInt;
}
void fun(T)(T arg) {
... use myInt() ...
}
Is that a joke? That just replaces global symbol theInt with global
symbol myInt. I don't see the win.
--bb
Forgot to mention that the function gives you the opportunity to initialize
the object in the general case.
Ah, ok. I thought you were proposing that as another way to limit the
scope of the variable.
--bb
Re: @safe leak fix?
Hello Walter,
Consider the code:
@safe:
T[] foo(T[] a) { return a; }
T[] bar()
{
T[10] x;
return foo(x);
}
Now we've got an escaping reference to bar's stack. This is not memory
safe. But giving up slices is a heavy burden.
So it occurred to me that the same solution for closures can be used
here. If the address is taken of a stack variable in a safe function,
that variable is instead allocated on the heap. If a more advanced
compiler could prove that the address does not escape, it could be put
back on the stack.
The code will be a little slower, but it will be memory safe. This
change wouldn't be done in trusted or unsafe functions.
Sounds good. If it happens, I'd vote for a push on the static analysis to
do those proofs.
Re: @safe leak fix?
On 2009-11-11 16:47:10 -0500, Walter Bright newshou...@digitalmars.com said:
Consider the code:
@safe:
T[] foo(T[] a) { return a; }
T[] bar()
{
T[10] x;
return foo(x);
}
Now we've got an escaping reference to bar's stack. This is not memory
safe. But giving up slices is a heavy burden.
So it occurred to me that the same solution for closures can be used
here. If the address is taken of a stack variable in a safe function,
that variable is instead allocated on the heap. If a more advanced
compiler could prove that the address does not escape, it could be put
back on the stack.
The code will be a little slower, but it will be memory safe. This
change wouldn't be done in trusted or unsafe functions.
Interesting. This is exactly what I've proposed a few months ago while
we were endlessly discussing about scope as a function argument
modifier: automatic heap allocation of all escaping variables.
Of course I'm all for it. :-)
But now you should consider wether or not it should do the same in
unsafe D. If it doesn't do the same unsafe D will crash for things safe
D won't crash. If you do this in unsafe D you need a way to force a
variable not be heap allocated whatever happens. (Perhaps using 'scope'
as a storage modifier for variables.)
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Go: A new system programing language
On 2009-11-11 14:02:17 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org said: It's definitely going to be a strong competitor for D's audience. Possibly, but IMHO not on technical merit at all. It is many years behind becoming usable for a real system. It will be interesting how it plays out. At least Go programs run on my computer. I can't say the same about D2 (OS X 10.6 here). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Go: A new system programing language
On 2009-11-11 10:57:20 -0500, Robert Jacques sandf...@jhu.edu said: * Uses '+' for concatenation That's what I dislike the most about it. I quite like the syntax and I quite like the concept of interfaces as a replacement for traditional OOP. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: @safe leak fix?
Walter Bright wrote:
Consider the code:
@safe:
T[] foo(T[] a) { return a; }
T[] bar()
{
T[10] x;
return foo(x);
}
Now we've got an escaping reference to bar's stack. This is not memory
safe. But giving up slices is a heavy burden.
So it occurred to me that the same solution for closures can be used
here. If the address is taken of a stack variable in a safe function,
that variable is instead allocated on the heap. If a more advanced
compiler could prove that the address does not escape, it could be put
back on the stack.
The code will be a little slower, but it will be memory safe. This
change wouldn't be done in trusted or unsafe functions.
That's just idiotic. One of the main uses of static arrays is to _avoid_
heap memory allocation in the first place. Do what you want within
@safe, but leave unsafe (oh god what a pejorative) alone.
