www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.xml should just go

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
For a while we've espoused the strategy of keeping std.xml in Phobos 
until something better comes along.

But recently we've started to rethink that.

Pretty much everyone who tries std.xml ends up disappointed. Anyone who 
wants to bash D has std.xml as an easy pick. Anyone who looks at speed 
comparisons sees std.xml there like a sore thumb. Finally, the mere 
existence of a package, no matter how inadequate, stifles the initiative 
of others working on it.

This all makes std.xml a net liability. It's not better than nothing; 
it's worse than nothing.

Should we nuke it?


Andrei
Feb 02 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.02.2011 00:33, schrieb Andrei Alexandrescu:
 For a while we've espoused the strategy of keeping std.xml in Phobos until
 something better comes along.
 
 But recently we've started to rethink that.
 
 Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants
to
 bash D has std.xml as an easy pick. Anyone who looks at speed comparisons sees
 std.xml there like a sore thumb. Finally, the mere existence of a package, no
 matter how inadequate, stifles the initiative of others working on it.
 
 This all makes std.xml a net liability. It's not better than nothing; it's
worse
 than nothing.
 
 Should we nuke it?
 
 
 Andrei

You could explicitly deprecate it. Or just nuke it, if someone still wants to use it (or is already using it) he can copy the source-file to his project. Cheers, - Daniel
Feb 02 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-02-03 00:38, Daniel Gibson wrote:
 Am 03.02.2011 00:33, schrieb Andrei Alexandrescu:
 For a while we've espoused the strategy of keeping std.xml in Phobos until
 something better comes along.

 But recently we've started to rethink that.

 Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants
to
 bash D has std.xml as an easy pick. Anyone who looks at speed comparisons sees
 std.xml there like a sore thumb. Finally, the mere existence of a package, no
 matter how inadequate, stifles the initiative of others working on it.

 This all makes std.xml a net liability. It's not better than nothing; it's
worse
 than nothing.

 Should we nuke it?


 Andrei

You could explicitly deprecate it. Or just nuke it, if someone still wants to use it (or is already using it) he can copy the source-file to his project. Cheers, - Daniel

I've already done that for the Orange project. -- /Jacob Carlborg
Feb 03 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On Wed, 02 Feb 2011 17:33:42 -0600, Andrei Alexandrescu wrote:
 
 Should we nuke it?

From orbit; it's the only way to be sure. Remove it with utter prejudice, before someone else makes the mistake of trying to use it.
Feb 02 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 02, 2011 15:33:42 Andrei Alexandrescu wrote:
 For a while we've espoused the strategy of keeping std.xml in Phobos
 until something better comes along.
 
 But recently we've started to rethink that.
 
 Pretty much everyone who tries std.xml ends up disappointed. Anyone who
 wants to bash D has std.xml as an easy pick. Anyone who looks at speed
 comparisons sees std.xml there like a sore thumb. Finally, the mere
 existence of a package, no matter how inadequate, stifles the initiative
 of others working on it.
 
 This all makes std.xml a net liability. It's not better than nothing;
 it's worse than nothing.
 
 Should we nuke it?

I'm fine with that, but then again, I've never used it. Still, I see some benefit in deprecating and/or removing modules that we know that we want to replace. At _minimum_, we should really start adding module comments to such modules that say that the module is going to be replaced at a later date, so you shouldn't expect it to be usable in your code in the long term unless you copy the source. - Jonathan M Davis
Feb 02 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Should we nuke it?

Yep. And do the same in similar situations. Bye, bearophile
Feb 02 2011
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/2/2011 3:33 PM, Andrei Alexandrescu wrote:
 For a while we've espoused the strategy of keeping std.xml in Phobos until
something better comes along.
 
 But recently we've started to rethink that.
 
 Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants
to bash D has std.xml as an easy pick.
 Anyone who looks at speed comparisons sees std.xml there like a sore thumb.
Finally, the mere existence of a package, no
 matter how inadequate, stifles the initiative of others working on it.
 
 This all makes std.xml a net liability. It's not better than nothing; it's
worse than nothing.
 
 Should we nuke it?
 
 
 Andrei

How sure are you about the assertion? I haven't used it nor am likely to, but I also have trouble ruling out the potential that there's users for which it works and they just aren't talking about it here. This forum is, like it or not, a minority of the user base. Certainly the vocal people are the minority. I'm not against replacement, but I'd be concerned about removal before a replacement is available. Later, Brad
Feb 02 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/2/11 6:28 PM, Brad Roberts wrote:
 On 2/2/2011 3:33 PM, Andrei Alexandrescu wrote:
 For a while we've espoused the strategy of keeping std.xml in Phobos until
something better comes along.

 But recently we've started to rethink that.

 Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants
to bash D has std.xml as an easy pick.
 Anyone who looks at speed comparisons sees std.xml there like a sore thumb.
Finally, the mere existence of a package, no
 matter how inadequate, stifles the initiative of others working on it.

 This all makes std.xml a net liability. It's not better than nothing; it's
worse than nothing.

 Should we nuke it?


 Andrei

How sure are you about the assertion? I haven't used it nor am likely to, but I also have trouble ruling out the potential that there's users for which it works and they just aren't talking about it here. This forum is, like it or not, a minority of the user base. Certainly the vocal people are the minority.

It has certain bugs (http://d.puremagic.com/issues/buglist.cgi?quicksearch=xml) that seem to occur in quite common XML code (though I'm no expert) yet nobody is discussing them or voting for them.
 I'm not against replacement, but I'd be concerned about removal before a
replacement is available.

My problem is that the mere presence is reducing the likelihood of a replacement coming about, in addition to the other liabilities. Andrei
Feb 02 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 03, 2011 11:30:17 Tomek Sowi=C5=84ski wrote:
 Andrei Alexandrescu napisa=C5=82:
 I'm not against replacement, but I'd be concerned about removal before
 a replacement is available.

My problem is that the mere presence is reducing the likelihood of a replacement coming about, in addition to the other liabilities.

Is anyone tasked with a replacement yet? I had to write an XML parser at some point. It's plenty of work bringing up to industrial quality, so I'd have to know that before I dive in.

I think that at least a couple of people have said that they have the begin= nings=20 of a replacement, but I don't believe that anyone has stepped up to say tha= t=20 they'll actually complete and propose a module for inclusion in Phobos. So, std.xml is still very much up in the air, and Tango has set a very high= bar=20 with regards to speed. And while we may not be able to match Tango for spee= d -=20 especially at first - we'd definitely like to have an xml solution that's c= lose.=20 And that's not necessarily going to be easy - especially since we're inevit= ably=20 going to want a range-based solution. And while ranges can be quite efficie= nt, it=20 can also be easy to make them inefficient if you're not careful. =2D Jonathan M Davis
Feb 03 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Jonathan M Davis napisał:
 
 I think that at least a couple of people have said that they have the
beginnings 
 of a replacement, but I don't believe that anyone has stepped up to say that 
 they'll actually complete and propose a module for inclusion in Phobos.

Wimps ;-)
 So, std.xml is still very much up in the air, and Tango has set a very high
bar 
 with regards to speed. And while we may not be able to match Tango for speed - 
 especially at first - we'd definitely like to have an xml solution that's
close. 
 And that's not necessarily going to be easy - especially since we're
inevitably 
 going to want a range-based solution. And while ranges can be quite efficient,
it 
 can also be easy to make them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first datetime and it gives me shivers...

You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked at the source it may be ok.. Maybe a clean-room approach is possible: Somebody else looks at the source and documents what it does and how it does that (without copying anything) and you could use that documentation for your own code. If you don't want to clone it but have questions about how they did something specific you could just ask here and (hopefully) someone looks it up and explains it to you. Cheers, - Daniel
Feb 03 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson <metalcaedes gmail.com>
wrote:
 
 Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Jonathan M Davis napisał:

 I think that at least a couple of people have said that they have the
 beginnings
 of a replacement, but I don't believe that anyone has stepped up to say that
 they'll actually complete and propose a module for inclusion in Phobos.

Wimps ;-)
 So, std.xml is still very much up in the air, and Tango has set a very high bar
 with regards to speed. And while we may not be able to match Tango for speed -
 especially at first - we'd definitely like to have an xml solution that's
 close.
 And that's not necessarily going to be easy - especially since we're inevitably
 going to want a range-based solution. And while ranges can be quite
 efficient, it
 can also be easy to make them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first datetime and it gives me shivers...

You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked at the source it may be ok..

It has been posited by Tango's developers that simply looking at the documentation of a D library isn't enough to understand the library, you probably have looked at the source. Until they change that opinion, I would avoid even the documentation. http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html The pertinent quote from there: "In my opinion, claiming a clean room implementation of an API in D is difficult, if for no other reason that it is (due to imperfect doc generation etc) somewhat difficult to properly study a D API without at the same time reading the source (or glimpsing at it)."

They can claim whatever they want.. if Tomek says he only looked at the documentation (for an idea how a good interface for a XML lib may look like) they can hardly prove anything. Furthermore this ("I haven't seen the source") is an argument that Walter will (probably) accept when deciding whether to include the module in Phobos, because he used it himself in the past IIRC.
 Maybe a clean-room approach is possible: Somebody else looks at the source and
 documents what it does and how it does that (without copying anything) and you
 could use that documentation for your own code.
 If you don't want to clone it but have questions about how they did something
 specific you could just ask here and (hopefully) someone looks it up and
 explains it to you.

Make sure if you follow this approach that you document exactly the process and how it was done.

Yes, it'd be best to do this publicly, e.g. in this newsgroup (or maybe the phobos mailing list). So it's obvious who has seen the source and has written the documentation that was used by someone else to write the code that may look similar to the Tango code.
 
 -Steve

Cheers, - Daniel
Feb 03 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.02.2011 22:45, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson <metalcaedes gmail.com>
wrote:
 
 Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson <metalcaedes gmail.com>
wrote:

 Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Speaking of Tango, may I look at it? I remember that beef over the first
 datetime and it gives me shivers...

You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked at the source it may be ok..

It has been posited by Tango's developers that simply looking at the documentation of a D library isn't enough to understand the library, you probably have looked at the source. Until they change that opinion, I would avoid even the documentation. http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html The pertinent quote from there: "In my opinion, claiming a clean room implementation of an API in D is difficult, if for no other reason that it is (due to imperfect doc generation etc) somewhat difficult to properly study a D API without at the same time reading the source (or glimpsing at it)."

They can claim whatever they want.. if Tomek says he only looked at the documentation (for an idea how a good interface for a XML lib may look like) they can hardly prove anything.

This exact situation was the case of the prior-mentioned infringement accusation. -Steve

Was it? I thought the Author *had* looked at the Tango source but claimed not to have used it? Claiming that looking at the documentation isn't sufficient to understand how the API works (from a users point of view, not internally) is pretty stupid: 1. it insults the modules author(s) ("You're too stupid to write meaningful documentation") 2. even if the documentation sucks one may have understood how to the API is used by looking at code examples using it... Well, however, so Tomek should probably not even look at the docs.. But when a possible API for the module is discussed maybe people with Tango experience can contribute ideas (if the Tango XML API is any good, so far I've only heard that their implementation is very fast, but nothing about usability). (This situation really sucks. It's unbelievable how much FUD that prior incident has created.) Cheers, - Daniel
Feb 03 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.02.2011 23:29, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 17:10:18 -0500, Daniel Gibson <metalcaedes gmail.com>
wrote:
 
 I thought the Author *had* looked at the Tango source but claimed not to
 have used it?

See here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=18090 His English isn't perfect, but I took his statements to mean he did not read the source (as I re-asserted in a later message). -Steve

Ok :)
Feb 03 2011
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-11 09:29:03 -0500, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 On 11/02/2011 13:48, Steven Schveighoffer wrote:
 I think D can do it without copying out of the buffer. You just have to
 avoid using immutable strings.
 
 -Steve

The data that you want to keep afterwards you will have to copy, that much is obvious.

In fact, if the amount of data you want to keep is greater than the one you want to throw away, it might be better to make the buffer immutable and allocate new buffers as you go forward. One allocation per buffer is likely going to be less wasteful than one allocation + one copy per string (+ some space wasted after each memory block). If you don't intend to keep most of the data after parsing however, then you should go for a mutable buffer and copy what you need. What I like very much about Andrei's proposal for a buffered input range is that it makes it supports equally well mutable and immutable buffers. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 11 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 02/03/2011 10:03 PM, Daniel Gibson wrote:
 You probably shouldn't look at the source.
 I dunno about the interface (documentation) - it's certainly not illegal to
take
 inspiration from it, but maybe then people will again claim that source was
 stolen.. but when you claim that you haven't looked at the source it may be
ok..

 Maybe a clean-room approach is possible: Somebody else looks at the source and
 documents what it does and how it does that (without copying anything) and you
 could use that documentation for your own code.
 If you don't want to clone it but have questions about how they did something
 specific you could just ask here and (hopefully) someone looks it up and
 explains it to you.

Mamma mia! In what world are we supposed to live!? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 03 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 2/3/11 11:46 PM, Jonathan M Davis wrote:
 […] If they were more open and
 willing to share code, then building off of what they have and turning it into
a
 range-based solution would likely make a lot of sense, but since that's not the
 case, we need to figure it out on our own.

Just like Andrei said, I don't think this issue is worth being discussed over and over again, but I'm curious: Did somebody actually talk to »Tango« resp. the authors of its XML module concerning amendment for Phobos? It's needlessly fueling an »us vs. them« debate in an already small community of developers which drives me crazy… David
Feb 03 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vqcns2egeav7ka steve-laptop...
 On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger <see klickverbot.at> 
 wrote:

 On 2/3/11 11:46 PM, Jonathan M Davis wrote:
 [.] If they were more open and
 willing to share code, then building off of what they have and turning 
 it into a
 range-based solution would likely make a lot of sense, but since that's 
 not the
 case, we need to figure it out on our own.

Just like Andrei said, I don't think this issue is worth being discussed over and over again, but I'm curious: Did somebody actually talk o Tango resp. the authors of its XML module concerning amendment for Phobos? It's needlessly fueling an us vs. them debate in an already small community of developers which drives me crazy.

