Re: D loosing the battle
Thanks for all. Well, it seems as all of my concerns are answered somewhere on the net. So than i have only one more request left, please update the web pages on the http://www.digitalmars.com/d/2.0/... to have references to the more verbose net sources (and not just at the additional links) Ex. I've been checking the http://www.digitalmars.com/d/2.0/future.html and other page from the site all the time, to see what's going on and didn't even know (didn' even thought of ) there exists more detailed pages of this topic (as I thought the official site should have all the main informations). So please emphasize the wiki4D a little bit more (like in the overview, on the future page, so on) on the official page. I think it'd help newbies a lot to find informations more easily. So thanks - this a reason I like D+community, they always answer my questions :)
Re: Go: A new system programing language
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
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? 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
Re: How is D doing?
In the sc.ini file, the LINKCMD should point to a valid digitalmars link.exe.
Re: typedef: what's it good for?
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
...
}
typedef: what's it good for?
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?
Re: Go: A new system programing language
On 11/10/2009 09:02 PM, dsimcha wrote: == Quote from Phil Deets (pjdee...@gmail.com)'s article On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen <4tuu4k...@sneakemail.com> wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s I watched the video. The language sounds like a cross between Smalltalk and C, but with better concurrency support. I was somewhat underwhelmed, but I do think the concurrency features are interesting. I watched part of the video, though I'm curious enough about it that I'll probably watch the rest later, esp. if Go keeps coming up around here. However, for me personally "normal" static typing is too rigid for just about anything. I would never choose a language that didn't either have duck typing or good templates that basically amount to compile-time duck typing. I'm not sure how Go addresses this. See http://golang.org/doc/go_lang_faq.html#inheritance "Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance." That, my friend, is duck typing. Incidentally, with pure duck typing I tend to feel a little bit...naked, unconstrained. So while it's very flexible and allows any compatible types to "just work," it also makes it a little hard to define any useful constraints in practice. Smalltalk makes this a tiny bit better because of its message passing syntax (the keyword arguments make things a little more clear), but I think D strikes a nice balance with templates and metaprogramming techniques, while still having some type-constrained relationships where they make sense. -Mike
Re: Go: A new system programing language
On Wed, 11 Nov 2009 03:21:27 +0100, Knud Soerensen wrote: > Google have made a new language. > > See http://www.youtube.com/watch?v=rKnDgT73v8s You could take like the first 15 minutes and just replace the word 'Go' with D. I found the way interfaces were handled to be quit interesting, similar to how Andrei is doing his range implementation. Not sure if an object hierarchy would get in the way of having it in D though. For those who didn't/can't watch: A function requires a specific interface; the compiler checks that the functions are implemented at compile-time.
Re: Go: A new system programing language
Phil Deets Wrote: > On Tue, 10 Nov 2009 23:09:13 -0500, Justin Johansson wrote: > > > Knud Soerensen Wrote: > > > >> Google have made a new language. > >> > >> See http://www.youtube.com/watch?v=rKnDgT73v8s > > > > Some of the people in the Go team include Ken Thompson and Rob Pike. > > > > As a matter of interest these people have been mentioned in a few past D > > NG articles. > > Apparently Ken Thompson designed UTF-8. > > > > Sorry if I'm stating something you already know, but Ken Thompson also was > one of the main creators of UNIX. Thanks. I had forgotten that. Whenever a new language comes on the horizon, it's useful to know exactly who are the people behind it. I tried watching the YT video but, as unfortunately my Three mobile broadband is just so s l o w, I stopped after 10 mins. (Anybody thinking of Three in your neck of the woods for broadband forget it.) 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? Justin
Re: Go: A new system programing language
== Quote from Phil Deets (pjdee...@gmail.com)'s article > On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen > <4tuu4k...@sneakemail.com> wrote: > > Google have made a new language. > > > > See http://www.youtube.com/watch?v=rKnDgT73v8s > > > I watched the video. The language sounds like a cross between Smalltalk > and C, but with better concurrency support. I was somewhat underwhelmed, > but I do think the concurrency features are interesting. I watched part of the video, though I'm curious enough about it that I'll probably watch the rest later, esp. if Go keeps coming up around here. However, for me personally "normal" static typing is too rigid for just about anything. I would never choose a language that didn't either have duck typing or good templates that basically amount to compile-time duck typing. I'm not sure how Go addresses this.
Re: Go: A new system programing language
On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen <4tuu4k...@sneakemail.com> wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s I watched the video. The language sounds like a cross between Smalltalk and C, but with better concurrency support. I was somewhat underwhelmed, but I do think the concurrency features are interesting.
Re: Go: A new system programing language
On Tue, 10 Nov 2009 23:09:13 -0500, Justin Johansson wrote: Knud Soerensen Wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s Some of the people in the Go team include Ken Thompson and Rob Pike. As a matter of interest these people have been mentioned in a few past D NG articles. Apparently Ken Thompson designed UTF-8. Sorry if I'm stating something you already know, but Ken Thompson also was one of the main creators of UNIX.
Re: CPAN for D
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? ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- I'm a rabbit in your headlights Scared of the spotlight You don't come to visit I'm stuck on this bed
Re: Go: A new system programing language
Knud Soerensen Wrote: > Google have made a new language. > > See http://www.youtube.com/watch?v=rKnDgT73v8s Some of the people in the Go team include Ken Thompson and Rob Pike. As a matter of interest these people have been mentioned in a few past D NG articles. Apparently Ken Thompson designed UTF-8. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42316 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=43505&header Justin
Re: CPAN for D
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. -- 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: Go: A new system programing language
Knud Soerensen wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s It fills the same niche that D is trying to fill: - Systems programming language with ideas taken from dynamic languages like Python to make life easier - Fast compile times - Built-in support for concurrency
Re: Go: A new system programing language
Knud Soerensen 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 web site URL: The Go Programming Language http://golang.org/
Re: Do we really need @unsafe?
Walter Bright Wrote: > bearophile wrote: > > Walter Bright: > > > >> Furthermore, why would a safe module wish to expose unsafe functions? > >> Shouldn't the programmer instead be obliged to produce trusted functions > >> in it? > > > > If what you say is right, then what's the purpose/advantage of using: > > module foo; > > @safe: > > > > Instead of this? > > module(safe) foo; > > > > ...unsafe functions... > @safe: > ...safe functions... > @trusted: > ...trusted functions... entia non sunt multiplicanda praeter necessitatem I would err on Walter's side; the fewer the number of options/keywords to achieve the required functionality the better and no fewer. Justin
Re: How is D doing?
IkeaTheSofa Wrote: > Can't run 'C:\D\dmd\dmd\bin\..\..\dm\bin\link.exe', check PATH > ... Can anyone decipher this? The PATH is an environment variable that the system uses to locate executables. You can set the PATH environment variable using the Start Button, selecting the Settings, Control Panel menu, selecting the System icon and editing the environment variables found on the Advanced tab. What you need to do is add the DMD installation bin folder to this PATH environment variable. > Any suggestions for a begginer(in general)? > I also can not get the ecliseD plugin to work, but thats a > different issue. FWIW here is a simple tutorial on how to get the D compiler to run from within the Zeus editor: http://www.zeusedit.com/forum/viewtopic.php?t=2465 This tutorial also goes into details on setting up the PATH.
Go: A new system programing language
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
Re: Semantics of toString
On Tue, Nov 10, 2009 at 5:27 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> 2009/11/10 Andrei Alexandrescu :
>>>
>>> Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
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?)
--bb
Re: Semantics of toString
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu :
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
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
Re: Do we really need @unsafe?
On Tue, Nov 10, 2009 at 3:56 PM, 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. I don't assume that a class is entirely private when I see private: at the top. Incremental search and grep are not difficult to use if you're trying to find out if a module contains anything @unsafe. > Furthermore, why would a safe module wish to expose unsafe functions? > Shouldn't the programmer instead be obliged to produce trusted functions in > it? Private implementation might be using unsafe functions as part of the implementation of trusted functions. --bb
Re: Semantics of toString
2009/11/10 Andrei Alexandrescu :
> Denis Koroskin wrote:
>>
>> On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
>> 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
Re: Semantics of toString
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
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.
Andrei
Re: Semantics of toString
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
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?
Re: On Iteration
Andrei Alexandrescu: > I consider changing a bit D's range model following the better > understanding reflected in this article: > http://erdani.com/publications/on-iteration.html > If you have any thoughts and if you can help with the implementation, > please let us know. See my post about vectorized lazyness, it's almost orthogonal to the things you talk about, but it may be a brick of the whole Range design. (I have also written some comments about your article here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=17143 ). Bye, bearophile
Re: Semantics of toString
Don: > It's problem 2 from my original posts: being able to output something > large (eg an xml doc) in a piece-by-piece manner. See my post about vectorized lazyness. Bye, bearophile
Re: Do we really need @unsafe?
bearophile wrote: Walter Bright: Furthermore, why would a safe module wish to expose unsafe functions? Shouldn't the programmer instead be obliged to produce trusted functions in it? If what you say is right, then what's the purpose/advantage of using: module foo; @safe: Instead of this? module(safe) foo; ...unsafe functions... @safe: ...safe functions... @trusted: ...trusted functions...
Re: Do we really need @unsafe?
Walter Bright: > Furthermore, why would a safe module wish to expose unsafe functions? > Shouldn't the programmer instead be obliged to produce trusted functions > in it? If what you say is right, then what's the purpose/advantage of using: module foo; @safe: Instead of this? module(safe) foo; Bye, bearophile
Re: CPAN for D
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. AUCH! I mean Perl!
Do we really need @unsafe?
@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?
Re: On Iteration
Bill Baxter wrote: On Mon, Nov 9, 2009 at 6:17 PM, Andrei Alexandrescu wrote: dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article I consider changing a bit D's range model following the better understanding reflected in this article: http://erdani.com/publications/on-iteration.html If you have any thoughts and if you can help with the implementation, please let us know. Andrei Can you detail a little more what you're proposing? I read your article this morning, though admittedly I skimmed over some of the examples that looked like things I had already been using in my code since ranges were released. The only thing I noticed was the save() function for forward ranges. This resolves the old wart that input ranges vs. forward ranges are strictly a convention, and I think it's a good idea. Other than that, again, please distill what you're proposing. One is indeed save(), the other is separation of iteration from access. These are the only major changes. The second is quite hefty. BTW, just saw on the announce group that the article was reddited - please vote up: http://www.reddit.com/r/programming/comments/a2hv3/ Andrei I'm not sure why this one is staying so far under the radar. Just marketing? The title of the previous reddit story "Iterators must die" got a lot more attention. I'd hate to think it just comes down to picking deliberately inflammatory titles. --bb For one thing I couldn't even see the article on the "Programming" page after only a few hours after posting. I guess if it doesn't stay there for a couple of hours after posting to get primed, it never buoys to attention. Andrei
Re: Semantics of toString
Steven Schveighoffer wrote:
On Tue, 10 Nov 2009 07:49:11 -0500, Justin Johansson 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.
}
That's starting to look like a "serialize" method!
As it should. I should be able to print a 1 element container
without having to load a string representation of 1 elements in memory.
I'd also like to see the name toString changed to something more
appropriate, like output().
And although I think a direct translation is mostly possible, emulating
writefln string formatting from tango would be a burden. I don't know
if there's any way around it without coming up with some complicated
"formatting provider" interface/object implementation, and I don't think
it's worth it.
Unfortunately, I doubt Walter accepts this, it's been proposed in the
past without success.
-Steve
Walter does not feel strongly about Phobos. The save() method in "On
Iteration" intently makes it possible to define ranges as interfaces,
which in turn should pave the way towards defining a coherent text
streaming mechanism.
Andrei
Re: Semantics of toString
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
Re: CPAN for D
On Tue, Nov 10, 2009 at 3:08 PM, 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. 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
Re: CPAN for D
Walter Bright: > 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. *PERL*! :-) A CPAN-like for D may be useful, but CPAN is not just a repository, it's surely the result of several compromises, a balance. So you have to design it carefully to have similar usefulness. So I think we have first of all to list really carefully what makes CPAN what it is. Do you need a dynamic language to have a CPAN-like site? Maybe not. And D has already modules (with some design holes that eventually must be fixed). Bye, bearophile
CPAN for D
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.
Re: static static
bearophile wrote:
Steven Schveighoffer:
What's the advantage over:
static int y;
T foo(T)(T x) { // ... }
That the global name space is kept clean, the "y" name can be seen
only inside foo. Reducing the visibility of names is useful to keep
things tidy. (Inside normal functions in D static has just that
purpose).
struct MyNameSpace
{
static int y;
T foo(T)(T x) { ... }
}
Re: Vectorized Laziness
Hello bearophile, I seem to recall watching that a while ago. Fun and cool stuff IIRC.
Re: static static
Yigal Chripun wrote: I wonder, how do other languages treat static variables inside templated functions? C++ generates a different variable for each instantiation.
Vectorized Laziness
I've seen this good Google Talk video from Jan 2008, "MonetDB/X100: a (very) fast column-store", about a more efficient column-oriented DBMS: http://www.youtube.com/watch?v=yrLd-3lnZ58 The efficiency of this DBMS (something like 50 times faster) is produced by few things: - It's column-wise, this helps in several other successive optimizations too (row-oriented DBMS have their purpose still, the column-oriented are good only if you want to perform statistics on most of your data, certain kinds of data mining, etc). - At 13.57 it shows that instead of yielding single tuples (or single items, it's column-oriented), it yields arrays of about 100 fields. This allows to create primitives that are much more efficient. And the CPU can process them better, using SSE instruction too. Such small arrays are designed to fit in the CPU cache (probably L2). Such vectorized operations are also pipelined in some way. - The filtering operations often don't produce new vectors, they just mark the items as not present any more inside an array. This helps reducing the number of allocatations of new arrays. - On disk data is kept compressed, the compression is column-wise, and decompression is done only just-in-time to reduce the amount of data transfers. The number compression takes in account that often data is sorted, so it's delta-compressed, and then such delta is compressed only in a range of the Gaussian-like residual distribution (outliers are encoded directly). This compression also allows to keep large indexes in RAM, that speeds up things more. Such compression is I/O bound, the CPU performs it at max speed. - They even shown vectorized hashing, but I have not understood how they work. - Reading from the disks is done in a merged way, to avoid reading the same data many times for similar queries. (The good thing is that it's not hard to understand most things shown in this video. But I'd like to see the C code they use as "reference", that's just 3 times faster than their DBMS. Such C code may be improved). Inside, DBMS work as the lazy operations that are getting more common in D2 code, that are common in Python3, and even more in Haskell. So in D2 to reduce the overhead of the lazy operations it may be useful to use a vectorized strategy (that's meant to be almost transparent for the D programmer), so items can be produced and moved in groups, inside arrays, like in that video. (The DBMS has an interpreter overhead, it's made of fast primitives used by lazy interpreted code). This idea can be applied in other languages too. Lazy filtering is a bit less common in D2 code, so I don't know if the idea of not creating new blocks (and just marking items as absent, for example using a bit array attached to the items array) can be useful in D2 too, as in that X100 DBMS. In this discussion you have to think about pieces of code like: xfilter(xchain(xmap(_, xrange(_)), xfilter(xmap(_ or things even more complex, and not something simpler, that LDC may be able to just fully inline. (Time ago I have posted related comments on the Python newsgroup, but it was ignored.) (Partially unrelated note: years after starting to program in D, I still miss a lot strict/lazy array comprehensions in D. Maybe Walter will eventually see how handy they are.) Bye, bearophile
Re: static static
Steven Schveighoffer:
> What's the advantage over:
>
> static int y;
>
> T foo(T)(T x) {
> // ...
> }
That the global name space is kept clean, the "y" name can be seen only inside
foo. Reducing the visibility of names is useful to keep things tidy. (Inside
normal functions in D static has just that purpose).
Bye,
bearophile
Re: SIMD/intrinsincs questions
Mike Farnsworth wrote:
Was it actually rewriting the executable code to call the alternate
functions (e.g. a exe load time decision, patch the code in memory,
and then run)? I thought that sort of thing would run into all sorts
of runtime linker issues (ro code pages in memory, shared libs that
also need the rewriting, etc.), but then again, they do that with JIT
compiling all the time.
It's much simpler than that. Some C:
=
void foo_with_FPU();
void foo_without_FPU();
void (*foo)();
void main()
{
has_fp = doesCPUhaveFPU();
if (has_fp)
foo = &foo_with_FPU();
else
foo = &foo_without_FPU();
... execute app ...
(*foo)();
... execute more app ...
}
=
#if WITH_FPU
#define FOO foo_with_FPU
#else
#define FOO foo_without_FPU
#endif
void FOO()
{
... do some floating point calculations ...
}
==
dmc -DWITH_FPU -c foo.c -f -ofoo_with_fpu.obj
dmc -c foo.c -ofoo_without_fpu.obj
dmc app.obj foo_with_fpu.obj foo_without_fpu.obj
===
Hope that makes it clearer. No runtime linking, no runtime compiling, no
self-modifying code, etc.
A better way to do it is to put your FP code behind a class interface,
then have derived classes implement them, compiled with different
instruction set options. At runtime, decide which derived class to use.
Re: On Iteration
On Tue, Nov 10, 2009 at 16:07, BLS wrote: > On 10/11/2009 11:18, Lutger wrote: > > - how to do ranges over a tree? >> My first thought was that a tree would define preorder / inorder / >> postorder >> ranges, and then perhaps visitors for more complex algorithms. >> > > > I asked the same question quit a while ago... I think we have to imagine a > tree's branch as sub range. ( In other words, treat them like linear > structures) > > How to implement it? I dunno. > I had a Tree (and Graph) struct some month ago. In another module, I defined depthFirst(Tree t) and breadthFirst(Tree t) functions, which just returned a lazy range (a struct, as always), iterating in a depth-first/breadth-first way on t. Except having them as methods of Tree/Graph, how would you do it?
Re: On Iteration
On Tue, Nov 10, 2009 at 02:53, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> I consider changing a bit D's range model following the better
> understanding reflected in this article:
>
> http://erdani.com/publications/on-iteration.html
>
> If you have any thoughts and if you can help with the implementation,
> please let us know.
Very nice article, and a pleasure to read!
I'll try do do some comments, but right now what strikes me most is the
Ref!T (well, Ref) idea, this separation between traversal and
access-mode.
For example, this bothers me immensely:
auto m = map!"a*a"([0,1,2,3][]);// right-o, a lazy map, cool!
auto c = cycle(m); // boom! Doesn't work. Because map.front is not a
lvalue and cycle returns by ref.
Why can't I have my 0,1,4, 9,0,1,4, 9,0,1,4,9,... range? Must cycle.front
really return by ref?
I'd be delighted to have some ref-ranges for sorting, writing and such, but
I use simple non-ref ranges 9 times out of ten. And it seems std.range falls
over itself to provide 'ref T front'. It makes for some interesting-to-study
code, but some ugly one as well.
So, could you elaborate on this idea ? Could this be a matter of policy?
struct Cycle(R, ByRefPolicy br = ByRef.ByRef) if (isForwardRange!(R))
And then, I guess, either having different implementation of .front (ugh,
but why not) or having something like:
Ref!(T, br) front() { ...} // Is this even possible?
Some comments:
p.5:
"When calling an algorithm with ranges, you write:
vector v;
...
*// implicitly take the "all" range of v*
sort(v);"
Do you think containers shall routinely expose a .all method, returning
their content as a range, as simply as possible?
Btw, as an aside, std.range I guess should have some 'rangification'
functions for common constructs in D, like AA and static arrays. It's a bit
frustrating not to be able to write:
auto m = map!"a*a"([0,1,2,3]); // Though I know [0,1,2,3] is _not_ a range.
Maybe instead of isInputRange!R, having isInputRange!(AsRange!R) ?
or:
auto aa = ["a":1, "b":2, "cde":33];
auto someVal = filter!"a.value>3"(aa.all); // Or whatever, I'm all for
aa.all returning a lazy range with tuple(key.value) as elements.
p.7:
"The save method serves two purposes. First, in a language with reference
semantics (such as Java), lookIMadeACopy is not a copy at all—it's an alias,
another reference to the same underlying Range object. Copying the actual
object requires a method call. "
vote++. I was bitten by this just a few days ago, not thinking that
modifying an array inside a range struct would also modify the initial
array. I had to use some static if to either have _input = input.dup or
_input. Doing _input=input.save() could help me there.
Also p.7:
"So a random access range extends different concepts, depending on its
finiteness."
Yes indeed. It may be interesting to put this somewhere in the std.range
docs. Hell, it's obvious the entire article is a must read before using
std.algo and std.range.
Though it was interesting to re-discover this by myself. The first time you
start writing .back for an infinite range, you stop, frown, and then smile
:-)
p.9:
"Other, more exotic range capabilities are primitives such as lookahead or
putback."
I'd have liked to have lookahead sometimes...
What would putback do? Re-inject the last front value (and not some other
arbitrary value) into the range, returning it to its 'pristine' state?
p. 10:
"In keeping with higher-order functions that take and return other
functions, a higher-order range is one that aggregates and manipulates other
ranges, while itself still offering a range interface. Building ranges that
decorate other ranges is easy, useful, and fun."
Oh hell, yes! That has been the funniest coding I did this year.
Higher-order ranges is a nice name btw. You could also call them
meta-ranges, but it may be a bit too pretentious.
p. 10:
"As a rule, a higher-order range must offer the highest capability that it
can, subject to what the original range can offer."
Yes, but std.range/algo don't always do that. Would you be interested in
putting some .back/length/opIndex into map for example? That would make it
play nice with some other ranges/algorithms. I could put it into bugzilla...
I was looking for a name for this kind of extensible range. It's a common
pattern, and I'm tired having to write in docs that such and such range will
also have a length if the input ranges have one, etc. As these are also
wrapper ranges, I call them 'tight wrappers', but will take any name
provided.
p. 10:
"If all contained ranges offer random access *and* length, then Chain offers
random access as well."
Yes, but it's an 'if', not an 'iff'. I was bitten by this. A common test
range for me was:
auto c = chain([0,1,2][], cycle([3,4,5][])); // 0,1,2,3,4,5,3,4,5,3,4,5, ...
Except it doesn't work as Chain is written right now. It doesn't even
compile: Chain.opIndex assumes all ranges have a length when they are
random-access. But cyc
Re: static static
On Tue, Nov 10, 2009 at 1:15 PM, 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.
Make it "super static" and I'm sold. :-)
Just kidding. It's never occurred to me to want something like that.
I guess I'd probably just use a global variable. And maybe that's for
the better since it screams out more clearly that something strange is
going on. And maybe gets the developer to rethink the design one more
time before going down that path.
--bb
Re: static static
On Tue, 10 Nov 2009 16:15:26 -0500, 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.
What's the advantage over:
static int y;
T foo(T)(T x) {
// ...
}
-Steve
Re: SIMD/intrinsincs questions
Walter Bright wrote: > Don wrote: >> I'd say it's not a problem to use MMX or even SSE1. It's really, really >> difficult to find a processor that doesn't support them. I've tried. >> I've really tried. I don't think many are still around: they all have >> motherboards which require really small hard disks that you can no >> longer buy. Certainly no-one is putting new software on them. >> Earlier this year I had to install Windows3.1 (!!!) on an ancient PC at >> work, to support an ancient but expensive bit of lab equipment. Even it >> was a Pentium II. Getting the spare parts for it was a nightmare*; we >> had to ship them from 600km away. Hard disks just don't last that long. > > I do have a working Pentium around here somewhere. I even have a 486, > though I haven't turned the machine on in 15 years. I no longer have a > 386 (gave it away). > > 10 years ago, I heard that the 386 was commonly used in embedded > systems. I don't know what the base level x86 used today is. Until recently my stepdad still had his 8086 setup to interface with an old- school velotype keyboard. I even built a nasty old 5 1/2 inch floppy drive into his shiny dualcore rig, which he used to transfer plain text files between the two machines. It worked fine.
Re: static static
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
Re: SIMD/intrinsincs questions
Walter Bright Wrote: > Mike Farnsworth wrote: > > For my purposes, runtime detection is probably out the window, unless > > the tests for it can happen infrequently enough to reduce the > > overhead. There are too many SSE variations to switch on them all, > > and they incrementally provide better and better functionality that I > > could make use of. I'd rather compile different executables for > > different hardware and distribute them all (e.g. detect the SSE > > version at compile time). Really, high performance graphics is an > > exercise in getting tightly vectorized code to inline appropriately, > > eliminate as many loads and stores as possible, and then on top of > > that build algorithms that don't suck in runtime or memory/cache > > complexity. > > The way to do it is to not distribute multiple executables, but have the > initialization code detect the chip. Then, you compile the same code for > different instructions, and have a high level runtime switch between them. > > I used to do this for machines with and without x87 support. Was it actually rewriting the executable code to call the alternate functions (e.g. a exe load time decision, patch the code in memory, and then run)? I thought that sort of thing would run into all sorts of runtime linker issues (ro code pages in memory, shared libs that also need the rewriting, etc.), but then again, they do that with JIT compiling all the time. Does dmd already have some of this capability hanging around (but not used yet)? -Mike
Re: SIMD/intrinsincs questions
Adam D. Ruppe wrote: If DMD starts outputting fancier code, that's awesome for the 99% of cases where it is fine, I'd just request a compiler switch in there to turn it back to old behaviour for the <1% of cases where we don't want it. Interestingly, dmd does a very good job of Pentium instruction scheduling. I thought that was hopelessly obsolete, although it didn't actually hurt anything, so no worries. But it turns out that the Intel Atom benefits a lot from Pentium style scheduling, and no other compiler seems to support that anymore!
Re: static static
bearophile wrote: When I convert a function to a templated function (for example because I know the value of an argument at compile time, so using a template gives me a poor's man partial compilation) the static variables get duplicated for each instance of the function template, and I may need to use true global variables/constants (but if you use link-time optimization then LDC is able to remove such shared constants). So I was thinking about a "static static" attribute that avoid moving the statics to globals. Is this a useless idea? Bye, bearophile 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. I wonder, how do other languages treat static variables inside templated functions?
Re: static static
Hello bearophile,
When I convert a function to a templated function (for example because
I know the value of an argument at compile time, so using a template
gives me a poor's man partial compilation) the static variables get
duplicated for each instance of the function template, and I may need
to use true global variables/constants (but if you use link-time
optimization then LDC is able to remove such shared constants).
So I was thinking about a "static static" attribute that avoid moving
the statics to globals. Is this a useless idea?
Bye,
bearophile
you can kida cheet with a template scope variable
template Foo(T...) // unique var for each set of args.
{
int bar;
}
Re: SIMD/intrinsincs questions
On Tue, Nov 10, 2009 at 12:06:08PM -0800, Walter Bright wrote: > I do have a working Pentium around here somewhere. I actually still use my Pentium 1 computers. I have three of them, one works as a thin terminal to my newer computer, one is my secondary main computer (if/when my main computer decides to quit working and I'm waiting on replacement parts, I go back to the old box - it was my main from 1996 through to 2005! I also use it for the occasional multiplayer game), and the last one I still use to host some small, low traffic websites. I don't buy into the "omg must be bleeding edge or else" philosophy. I'll work these computers until their parts fail entirely! But, I'm surely in the minority. Heck, I still sometimes write 16 bit DOS code for those computers! If DMD starts outputting fancier code, that's awesome for the 99% of cases where it is fine, I'd just request a compiler switch in there to turn it back to old behaviour for the <1% of cases where we don't want it. -- Adam D. Ruppe http://arsdnet.net
Re: SIMD/intrinsincs questions
Mike Farnsworth wrote: For my purposes, runtime detection is probably out the window, unless the tests for it can happen infrequently enough to reduce the overhead. There are too many SSE variations to switch on them all, and they incrementally provide better and better functionality that I could make use of. I'd rather compile different executables for different hardware and distribute them all (e.g. detect the SSE version at compile time). Really, high performance graphics is an exercise in getting tightly vectorized code to inline appropriately, eliminate as many loads and stores as possible, and then on top of that build algorithms that don't suck in runtime or memory/cache complexity. The way to do it is to not distribute multiple executables, but have the initialization code detect the chip. Then, you compile the same code for different instructions, and have a high level runtime switch between them. I used to do this for machines with and without x87 support.
Re: SIMD/intrinsincs questions
Don wrote: I'd say it's not a problem to use MMX or even SSE1. It's really, really difficult to find a processor that doesn't support them. I've tried. I've really tried. I don't think many are still around: they all have motherboards which require really small hard disks that you can no longer buy. Certainly no-one is putting new software on them. Earlier this year I had to install Windows3.1 (!!!) on an ancient PC at work, to support an ancient but expensive bit of lab equipment. Even it was a Pentium II. Getting the spare parts for it was a nightmare*; we had to ship them from 600km away. Hard disks just don't last that long. I do have a working Pentium around here somewhere. I even have a 486, though I haven't turned the machine on in 15 years. I no longer have a 386 (gave it away). 10 years ago, I heard that the 386 was commonly used in embedded systems. I don't know what the base level x86 used today is.
Re: SIMD/intrinsincs questions
bearophile wrote: Walter Bright: Modern compilers don't do much better. The point of diminishing returns was clearly reached. I routinely see D benchmarks that are 2+ times faster with LDC compared to DMD. Have to be careful about benchmarks without looking at why. A few months ago, a benchmark was posted here purportedly showing that dmd was awful at integer math. Turns out, the problem was entirely in the long divide function, not the code generator at all. I rewrote the long divide helper function, and problem solved.
Re: SIMD/intrinsincs questions
Chad J Wrote: > Walter Bright wrote: > > > > ... To generate the code directly, assuming the existence of SSE, > > is to mean the code will only run on modern chips. Whether or not this > > is a problem depends on your application. > > If MMX/SSE/SSE2 optimizations are low-lying fruit, I'd at least like to > have an -sse (and maybe -sse2, -sse3, and -no-sse) switch for the > compiler to determine whether the compiler emits those instructions or > not. > > I'm also wondering if a more ideal approach (and perhaps additional > option to those above) would be to borrow the best of JIT compilation > and emit multiple code paths. Maybe the program would have a bootstrap > phase when starting up where it would call cpuid, find out what it has > available, rewrite the main binary to use the optimal paths, then > execute the main binary. That way feature detection doesn't happen > while the program itself is running, and thus doesn't slow down the > computations as they happen. Then passing -sse* would cause it to not > emit the bootstrap, but instead just assume that the instructions will > be available. Incidentally, if you use LLVM to compile to their bitcode, you can at runtime do exactly this sort of thing based on the host hardware, selecting opt passes and having it run codegen based on your exact hardware. As long as using a given intrinsic falls through to the right glue code where it isn't supported, or else you let the compiler deduce where to use the fancier instructions (not as likely to happen), that works out nicely. -Mike
Re: On Iteration
On Tue, Nov 10, 2009 at 11:34 AM, Phil Deets wrote: > On Tue, 10 Nov 2009 05:18:59 -0500, Lutger > wrote: > >> - why is a UTF-string iterator bidirectional and why is that unexpected? > > I think it is wouldn't support random access since accessing the nth code > point (code points are similar to characters) is not a constant time > operation since different code points can be made up of different numbers of > bytes. That isn't necessarily intuitive since UTF-strings are stored > contiguously in memory; so you might expect them to be random-accessible. I thought the comment was about this: you might expect it to be just a forward iterator, but (surprise!) you can also find the previous codepoint in O(1) time, due to lead units being in values ranges distinct from following units. But I still don't find it particularly unexpected. It's probably only unexpected if you don't know anything about UTF other than the fact that each character is a variable number of bytes. --bb
Re: SIMD/intrinsincs questions
Walter Bright wrote: > > ... To generate the code directly, assuming the existence of SSE, > is to mean the code will only run on modern chips. Whether or not this > is a problem depends on your application. If MMX/SSE/SSE2 optimizations are low-lying fruit, I'd at least like to have an -sse (and maybe -sse2, -sse3, and -no-sse) switch for the compiler to determine whether the compiler emits those instructions or not. I'm also wondering if a more ideal approach (and perhaps additional option to those above) would be to borrow the best of JIT compilation and emit multiple code paths. Maybe the program would have a bootstrap phase when starting up where it would call cpuid, find out what it has available, rewrite the main binary to use the optimal paths, then execute the main binary. That way feature detection doesn't happen while the program itself is running, and thus doesn't slow down the computations as they happen. Then passing -sse* would cause it to not emit the bootstrap, but instead just assume that the instructions will be available.
Re: On Iteration
On Tue, 10 Nov 2009 05:18:59 -0500, Lutger wrote: - why is a UTF-string iterator bidirectional and why is that unexpected? I think it is wouldn't support random access since accessing the nth code point (code points are similar to characters) is not a constant time operation since different code points can be made up of different numbers of bytes. That isn't necessarily intuitive since UTF-strings are stored contiguously in memory; so you might expect them to be random-accessible.
Re: Request for comment _ survey of the 'D programming language ' community.
Leandro Lucarella wrote: Nick B, el 9 de noviembre a las 15:19 me escribiste: What is the definition that this community is succeeding / making progress ? I would like to propose there is _only_ one. That the community is growing from year to year. From ten years ago when Walter, started the D project it certainly has grown, but compared to one year ago, has it grown or shrunk ? Without any hard data there is no way to know. I propose a brief email survey to gather of the size of the community, repeated at yearly intervals. Proposed questions: Name: Alternative name (handle:) Number of years using D: Framework: Phobos ; Tango, Both; None; & Other Comments ? Git does a very nice and useful survey each year: http://git.or.cz/gitwiki/GitSurvey2009 An DVCS is not the same as a language, but it can be taken as a base. Hi Leandro, thank you for this high quality example. I have had very little response, (and one response privately), so I can only assume that almost no one sees any value in this. I thought Walter might although. So I will do nothing for now, and may raise this next year. cheers Nick B ps perhaps this community need a marketing director.
Re: On Iteration
On Tue, 10 Nov 2009 06:59:31 -0800, Bill Baxter wrote: > On Mon, Nov 9, 2009 at 6:17 PM, Andrei Alexandrescu > wrote: >> dsimcha wrote: >>> >>> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s >>> article I consider changing a bit D's range model following the better understanding reflected in this article: http://erdani.com/publications/on-iteration.html If you have any thoughts and if you can help with the implementation, please let us know. Andrei >>> >>> Can you detail a little more what you're proposing? I read your >>> article this >>> morning, though admittedly I skimmed over some of the examples that >>> looked like >>> things I had already been using in my code since ranges were released. >>> The only >>> thing I noticed was the save() function for forward ranges. This >>> resolves the old >>> wart that input ranges vs. forward ranges are strictly a convention, >>> and I think >>> it's a good idea. Other than that, again, please distill what you're >>> proposing. >> >> One is indeed save(), the other is separation of iteration from access. >> These are the only major changes. The second is quite hefty. >> >> BTW, just saw on the announce group that the article was reddited - >> please vote up: http://www.reddit.com/r/programming/comments/a2hv3/ >> >> >> Andrei >> >> > I'm not sure why this one is staying so far under the radar. Just > marketing? The title of the previous reddit story "Iterators must die" > got a lot more attention. I'd hate to think it just comes down to > picking deliberately inflammatory titles. > > --bb I think it's another case of "Iterators? Again?". The announcement to finish the topic is likely to have a better perception.
Re: Semantics of toString
Bill Baxter wrote:
2009/11/10 Denis Koroskin <2kor...@gmail.com>:
On Tue, 10 Nov 2009 15:30:20 +0300, Don wrote:
Bill Baxter wrote:
On Tue, Nov 10, 2009 at 2:51 AM, Don wrote:
Lutger wrote:
Justin Johansson wrote:
Lutger Wrote:
Justin Johansson wrote:
I assert that the semantics of "toString" or similarly
named/purposed
methods/functions in many PL's (including and not limited to D) is
ill-defined.
To put this statement into perspective, I would be most appreciative
of
D NG readers responding with their own idea(s) of what the semantics
of
"toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry.
Semantics of toString would depend on the object, I would think there
are
three general types of objects:
1. objects with only one sensible or one clear default string
representations, like integers. Maybe even none of these exist
(except
strings themselves?)
2. objects that, given some formatting options or locale have a clear
string representation. floating points, dates, curreny and the like.
3. objects that have no sensible default representation.
toString() would not make sense for 3) type objects and only for 2)
type
objects as part of a formatting / localization package.
toString() as a debugging aid sometimes doubles as a formatter for 1)
and
2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger.
Do you think it would make better sense if programming languages/their
libraries separated functions/methods which are currently loosely
purposed
as "toString" into methods which are more specific to the types you
suggest (leaving only the types/classifications and number thereof to
argue about)?
In my own D project, I've introduced a toDebugString method and left
toString alone. There are times when I like D's default toString
printing
out the name of the object
class. For debug purposes there are times also when I like to see a
string printed
out in quotes so you can tell the difference between "123" and 123.
Then
again, and since I'm working on a scripting language, sometimes I like
to
see debug output distinguish between different numeric types.
Anyway going by the replies on this topic, looks like most people view
toString as being good for debug purposes and that about it.
Cheers
Justin
Your design makes better sense (to me at least) because it is based on
why
you want a string from some object.
Take .NET for example: it does provide very elaborate and nice
formatting
options based and toString() with parameters. For some types however,
the
default toString() gives you the name of the type itself which is in no
way
related to formatting an object. You learn to work with it, but I find
it a
bit muddled.
As a last note, I think people view toString as a debug thing mostly
because it is very underpowered.
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.
You can definitely do something with it -- printf debugging. And if I
were using BigInt, that's exactly why I'd want BigInt to have a
toString.
I almost always want to print the value out in hex. And with some kind of
digit separators, so that I can see how many digits it has.
Just out of curiousity, how does someone print out the
value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper
formatting options, it's the biggest thing which isn't done. I hit one too
many compiler segfaults and starting patching the compiler instead . But
I really want a decent toString().
Given a BigInt n, you should be able to just do
writefln("%s %x", n, n); // Phobos
formatln("{0} {0:X}", n); // Tango
To solve this part of the issue, it would be enough to have toString()
take a string parameter. (it would be "x" or "X" in this case).
string toString(string fmt);
But the performance would still be very poor, and that's much more
difficult to solve.
Yes, it would solve half of the toString problems.
Another part (i.e. memory allocation) could be solved by providing an
optional buffer to the toString:
char[] toString(string format = "s" /* comes from %s which is a default
qualifier */, char[] buffer = null)
{
// operate on the buffer, possibly resizing it
// which is safe and fast - it only allocates
// when *really* necessary, instead of always, as now
return buffer;
}
With Don's delegate idea, if you do have a toString with special
performance concerns, then it can use its own stack-allocated buffer.
void toString(void delegate(const(char)[]) put, string format)
{
char[512] preallocBuffer;
foreach( ... ) {
...
put(preallocBuffer[0..lenUsed]);
}
}
Thanks. 'put' is so much better than 'sink'.
If the buffer is going to be passed in, then
Re: Semantics of toString
grauzone wrote: Don wrote: grauzone 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. How are you supposed to print a BigInt then? How are you supposed to print one with it? It doesn't help. (The problem even more obvious if you consider BigFloat). Just put it into an "interface DebugOutput", remove Object.toString(), and be done with it. That interface could be defined in the same module as writefln or format, and its use will be clear. BigInt is a struct, so it doesn't have interfaces. Structs are a different matter. Nothing dictates that a struct should have a toString method, or what arguments that method should have, right? (There's this compiler/runtime hack to make struct toString work with writefln, but now that wirtefln uses compile time varargs, it can go.) This discussion is about that hack. Yes, it might be unnecessary if compile time varargs work sufficiently well.
static static
When I convert a function to a templated function (for example because I know the value of an argument at compile time, so using a template gives me a poor's man partial compilation) the static variables get duplicated for each instance of the function template, and I may need to use true global variables/constants (but if you use link-time optimization then LDC is able to remove such shared constants). So I was thinking about a "static static" attribute that avoid moving the statics to globals. Is this a useless idea? Bye, bearophile
Re: Semantics of toString
Bill Baxter: > Well, anyway, [...] You are welcome. Bye, bearophile
Re: Semantics of toString
2009/11/10 Denis Koroskin <2kor...@gmail.com>:
> On Tue, 10 Nov 2009 15:30:20 +0300, Don wrote:
>
>> Bill Baxter wrote:
>>>
>>> On Tue, Nov 10, 2009 at 2:51 AM, Don wrote:
Lutger wrote:
>
> Justin Johansson wrote:
>
>> Lutger Wrote:
>>
>>> Justin Johansson wrote:
>>>
I assert that the semantics of "toString" or similarly
named/purposed
methods/functions in many PL's (including and not limited to D) is
ill-defined.
To put this statement into perspective, I would be most appreciative
of
D NG readers responding with their own idea(s) of what the semantics
of
"toString" are (or should be) in a language agnostic ideology.
>>> My other reply didn't take the language agnostic into account, sorry.
>>>
>>> Semantics of toString would depend on the object, I would think there
>>> are
>>> three general types of objects:
>>>
>>> 1. objects with only one sensible or one clear default string
>>> representations, like integers. Maybe even none of these exist
>>> (except
>>> strings themselves?)
>>>
>>> 2. objects that, given some formatting options or locale have a clear
>>> string representation. floating points, dates, curreny and the like.
>>>
>>> 3. objects that have no sensible default representation.
>>>
>>> toString() would not make sense for 3) type objects and only for 2)
>>> type
>>> objects as part of a formatting / localization package.
>>>
>>> toString() as a debugging aid sometimes doubles as a formatter for 1)
>>> and
>>> 2) class objects, but that may be more confusing than it's worth.
>>>
>> Thanks for that Lutger.
>>
>> Do you think it would make better sense if programming languages/their
>> libraries separated functions/methods which are currently loosely
>> purposed
>> as "toString" into methods which are more specific to the types you
>> suggest (leaving only the types/classifications and number thereof to
>> argue about)?
>>
>> In my own D project, I've introduced a toDebugString method and left
>> toString alone. There are times when I like D's default toString
>> printing
>> out the name of the object
>> class. For debug purposes there are times also when I like to see a
>> string printed
>> out in quotes so you can tell the difference between "123" and 123.
>> Then
>> again, and since I'm working on a scripting language, sometimes I like
>> to
>> see debug output distinguish between different numeric types.
>>
>> Anyway going by the replies on this topic, looks like most people view
>> toString as being good for debug purposes and that about it.
>>
>> Cheers
>> Justin
>>
> Your design makes better sense (to me at least) because it is based on
> why
> you want a string from some object.
> Take .NET for example: it does provide very elaborate and nice
> formatting
> options based and toString() with parameters. For some types however,
> the
> default toString() gives you the name of the type itself which is in no
> way
> related to formatting an object. You learn to work with it, but I find
> it a
> bit muddled.
> As a last note, I think people view toString as a debug thing mostly
> because it is very underpowered.
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.
>>>
>>> You can definitely do something with it -- printf debugging. And if I
>>> were using BigInt, that's exactly why I'd want BigInt to have a
>>> toString.
>>
>> I almost always want to print the value out in hex. And with some kind of
>> digit separators, so that I can see how many digits it has.
>>
>> Just out of curiousity, how does someone print out the
>>>
>>> value of a BigInt right now?
>>
>> In Tango, there's just .toHex() and .toDecimalString(). Needs proper
>> formatting options, it's the biggest thing which isn't done. I hit one too
>> many compiler segfaults and starting patching the compiler instead . But
>> I really want a decent toString().
>>
>> Given a BigInt n, you should be able to just do
>>
>> writefln("%s %x", n, n); // Phobos
>> formatln("{0} {0:X}", n); // Tango
>>
>> To solve this part of the issue, it would be enough to have toString()
>> take a string parameter. (it would be "x" or "X" in this case).
>>
>> string toString(string fmt);
>> But the performance would still be very poor, and that's much more
>> difficult to solve.
>
> Yes, it would solve half of the toString problems.
>
> Another part (i.e. memory allocation) could be solved by providing an
> optional buffer to t
Re: Semantics of toString
On Tue, Nov 10, 2009 at 9:16 AM, bearophile wrote: > Bill Baxter: >> Maybe it's just my ignorance of BigNum issues, but those links look to >> me to be about divsion and not generating string representations. Are >> those somehow synonymous in BigInt land? > > Look the numeral() function inside here from those blog posts: > http://www.dd.chalmers.se/~frejohl/code/div.py > > To convert a positive integer to string you have to keep dividing a number by > 10, and accumulate the modulus as the digit, converted to ['0', '9']. When > the number is zero you are done: > > n = 541489 > result = "" > while n: > n, digit = divmod(n, 10) > result = str(digit) + result # don't do this > print repr(result) # prints '541489' > > But all those large divisions are slow if the number is huge. So that div.py > python program shows a faster algorithm that does something smarter, to > decrease the computational complexity of all that. Well, anyway, slowness of BigInt is not what Don was referring to. He was talking about the general slowness of a toString interface that forces allocating enough memory to hold the entire result, instead of being able to dole out the result piecemeal. --bb
Re: SIMD/intrinsincs questions
Walter Bright Wrote: > Don wrote: > > The bad news: The DMD back-end is a state-of-the-art backend from the > > late 90's. Despite its age, its treatment of integer operations is, in > > general, still quite respectable. > > Modern compilers don't do much better. The point of diminishing returns > was clearly reached. > > > However, it _never_ generates SSE > > instructions. Ever. However, array operations _are_ detected, and they > > become to calls to library functions which use SSE if available. That's > > not bad for moderately large arrays -- 200 elements or so -- but of > > course it's completely non-optimal for short arrays. > > > > The good news: Now that static arrays are passed by value, introducing > > inline SSE support for short arrays suddenly makes a lot of sense -- > > there can be a big performance benefit for a small backend change; it > > could be done without introducing SSE anywhere else. Most importantly, > > it doesn't require any auto-vectorisation support. > > What the library functions also do is have a runtime switch based on the > capabilities of the processor, switching to operations tailored to that > processor. To generate the code directly, assuming the existence of SSE, > is to mean the code will only run on modern chips. Whether or not this > is a problem depends on your application. For my purposes, runtime detection is probably out the window, unless the tests for it can happen infrequently enough to reduce the overhead. There are too many SSE variations to switch on them all, and they incrementally provide better and better functionality that I could make use of. I'd rather compile different executables for different hardware and distribute them all (e.g. detect the SSE version at compile time). Really, high performance graphics is an exercise in getting tightly vectorized code to inline appropriately, eliminate as many loads and stores as possible, and then on top of that build algorithms that don't suck in runtime or memory/cache complexity. Often in computer graphics you end up distilling a huge amount of operations down to SIMD instructions that are very highly-threaded and have (hopefully) minimal I/O. If you introduce any extra overhead for getting to those SIMD instructions, you usually take a measurable throughput hit. I'd like to see D give me a much better mix of high throughput + high coding productivity. As it stands, I've got high throughput + medium coding productivity in C++, and medium throughput + fairly high coding productivity in C#. I've started looking at some ldc code to lurch towards this goal, and if there is something I can look at in dmd2 itself to help out, I'd love to. Just point me where you think I ought to start. -Mike
Re: D loosing the battle
My first observation is that you are using D2 expecting it to be stable. The website still doesn't make it clear that D2 should be used for minor tasks to experiment with the language. That said, I can see the concern that if you code for D1 you'll still have the incompatibility. But it would still be better to go from D1 to D2 than try and match all the changes as they happen. There is a page to help with this transition too: http://www.digitalmars.com/d/2.0/features2.html There is also a more permanent place to find the proposal for properties. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs It seems Walter has gone with the idea of annotations, though no formal word on that: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 There is also a page with many things that still need changed in the compiler, ideas Walter wanted in, informal suggestions that haven't gotten feedback: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections I hope these likes have been what you were looking for.
Re: D loosing the battle
gzp: > but by the time I was almost finished, I saw some major > features are being altered. The situation is really simple: D2 is alpha state still, don't use it to develop real code. Use it only if you want to do experiments or if you want to add things to its std lib. For all other usages use D1. > there was a proposal about altering the > property. There`s also been a voting, but now there's no sign of this > anywhere (except for the forum). It's being implemented. Probably it will be present when D2 comes out of alpha state. > The same stands for the scoped variables. I've started to use it to > allocate class instances of (small)matrices on the stack, but than i've > read, it will go. Scoped objects will not go away (lot of people will not accept such change). And with some luck we'll see scoped objects inside other objects (and maybe scoped dynamic arrays too, that are easy to implement and to make safe). >Missing stable, compiler with enhanced optimization features (minor > issue). LDC optimizes quite well. Bye, bearophile
Re: D loosing the battle
I've been following D for a while, and I've lost some of my interest too for several reasons. The continuous redesign. When I started to implement s/g, I checked what opportunities I have, what the language specification tells, and what others did to achieve a similar goal. Then I implemented my own version, but by the time I was almost finished, I saw some major features are being altered. (scope - allocation, Ranges, operator overloading, struct constructors, array referencing, property, etc.). I know D is a language being developed, but when core functionality is being altered all the time, it's really hard to design/implement new libraries. At least D users (especially for newbies) should be informed of the state of the progress, not only through mailing list since the have lot's of proposals those are dropped immediately. ex: The language reference should be up to date as much as possible and *HILIGHT* the features being redesigned and what are the proposals (in 1-2 words). I'm sure Walter, Andrei, and the other (key) developers have a todo-list (and some time-tables) for the proposed modifications. (If no, D is Doomed for sure, since after a while no one knows what's finished and what is still to be implemented, and what was the planned feature) For example, some time back, there was a proposal about altering the property. There`s also been a voting, but now there's no sign of this anywhere (except for the forum). I liked the property idea a lot, but I cannot use it, i cannot even design my code to later update it using properties as there's no sign of its currnet state. I know the current property implementation is based on omitting the () signs, but I'm not using it, as it was meant to be changed, but when and how ??? The same stands for the scoped variables. I've started to use it to allocate class instances of (small)matrices on the stack, but than i've read, it will go. So I have to redesign things to use structs instead of classes to have them on the stack, but using struct requires other type of initialization mechanism, as they have no default constructor to overload. And now the construction of the struct is being altered as well. And so on... I don't require a language with all the features completed, but altering the core features makes it impossible to create new/stable libraries. I can go quite well without the opPow, and other operator overloading stuffs. I will update the library if they are present in the language and call the my appropriate function ( 1+2 additional lines to the source) but how to design anything if basic semantics are changing ?! Lack of IDE (minor issue). It's not a big problem, actually I can go quite well without an IDE, or without a debugger either (good old printf:) in most cases. (I've seen there were made great progresses in this as well) Missing stable, compiler with enhanced optimization features (minor issue). I've tried to reimplement some of my older algorithm from c++, but finally I haven't even tried most of them, as I didn't see any optimization in the asm codes for my simplest range. (The popFront, front, empty function calls were not inlined at all - though i didn't experienced with it too much as I could not find an appropriate IDE/debugger to check the asm code and insert breakpoints) I've tried to use gdc, but it only superts D1. The patch/branch to use D2 i have to be built manually. I don't want to compile, patch, etc. a C/C++ project from some unstable source and work for hours to have a working D compiler. I want to do D. So for these reason I'm in a passive state and i'm waiting where D goes to. According to my oppinion there are many other programmars following D in a passive way like I do. I like many features of D (and dislike some - but it's ok, cannot have a language that fits all the desires for everybody ), but while it's in a so mutable state, it`s hard to use it. I have to wait while most features are made immutable (and not const, that can be altered through some nasty const_cast proposals :) ). Regards, Gzp
Re: Semantics of toString
On Tue, 10 Nov 2009 15:30:20 +0300, Don wrote:
Bill Baxter wrote:
On Tue, Nov 10, 2009 at 2:51 AM, Don wrote:
Lutger wrote:
Justin Johansson wrote:
Lutger Wrote:
Justin Johansson wrote:
I assert that the semantics of "toString" or similarly
named/purposed
methods/functions in many PL's (including and not limited to D) is
ill-defined.
To put this statement into perspective, I would be most
appreciative of
D NG readers responding with their own idea(s) of what the
semantics of
"toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account,
sorry.
Semantics of toString would depend on the object, I would think
there
are
three general types of objects:
1. objects with only one sensible or one clear default string
representations, like integers. Maybe even none of these exist
(except
strings themselves?)
2. objects that, given some formatting options or locale have a
clear
string representation. floating points, dates, curreny and the like.
3. objects that have no sensible default representation.
toString() would not make sense for 3) type objects and only for 2)
type
objects as part of a formatting / localization package.
toString() as a debugging aid sometimes doubles as a formatter for
1)
and
2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger.
Do you think it would make better sense if programming
languages/their
libraries separated functions/methods which are currently loosely
purposed
as "toString" into methods which are more specific to the types you
suggest (leaving only the types/classifications and number thereof to
argue about)?
In my own D project, I've introduced a toDebugString method and left
toString alone. There are times when I like D's default toString
printing
out the name of the object
class. For debug purposes there are times also when I like to see a
string printed
out in quotes so you can tell the difference between "123" and 123.
Then
again, and since I'm working on a scripting language, sometimes I
like to
see debug output distinguish between different numeric types.
Anyway going by the replies on this topic, looks like most people
view
toString as being good for debug purposes and that about it.
Cheers
Justin
Your design makes better sense (to me at least) because it is based
on why
you want a string from some object.
Take .NET for example: it does provide very elaborate and nice
formatting
options based and toString() with parameters. For some types however,
the
default toString() gives you the name of the type itself which is in
no way
related to formatting an object. You learn to work with it, but I
find it a
bit muddled.
As a last note, I think people view toString as a debug thing mostly
because it is very underpowered.
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.
You can definitely do something with it -- printf debugging. And if I
were using BigInt, that's exactly why I'd want BigInt to have a
toString.
I almost always want to print the value out in hex. And with some kind
of digit separators, so that I can see how many digits it has.
Just out of curiousity, how does someone print out the
value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper
formatting options, it's the biggest thing which isn't done. I hit one
too many compiler segfaults and starting patching the compiler instead
. But I really want a decent toString().
Given a BigInt n, you should be able to just do
writefln("%s %x", n, n); // Phobos
formatln("{0} {0:X}", n); // Tango
To solve this part of the issue, it would be enough to have toString()
take a string parameter. (it would be "x" or "X" in this case).
string toString(string fmt);
But the performance would still be very poor, and that's much more
difficult to solve.
Yes, it would solve half of the toString problems.
Another part (i.e. memory allocation) could be solved by providing an
optional buffer to the toString:
char[] toString(string format = "s" /* comes from %s which is a default
qualifier */, char[] buffer = null)
{
// operate on the buffer, possibly resizing it
// which is safe and fast - it only allocates
// when *really* necessary, instead of always, as now
return buffer;
}
You can use it almost the same way you used it before:
string s = assumeUnique(someObject.toString()); // because we return a
mutable string now
Optimization example:
int sprintf(string format, ...)
{
char[512] preallocatedBuffer;
char[] buffer = preallocatedBuffer[]; // buffer may grow, but
// initially points to a preallocatedBuffer
char[] storage = buffer[]; // storage fo
Re: Semantics of toString
Bill Baxter: > Maybe it's just my ignorance of BigNum issues, but those links look to > me to be about divsion and not generating string representations. Are > those somehow synonymous in BigInt land? Look the numeral() function inside here from those blog posts: http://www.dd.chalmers.se/~frejohl/code/div.py To convert a positive integer to string you have to keep dividing a number by 10, and accumulate the modulus as the digit, converted to ['0', '9']. When the number is zero you are done: n = 541489 result = "" while n: n, digit = divmod(n, 10) result = str(digit) + result # don't do this print repr(result) # prints '541489' But all those large divisions are slow if the number is huge. So that div.py python program shows a faster algorithm that does something smarter, to decrease the computational complexity of all that. Bye, bearophile
Re: Semantics of toString
On Tue, Nov 10, 2009 at 7:29 AM, Don wrote:
> Bill Baxter wrote:
>>
>> On Tue, Nov 10, 2009 at 4:40 AM, 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.
>>>
>>> }
>>
>> That looks pretty good, actually.
>> I guess I would like to see plain no-arg toString() still supported.
>
> The thing is, the toString() function is essentially a virtual function
> present in every struct. Each one of those functions needs a very strong
> justification to exist.
Structs can't have virtual functions... so what do you mean?
>> A default toString() could be implemented in terms of the fancy one as:
>>
>> string toString() {
>> char buf[];
>> toString( (string s) { buf ~= s; }, "" );
>> return assumeUnique!(buf);
>> }
>>
>> could be a mixin in a library I suppose.
>
> More for the benefit of consumers, or producers?
Consumers. I was just thinking it would be a little annoying to have
to reproduce the above 3-line snippet of code every time I want to get
the string version of an object.
But I guess such needs can be adequately served by std.string.format
or sformat. So scratch that, no old-style toString() needed.
> Because
> void toString(void delegate(const(char)[]) sink, string fmt) {
> sink("xxx");
> }
> isn't much more complex than:
> string toString()
> {
> return "xxx";
> }
> other than the signature.
Yeh, for authors of toString methods it's fine.
Well, a different way to write delegates would be nice, but that's a
different discussion.
>> I think I would like to see the format strings not necessarily tied to
>> writefln's particular format.
>
> I think the format strings are actually pretty similar, Tango vs writefln?
> There might be enough common ground. I think the Tango format is a slight
> superset of the writefln one.
Pretty similar, maybe, but I'd be surprised if they just happened to
be identical without any attempt at compatibility having been made.
--bb
Re: Semantics of toString
On Tue, Nov 10, 2009 at 7:04 AM, bearophile wrote: > Bill Baxter: > >> Though they may be useful, those don't look to have anything to do >> with formatting user types into strings, which is the subject at hand. > > Don has said: "But the performance would still be very poor, and that's much > more difficult to solve." And those links show a way to quickly convert a > large multi-precision integer into a string. What is that I am missing? Maybe it's just my ignorance of BigNum issues, but those links look to me to be about divsion and not generating string representations. Are those somehow synonymous in BigInt land? --bb
Re: Semantics of toString
Don wrote: grauzone 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. How are you supposed to print a BigInt then? How are you supposed to print one with it? It doesn't help. (The problem even more obvious if you consider BigFloat). Just put it into an "interface DebugOutput", remove Object.toString(), and be done with it. That interface could be defined in the same module as writefln or format, and its use will be clear. BigInt is a struct, so it doesn't have interfaces. Structs are a different matter. Nothing dictates that a struct should have a toString method, or what arguments that method should have, right? (There's this compiler/runtime hack to make struct toString work with writefln, but now that wirtefln uses compile time varargs, it can go.)
Re: Semantics of toString
grauzone 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. How are you supposed to print a BigInt then? How are you supposed to print one with it? It doesn't help. (The problem even more obvious if you consider BigFloat). Just put it into an "interface DebugOutput", remove Object.toString(), and be done with it. That interface could be defined in the same module as writefln or format, and its use will be clear. BigInt is a struct, so it doesn't have interfaces.
Re: Semantics of toString
bearophile wrote: Bill Baxter: Though they may be useful, those don't look to have anything to do with formatting user types into strings, which is the subject at hand. Don has said: "But the performance would still be very poor, and that's much more difficult to solve." And those links show a way to quickly convert a large multi-precision integer into a string. What is that I am missing? It's problem 2 from my original posts: being able to output something large (eg an xml doc) in a piece-by-piece manner.
Re: Semantics of toString
Bill Baxter wrote:
On Tue, Nov 10, 2009 at 4:40 AM, 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.
}
That looks pretty good, actually.
I guess I would like to see plain no-arg toString() still supported.
The thing is, the toString() function is essentially a virtual function
present in every struct. Each one of those functions needs a very strong
justification to exist.
A default toString() could be implemented in terms of the fancy one as:
string toString() {
char buf[];
toString( (string s) { buf ~= s; }, "" );
return assumeUnique!(buf);
}
could be a mixin in a library I suppose.
More for the benefit of consumers, or producers?
Because
void toString(void delegate(const(char)[]) sink, string fmt) {
sink("xxx");
}
isn't much more complex than:
string toString()
{
return "xxx";
}
other than the signature.
I think I would like to see the format strings not necessarily tied to
writefln's particular format.
I think the format strings are actually pretty similar, Tango vs
writefln? There might be enough common ground. I think the Tango format
is a slight superset of the writefln one.
Re: Semantics of toString
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.
How are you supposed to print a BigInt then?
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.
}
Just put it into an "interface DebugOutput", remove Object.toString(),
and be done with it. That interface could be defined in the same module
as writefln or format, and its use will be clear.
Re: On Iteration
On 10/11/2009 11:18, Lutger wrote: Andrei Alexandrescu wrote: I consider changing a bit D's range model following the better understanding reflected in this article: http://erdani.com/publications/on-iteration.html Very good read. - how to do ranges over a tree? My first thought was that a tree would define preorder / inorder / postorder ranges, and then perhaps visitors for more complex algorithms. I asked the same question quit a while ago... I think we have to imagine a tree's branch as sub range. ( In other words, treat them like linear structures) How to implement it? I dunno. IMO it would make sense to implement some basic data structures for std.mutable.dtl. (Tree like structures) ...not production ready, just as Range "proof of product" test. atm I am implementing two of them : skip lists and left leaning rb trees. Would be nice to have some support btw.
Re: Semantics of toString
Bill Baxter: > Though they may be useful, those don't look to have anything to do > with formatting user types into strings, which is the subject at hand. Don has said: "But the performance would still be very poor, and that's much more difficult to solve." And those links show a way to quickly convert a large multi-precision integer into a string. What is that I am missing? Bye, bearophile
Re: On Iteration
On Mon, Nov 9, 2009 at 6:17 PM, Andrei Alexandrescu wrote: > dsimcha wrote: >> >> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s >> article >>> >>> I consider changing a bit D's range model following the better >>> understanding reflected in this article: >>> http://erdani.com/publications/on-iteration.html >>> If you have any thoughts and if you can help with the implementation, >>> please let us know. >>> Andrei >> >> Can you detail a little more what you're proposing? I read your article >> this >> morning, though admittedly I skimmed over some of the examples that looked >> like >> things I had already been using in my code since ranges were released. >> The only >> thing I noticed was the save() function for forward ranges. This resolves >> the old >> wart that input ranges vs. forward ranges are strictly a convention, and I >> think >> it's a good idea. Other than that, again, please distill what you're >> proposing. > > One is indeed save(), the other is separation of iteration from access. > These are the only major changes. The second is quite hefty. > > BTW, just saw on the announce group that the article was reddited - please > vote up: http://www.reddit.com/r/programming/comments/a2hv3/ > > > Andrei > I'm not sure why this one is staying so far under the radar. Just marketing? The title of the previous reddit story "Iterators must die" got a lot more attention. I'd hate to think it just comes down to picking deliberately inflammatory titles. --bb
Re: Semantics of toString
On Tue, Nov 10, 2009 at 4:40 AM, 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.
>
> }
That looks pretty good, actually.
I guess I would like to see plain no-arg toString() still supported.
A default toString() could be implemented in terms of the fancy one as:
string toString() {
char buf[];
toString( (string s) { buf ~= s; }, "" );
return assumeUnique!(buf);
}
could be a mixin in a library I suppose.
I think I would like to see the format strings not necessarily tied to
writefln's particular format.
--bb
Re: Semantics of toString
On Tue, Nov 10, 2009 at 4:30 AM, Don wrote: >> Just out of curiousity, how does someone print out the >> >> value of a BigInt right now? > > In Tango, there's just .toHex() and .toDecimalString(). Needs proper > formatting options, it's the biggest thing which isn't done. I hit one too > many compiler segfaults and starting patching the compiler instead . But > I really want a decent toString(). Ah, ok. So there is something, it's just not called "toString". --bb
Re: Semantics of toString
On Tue, Nov 10, 2009 at 6:11 AM, bearophile wrote: > Don: >> But the performance would still be very poor, and that's much more >> difficult to solve. > > This may help: > > http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html > http://fredrik-j.blogspot.com/2008/07/division-sequel-with-bonus-material.html > http://bugs.python.org/issue3451 Though they may be useful, those don't look to have anything to do with formatting user types into strings, which is the subject at hand. --bb
Re: Semantics of toString
Don: > But the performance would still be very poor, and that's much more > difficult to solve. This may help: http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html http://fredrik-j.blogspot.com/2008/07/division-sequel-with-bonus-material.html http://bugs.python.org/issue3451 Bye, bearophile
Re: Semantics of toString
On Tue, 10 Nov 2009 07:49:11 -0500, Justin Johansson 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.
}
That's starting to look like a "serialize" method!
As it should. I should be able to print a 1 element container without
having to load a string representation of 1 elements in memory.
I'd also like to see the name toString changed to something more
appropriate, like output().
And although I think a direct translation is mostly possible, emulating
writefln string formatting from tango would be a burden. I don't know if
there's any way around it without coming up with some complicated
"formatting provider" interface/object implementation, and I don't think
it's worth it.
Unfortunately, I doubt Walter accepts this, it's been proposed in the past
without success.
-Steve
Re: Semantics of toString
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.
>
> }
That's starting to look like a "serialize" method!
Re: Semantics of toString
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.
}
Re: Semantics of toString
Bill Baxter wrote:
On Tue, Nov 10, 2009 at 2:51 AM, Don wrote:
Lutger wrote:
Justin Johansson wrote:
Lutger Wrote:
Justin Johansson wrote:
I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many PL's (including and not limited to D) is
ill-defined.
To put this statement into perspective, I would be most appreciative of
D NG readers responding with their own idea(s) of what the semantics of
"toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry.
Semantics of toString would depend on the object, I would think there
are
three general types of objects:
1. objects with only one sensible or one clear default string
representations, like integers. Maybe even none of these exist (except
strings themselves?)
2. objects that, given some formatting options or locale have a clear
string representation. floating points, dates, curreny and the like.
3. objects that have no sensible default representation.
toString() would not make sense for 3) type objects and only for 2) type
objects as part of a formatting / localization package.
toString() as a debugging aid sometimes doubles as a formatter for 1)
and
2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger.
Do you think it would make better sense if programming languages/their
libraries separated functions/methods which are currently loosely
purposed
as "toString" into methods which are more specific to the types you
suggest (leaving only the types/classifications and number thereof to
argue about)?
In my own D project, I've introduced a toDebugString method and left
toString alone. There are times when I like D's default toString printing
out the name of the object
class. For debug purposes there are times also when I like to see a
string printed
out in quotes so you can tell the difference between "123" and 123. Then
again, and since I'm working on a scripting language, sometimes I like to
see debug output distinguish between different numeric types.
Anyway going by the replies on this topic, looks like most people view
toString as being good for debug purposes and that about it.
Cheers
Justin
Your design makes better sense (to me at least) because it is based on why
you want a string from some object.
Take .NET for example: it does provide very elaborate and nice formatting
options based and toString() with parameters. For some types however, the
default toString() gives you the name of the type itself which is in no way
related to formatting an object. You learn to work with it, but I find it a
bit muddled.
As a last note, I think people view toString as a debug thing mostly
because it is very underpowered.
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.
You can definitely do something with it -- printf debugging. And if I
were using BigInt, that's exactly why I'd want BigInt to have a
toString.
I almost always want to print the value out in hex. And with some kind
of digit separators, so that I can see how many digits it has.
Just out of curiousity, how does someone print out the
value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper
formatting options, it's the biggest thing which isn't done. I hit one
too many compiler segfaults and starting patching the compiler instead
. But I really want a decent toString().
Given a BigInt n, you should be able to just do
writefln("%s %x", n, n); // Phobos
formatln("{0} {0:X}", n); // Tango
To solve this part of the issue, it would be enough to have toString()
take a string parameter. (it would be "x" or "X" in this case).
string toString(string fmt);
But the performance would still be very poor, and that's much more
difficult to solve.
Re: Semantics of toString
Bill Baxter Wrote: > On Tue, Nov 10, 2009 at 3:59 AM, Justin Johansson 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 have a feeling (and I may well be wrong) that toString might be used in > > relation to associative arrays. I implemented an AA recently based upon > > a struct key (I think). Though I cannot remember the exact details I do > > remember DMD saying something about toString not implemented and > > so without thinking I gave the struct a toString and that kept DMD happy. > > Since the code was throw-away I didn't bother to investigate. > > > > Like I say, I cannot remember the details but others may recall some similar > > experience. For all I know it may be a case of RTFM? > > Shouldn't be the case. From TFM: > """ > Classes can be used as the KeyType. For this to work, the class > definition must override the following member functions of class > Object: > > hash_t toHash() > bool opEquals(Object) > int opCmp(Object) > """ > > --bb I think you are right; if I can dig up what it was, and if relevant to this discussion, I'll post it. Ignore what I said for mom. Just wondering now though and in reference to Lutger's comment > >> 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. how much core code would be broken if toString was actually banished?
Re: On Iteration
On Mon, 09 Nov 2009 20:53:01 -0500, Andrei Alexandrescu wrote: I consider changing a bit D's range model following the better understanding reflected in this article: http://erdani.com/publications/on-iteration.html If you have any thoughts and if you can help with the implementation, please let us know. Very good article. I think the idea of separating access from traversal is a very good one. I still don't like the idea of having a "save" method vs. just assignment but I don't have a better idea right now. One note: As you know I think iterators are still useful for keeping pointers to individual elements. One other drawback from storing 1-element ranges as a substitute is that they may not remain one-element ranges. For instance, if you had a sorted map, stored as a RB-tree, a one element range would undoubtedly consist of a begin element and an end element, which would be the next largest element. If you inserted an element that was between those two, suddenly your 1-element range becomes a 2-element range. Although you can simply say that all ranges are invalidated when the underlying container is modified, an iterator-based solution can say that iterators always remain valid when the container is added to. That allows certain types of logic that wouldn't be as efficient with ranges. What about adding a "marker" type that has the ability to reference the data but not to traverse to another element (except by assignment)? Basically a rebindable reference. You can always get a marker to a copyable range's front element, and then a container can use 2 markers to make a traversable range, or use it as the primitive for functions like remove or insert (as an insert location), and 3-legged functions that don't map easily into 2-range functions. I'm thinking this is how I'm going to implement ranges in dcollections. Currently I support cursors, which are akin to C++ iterators (my Iterator objects are akin to Java iterators, and support only foreach). But what I might do is change them into markers, and make ranges out of 2 of them. -Steve
Re: Semantics of toString
Bill Baxter: > Just out of curiousity, how does someone print out the > value of a BigInt right now? I have added a toString to my copy of the BigInt. Bye, bearophile
Re: Semantics of toString
On Tue, Nov 10, 2009 at 2:51 AM, Don wrote: > Lutger wrote: >> >> Justin Johansson wrote: >> >>> Lutger Wrote: >>> Justin Johansson wrote: > I assert that the semantics of "toString" or similarly named/purposed > methods/functions in many PL's (including and not limited to D) is > ill-defined. > > To put this statement into perspective, I would be most appreciative of > D NG readers responding with their own idea(s) of what the semantics of > "toString" are (or should be) in a language agnostic ideology. > My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth. >>> Thanks for that Lutger. >>> >>> Do you think it would make better sense if programming languages/their >>> libraries separated functions/methods which are currently loosely >>> purposed >>> as "toString" into methods which are more specific to the types you >>> suggest (leaving only the types/classifications and number thereof to >>> argue about)? >>> >>> In my own D project, I've introduced a toDebugString method and left >>> toString alone. There are times when I like D's default toString printing >>> out the name of the object >>> class. For debug purposes there are times also when I like to see a >>> string printed >>> out in quotes so you can tell the difference between "123" and 123. Then >>> again, and since I'm working on a scripting language, sometimes I like to >>> see debug output distinguish between different numeric types. >>> >>> Anyway going by the replies on this topic, looks like most people view >>> toString as being good for debug purposes and that about it. >>> >>> Cheers >>> Justin >>> >> >> Your design makes better sense (to me at least) because it is based on why >> you want a string from some object. >> Take .NET for example: it does provide very elaborate and nice formatting >> options based and toString() with parameters. For some types however, the >> default toString() gives you the name of the type itself which is in no way >> related to formatting an object. You learn to work with it, but I find it a >> bit muddled. >> As a last note, I think people view toString as a debug thing mostly >> because it is very underpowered. > > 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. You can definitely do something with it -- printf debugging. And if I were using BigInt, that's exactly why I'd want BigInt to have a toString. Just out of curiousity, how does someone print out the value of a BigInt right now? --bb
Re: Semantics of toString
On Tue, Nov 10, 2009 at 3:59 AM, Justin Johansson 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 have a feeling (and I may well be wrong) that toString might be used in > relation to associative arrays. I implemented an AA recently based upon > a struct key (I think). Though I cannot remember the exact details I do > remember DMD saying something about toString not implemented and > so without thinking I gave the struct a toString and that kept DMD happy. > Since the code was throw-away I didn't bother to investigate. > > Like I say, I cannot remember the details but others may recall some similar > experience. For all I know it may be a case of RTFM? Shouldn't be the case. From TFM: """ Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object: •hash_t toHash() •bool opEquals(Object) •int opCmp(Object) """ --bb
Re: Semantics of toString
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 have a feeling (and I may well be wrong) that toString might be used in relation to associative arrays. I implemented an AA recently based upon a struct key (I think). Though I cannot remember the exact details I do remember DMD saying something about toString not implemented and so without thinking I gave the struct a toString and that kept DMD happy. Since the code was throw-away I didn't bother to investigate. Like I say, I cannot remember the details but others may recall some similar experience. For all I know it may be a case of RTFM? beers, Justin