You are welcome to try. I don't hold out much hope based on past.

The main part of the problem is that Tango modules have many developers and *all* of the relevent contributors need to 1. be successfully contacted and 2. give approval. That all stems purely from legal constraints (ie the interactions of licenses). Part two has never really been a problem, but as was learned, part one can be a real problem.
Feb 03 2011
next sibling parent reply %u <e ee.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 I hate to fuel this any further, but I want to re-iterate what I have
 learned.  Please re-read my summary (titled "SHOO's Time code --
 conclusion") in the announce group.
 I personally went through great lengths to satisfy 1.  It was 2 that was
 the problem.
 Seeing that the same author who did not give approval to relicense the
 time code is an author of Tango's XML code, I doubt his views have changed.
 -Steve

With only two(or one even) off these three helping out: larsivi, kris and stonecobra, you can get quite a bit of (older) code readable.
Feb 03 2011
next sibling parent %u <e ee.com> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 On Thursday, February 03, 2011 15:51:10 %u wrote:
 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 I hate to fuel this any further, but I want to re-iterate what I have
 learned.  Please re-read my summary (titled "SHOO's Time code --
 conclusion") in the announce group.
 I personally went through great lengths to satisfy 1.  It was 2 that was
 the problem.
 Seeing that the same author who did not give approval to relicense the
 time code is an author of Tango's XML code, I doubt his views have
 changed. -Steve

With only two(or one even) off these three helping out: larsivi, kris and stonecobra, you can get quite a bit of (older) code readable.

libraries out there. We have no need to base Phobos code off of Tango. Let's just drop it and move on. I only brought up Tango in the first place to point out that it is a goal of the new std.xml to at least come close to Tango's performance in parsing XML, because Tango's XML parser is very fast. It's a point which has been brought up before and I believe that it still holds. However, that doesn't mean that we need to deal with the Tango API or source code, and we definitely don't want any more debates about "us vs them" or any such nonsense. Let's just move on. - Jonathan M Davis

I couldn't care less about any such debates and will not take part any of it. As Steven Schveighoffer already contacted some of the Tango developers I thought he might also have received a "sure" from one of them.. would be a waste to not at least take a look at that devs code, if he exists. But now that I reread Stevens post, he might have gotten only "no"s. ;)
Feb 03 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 I only brought up Tango in the first place to point out that it is a goal of
the 
 new std.xml to at least come close to Tango's performance in parsing XML, 
 because Tango's XML parser is very fast.

The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong.
Feb 03 2011
next sibling parent reply Max Samukha <maxsamukha spambox.com> writes:
On 02/04/2011 05:07 AM, Walter Bright wrote:
 Jonathan M Davis wrote:
 I only brought up Tango in the first place to point out that it is a
 goal of the new std.xml to at least come close to Tango's performance
 in parsing XML, because Tango's XML parser is very fast.

The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong.

.NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those.
Feb 03 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Max Samukha wrote:
 .NET and Qt do have slices of some kind:
 
 http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx
 http://doc.qt.nokia.com/latest/qstringref.html#details
 
 I am not sure whether their XML libraries use those.

.net's slices are inadequate, because its strings are not interchangeable with slices. When they're not interchangeable, then you wind up being forced to make copies.
Feb 04 2011
parent Max Samukha <maxsamukha spambox.com> writes:
On 02/04/2011 11:24 AM, Walter Bright wrote:
 Max Samukha wrote:
 .NET and Qt do have slices of some kind:

 http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx
 http://doc.qt.nokia.com/latest/qstringref.html#details

 I am not sure whether their XML libraries use those.

.net's slices are inadequate, because its strings are not interchangeable with slices. When they're not interchangeable, then you wind up being forced to make copies.

Right. The same applies to Qt. Whenever a QStringRef is converted to QString, a copy is made.
Feb 04 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
spir wrote:
 On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other 
 languages'
 arrays...

What are the other ones?

Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see.
Feb 04 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
so wrote:
 It doesn't matter what signature you use for the function, compiler is 
 aware and will output an error when you do the opposite of the 
 signature. If this is the case, why do we need that signature?

Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You'd fall back to const by convention, and that is not reliable and does not scale. You have to manually go through an entire hierarchy of function calls to figure out if one might change a member of the data structure, and then after a few maintenance cycles, you have to do that all over again. Or not, and just hope for the best (which is what happens in practice). The "why", then, is that guarantees are better than hope.
Feb 04 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
so wrote:
 Examine the API of a function in a library. It says it doesn't modify 
 anything reachable through its arguments, but is that true? How would 
 you know? And how would you know if the API doc doesn't say?

You are right, but try to look at this from another angle (probably i am not making any sense here). Should "D const" be perceived this way? When i say "const A", it broadly means don't assign to this.

That's "head const", which is what C++ has. The const system in C++ does not work. If you view const strictly as a storage class, that fails as soon as you introduce pointers.
 You'd fall back to const by convention, and that is not reliable and 
 does not scale. You have to manually go through an entire hierarchy of 
 function calls to figure out if one might change a member of the data 
 structure, and then after a few maintenance cycles, you have to do 
 that all over again.

I have no idea how to solve this for documentation and such but the second you compile the source, everything will be clear as day.

As I wrote in another reply to you, there are many cases where the compiler cannot determine this.
Feb 04 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-04 20:33, Walter Bright wrote:
 so wrote:
 It doesn't matter what signature you use for the function, compiler is
 aware and will output an error when you do the opposite of the
 signature. If this is the case, why do we need that signature?

Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You'd fall back to const by convention, and that is not reliable and does not scale.

This is quite interesting, I generally agree with this but on the other hand Ruby on Rails is basically built on conventions, it works out very well and I love it. For example: The class "FooBar" matches the table "foo_bars".
 You have to manually go through an entire hierarchy of
 function calls to figure out if one might change a member of the data
 structure, and then after a few maintenance cycles, you have to do that
 all over again.

 Or not, and just hope for the best (which is what happens in practice).

 The "why", then, is that guarantees are better than hope.

-- /Jacob Carlborg
Feb 06 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 On 2011-02-04 20:33, Walter Bright wrote:
 so wrote:
 It doesn't matter what signature you use for the function, compiler is
 aware and will output an error when you do the opposite of the
 signature. If this is the case, why do we need that signature?

Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You'd fall back to const by convention, and that is not reliable and does not scale.

This is quite interesting, I generally agree with this but on the other hand Ruby on Rails is basically built on conventions, it works out very well and I love it.

I'm not tapped into the ruby community, but I've heard some scuttlebutt that usage of ruby is declining in large systems because ruby seems to have problems with large systems due to "monkey patching" and other cowboying that ruby encourages.
Feb 06 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-06 20:59, Walter Bright wrote:
 Jacob Carlborg wrote:
 On 2011-02-04 20:33, Walter Bright wrote:
 so wrote:
 It doesn't matter what signature you use for the function, compiler is
 aware and will output an error when you do the opposite of the
 signature. If this is the case, why do we need that signature?

Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You'd fall back to const by convention, and that is not reliable and does not scale.

This is quite interesting, I generally agree with this but on the other hand Ruby on Rails is basically built on conventions, it works out very well and I love it.

I'm not tapped into the ruby community, but I've heard some scuttlebutt that usage of ruby is declining in large systems because ruby seems to have problems with large systems due to "monkey patching" and other cowboying that ruby encourages.

Maybe, I have no idea. Although I noticed myself that I wanted to have static typing in Ruby a couple of times. -- /Jacob Carlborg
Feb 06 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/02/2011 21:30, Jacob Carlborg wrote:
 On 2011-02-06 20:59, Walter Bright wrote:
 Jacob Carlborg wrote:
 On 2011-02-04 20:33, Walter Bright wrote:
 so wrote:
 It doesn't matter what signature you use for the function, compiler is
 aware and will output an error when you do the opposite of the
 signature. If this is the case, why do we need that signature?

Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You'd fall back to const by convention, and that is not reliable and does not scale.

This is quite interesting, I generally agree with this but on the other hand Ruby on Rails is basically built on conventions, it works out very well and I love it.

I'm not tapped into the ruby community, but I've heard some scuttlebutt that usage of ruby is declining in large systems because ruby seems to have problems with large systems due to "monkey patching" and other cowboying that ruby encourages.

Maybe, I have no idea. Although I noticed myself that I wanted to have static typing in Ruby a couple of times.

Problems with large systems? Wanting to use static typing? Well, there is a solution to that, but it is even a more radical kind of a monkey patch: basically you remove 100% of the Ruby runtime and install and use Java and Java frameworks instead... ;) -- Bruno Medeiros - Software Engineer
Feb 11 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
so Wrote:

 It doesn't matter what signature you use for the function, compiler is  
 aware and will output an error when you do the opposite of the signature.  
 If this is the case, why do we need that signature?
 Its presence just makes things complicated and with actually no reason.

Are you saying that having the compiler auto detect const functions is better? This has been discussed and not considered a 'hole.' By declaring the function const the compiler is able to inform you when you make a call which no longer makes this true. It does mean const will be used less then in C++, but if we just remove it that would still be the case.
Feb 04 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
so wrote:
 You changed the function and the new function is not working, just what 
 you expect.
 It is not silently is it? Unlike you use "A a" instead of "const A a". 
 this const alone would give you all the guaranties you need.

What would you do in the case of pointers to functions, virtual functions, functions implemented with inline assembly, and functions for which the source is not available?
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 06:33 PM, Walter Bright wrote:
 spir wrote:
 On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other languages'
 arrays...

What are the other ones?

Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see.

Agreed. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-04 08:34, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other languages'
 arrays...

 - Jonathan M Davis

Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other hand a new instance is created when making a slice (I assume, since everything is an object in Ruby). -- /Jacob Carlborg
Feb 05 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 On 2011-02-04 08:34, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other 
 languages'
 arrays...

 - Jonathan M Davis

Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other hand a new instance is created when making a slice (I assume, since everything is an object in Ruby).

Can you use an array slice in ruby as an argument to any function that takes a string?
Feb 06 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 Can you use an array slice in ruby as an argument to any function that takes a 
 string?

The NumPy library for Python uses light slices, that are seen as normal NumPy arrays, like in D. NumPy arrays may contain numbers, chars, records, etc. Bye, bearophile
Feb 06 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-02-06 20:51, Walter Bright wrote:
 Jacob Carlborg wrote:
 On 2011-02-04 08:34, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other
 languages'
 arrays...

 - Jonathan M Davis

Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other hand a new instance is created when making a slice (I assume, since everything is an object in Ruby).

Can you use an array slice in ruby as an argument to any function that takes a string?

Since Ruby is a dynamically typed language you can pass in anything you want and relay on duck typing. The object passed in just have to support the slicing syntax/method. Hm, I just tried this and apparently a slice does NOT behave as in D. Modifying the slice does NOT modify the original array/string, I was completely sure it did. -- /Jacob Carlborg
Feb 06 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/06/2011 10:28 PM, Jacob Carlborg wrote:
 On 2011-02-06 20:51, Walter Bright wrote:
 Jacob Carlborg wrote:
 On 2011-02-04 08:34, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other
 languages'
 arrays...

 - Jonathan M Davis

Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other hand a new instance is created when making a slice (I assume, since everything is an object in Ruby).

Can you use an array slice in ruby as an argument to any function that takes a string?

Since Ruby is a dynamically typed language you can pass in anything you want and relay on duck typing. The object passed in just have to support the slicing syntax/method. Hm, I just tried this and apparently a slice does NOT behave as in D. Modifying the slice does NOT modify the original array/string, I was completely sure it did.

I was wondering about this question by Walter. And actually, another answer would have surprised me, unless some magic would be in play, somewhat contradictory to Ruby's all-object motto. I mean, modifying a slice (all or part of it) is replacing 1 or more element(s), each having their own address/identity, as /objects/ by themselves, not as variable values. Unlike in static languages (for non-referenced elements). To get a similar behaviour, you'd need a double referencing/indirect, provided for instance by putting composite objects (or other collections, provided they're referenced) in an array, then changing slots of said objects (or elements of sub-collection). Then (if my reasoning is correct), modifying a slice would be seen from the original array. Denis PS: just tried in python [id() actualy returns address]: l = [1,2,3] s = l[1:2] print l,s print id(l[1]), id(s[0]) s[0] = 0 print l,s print id(l[1]), id(s[0]) print l = [1,[2],3] s = l[1:2] print l,s print id(l[1]), id(s[0]) s[0][0] = 0 print l,s print id(l[1]), id(s[0]) ==> spir d:~/prog/python$ python "__essai__.py" [1, 2, 3] [2] 169172356 169172356 [1, 2, 3] [0] 169172356 169172380 [1, [2], 3] [[2]] 3078505324 3078505324 [1, [0], 3] [[0]] 3078505324 3078505324 -- _________________ vita es estrany spir.wikidot.com
Feb 06 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 03 February 2011 23:17:10 Max Samukha wrote:
 On 02/04/2011 05:07 AM, Walter Bright wrote:
 Jonathan M Davis wrote:
 I only brought up Tango in the first place to point out that it is a
 goal of the new std.xml to at least come close to Tango's performance
 in parsing XML, because Tango's XML parser is very fast.

The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong.

.NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those.

Interesting. Slices are a rarity in C-based languages. In fact, I'd never even heard of them before I started learning D. But now it drives me nuts to not have them in C++. If I have to do much more string processing at work, I'll probably write a StringSlice class or something similar to wrap strings in just so I don't go insane. In any case, if you're not used to using slices, I'm not sure that it's the kind of thing that your average programmer is even going to think of, so it wouldn't surprise me at all if their XML libraries don't use their slicing constructs - though perhaps they do. It definitely helps that slices are built into D though. We really don't have a good excuse _not_ to use them in std.xml. Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
 Scope guard is another.

Scope guard is awesome with C libs that have complicated acquire/release rules. Saves my butt. :D
Feb 04 2011
prev sibling next sibling parent so <so so.do> writes:
On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 spir wrote:
 On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other  
 languages'
 arrays...


Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see.

There are many features small in detail but superb in practice. But still, i keep saying D has design errors as well, to me the biggest one and maybe the main reason why D1 crowd is hostile to D2. Const system (CS): CS in theory a great thing, in practice it has many corner cases, simply it doesn't worth having. D had(still has) a chance to fix this issue in two different ways, either avoid it or don't leave holes. This hole is not that explicit in C++ because it is not transitive. Transitive const brings something with it... transitivity! Now, what i mean with this: --- struct A { B whatever; bool opEquals(A a) { return whatever == a.whatever; // just comparision, this function is const } bool anything(A a) { whatever = 2; // here i have an assignment, this function is not const return whatever; } } --- It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Its presence just makes things complicated and with actually no reason. --- struct A { B whatever; bool opEquals(A a) { return whatever == a.whatever; } } const(A) a; A b; bool e = a == b; ---- Thanks;
Feb 04 2011
prev sibling next sibling parent so <so so.do> writes:
 This hole is not that explicit in C++ because it is not transitive.

Ignore this line... Btw, if i made myself clear to at least one person, please let me know since this is (at least to me) very important.
Feb 04 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 04 Feb 2011 13:49:42 -0500, so <so so.do> wrote:


 Now, what i mean with this:

 ---
 struct A {
 	B whatever;
 	bool opEquals(A a) {
 		return whatever == a.whatever;  // just comparision, this function is  
 const
 	}
 	bool anything(A a) {
 		whatever = 2; // here i have an assignment, this function is not const
 		return whatever;
 	}
 }
 ---

 It doesn't matter what signature you use for the function, compiler is  
 aware and will output an error when you do the opposite of the  
 signature. If this is the case, why do we need that signature?
 Its presence just makes things complicated and with actually no reason.

Actually, there are two reasons. First, it's due to the compilation model of D. Without the signature to convey the information, the compiler cannot make any guarantees. It is legal to declare simply a function signature without the relevant source, in order to link against the function. This means, the compiler does not have access to the source, so if it doesn't have access to the source, how does it know that the function is const or not? Second, it has to do with the desires of the developer who's writing the function. Let's say you have your code, and the opEquals is treated as const due to the implicit detection of the compiler. Now, you realize your code that compares B types is really slow, so you want to do some sort of caching of the data: struct A { private B whatever; // changed to private for illustration purposes private md5 previousCompare; private bool previousCompareResult; bool opEquals(A a) { md5 ah = getMd5sum(a); if(ah != previousCompare) { previousCompare = ah; previousCompareResult = (whatever == a.whatever); } return previousCompareResult; } ... } So what does the compiler do? Well, not only would this function now silently not be const, it silently un-consts all functions that call it. The point is, many times, people want the compiler to tell them "hey, wait a minute, you marked this as const, but you're trying to do non-const things!" As it turns out, it's really useful to know "this function is not going to change your object/struct." logically, you can make a lot of assumptions based on that. If the compiler doesn't help you enforce that, then stuff like the above creeps into the code, and your const expectation is broken. What's somewhat unfortunate is that once you mark something as const, you have to mark all sorts of other things as const. So for example, B's opEquals must also be const. However, if you properly mark items as const when they really are const, this should already be the case. The statement that "you don't need to use const if you don't want to" is really weak. If you use D libraries, you will undoubtedly have to use const (once const is sane and libraries start using it). But using it is not "pointless" and does add value. -Steve
Feb 04 2011
prev sibling next sibling parent so <so so.do> writes:
 Actually, there are two reasons.

 First, it's due to the compilation model of D.  Without the signature to  
 convey the information, the compiler cannot make any guarantees.  It is  
 legal to declare simply a function signature without the relevant  
 source, in order to link against the function.  This means, the compiler  
 does not have access to the source, so if it doesn't have access to the  
 source, how does it know that the function is const or not?

You can solve this at linking, but i have no idea about linking process, it would probably add overhead (data).
 Second, it has to do with the desires of the developer who's writing the  
 function.

 Let's say you have your code, and the opEquals is treated as const due  
 to the implicit detection of the compiler.  Now, you realize your code  
 that compares B types is really slow, so you want to do some sort of  
 caching of the data:

 struct A
 {
     private B whatever; // changed to private for illustration purposes
     private md5 previousCompare;
     private bool previousCompareResult;

     bool opEquals(A a)
     {
        md5 ah = getMd5sum(a);
        if(ah != previousCompare)
        {
           previousCompare = ah;
           previousCompareResult = (whatever == a.whatever);
        }
        return previousCompareResult;
     }
 ...
 }

 So what does the compiler do?  Well, not only would this function now  
 silently not be const, it silently un-consts all functions that call it.

You changed the function and the new function is not working, just what you expect. It is not silently is it? Unlike you use "A a" instead of "const A a". this const alone would give you all the guaranties you need.
 The point is, many times, people want the compiler to tell them "hey,  
 wait a minute, you marked this as const, but you're trying to do  
 non-const things!"  As it turns out, it's really useful to know "this  
 function is not going to change your object/struct."  logically, you can  
 make a lot of assumptions based on that.  If the compiler doesn't help  
 you enforce that, then stuff like the above creeps into the code, and  
 your const expectation is broken.

I understand the importance of the signatures, but i am trying to understand if this is also practical. What i am saying is, indeed there are many expectations but one thing (not necessarily the solution) is that unless you use "const A a" having const signatures/guaranties pointless, right?
Feb 04 2011
prev sibling next sibling parent so <so so.do> writes:
 Examine the API of a function in a library. It says it doesn't modify  
 anything reachable through its arguments, but is that true? How would  
 you know? And how would you know if the API doc doesn't say?

You are right, but try to look at this from another angle (probably i am not making any sense here). Should "D const" be perceived this way? When i say "const A", it broadly means don't assign to this.
 You'd fall back to const by convention, and that is not reliable and  
 does not scale. You have to manually go through an entire hierarchy of  
 function calls to figure out if one might change a member of the data  
 structure, and then after a few maintenance cycles, you have to do that  
 all over again.

I have no idea how to solve this for documentation and such but the second you compile the source, everything will be clear as day.
Feb 04 2011
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 02/03/2011 10:07 PM, Walter Bright wrote:
 The way to get a high performance string parser in D is to take
 advantage of one of D's unique features - slices. Java, C++, C#, etc.,
 all rely on copying strings. With D you can just use slices into the
 original XML source text. If you're copying the text, you're doing it
 wrong.

Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.
Feb 04 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-04 21:44, Jeff Nowakowski wrote:
 On 02/03/2011 10:07 PM, Walter Bright wrote:
 The way to get a high performance string parser in D is to take
 advantage of one of D's unique features - slices. Java, C++, C#, etc.,
 all rely on copying strings. With D you can just use slices into the
 original XML source text. If you're copying the text, you're doing it
 wrong.

Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.

But, I assume, it will allocate a new instance of String even though the content point to the same data? -- /Jacob Carlborg
Feb 06 2011
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 02/06/2011 05:43 AM, Jacob Carlborg wrote:
 On 2011-02-04 21:44, Jeff Nowakowski wrote:
 Java's substring() does not copy the text, at least in the official JDK
 implementation. Unfortunately, it doesn't specify this behavior as part
 of the String API.

But, I assume, it will allocate a new instance of String even though the content point to the same data?

Yes, but small objects in Java are very fast to allocate and garbage collect.
Feb 06 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Jeff Nowakowski wrote:
 On 02/06/2011 05:43 AM, Jacob Carlborg wrote:
 On 2011-02-04 21:44, Jeff Nowakowski wrote:
 Java's substring() does not copy the text, at least in the official JDK
 implementation. Unfortunately, it doesn't specify this behavior as part
 of the String API.

But, I assume, it will allocate a new instance of String even though the content point to the same data?

Yes, but small objects in Java are very fast to allocate and garbage collect.

It's even faster to not allocate/collect at all! That's the advantage of proper slices.
Feb 06 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 04/02/2011 21:07, Steven Schveighoffer wrote:
 On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski <jeff dilacero.org>
 wrote:

 On 02/03/2011 10:07 PM, Walter Bright wrote:
 The way to get a high performance string parser in D is to take
 advantage of one of D's unique features - slices. Java, C++, C#, etc.,
 all rely on copying strings. With D you can just use slices into the
 original XML source text. If you're copying the text, you're doing it
 wrong.

Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.

Yes, but Java's strings are immutable. Typically a buffered I/O stream has a mutable buffer used to read data. This necessitates a copy. At the very least, you need to continue allocating more memory to hold all the strings. -Steve

True, but in this case you will have the exact same problem with any other language as well. So it doesn't seem like D will have any particular advantage over Java, with regards to slicing and strings. -- Bruno Medeiros - Software Engineer
Feb 11 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/02/2011 13:48, Steven Schveighoffer wrote:
 On Fri, 11 Feb 2011 08:19:51 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 04/02/2011 21:07, Steven Schveighoffer wrote:
 On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski <jeff dilacero.org>
 wrote:

 On 02/03/2011 10:07 PM, Walter Bright wrote:
 The way to get a high performance string parser in D is to take
 advantage of one of D's unique features - slices. Java, C++, C#, etc.,
 all rely on copying strings. With D you can just use slices into the
 original XML source text. If you're copying the text, you're doing it
 wrong.

Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.

Yes, but Java's strings are immutable. Typically a buffered I/O stream has a mutable buffer used to read data. This necessitates a copy. At the very least, you need to continue allocating more memory to hold all the strings. -Steve

True, but in this case you will have the exact same problem with any other language as well. So it doesn't seem like D will have any particular advantage over Java, with regards to slicing and strings.

I think D can do it without copying out of the buffer. You just have to avoid using immutable strings. -Steve

The data that you want to keep afterwards you will have to copy, that much is obvious. As for the data you don't want to keep (but just guide you through the parsing), yes in D you can look at it without copying it out of the buffer. But you can do the same in Java, there is this core interface CharSequence that is roughly equivalent to a D slice for chars (http://download.oracle.com/javase/1.4.2/docs/api/java/lang/CharSequence.html) -- Bruno Medeiros - Software Engineer
Feb 11 2011
prev sibling next sibling parent so <so so.do> writes:
 What would you do in the case of pointers to functions, virtual  
 functions, functions implemented with inline assembly, and functions for  
 which the source is not available?

Just like we don't know if the derived class overrides a given function, we could do something similar i suppose? Similar could be applied to functions without source, after all we don't know until linking that the provided function has the right signature. I am sorry if these doesn't make sense for a compiler writer, i have no idea about the process :)
Feb 04 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 04 Feb 2011 15:26:07 -0500, so <so so.do> wrote:

 Actually, there are two reasons.

 First, it's due to the compilation model of D.  Without the signature  
 to convey the information, the compiler cannot make any guarantees.  It  
 is legal to declare simply a function signature without the relevant  
 source, in order to link against the function.  This means, the  
 compiler does not have access to the source, so if it doesn't have  
 access to the source, how does it know that the function is const or  
 not?

You can solve this at linking, but i have no idea about linking process, it would probably add overhead (data).

Yes, but that requires a custom linker/object file format. Java does this, and D could do it, but it requires a major investment of time/effort.
 Second, it has to do with the desires of the developer who's writing  
 the function.

 Let's say you have your code, and the opEquals is treated as const due  
 to the implicit detection of the compiler.  Now, you realize your code  
 that compares B types is really slow, so you want to do some sort of  
 caching of the data:

 struct A
 {
     private B whatever; // changed to private for illustration purposes
     private md5 previousCompare;
     private bool previousCompareResult;

     bool opEquals(A a)
     {
        md5 ah = getMd5sum(a);
        if(ah != previousCompare)
        {
           previousCompare = ah;
           previousCompareResult = (whatever == a.whatever);
        }
        return previousCompareResult;
     }
 ...
 }

 So what does the compiler do?  Well, not only would this function now  
 silently not be const, it silently un-consts all functions that call it.

You changed the function and the new function is not working, just what you expect. It is not silently is it? Unlike you use "A a" instead of "const A a". this const alone would give you all the guaranties you need.

It is silent. This is a basic difference in philosophy. What it boils down to is declaration vs. usage. Let's say I *don't* use const A a anywhere, so my code just compiles, I then release my library, and your code breaks because you do use const A a. You might just be screwed, because I say "I don't care, I never meant that function to be const". Now, you are stuck on an older version of the library, or forced to make drastic changes to your code. Conversely, if the compiler *requires* the const decoration in the signature, your code never compiles to begin with, you can either work around the limitation, file a bug, or use a different library. But since the API isn't going to change, you can be sure future versions of my code will work. I feel the second scenario is better for all -- declare what you intend for the API, then there are no surprises later. -Steve
Feb 04 2011
prev sibling next sibling parent so <so so.do> writes:
On Fri, 04 Feb 2011 22:44:51 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 so wrote:
 Examine the API of a function in a library. It says it doesn't modify  
 anything reachable through its arguments, but is that true? How would  
 you know? And how would you know if the API doc doesn't say?

am not making any sense here). Should "D const" be perceived this way? When i say "const A", it broadly means don't assign to this.

That's "head const", which is what C++ has. The const system in C++ does not work. If you view const strictly as a storage class, that fails as soon as you introduce pointers.

No no! I mean the way it works in D. I tried to say that: because of the semantic of C++ const, it maybe maybe a good idea to have signatures but with the semantics in D const it is not that needed.
Feb 04 2011
prev sibling parent so <so so.do> writes:
 The case is different --I mean the comparison does not hold IIUC.  
 Virtual methods are /intended/ to be overriden, this is precisely part  
 of their semantics. While the whole point of const-the-D-way is to  
 ensure actual constness as marked in a given function's signature,  
 whatever this function itself calls. The contract is such that the  
 reader does not even need to watch further. Again, IIUC (please correct  
 if I'm wrong on this).

 Denis

Well you are thinking with the current usage. --- const int i; const A a; --- Think about these two lines. If this is a C++ code, you can't say much about their constness. But if this is a D code, you can say many things about each line and go even further and say their constness is exactly same! What i am getting at is that if we have this affinity between types and constness always a first class attribute why don't we go even further and drop the signatures all together and make constness accessible to every single D code written. Walter and Steve are talking about the contract feature we give to const signature, i am not saying it is wrong or it has lesser importance than they claim. I am just questioning if this what CS should be.
Feb 05 2011
prev sibling next sibling parent David Nadlinger <see klickverbot.at> writes:
On 2/4/11 12:30 AM, Steven Schveighoffer wrote:
 I hate to fuel this any further, but I want to re-iterate what I have
 learned. Please re-read my summary (titled "SHOO's Time code --
 conclusion") in the announce group.

Okay, sorry, I just noticed that some of the details already started to fade from my memory. I apologize for fueling the debate myself once again, let's leave it at that. David
Feb 03 2011
prev sibling parent Gary Whatmore <no spam.sp> writes:
Steven Schveighoffer Wrote:

 On Thu, 03 Feb 2011 18:22:21 -0500, Nick Sabalausky <a a.a> wrote:
 
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vqcns2egeav7ka steve-laptop...
 On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger <see klickverbot.at>
 wrote:

 On 2/3/11 11:46 PM, Jonathan M Davis wrote:
 [.] If they were more open and
 willing to share code, then building off of what they have and turning
 it into a
 range-based solution would likely make a lot of sense, but since  
 that's
 not the
 case, we need to figure it out on our own.

Just like Andrei said, I don't think this issue is worth being discussed over and over again, but I'm curious: Did somebody actually talk o »Tango« resp. the authors of its XML module concerning amendment for Phobos? It's needlessly fueling an »us vs. them« debate in an already small community of developers which drives me crazy.

You are welcome to try. I don't hold out much hope based on past.

The main part of the problem is that Tango modules have many developers and *all* of the relevent contributors need to 1. be successfully contacted and 2. give approval. That all stems purely from legal constraints (ie the interactions of licenses). Part two has never really been a problem, but as was learned, part one can be a real problem.

I hate to fuel this any further, but I want to re-iterate what I have learned. Please re-read my summary (titled "SHOO's Time code -- conclusion") in the announce group. I personally went through great lengths to satisfy 1. It was 2 that was the problem. Seeing that the same author who did not give approval to relicense the time code is an author of Tango's XML code, I doubt his views have changed.

I think being overly correct politically is not necessary in this case. There's only one person against D now, the 'kris' or whatever his real name is. The way I see it, when Andrei came to the community, we all noticed how the better technical and leadership skills started to improve our situation. We've migrated to a more free license useable in commercial contexts unlike the viral Tango license with outrageous attribution clauses. Now instead of reinventing everything under a more closed "open" license, we can make use of commercial grade Boost licensed code. We also now have the good runtime by Sean (not kris) in D2 and naturally all better language features. TDPL is also more popular than the book by Tango developers, which is good for D. The whole Tango ship is sinking. Their most important developers have moved to the Phobos boat. Rest of them probably left D and found inferior mainstream languages. They're grown hatred towards D (which I can tell from the occasional trolling here) because of all those wasted years. Their only motivation to not open their codes is to revenge Walter. - G.W.
Feb 03 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 01:55 AM, Gary Whatmore wrote:
 ... They're grown hatred towards D (which I can tell from the occasional
trolling here)  ...

this (what you're playing) is called the game of the mirror Denis -- _________________ vita es estrany spir.wikidot.com
Feb 03 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/11 1:30 PM, Tomek Sowiński wrote:
 Andrei Alexandrescu napisał:

 I'm not against replacement, but I'd be concerned about removal before a
replacement is available.

My problem is that the mere presence is reducing the likelihood of a replacement coming about, in addition to the other liabilities.

Is anyone tasked with a replacement yet? I had to write an XML parser at some point. It's plenty of work bringing up to industrial quality, so I'd have to know that before I dive in.

Nobody that I know of. If you want to discuss design here while working on it, that would be great. I could think of a few high-level requirements: * works with input ranges so we can plug it in with any source * works with all UTF widths (statically selectable) * avoids where possible memory allocation (perhaps by offering incremental access a la joiner()) * avoids often-called delegates in favor of alias functions * is familiar in concept to people who've used today's successful XML libraries Andrei
Feb 03 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Nobody that I know of. If you want to discuss design here while working 
 on it, that would be great. I could think of a few high-level requirements:
 
 * works with input ranges so we can plug it in with any source

The difficulty with that is if it's a pure input range, then the output cannot be slices of the input.
 * works with all UTF widths (statically selectable)
 
 * avoids where possible memory allocation (perhaps by offering 
 incremental access a la joiner())
 
 * avoids often-called delegates in favor of alias functions
 
 * is familiar in concept to people who've used today's successful XML 
 libraries
 
 
 Andrei
 

Feb 03 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/11 9:11 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Nobody that I know of. If you want to discuss design here while
 working on it, that would be great. I could think of a few high-level
 requirements:

 * works with input ranges so we can plug it in with any source

The difficulty with that is if it's a pure input range, then the output cannot be slices of the input.

In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway. Andrei
Feb 03 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 2/3/11 9:11 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Nobody that I know of. If you want to discuss design here while
 working on it, that would be great. I could think of a few high-level
 requirements:

 * works with input ranges so we can plug it in with any source

The difficulty with that is if it's a pure input range, then the output cannot be slices of the input.

In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway.

Sounds good.
Feb 03 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-03 22:27:08 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On 2/3/11 9:11 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Nobody that I know of. If you want to discuss design here while
 working on it, that would be great. I could think of a few high-level
 requirements:
 
 * works with input ranges so we can plug it in with any source

The difficulty with that is if it's a pure input range, then the output cannot be slices of the input.

In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway.

The problem with parametrizing on the character width is that whether a parser parses a UTF-8 document or a UTF-16 document is determined at runtime by inspecting the document. How is the user of the parser supposed to decide in advance which to instantiate? And how the application is supposed to handle slices of different string types coming from those different parser instances? The actual low-level parser could indeed use a different instance depending on the text encoding as an optimization, but the end-user API should standardize on one string type. Unfortunately, if the XML file is not using the same text encoding as your standard string type, then you can't use slicing and have to create copies for each and every string... Another option is to use a "smart" string type that can accept strings slices of any encoding. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 03 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/11 11:01 PM, Michel Fortin wrote:
 On 2011-02-03 22:27:08 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 On 2/3/11 9:11 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Nobody that I know of. If you want to discuss design here while
 working on it, that would be great. I could think of a few high-level
 requirements:

 * works with input ranges so we can plug it in with any source

The difficulty with that is if it's a pure input range, then the output cannot be slices of the input.

In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway.

The problem with parametrizing on the character width is that whether a parser parses a UTF-8 document or a UTF-16 document is determined at runtime by inspecting the document. How is the user of the parser supposed to decide in advance which to instantiate? And how the application is supposed to handle slices of different string types coming from those different parser instances?

In that case you'd want to store one specific format and convert to it in your I/O routine. Possibly you'd allow the user to choose the encoding format that best suits them.
 The actual low-level parser could indeed use a different instance
 depending on the text encoding as an optimization, but the end-user API
 should standardize on one string type. Unfortunately, if the XML file is
 not using the same text encoding as your standard string type, then you
 can't use slicing and have to create copies for each and every string...

 Another option is to use a "smart" string type that can accept strings
 slices of any encoding.

All good points. Andrei
Feb 03 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 15:48:45 -0500, Tomek Sowiński <just ask.me> wrote:

 Jonathan M Davis napisał:

 I think that at least a couple of people have said that they have the  
 beginnings
 of a replacement, but I don't believe that anyone has stepped up to say  
 that
 they'll actually complete and propose a module for inclusion in Phobos.

Wimps ;-)
 So, std.xml is still very much up in the air, and Tango has set a very  
 high bar
 with regards to speed. And while we may not be able to match Tango for  
 speed -
 especially at first - we'd definitely like to have an xml solution  
 that's close.
 And that's not necessarily going to be easy - especially since we're  
 inevitably
 going to want a range-based solution. And while ranges can be quite  
 efficient, it
 can also be easy to make them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first datetime and it gives me shivers...

I'd recommend not looking at it based on past experience. From this Tango forum post: http://www.dsource.org/projects/tango/forums/topic/389 it looks like it was based on sendero, which looks like it's GPL (http://sourceforge.net/projects/sendero/). Not much help there, but you might get good luck contacting the sendero author to see if he is willing to change the license for Phobos (he obviously must have for Tango, since Tango is not GPL). I believe it is a pull parser, though I'm not sure what that means. What I do know about Tango is that they strive to avoid memory allocation at any cost. Likely it uses the excellent buffering I/O that Tango has in order to avoid copying the input data once it is read from a file. You will be hard pressed to compete with Tango until phobos gets better I/O support (it currently relies on C FILE * I/O). -Steve
Feb 03 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Jonathan M Davis napisał:

 I think that at least a couple of people have said that they have the  
 beginnings
 of a replacement, but I don't believe that anyone has stepped up to  
 say that
 they'll actually complete and propose a module for inclusion in Phobos.

Wimps ;-)
 So, std.xml is still very much up in the air, and Tango has set a very  
 high bar
 with regards to speed. And while we may not be able to match Tango for  
 speed -
 especially at first - we'd definitely like to have an xml solution  
 that's close.
 And that's not necessarily going to be easy - especially since we're  
 inevitably
 going to want a range-based solution. And while ranges can be quite  
 efficient, it
 can also be easy to make them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first datetime and it gives me shivers...

You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked at the source it may be ok..

It has been posited by Tango's developers that simply looking at the documentation of a D library isn't enough to understand the library, you probably have looked at the source. Until they change that opinion, I would avoid even the documentation. http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html The pertinent quote from there: "In my opinion, claiming a clean room implementation of an API in D is difficult, if for no other reason that it is (due to imperfect doc generation etc) somewhat difficult to properly study a D API without at the same time reading the source (or glimpsing at it)."
 Maybe a clean-room approach is possible: Somebody else looks at the  
 source and
 documents what it does and how it does that (without copying anything)  
 and you
 could use that documentation for your own code.
 If you don't want to clone it but have questions about how they did  
 something
 specific you could just ask here and (hopefully) someone looks it up and
 explains it to you.

Make sure if you follow this approach that you document exactly the process and how it was done. -Steve
Feb 03 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson  
 <metalcaedes gmail.com> wrote:

 Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Speaking of Tango, may I look at it? I remember that beef over the  
 first
 datetime and it gives me shivers...

You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked at the source it may be ok..

It has been posited by Tango's developers that simply looking at the documentation of a D library isn't enough to understand the library, you probably have looked at the source. Until they change that opinion, I would avoid even the documentation. http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html The pertinent quote from there: "In my opinion, claiming a clean room implementation of an API in D is difficult, if for no other reason that it is (due to imperfect doc generation etc) somewhat difficult to properly study a D API without at the same time reading the source (or glimpsing at it)."

They can claim whatever they want.. if Tomek says he only looked at the documentation (for an idea how a good interface for a XML lib may look like) they can hardly prove anything.

This exact situation was the case of the prior-mentioned infringement accusation. -Steve
Feb 03 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 17:10:18 -0500, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 I thought the Author *had* looked at the Tango source but claimed not to
 have used it?

See here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=18090 His English isn't perfect, but I took his statements to mean he did not read the source (as I re-asserted in a later message). -Steve
Feb 03 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-02-03 01:47, Bernard Helyer wrote:
 On Wed, 02 Feb 2011 16:28:27 -0800, Brad Roberts wrote:

 I haven't used it nor am likely to,
 but I also have trouble ruling out the potential that there's users for
 which it works and they just aren't talking about it here.

I do not believe that it's possible that anyone has used std.xml successfully for something substantial. :D

I've used std.xml in the Orange project (serialization library) with some modifications. Don't know if that would be counted as something substantial. -- /Jacob Carlborg
Feb 03 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Should we nuke it?

Nuke it. Old versions of Phobos are available to those who need it, and those should be very few. -- Simen
Feb 02 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On Wed, 02 Feb 2011 16:28:27 -0800, Brad Roberts wrote:

 I haven't used it nor am likely to,
 but I also have trouble ruling out the potential that there's users for
 which it works and they just aren't talking about it here.

I do not believe that it's possible that anyone has used std.xml successfully for something substantial. :D
Feb 02 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 02 Feb 2011 17:33:42 -0600, Andrei Alexandrescu wrote:

 For a while we've espoused the strategy of keeping std.xml in Phobos
 until something better comes along.
 
 But recently we've started to rethink that.
 
 Pretty much everyone who tries std.xml ends up disappointed. Anyone who
 wants to bash D has std.xml as an easy pick. Anyone who looks at speed
 comparisons sees std.xml there like a sore thumb. Finally, the mere
 existence of a package, no matter how inadequate, stifles the initiative
 of others working on it.
 
 This all makes std.xml a net liability. It's not better than nothing;
 it's worse than nothing.
 
 Should we nuke it?

Absolutely. -Lars
Feb 02 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-03 00:33, Andrei Alexandrescu wrote:
 For a while we've espoused the strategy of keeping std.xml in Phobos
 until something better comes along.

 But recently we've started to rethink that.

 Pretty much everyone who tries std.xml ends up disappointed. Anyone who
 wants to bash D has std.xml as an easy pick. Anyone who looks at speed
 comparisons sees std.xml there like a sore thumb. Finally, the mere
 existence of a package, no matter how inadequate, stifles the initiative
 of others working on it.

 This all makes std.xml a net liability. It's not better than nothing;
 it's worse than nothing.

 Should we nuke it?


 Andrei

Yes, hasn't this been done already ? -- /Jacob Carlborg
Feb 03 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 03 February 2011 02:01:35 Jacob Carlborg wrote:
 On 2011-02-03 00:33, Andrei Alexandrescu wrote:
 For a while we've espoused the strategy of keeping std.xml in Phobos
 until something better comes along.
 
 But recently we've started to rethink that.
 
 Pretty much everyone who tries std.xml ends up disappointed. Anyone who
 wants to bash D has std.xml as an easy pick. Anyone who looks at speed
 comparisons sees std.xml there like a sore thumb. Finally, the mere
 existence of a package, no matter how inadequate, stifles the initiative
 of others working on it.
 
 This all makes std.xml a net liability. It's not better than nothing;
 it's worse than nothing.
 
 Should we nuke it?
 
 
 Andrei

Yes, hasn't this been done already ?

I don't think that anything has been removed from Phobos yet which didn't have a replacement ready. - Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Thu, 03 Feb 2011 08:33:42 +0900, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 For a while we've espoused the strategy of keeping std.xml in Phobos  
 until something better comes along.

 But recently we've started to rethink that.

 Pretty much everyone who tries std.xml ends up disappointed. Anyone who  
 wants to bash D has std.xml as an easy pick. Anyone who looks at speed  
 comparisons sees std.xml there like a sore thumb. Finally, the mere  
 existence of a package, no matter how inadequate, stifles the initiative  
 of others working on it.

 This all makes std.xml a net liability. It's not better than nothing;  
 it's worse than nothing.

 Should we nuke it?

Good! Masahiro
Feb 03 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Andrei Alexandrescu napisa=C5=82:

 I'm not against replacement, but I'd be concerned about removal before =


=20
 My problem is that the mere presence is reducing the likelihood of a=20
 replacement coming about, in addition to the other liabilities.

Is anyone tasked with a replacement yet? I had to write an XML parser at so= me point. It's plenty of work bringing up to industrial quality, so I'd hav= e to know that before I dive in. --=20 Tomek
Feb 03 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Andrei Alexandrescu napisa=C5=82:

 Is anyone tasked with a replacement yet? I had to write an XML parser a=


have to know that before I dive in. =20
=20
 Nobody that I know of. If you want to discuss design here while working=20
 on it, that would be great.

Alright, I'm game. I'll assemble something discussable.
 I could think of a few high-level requirements:

My requirements are similar. (if I don't comment below, then I agree)
 * works with input ranges so we can plug it in with any source
=20
 * works with all UTF widths (statically selectable)
=20
 * avoids where possible memory allocation (perhaps by offering=20
 incremental access a la joiner())

What you mean by incremental access? A lazy range? It's obvious for the lex= er, but on a higher level? Not sure if I can start traversing the DOM until= the closing tag comes (if at all)... A lazy range of tags defined in the g= lobal scope seems possible, though.
 * avoids often-called delegates in favor of alias functions

What use case of delegates are you talking about?
 * is familiar in concept to people who've used today's successful XML=20
 libraries

--=20 Tomek
Feb 03 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Jonathan M Davis napisa=C5=82:

 I think that at least a couple of people have said that they have the beg=

 of a replacement, but I don't believe that anyone has stepped up to say t=

 they'll actually complete and propose a module for inclusion in Phobos.

Wimps ;-)
 So, std.xml is still very much up in the air, and Tango has set a very hi=

 with regards to speed. And while we may not be able to match Tango for sp=

 especially at first - we'd definitely like to have an xml solution that's=

 And that's not necessarily going to be easy - especially since we're inev=

 going to want a range-based solution. And while ranges can be quite effic=

 can also be easy to make them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first da= tetime and it gives me shivers... --=20 Tomek
Feb 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 03 February 2011 12:48:45 Tomek Sowi=C5=84ski wrote:
 Jonathan M Davis napisa=C5=82:
 I think that at least a couple of people have said that they have the
 beginnings of a replacement, but I don't believe that anyone has stepped
 up to say that they'll actually complete and propose a module for
 inclusion in Phobos.

Wimps ;-) =20
 So, std.xml is still very much up in the air, and Tango has set a very
 high bar with regards to speed. And while we may not be able to match
 Tango for speed - especially at first - we'd definitely like to have an
 xml solution that's close. And that's not necessarily going to be easy -
 especially since we're inevitably going to want a range-based solution.
 And while ranges can be quite efficient, it can also be easy to make
 them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first datetime and it gives me shivers...

I don't know. I wouldn't. It would just be safer that way. I avoid Tango=20 completely, because I don't want even the possibility of being accused of=20 copying anything from there. But maybe someone who's more in the know about= =20 Tango would have something different to say. Regardless, as I understand it, the main reasons for Tango's speed in parsi= ng=20 xml is the fact that D's array slicing lets it avoid doing much in the way = of=20 copying. And while the new std.xml should be range-based, the slicing benef= its=20 should still hold (at least with built-in strings) as long as we avoid usin= g=20 range-based functions which would copy the data rather than slicing it. =2D Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/03/2011 10:00 PM, Steven Schveighoffer wrote:
 I believe it is a pull parser, though I'm not sure what that means.

http://en.wikipedia.org/wiki/XML#Pull_parsing --- Denis -- _________________ vita es estrany spir.wikidot.com
Feb 03 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Daniel Gibson napisa=C5=82:

 They can claim whatever they want.. if Tomek says he only looked at the
 documentation (for an idea how a good interface for a XML lib may look li=

 they can hardly prove anything.

One remark: I haven't even looked at the doc. That's why I was asking "may = I look". --=20 Tomek
Feb 03 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
spir spir napisa=C5=82:

 You probably shouldn't look at the source.
 I dunno about the interface (documentation) - it's certainly not illega=


 inspiration from it, but maybe then people will again claim that source=


 stolen.. but when you claim that you haven't looked at the source it ma=


 Maybe a clean-room approach is possible: Somebody else looks at the sou=


 documents what it does and how it does that (without copying anything) =


 could use that documentation for your own code.
 If you don't want to clone it but have questions about how they did som=


 specific you could just ask here and (hopefully) someone looks it up and
 explains it to you. =20

Mamma mia! In what world are we supposed to live!?

My thoughts exactly. I mean, as soon as Jonathan mentioned Tango's XML, I k= nee-jerkingly got paranoid and asked about legality of even reading about i= t to stay clear. I only hope having heard about it is legal. --=20 Tomek
Feb 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 03, 2011 14:17:49 Tomek Sowi=C5=84ski wrote:
 spir spir napisa=C5=82:
 You probably shouldn't look at the source.
 I dunno about the interface (documentation) - it's certainly not
 illegal to take inspiration from it, but maybe then people will again
 claim that source was stolen.. but when you claim that you haven't
 looked at the source it may be ok..
=20
 Maybe a clean-room approach is possible: Somebody else looks at the
 source and documents what it does and how it does that (without
 copying anything) and you could use that documentation for your own
 code.
 If you don't want to clone it but have questions about how they did
 something specific you could just ask here and (hopefully) someone
 looks it up and explains it to you.

Mamma mia! In what world are we supposed to live!?

My thoughts exactly. I mean, as soon as Jonathan mentioned Tango's XML, I knee-jerkingly got paranoid and asked about legality of even reading about it to stay clear. I only hope having heard about it is legal.

Well, we're not looking to copy what they did. We're just looking to get=20 performance that's similar. As I understand it, Tango's XML parser is one o= f the=20 best out there as far as speed goes. From the benchmarks I've seen, it=20 absolutely creams the competition. So, they're set a high bar, and we'd lik= e to=20 reach it. We probably won't be that fast at first, and we may never be that= fast,=20 but it's something to shoot for. Regardless, it's their performance that we= 're=20 interested in, not necessarily their implementation. If they were more open= and=20 willing to share code, then building off of what they have and turning it i= nto a=20 range-based solution would likely make a lot of sense, but since that's not= the=20 case, we need to figure it out on our own. =2D Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/03/2011 11:10 PM, Daniel Gibson wrote:
 Claiming that looking at the documentation isn't sufficient to understand how
 the API works (from a users point of view, not internally) is pretty stupid:
 1. it insults the modules author(s) ("You're too stupid to write meaningful
 documentation")
 2. even if the documentation sucks one may have understood how to the API is
 used by looking at code examples using it...

There is an obvious loophole in their argumentation: what if the author of the new lib has used the old one for years: thus perfectly understands the API from the client side, and certainly has a good idea of how it may well be implemented, even more beeing a library author (even more since client & implementation languages are the same in this case). Denis -- _________________ vita es estrany spir.wikidot.com
Feb 03 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger <see klickverbot.at>  
wrote:

 On 2/3/11 11:46 PM, Jonathan M Davis wrote:
 […] If they were more open and
 willing to share code, then building off of what they have and turning  
 it into a
 range-based solution would likely make a lot of sense, but since that's  
 not the
 case, we need to figure it out on our own.

Just like Andrei said, I don't think this issue is worth being discussed over and over again, but I'm curious: Did somebody actually talk to »Tango« resp. the authors of its XML module concerning amendment for Phobos? It's needlessly fueling an »us vs. them« debate in an already small community of developers which drives me crazy…

You are welcome to try. I don't hold out much hope based on past. I did not want to fuel a debate on "us vs. them", Phobos and Tango can happily co-exist without crossing paths, I just wanted to respond Tomek to tread carefully based on Tango representatives' prior statements, since he asked. The last thing I want to see again is someone waste effort, nobody likes to do that. With the correct precautions, we don't have to go through this again. I think Andrei said it best -- we can find other XML libraries to learn from. -Steve
Feb 03 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 18:22:21 -0500, Nick Sabalausky <a a.a> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vqcns2egeav7ka steve-laptop...
 On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger <see klickverbot.at>
 wrote:

 On 2/3/11 11:46 PM, Jonathan M Davis wrote:
 [.] If they were more open and
 willing to share code, then building off of what they have and turning
 it into a
 range-based solution would likely make a lot of sense, but since  
 that's
 not the
 case, we need to figure it out on our own.

Just like Andrei said, I don't think this issue is worth being discussed over and over again, but I'm curious: Did somebody actually talk o »Tango« resp. the authors of its XML module concerning amendment for Phobos? It's needlessly fueling an »us vs. them« debate in an already small community of developers which drives me crazy.

You are welcome to try. I don't hold out much hope based on past.

The main part of the problem is that Tango modules have many developers and *all* of the relevent contributors need to 1. be successfully contacted and 2. give approval. That all stems purely from legal constraints (ie the interactions of licenses). Part two has never really been a problem, but as was learned, part one can be a real problem.

I hate to fuel this any further, but I want to re-iterate what I have learned. Please re-read my summary (titled "SHOO's Time code -- conclusion") in the announce group. I personally went through great lengths to satisfy 1. It was 2 that was the problem. Seeing that the same author who did not give approval to relicense the time code is an author of Tango's XML code, I doubt his views have changed. -Steve
Feb 03 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 03, 2011 15:51:10 %u wrote:
 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 
 I hate to fuel this any further, but I want to re-iterate what I have
 learned.  Please re-read my summary (titled "SHOO's Time code --
 conclusion") in the announce group.
 I personally went through great lengths to satisfy 1.  It was 2 that was
 the problem.
 Seeing that the same author who did not give approval to relicense the
 time code is an author of Tango's XML code, I doubt his views have
 changed. -Steve

With only two(or one even) off these three helping out: larsivi, kris and stonecobra, you can get quite a bit of (older) code readable.

Which brings us back to Andrei's point. There are plenty of other good XML libraries out there. We have no need to base Phobos code off of Tango. Let's just drop it and move on. I only brought up Tango in the first place to point out that it is a goal of the new std.xml to at least come close to Tango's performance in parsing XML, because Tango's XML parser is very fast. It's a point which has been brought up before and I believe that it still holds. However, that doesn't mean that we need to deal with the Tango API or source code, and we definitely don't want any more debates about "us vs them" or any such nonsense. Let's just move on. - Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent so <so so.do> writes:
 Let's just move on.

Like we could do the opposite, these tries of cooling down "the sides" quite pointless in this "debate". 99.999(can continue)% of the posts about this were nothing but a monologue.
Feb 03 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski <jeff dilacero.org>  
wrote:

 On 02/03/2011 10:07 PM, Walter Bright wrote:
 The way to get a high performance string parser in D is to take
 advantage of one of D's unique features - slices. Java, C++, C#, etc.,
 all rely on copying strings. With D you can just use slices into the
 original XML source text. If you're copying the text, you're doing it
 wrong.

Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.

Yes, but Java's strings are immutable. Typically a buffered I/O stream has a mutable buffer used to read data. This necessitates a copy. At the very least, you need to continue allocating more memory to hold all the strings. -Steve
Feb 04 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Feb 2011 08:19:51 -0500, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 04/02/2011 21:07, Steven Schveighoffer wrote:
 On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski <jeff dilacero.org>
 wrote:

 On 02/03/2011 10:07 PM, Walter Bright wrote:
 The way to get a high performance string parser in D is to take
 advantage of one of D's unique features - slices. Java, C++, C#, etc.,
 all rely on copying strings. With D you can just use slices into the
 original XML source text. If you're copying the text, you're doing it
 wrong.

Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.

Yes, but Java's strings are immutable. Typically a buffered I/O stream has a mutable buffer used to read data. This necessitates a copy. At the very least, you need to continue allocating more memory to hold all the strings. -Steve

True, but in this case you will have the exact same problem with any other language as well. So it doesn't seem like D will have any particular advantage over Java, with regards to slicing and strings.

I think D can do it without copying out of the buffer. You just have to avoid using immutable strings. -Steve
Feb 11 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Feb 2011 19:55:59 -0500, Gary Whatmore <no spam.sp> wrote:

There are a few false statements in here, I feel like saying "I don't know  
this guy."  I'm sorry I had to bring this up again...

Tango is not evil, it is built much the same way Phobos is, from many  
enthusiastic developers who want to make things better.  Not to mention  
their code is very good (I know, I wrote some of it, and I've read a lot  
of it).

Unfortunately for us, some main contributors believe the license should  
not be changed (which is perfectly within their rights), and there's not  
much we can do about it except avoid using their code.  We should just  
move on and forget about it.  Let's see how good we can do on our own, I  
think we have the technical prowess to get reasonable performance in an  
XML library cleanly.

-Steve
Feb 03 2011
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
On 03/02/2011 00:33, Andrei Alexandrescu wrote:
 For a while we've espoused the strategy of keeping std.xml in Phobos
 until something better comes along.

 But recently we've started to rethink that.

 Pretty much everyone who tries std.xml ends up disappointed. Anyone who
 wants to bash D has std.xml as an easy pick. Anyone who looks at speed
 comparisons sees std.xml there like a sore thumb. Finally, the mere
 existence of a package, no matter how inadequate, stifles the initiative
 of others working on it.

 This all makes std.xml a net liability. It's not better than nothing;
 it's worse than nothing.

 Should we nuke it?


 Andrei

What about ... http://dsource.org/projects/xmlp well documented, well tested, reasonable speed. But I think std.xml is not the biggest problem. Problem #1 The chaotic non-managed way phobos evolves. Problem #2 Ignorance respective ignoring good stuff. What about adding BCS's units ? Problem #3 Andrei's range obsession. Andrei : Please show a pure range based implementation of, say, a Map. The basic ADT is already in place. I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern
Feb 03 2011
next sibling parent so <so so.do> writes:
 What about ...
 http://dsource.org/projects/xmlp

 well documented, well tested, reasonable speed.

 But I think std.xml is not the biggest problem.
 Problem #1 The chaotic non-managed way phobos evolves.

What does that mean? Top down OOP?
 Problem #3 Andrei's range obsession. Andrei : Please show a pure range  
 based implementation of, say, a Map. The basic ADT is already in place.

This is wrong, having a unified (range for D) interface is necessary for many reasons, mainly composability. If you have arguments against ranges, say so we get to know them and maybe solve/replace with something better.
 I got more and more the feeling that the D2 monster was made just for  
 ranges. The smart and elegant D1 design is definitely dead an gone. I  
 think I am not the only one who would prefer a D1 plus instead of D2.

Isn't it apples to oranges? I agree on a few features D2 made mistakes but ranges not one of them. Also, you seem to favor "one paradigm (OOP) to rule them all" but at the same time against "one interface to rule them all" which is IMO more palatable comparing to the first one.
Feb 03 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/11 7:56 PM, BLS wrote:
 What about ...
 http://dsource.org/projects/xmlp

 well documented, well tested, reasonable speed.

Cool. Is Michael Rynn willing to make a submission?
 But I think std.xml is not the biggest problem.
 Problem #1 The chaotic non-managed way phobos evolves.

In recent times we have increased the number of active contributors base dramatically; we have been adding features and fixed bugs by the dozens with each release; we have improved the review process with two successful iterations (datetime and unittests); and we moved to github which further increases collaboration and contributions. Obviously there are many other ways in which we can improve phobos' evolution. Please share any ideas you might have.
 Problem #2 Ignorance respective ignoring good stuff. What about adding
 BCS's units ?

Benjamin did not submit units for review. My understanding is that he is not interested in doing so, but has graciously offered the code for someone else to put it into a form appropriate for submission.
 Problem #3 Andrei's range obsession. Andrei : Please show a pure range
 based implementation of, say, a Map. The basic ADT is already in place.

I don't understand this challenge. What would "pure range-based" mean? A map needs to offer iteration over its keys, values, and probably pairs of keys and values, and in addition has other primitives. The current way in which built-in associative arrays offers its keys and values (as a copy in an array) is inadequate for obvious reasons.
 I got more and more the feeling that the D2 monster was made just for
 ranges. The smart and elegant D1 design is definitely dead an gone. I
 think I am not the only one who would prefer a D1 plus instead of D2.
 bjoern

There are a few differences between D2 and D1 and it's entirely understandable that someone who enjoys D1 is not thrilled with D2. Here's a personal opinion - it may be a good time to face the notion that D1 will never make it to prime time. It is not equipped properly and it does not offer sufficient compelling advantages compared to other languages. This is an issue independent from D2. D1 does not have enough gasoline in the tank to go up the hill. On the other hand, D2 does. It has a better definition, a powerful concurrency model, true generic concepts, and a standard library to match. I believe ranges are a great idea, and not because it's mine (in fact it's rather derivative). A Phobos component that manipulates sequences is reasonably expected to work with ranges, because there's just so much infrastructure built on them. At this point there is no turning back from ranges, unless we come about with an even better idea (I discussed one with Walter but we're not pursuing it yet). Feel free to share anything you feel is lacking about ranges and better alternatives; emotional but vague characterizations are unlikely to help matters. All in all it's fair to say that if you hate ranges you're going to dislike D2, and there's little that can be done about that. Andrei
Feb 03 2011
next sibling parent SiegeLord <none none.com> writes:
 All in all it's fair to say that if you hate ranges you're going to 
 dislike D2, and there's little that can be done about that.
 

Well, you can just not use Phobos2. It's a standard library, not a mandatory library. -SiegeLord
 
 Andrei

Feb 03 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:iifrf0$2g2q$1 digitalmars.com...
 At this point there is no turning back from ranges, unless we come about 
 with an even better idea (I discussed one with Walter but we're not 
 pursuing it yet).

Any teaser? You've got me really curious.
Feb 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 03 February 2011 23:35:18 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:iifrf0$2g2q$1 digitalmars.com...
 
 At this point there is no turning back from ranges, unless we come about
 with an even better idea (I discussed one with Walter but we're not
 pursuing it yet).

Any teaser? You've got me really curious.

They're Lone Ranges! They'll ride to your rescue! Or, maybe not... ;) But yes. That statement abouth finding something better than ranges does peek one's curiosity. Of course, Phobos is so entrenched in ranges at this point that it would probably have to be either _way_ better than ranges or similar that it would be easy to integrate it for it to go into Phobos anytime soon - which may be why it's not. - Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 On 2/3/11 7:56 PM, BLS wrote:

 I got more and more the feeling that the D2 monster was made just for
 ranges. The smart and elegant D1 design is definitely dead an gone. I
 think I am not the only one who would prefer a D1 plus instead of D2.
 bjoern


 All in all it's fair to say that if you hate ranges you're going to 
 dislike D2, and there's little that can be done about that.

Yes, but... I think we really, really, need to work on making Phobos less daunting. Right now, we have most of the functionality. But some things are unnecessarily complicated -- some are historical, some are workarounds for compiler bugs (many of which are now fixed), some are rough edges in the language definition which could probably be fixed. We don't have many examples; many discussions and explanations assume too much familiarity with terminology and concepts from functional programming languages; and probably most importantly, we don't have tutorials. All these things can and will be fixed. But right now, the learning curve is horrible, and it's a major turnoff for people.
Feb 04 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/11 3:15 AM, Don wrote:
 Andrei Alexandrescu wrote:
 On 2/3/11 7:56 PM, BLS wrote:

 I got more and more the feeling that the D2 monster was made just for
 ranges. The smart and elegant D1 design is definitely dead an gone. I
 think I am not the only one who would prefer a D1 plus instead of D2.
 bjoern


 All in all it's fair to say that if you hate ranges you're going to
 dislike D2, and there's little that can be done about that.

Yes, but... I think we really, really, need to work on making Phobos less daunting. Right now, we have most of the functionality. But some things are unnecessarily complicated -- some are historical, some are workarounds for compiler bugs (many of which are now fixed), some are rough edges in the language definition which could probably be fixed. We don't have many examples; many discussions and explanations assume too much familiarity with terminology and concepts from functional programming languages; and probably most importantly, we don't have tutorials. All these things can and will be fixed. But right now, the learning curve is horrible, and it's a major turnoff for people.

Absolutely. There are some major strides we have and can make, enabled by recent bug fixes and language improvements. For example a lot of things are made considerably easier by auto returns. Then I think relaxing the rules for eponymous templates would tremendously reduce code size for a variety of templates. Finally, eliminating bugs and undue limitations from the language will again allow us to simplify things a lot. With documentation and tutorials I am confident the entire community will help in time. Andrei
Feb 04 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 Having a perspective on how all features tie together is crucial to
 understanding the purpose of individual features themselves. In my
 opinion!

Of course, but both are necessary.
Feb 04 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 (and not implicitely assuming 10 years of C++ programming --esp. about
vocabulary:

I've seen too many times people in D newsgroups assume that most D programmers come from C++ and know C++ well enough. This is bad. Bye, bearophile
Feb 04 2011
prev sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:

 On 2/4/11, spir <denis.spir gmail.com> wrote:
 About that, I would love a tutorial about eponymous templates starting
 with their /purpose/ (why does this feature even exist? what does it
 /mean/? what does it compare/oppose to? why is one supposed to need/enjoy
 it? how is it supposed to help & make code better mirror model?) Same for
 alias template params. Same for a rather long list of features, probably.

But both of these are already explained in the manual: http://www.digitalmars.com/d/2.0/template.html (search for Implicit Template Properties) http://www.digitalmars.com/d/2.0/template.html (search for Template Alias Parameters) Granted, eponymous templates aren't explained in much detail on that page. As for explaining how they work together, I did write that short template tutorial (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but you've already seen that. :) However, I do not think we should write tutorials on single features alone. I've read a bunch of books that explain the language in feature-by-feature basis, but neglect to tie everything together. For example, "Learning Python" is this 1200 page book about Python 3, explaining the language feature by feature but never really discussing the language as a whole. It's only good as a reference, which ironically defeats the book's title. OTOH "Dive into Python 3" gradually introduces you to more features of the language, but always has code examples where you can see multiple features of the language being used. (IIRC there were string processing examples which used regex, multiple modules, and unittests all at once). Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion!

I agree, most of the 'dive into' books are excellent and complementary to reference materials. TDPL also has great little examples that illustrate the why of things, without ever becoming a mindless tutorial. It's hard to write such things however (witness the abundant amount of horrible technical writing), I truly admire those who can.
Feb 05 2011
prev sibling next sibling parent reply Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
 At this point there is no turning back from ranges, unless we come about
 with an even better idea (I discussed one with Walter but we're not
 pursuing it yet).

Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?
Feb 04 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 04/02/2011 16:14, Eric Poggel wrote:
 On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
 At this point there is no turning back from ranges, unless we come about
 with an even better idea (I discussed one with Walter but we're not
 pursuing it yet).

Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?

That comment left me curious as well... -- Bruno Medeiros - Software Engineer
Feb 11 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/11 8:31 AM, Bruno Medeiros wrote:
 On 04/02/2011 16:14, Eric Poggel wrote:
 On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
 At this point there is no turning back from ranges, unless we come about
 with an even better idea (I discussed one with Walter but we're not
 pursuing it yet).

Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?

That comment left me curious as well...

The discussed idea went as follows. Currently we have r.front and r.back for accessing the first and last element, and r[n] for an arbitrary element. Plus, r[n] is extremely flexible (opIndex, opIndexAssign, opIndexOpAssign... awesome level of control... just perfect). So then I thought, how about unifying everything? Imagine we gave up on r.front and r.back. Poof. They disappeared. Now we define two entities "first" and last" such that r[first] and r[last] refer the first and last elements in the range. Now we have the situ: - Input and forward ranges statically allow only r[first] - Bidirectional ranges allow r[first] and r[last] - Random-access ranges allow r[first], r[last], and r[n] for integrals n Now we have a unified way of referring to elements in ranges. Walter's excellent follow-up is that the compiler could use lowering such that you don't even need to use first and last. You'd just use r[0] and r[$ - 1] and the compiler would take care of handling these special cases. Advantages: unified syntax, increased flexibility with opIndexAssign and opIndexOpAssign. Disadvantages: breaks all range-oriented code out there. Andrei
Feb 11 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Now we have a unified way of referring to elements in ranges. Walter's 
 excellent follow-up is that the compiler could use lowering such that 
 you don't even need to use first and last. You'd just use r[0] and r[$ - 
 1] and the compiler would take care of handling these special cases.

Nice. Now you just need to lower the syntax a~b to mean chain(a,b) for lazy ranges, and we are starting to use ranges well enough, as lists in functional languages :-) Bye, bearophile
Feb 11 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Except that then you get the issue of eager vs lazy concatenation. chain is
lazy 
 whereas ~ is eager, so that wouldn't fly.

In dlibs1 I have a lazy chain(). If you perform a chain(chain(x, y), z) or chain(x, chain(y, z)) it's rewritten as chain(x,y,z). Plus there's a "chainable" mixin. If you mix it into a struct or class, the struct or class defines the ~ and ~= operators, making them mean chain(). All this requires no changed in the compiler front-end, and I think it doesn't have the problem you mention. Bye, bearophile
Feb 12 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 It's a problem of semantics. ~ is intended for eager concatenation. That's how 
 it's designed and what it's expected to mean.

This is written nowhere. I am referring to my second proposal. It makes code more generic, because it allows you to use ~ for both arrays and lazy iterables in a polymorphic situation, and the computational complexity here is not a problem. I'd like to know Andrei opinion on this :-)
 More importantly, that's how it 
 works for arrays. If you made it lower to chain, then either ~ for arrays has 
 become lazy (along with every other user-defined type which overloads 
 opBinary!"~" and made it eager as would be expected),

I agree, that's why I have prosed a second alternative that lacks this problem (it doesn't use lowering, just operator overloading and a mixin).
 Regardless, as it's not going to be implemented any time soon, there's not
much 
 point in debating it right now.

My second suggestion is related for Phobos only, and it's implementable now, if there's enough desire. Bye, bearophile
Feb 12 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 12 February 2011 06:26:40 spir wrote:
 On 02/12/2011 03:17 PM, bearophile wrote:
 Jonathan M Davis:
 It's a problem of semantics. ~ is intended for eager concatenation.
 That's how it's designed and what it's expected to mean.

This is written nowhere. I am referring to my second proposal. It makes code more generic, because it allows you to use ~ for both arrays and lazy iterables in a polymorphic situation, and the computational complexity here is not a problem. I'd like to know Andrei opinion on this :-) =20
 More importantly, that's how it
 works for arrays. If you made it lower to chain, then either ~ for
 arrays has become lazy (along with every other user-defined type which
 overloads opBinary!"~" and made it eager as would be expected),

I agree, that's why I have prosed a second alternative that lacks this problem (it doesn't use lowering, just operator overloading and a mixin). =20
 Regardless, as it's not going to be implemented any time soon, there's
 not much point in debating it right now.

My second suggestion is related for Phobos only, and it's implementable now, if there's enough desire.

Hol=C3=A0 bearophile, what about using '*' for chaining syntax sugar. I mean, func composition =

 often written using '.' which means product (and is sometimes even spelled
 "product" for functions too), right? And product is written '*' in D...
 What do you think?

Walter already decided against using + for concatenation because of the=20 perceived ambiguity - e.g. does "5" + "2" do "52" or "7"? He's not going to= go=20 for * for anything similar. Honestly, we don't need more syntactic sugar at= this=20 point. =2D Jonathan M Davis
Feb 12 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 what about using '*' for chaining syntax sugar. I mean, func composition is 
 often written using '.' which means product (and is sometimes even spelled 
 "product" for functions too), right? And product is written '*' in D... What
do 
 you think?

I think that using * for lazy chaining breaks the genericity of the code, because you need a symbol for arrays/strings and another symbol for lazy sequences. So it's mostly useless if not actively negative. Bye, bearophile
Feb 12 2011
prev sibling parent so <so so.so> writes:
 Walter already decided against using + for concatenation because of the
 perceived ambiguity - e.g. does "5" + "2" do "52" or "7"? He's not going  
 to go
 for * for anything similar. Honestly, we don't need more syntactic sugar  
 at this
 point.

 - Jonathan M Davis

Isn't it quite obvious? Both "+" "*" serves nothing but ambiguity, their literal meanings have nothing to do with chaining. While at first look, it may seem that "+" have some relation with the chaining. But if you think for a while, it is not chaining at all. On the other hand "~" is designed exactly for this reason and if we were to lower it, this "has to" be the obvious choice.
Feb 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/12/2011 03:17 PM, bearophile wrote:
 Jonathan M Davis:

 It's a problem of semantics. ~ is intended for eager concatenation. That's how
 it's designed and what it's expected to mean.

This is written nowhere. I am referring to my second proposal. It makes code more generic, because it allows you to use ~ for both arrays and lazy iterables in a polymorphic situation, and the computational complexity here is not a problem. I'd like to know Andrei opinion on this :-)
 More importantly, that's how it
 works for arrays. If you made it lower to chain, then either ~ for arrays has
 become lazy (along with every other user-defined type which overloads
 opBinary!"~" and made it eager as would be expected),

I agree, that's why I have prosed a second alternative that lacks this problem (it doesn't use lowering, just operator overloading and a mixin).
 Regardless, as it's not going to be implemented any time soon, there's not much
 point in debating it right now.

My second suggestion is related for Phobos only, and it's implementable now, if there's enough desire.

Holà bearophile, what about using '*' for chaining syntax sugar. I mean, func composition is often written using '.' which means product (and is sometimes even spelled "product" for functions too), right? And product is written '*' in D... What do you think? denis -- _________________ vita es estrany spir.wikidot.com
Feb 12 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 11, 2011 17:01:31 bearophile wrote:
 Andrei:
 Now we have a unified way of referring to elements in ranges. Walter's
 excellent follow-up is that the compiler could use lowering such that
 you don't even need to use first and last. You'd just use r[0] and r[$ -
 1] and the compiler would take care of handling these special cases.

Nice. Now you just need to lower the syntax a~b to mean chain(a,b) for lazy ranges, and we are starting to use ranges well enough, as lists in functional languages :-)

Except that then you get the issue of eager vs lazy concatenation. chain is lazy whereas ~ is eager, so that wouldn't fly. Regardless, it sounds like it would be an idea best suited to D3 if there ever is one. It doesn't add enough value to be worth the breakage that it would cause (which appears to be Walter and Andrei's conclusion). - Jonathan M Davis
Feb 11 2011
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 04/02/2011 04:20, Andrei Alexandrescu wrote:
 Cool. Is Michael Rynn willing to make a submission?

He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he offers his implementation for phobos. Regarding ranges. - Ranges of ranges which are IMHO needed for any kind of non linear data-structures (say:everything which contains a node) seem to be very difficult to handle. -I could further argue that Steven is still using cursors in dcollections, but well, you already know that :) Finally, don't get me wrong, I still like D. Bjoern
Feb 05 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/11 17:54 EST, BLS wrote:
 On 04/02/2011 04:20, Andrei Alexandrescu wrote:
 Cool. Is Michael Rynn willing to make a submission?

He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he offers his implementation for phobos.

We need to improve the formalism of submissions to Phobos. The first successful instance of that is std.datetime - a model we should follow.
 Regarding ranges.
 - Ranges of ranges which are IMHO needed for any kind of non linear
 data-structures (say:everything which contains a node) seem to be very
 difficult to handle.

Feel free to discuss. (I'll note that that would only further my obsession with ranges...)
 -I could further argue that Steven is still using cursors in
 dcollections, but well, you already know that :)

Cursors are an addendum to ranges, not a replacement. Andrei
Feb 06 2011
parent reply BLS <windevguy hotmail.de> writes:
On 06/02/2011 16:41, Andrei Alexandrescu wrote:
 On 2/5/11 17:54 EST, BLS wrote:
 On 04/02/2011 04:20, Andrei Alexandrescu wrote:
 Cool. Is Michael Rynn willing to make a submission?

He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he offers his implementation for phobos.

We need to improve the formalism of submissions to Phobos. The first successful instance of that is std.datetime - a model we should follow.
 Regarding ranges.
 - Ranges of ranges which are IMHO needed for any kind of non linear
 data-structures (say:everything which contains a node) seem to be very
 difficult to handle.

Feel free to discuss. (I'll note that that would only further my obsession with ranges...)
 -I could further argue that Steven is still using cursors in
 dcollections, but well, you already know that :)

Cursors are an addendum to ranges, not a replacement. Andrei

dictionary container. Nothing special so far but interesting 'cause its Node-Structure contains node[]. (or node*[] // ) Since skiplists are pretty simple datastructures, at least compared to some self balancing tree algorithms, it would be an excellent opportunity to show how ranges work on data-structures. In practice. IMHO, we need again a new a discussion regarding how to implement containers. 1- concurrent/ non concurrent containers 2- Isn't it cleaner to have std.adt // abstract datatypes like rbtree, avl, whatever nodes, graphs 3- final class vs struct 4- Constraints vs Interfaces 5- What about container events ? bjoern ps Despite that, due to the fact that the QT folks *prefer to implement their dictionary container based on skiplists, this structure is probably worth to become part of phobos.
Feb 07 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/11 12:02 PM, BLS wrote:
 On 06/02/2011 16:41, Andrei Alexandrescu wrote:
 On 2/5/11 17:54 EST, BLS wrote:
 On 04/02/2011 04:20, Andrei Alexandrescu wrote:
 Cool. Is Michael Rynn willing to make a submission?

He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he offers his implementation for phobos.

We need to improve the formalism of submissions to Phobos. The first successful instance of that is std.datetime - a model we should follow.
 Regarding ranges.
 - Ranges of ranges which are IMHO needed for any kind of non linear
 data-structures (say:everything which contains a node) seem to be very
 difficult to handle.

Feel free to discuss. (I'll note that that would only further my obsession with ranges...)
 -I could further argue that Steven is still using cursors in
 dcollections, but well, you already know that :)

Cursors are an addendum to ranges, not a replacement. Andrei

dictionary container.

I appreciate that, but it's not worth making me the bottleneck on a topic of general interest. You should post here.
 Nothing special so far but interesting 'cause its
 Node-Structure contains node[]. (or node*[] // )

 Since skiplists are pretty simple datastructures, at least compared to
 some self balancing tree algorithms, it would be an excellent
 opportunity to show how ranges work on data-structures. In practice.

 IMHO, we need again a new a discussion regarding how to implement
 containers.
 1- concurrent/ non concurrent containers

For now concurrent containers are considered completely different beasts from non-concurrent ones.
 2- Isn't it cleaner to have std.adt // abstract datatypes like rbtree,
 avl, whatever nodes, graphs

I don't think so.
 3- final class vs struct

Looks like final class is a bit cleaner.
 4- Constraints vs Interfaces

That's tied to 2; I think interfaces are a poor fit for the variety of containers that are out there.
 5- What about container events ?

A container that emits events upon change should be a parameterized non-final class that takes the container C as a parameter and exposes the same methods as C with events in tow.
 bjoern
 ps
 Despite that, due to the fact that the QT folks *prefer to implement
 their dictionary container based on skiplists, this structure is
 probably worth to become part of phobos.

Skiplists fit the philosophy of std.container very well. Andrei
Feb 07 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/11, spir <denis.spir gmail.com> wrote:
 About that, I would love a tutorial about eponymous templates starting with
 their /purpose/ (why does this feature even exist? what does it /mean/? what
 does it compare/oppose to? why is one supposed to need/enjoy it? how is it
 supposed to help & make code better mirror model?) Same for alias template
 params. Same for a rather long list of features, probably.

But both of these are already explained in the manual: http://www.digitalmars.com/d/2.0/template.html (search for Implicit Template Properties) http://www.digitalmars.com/d/2.0/template.html (search for Template Alias Parameters) Granted, eponymous templates aren't explained in much detail on that page. As for explaining how they work together, I did write that short template tutorial (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but you've already seen that. :) However, I do not think we should write tutorials on single features alone. I've read a bunch of books that explain the language in feature-by-feature basis, but neglect to tie everything together. For example, "Learning Python" is this 1200 page book about Python 3, explaining the language feature by feature but never really discussing the language as a whole. It's only good as a reference, which ironically defeats the book's title. OTOH "Dive into Python 3" gradually introduces you to more features of the language, but always has code examples where you can see multiple features of the language being used. (IIRC there were string processing examples which used regex, multiple modules, and unittests all at once). Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion!
Feb 04 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
BLS wrote:
 I got more and more the feeling that the D2 monster was made just for 
 ranges.

The only range support that is actually in the language is in foreach. That can be ignored if you prefer. Unix's core structure is that everything is a file. Operations are strung together as operations on files, the output of each "filter" is fed as a file into the next one. The huge success is that so many operations are implementable as filters, and that filters can be plugged together in any order. There have been many attempts to duplicate this success in programming languages, called "component" programming. Lisp is, of course, a very early example. It accomplished this by "everything is a list", and so diverse operations on lists could all be componentized snapped together. Microsoft COM is another example, built on top of OOP. C++'s hat in that ring is iterators, and to some extent it was successful. I think C++ would be dead now if not for iterators. I'm as convinced as I can be without a decade of experience behind it, that ranges are the new paradigm for component programming. The more Phobos APIs are reworked to use ranges, the more componentized things get. I don't think we've quite reached the tipping point yet, but we're close. Although I said earlier that the only explicit range support in D2 is in foreach, a lot of the enhancements and adjustments to D2 were to better support ranges.
Feb 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/11, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrej Mitrovic wrote:
 Having a perspective on how all features tie together is crucial to
 understanding the purpose of individual features themselves. In my
 opinion!

Of course, but both are necessary.

Well, I'm saying that you've already done your part of the job in the manual. Well at least most of it, there's a few sections missing but this was reported in bugzilla.
Feb 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/11, spir <denis.spir gmail.com> wrote:
 but there are tons of parts of D2 that would
 benefit of a good introduction, really starting from the base (and not
 implicitely assuming 10 years of C++ programming --esp. about vocabulary:
 people here don't seem to realise how much words they use everyday can be
 misleading coming from != background, or even not be used elsewhere in
 programming).

So how would you go about doing this?
Feb 04 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/11/11 8:31 AM, Bruno Medeiros wrote:
 On 04/02/2011 16:14, Eric Poggel wrote:
 On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
 At this point there is no turning back from ranges, unless we come  
 about
 with an even better idea (I discussed one with Walter but we're not
 pursuing it yet).

Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?

That comment left me curious as well...

The discussed idea went as follows. Currently we have r.front and r.back for accessing the first and last element, and r[n] for an arbitrary element. Plus, r[n] is extremely flexible (opIndex, opIndexAssign, opIndexOpAssign... awesome level of control... just perfect). So then I thought, how about unifying everything? Imagine we gave up on r.front and r.back. Poof. They disappeared. Now we define two entities "first" and last" such that r[first] and r[last] refer the first and last elements in the range. Now we have the situ: - Input and forward ranges statically allow only r[first] - Bidirectional ranges allow r[first] and r[last] - Random-access ranges allow r[first], r[last], and r[n] for integrals n Now we have a unified way of referring to elements in ranges. Walter's excellent follow-up is that the compiler could use lowering such that you don't even need to use first and last. You'd just use r[0] and r[$ - 1] and the compiler would take care of handling these special cases.

er... I don't like this. 0 does not necessarily mean first element. A map has arbitrary keys. That is, even though it potentially could be unambiguous (the compiler could ensure that it is indeed a range type before allowing the conversion of 0 to first), there would be confusion where [0] *didn't* mean first element.
 Advantages: unified syntax, increased flexibility with opIndexAssign and  
 opIndexOpAssign. Disadvantages: breaks all range-oriented code out there.

opIndexOpAssign is really the only improvement. I think code-wise, things would get uglier. For example, in a bidirectional range, front() and back() do not simply translate to some index that can be applied to another function. However, in random-access ranges, front() can simply be defined as opIndex. So for, random-access ranges, code gets shorter, but not necessarily simpler (slightly less boilerplate) but bidirectional ranges get much uglier (static ifs and the like). But I agree the opIndexOpAssign is a missing piece for front and back. But let's think about something else -- you want first and last, but front and back also work. What if we continued to use front and back, kept the current functions, but treated r[front] and r[back] as you say? Then, you'd have some rule for r[front] like: 1. if front() is defined, translates to r.front() 2. if opIndex is defined, translates to r.opIndex[0], although I would prefer some symbol other than 0, because I'd like to use it on a custom map type to mean "front element". And then all existing ranges still work, with the new syntax, and you can keep the clear separation of functions for when it makes sense. -Steve
Feb 14 2011
prev sibling parent retard <re tard.com.invalid> writes:
Mon, 14 Feb 2011 18:48:53 +0100, spir wrote:

 On 02/14/2011 04:11 PM, Steven Schveighoffer wrote:
 On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/11/11 8:31 AM, Bruno Medeiros wrote:
 On 04/02/2011 16:14, Eric Poggel wrote:
 On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
 At this point there is no turning back from ranges, unless we come
 about with an even better idea (I discussed one with Walter but
 we're not pursuing it yet).

Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?

That comment left me curious as well...

The discussed idea went as follows. Currently we have r.front and r.back for accessing the first and last element, and r[n] for an arbitrary element. Plus, r[n] is extremely flexible (opIndex, opIndexAssign, opIndexOpAssign... awesome level of control... just perfect). So then I thought, how about unifying everything? Imagine we gave up on r.front and r.back. Poof. They disappeared. Now we define two entities "first" and last" such that r[first] and r[last] refer the first and last elements in the range. Now we have the situ: - Input and forward ranges statically allow only r[first] - Bidirectional ranges allow r[first] and r[last] - Random-access ranges allow r[first], r[last], and r[n] for integrals n Now we have a unified way of referring to elements in ranges. Walter's excellent follow-up is that the compiler could use lowering such that you don't even need to use first and last. You'd just use r[0] and r[$ - 1] and the compiler would take care of handling these special cases.

er... I don't like this. 0 does not necessarily mean first element. A map has arbitrary keys. That is, even though it potentially could be unambiguous (the compiler could ensure that it is indeed a range type before allowing the conversion of 0 to first), there would be confusion where [0] *didn't* mean first element.
 Advantages: unified syntax, increased flexibility with opIndexAssign
 and opIndexOpAssign. Disadvantages: breaks all range-oriented code out
 there.

opIndexOpAssign is really the only improvement. I think code-wise, things would get uglier. For example, in a bidirectional range, front() and back() do not simply translate to some index that can be applied to another function. However, in random-access ranges, front() can simply be defined as opIndex. So for, random-access ranges, code gets shorter, but not necessarily simpler (slightly less boilerplate) but bidirectional ranges get much uglier (static ifs and the like). But I agree the opIndexOpAssign is a missing piece for front and back. But let's think about something else -- you want first and last, but front and back also work. What if we continued to use front and back, kept the current functions, but treated r[front] and r[back] as you say? Then, you'd have some rule for r[front] like: 1. if front() is defined, translates to r.front() 2. if opIndex is defined, translates to r.opIndex[0], although I would prefer some symbol other than 0, because I'd like to use it on a custom map type to mean "front element". And then all existing ranges still work, with the new syntax, and you can keep the clear separation of functions for when it makes sense.

I'd also like r.rest or r[rest] (meaning lisp's cdr = all but first). Rather frequent needs in functions à la reduce (take first element as seed, then iterate/recurse on rest), and recursive functional algorithms in general. What do you think? functional 'in': bool contains (E) (E[] elements, E element) { if (elements.length == 0) return false; if (elements[0] == element) return true; return contains(elements.rest(), element); } [By the way, I'm looking for a clear explanation of how tail recursion elimination is typically implemented: pointer welcome off list if you have that.]

http://en.wikipedia.org/wiki/Tail_recursion#Implementation_methods
Feb 14 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other languages'
 arrays...

What are the other ones? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 10:15 AM, Don wrote:
 Andrei Alexandrescu wrote:
 On 2/3/11 7:56 PM, BLS wrote:

 I got more and more the feeling that the D2 monster was made just for
 ranges. The smart and elegant D1 design is definitely dead an gone. I
 think I am not the only one who would prefer a D1 plus instead of D2.
 bjoern


 All in all it's fair to say that if you hate ranges you're going to dislike
 D2, and there's little that can be done about that.

Yes, but... I think we really, really, need to work on making Phobos less daunting. Right now, we have most of the functionality. But some things are unnecessarily complicated -- some are historical, some are workarounds for compiler bugs (many of which are now fixed), some are rough edges in the language definition which could probably be fixed. We don't have many examples; many discussions and explanations assume too much familiarity with terminology and concepts from functional programming languages; and probably most importantly, we don't have tutorials. All these things can and will be fixed. But right now, the learning curve is horrible, and it's a major turnoff for people.

I do agree. Would like to help on some of those points (eg tutorials, howtos, examples, and generally rewriting docs so that they do not assume familiarity fith FP /and/ with 99% of C++): but those points raised by Don, precisely, prevent me from getting a knowledge of D2 the language good enough to even dare thinking at such contributions. Nice clercle ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 10:32 AM, Andrei Alexandrescu wrote:
 relaxing the rules for eponymous templates

About that, I would love a tutorial about eponymous templates starting with their /purpose/ (why does this feature even exist? what does it /mean/? what does it compare/oppose to? why is one supposed to need/enjoy it? how is it supposed to help & make code better mirror model?) Same for alias template params. Same for a rather long list of features, probably. Moreover, said purpose should be summarized in one line introducing *every* feature in language and stdlib references. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 06:30 PM, Andrej Mitrovic wrote:
 On 2/4/11, spir<denis.spir gmail.com>  wrote:
 About that, I would love a tutorial about eponymous templates starting with
 their /purpose/ (why does this feature even exist? what does it /mean/? what
 does it compare/oppose to? why is one supposed to need/enjoy it? how is it
 supposed to help&  make code better mirror model?) Same for alias template
 params. Same for a rather long list of features, probably.

But both of these are already explained in the manual: http://www.digitalmars.com/d/2.0/template.html (search for Implicit Template Properties) http://www.digitalmars.com/d/2.0/template.html (search for Template Alias Parameters)

I've read this thrice ;-) Precisely, this doc is nice & rather good; but, for me, doesn't answer the /base/ question. You'll find there what you need if you already have an idea on what you're supposed to need it for. Reason why I chose these example, precisely... but there are tons of parts of D2 that would benefit of a good introduction, really starting from the base (and not implicitely assuming 10 years of C++ programming --esp. about vocabulary: people here don't seem to realise how much words they use everyday can be misleading coming from != background, or even not be used elsewhere in programming).
 Granted, eponymous templates aren't explained in much detail on that page.
 As for explaining how they work together, I did write that short
 template tutorial
 (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but
 you've already seen that. :)

Yop, thanks for that.
 However, I do not think we should write tutorials on single features
 alone. I've read a bunch of books that explain the language in
 feature-by-feature basis, but neglect to tie everything together. For
 example, "Learning Python" is this 1200 page book about Python 3,
 explaining the language feature by feature but never really discussing
 the language as a whole. It's only good as a reference, which
 ironically defeats the book's title. OTOH "Dive into Python 3"
 gradually introduces you to more features of the language, but always
 has code examples where you can see multiple features of the language
 being used. (IIRC there were string processing examples which used
 regex, multiple modules, and unittests all at once).

 Having a perspective on how all features tie together is crucial to
 understanding the purpose of individual features themselves. In my
 opinion!

I do agree. I also miss a great picture of D2, and even more of Phobos2 ('s future overall design). But aren't both necessary? If one doesn't get a given feature's purpose, how can it find its place meaningfully in the great picture? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 07:49 PM, so wrote:
 On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright <newshound2 digitalmars.com>
 wrote:

 spir wrote:
 On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
 Slices: just one more reason why D's arrays kick the pants of other languages'
 arrays...


Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see.

There are many features small in detail but superb in practice. But still, i keep saying D has design errors as well, to me the biggest one and maybe the main reason why D1 crowd is hostile to D2. Const system (CS): CS in theory a great thing, in practice it has many corner cases, simply it doesn't worth having. D had(still has) a chance to fix this issue in two different ways, either avoid it or don't leave holes. This hole is not that explicit in C++ because it is not transitive. Transitive const brings something with it... transitivity! Now, what i mean with this: --- struct A { B whatever; bool opEquals(A a) { return whatever == a.whatever; // just comparision, this function is const } bool anything(A a) { whatever = 2; // here i have an assignment, this function is not const return whatever; } } --- It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Its presence just makes things complicated and with actually no reason. --- struct A { B whatever; bool opEquals(A a) { return whatever == a.whatever; } } const(A) a; A b; bool e = a == b; ---- Thanks;

Runs with opEquals signature expected by the compiler: struct A { int whatever; const bool opEquals(ref const(A) a) { return whatever == a.whatever; } } unittest { const(A) a; A b; assert(a == b); } But what do you actually /mean/? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 09:52 PM, so wrote:
 What would you do in the case of pointers to functions, virtual functions,
 functions implemented with inline assembly, and functions for which the
 source is not available?

Just like we don't know if the derived class overrides a given function, we could do something similar i suppose?

The case is different --I mean the comparison does not hold IIUC. Virtual methods are /intended/ to be overriden, this is precisely part of their semantics. While the whole point of const-the-D-way is to ensure actual constness as marked in a given function's signature, whatever this function itself calls. The contract is such that the reader does not even need to watch further. Again, IIUC (please correct if I'm wrong on this). Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 10:41 PM, Andrej Mitrovic wrote:
 On 2/4/11, spir<denis.spir gmail.com>  wrote:
 but there are tons of parts of D2 that would
 benefit of a good introduction, really starting from the base (and not
 implicitely assuming 10 years of C++ programming --esp. about vocabulary:
 people here don't seem to realise how much words they use everyday can be
 misleading coming from != background, or even not be used elsewhere in
 programming).

So how would you go about doing this?

As I see it, it's mainly a question of state of mind, that helps and noticing where/how/why newcomers may block. Some people seemingly cannot do that (technical people are famously untalented at this, but imo this is a myth: others are as bad ;-), a minority do it spontaneously. Your doc about templates obviously is motivated by this attitude (or I am very wrong). In any case, just trying at best to simply answer a set of questions like the one posted in a previous message has good chances to do the job, don't you think? at least to be very helpful, I guess... Others difficulties is not to be too low-level (readers are not idiots), the trap of using a school-like tone, etc. I will try to contribute when I find a motivating topic, and have time for that. (It is very time-consuming.) Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 12 February 2011 03:08:15 bearophile wrote:
 Jonathan M Davis:
 Except that then you get the issue of eager vs lazy concatenation. chain
 is lazy whereas ~ is eager, so that wouldn't fly.

In dlibs1 I have a lazy chain(). If you perform a chain(chain(x, y), z) or chain(x, chain(y, z)) it's rewritten as chain(x,y,z). Plus there's a "chainable" mixin. If you mix it into a struct or class, the struct or class defines the ~ and ~= operators, making them mean chain(). All this requires no changed in the compiler front-end, and I think it doesn't have the problem you mention.

It's a problem of semantics. ~ is intended for eager concatenation. That's how it's designed and what it's expected to mean. More importantly, that's how it works for arrays. If you made it lower to chain, then either ~ for arrays has become lazy (along with every other user-defined type which overloads opBinary!"~" and made it eager as would be expected), or it's eager for some stuff and non-eager for others, meaning that you can't rely on whether ~ is eager or not when you use it. Either case would be bad. Yes, you _could_ make ~ lower to chain, but it changes the semantics just for some syntactic sugar. I think that that is a _bad_ idea. Regardless, as it's not going to be implemented any time soon, there's not much point in debating it right now. - Jonathan M Davis
Feb 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/14/2011 04:11 PM, Steven Schveighoffer wrote:
 On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/11/11 8:31 AM, Bruno Medeiros wrote:
 On 04/02/2011 16:14, Eric Poggel wrote:
 On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
 At this point there is no turning back from ranges, unless we come about
 with an even better idea (I discussed one with Walter but we're not
 pursuing it yet).

Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?

That comment left me curious as well...

The discussed idea went as follows. Currently we have r.front and r.back for accessing the first and last element, and r[n] for an arbitrary element. Plus, r[n] is extremely flexible (opIndex, opIndexAssign, opIndexOpAssign... awesome level of control... just perfect). So then I thought, how about unifying everything? Imagine we gave up on r.front and r.back. Poof. They disappeared. Now we define two entities "first" and last" such that r[first] and r[last] refer the first and last elements in the range. Now we have the situ: - Input and forward ranges statically allow only r[first] - Bidirectional ranges allow r[first] and r[last] - Random-access ranges allow r[first], r[last], and r[n] for integrals n Now we have a unified way of referring to elements in ranges. Walter's excellent follow-up is that the compiler could use lowering such that you don't even need to use first and last. You'd just use r[0] and r[$ - 1] and the compiler would take care of handling these special cases.

er... I don't like this. 0 does not necessarily mean first element. A map has arbitrary keys. That is, even though it potentially could be unambiguous (the compiler could ensure that it is indeed a range type before allowing the conversion of 0 to first), there would be confusion where [0] *didn't* mean first element.
 Advantages: unified syntax, increased flexibility with opIndexAssign and
 opIndexOpAssign. Disadvantages: breaks all range-oriented code out there.

opIndexOpAssign is really the only improvement. I think code-wise, things would get uglier. For example, in a bidirectional range, front() and back() do not simply translate to some index that can be applied to another function. However, in random-access ranges, front() can simply be defined as opIndex. So for, random-access ranges, code gets shorter, but not necessarily simpler (slightly less boilerplate) but bidirectional ranges get much uglier (static ifs and the like). But I agree the opIndexOpAssign is a missing piece for front and back. But let's think about something else -- you want first and last, but front and back also work. What if we continued to use front and back, kept the current functions, but treated r[front] and r[back] as you say? Then, you'd have some rule for r[front] like: 1. if front() is defined, translates to r.front() 2. if opIndex is defined, translates to r.opIndex[0], although I would prefer some symbol other than 0, because I'd like to use it on a custom map type to mean "front element". And then all existing ranges still work, with the new syntax, and you can keep the clear separation of functions for when it makes sense.

I'd also like r.rest or r[rest] (meaning lisp's cdr = all but first). Rather frequent needs in functions à la reduce (take first element as seed, then iterate/recurse on rest), and recursive functional algorithms in general. What do you think? functional 'in': bool contains (E) (E[] elements, E element) { if (elements.length == 0) return false; if (elements[0] == element) return true; return contains(elements.rest(), element); } [By the way, I'm looking for a clear explanation of how tail recursion elimination is typically implemented: pointer welcome off list if you have that.] Denis -- _________________ vita es estrany spir.wikidot.com
Feb 14 2011