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 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
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 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
parent reply 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 =




a replacement is available. =20

=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
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.


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


=20
 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
parent reply 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=


innings=20

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


hat=20

 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=


gh bar=20

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


eed -=20

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


 close.=20

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


itably=20

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


ient, it=20

 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
next sibling parent reply "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
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 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 "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
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
next sibling parent reply "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
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
next sibling parent reply "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
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 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 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=


ke)

 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 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 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=




l 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 ma=




y be ok..

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




rce 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 som=




ething

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


=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
parent reply 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.


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


=20
 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
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
parent reply "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
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
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 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
parent reply 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
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.


 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


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 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 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 

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

 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 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

 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
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
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 reply 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
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 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 parent reply 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
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 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 reply 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...


  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.


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
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 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 reply 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
parent reply 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
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?


  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.


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 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 next sibling parent reply "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
parent reply 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
next sibling parent reply 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
parent reply 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
parent reply 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
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 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 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...


 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.


 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 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 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

 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 "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

 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
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

 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 reply "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

 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
parent reply 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

 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
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 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

 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 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 reply 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
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 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 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.


=20
 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.


=20
 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 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
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=




t some point. It's plenty of work bringing up to industrial quality, so I'd=
 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 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 "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 "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 reply Gary Whatmore <no spam.sp> writes:
Steven Schveighoffer Wrote:


 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.


It's sad to read how much these Tango assholes are trying to wreck the whole
language. I doubt their implementation is any better than the high performance
C++ libraries. I've been using RapidXML before and it's damn fast. My recipe
for success would be: use the Boost license, do a clean room implementation
inspired by the best C++ code, use ranges instead of slices or iterators, use
Phobos free function and naming conventions, get Andrei's blessing. This will
teach the Tango douchebags a lesson or two.

They always complain about us doing NIH code. But they're forcing us!

 -G.W.
Feb 03 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/11 3:51 PM, Gary Whatmore wrote:

 Steven Schveighoffer Wrote:


 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.


 It's sad to read how much these Tango assholes are trying to wreck the whole
language. I doubt their implementation is any better than the high performance
C++ libraries. I've been using RapidXML before and it's damn fast. My recipe
for success would be: use the Boost license, do a clean room implementation
inspired by the best C++ code, use ranges instead of slices or iterators, use
Phobos free function and naming conventions, get Andrei's blessing. This will
teach the Tango douchebags a lesson or two.

 They always complain about us doing NIH code. But they're forcing us!


I think it's reasonable of me to ask avoiding reopening a debate that 
has little chance of being solved by emotional rhetoric.

Regarding taking inspiration from Tango code, I don't know what the 
exact licensing issues are but the lesson learned during past incidents 
is clear: Phobos contributors should conservatively avoid looking at 
Tango. This is not difficult because there are many XML libraries of 
good quality and performance. So let's.


Thanks,

Andrei
Feb 03 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 03, 2011 14:36:06 Andrei Alexandrescu wrote:

 On 2/3/11 3:51 PM, Gary Whatmore wrote:

 Steven Schveighoffer Wrote:

 On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson<metalcaedes gmail.co=






m>

=20
 wrote:

 Am 03.02.2011 22:26, schrieb Steven Schveighoffer:

 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
=20
 <metalcaedes gmail.com>  wrote:

 Am 03.02.2011 21:48, schrieb Tomek Sowi=C5=84ski:

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


=20
 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
 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.
=20
 http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
=20
 The pertinent quote from there:
=20
 "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)."


=20
 They can claim whatever they want.. if Tomek says he only looked at t=








he

 documentation (for an idea how a good interface for a XML lib may look
 like)
 they can hardly prove anything.


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


=20
 It's sad to read how much these Tango assholes are trying to wreck the
 whole language. I doubt their implementation is any better than the high
 performance C++ libraries. I've been using RapidXML before and it's damn
 fast. My recipe for success would be: use the Boost license, do a clean
 room implementation inspired by the best C++ code, use ranges instead of
 slices or iterators, use Phobos free function and naming conventions,
 get Andrei's blessing. This will teach the Tango douchebags a lesson or
 two.
=20
 They always complain about us doing NIH code. But they're forcing us!


=20
 I think it's reasonable of me to ask avoiding reopening a debate that
 has little chance of being solved by emotional rhetoric.
=20
 Regarding taking inspiration from Tango code, I don't know what the
 exact licensing issues are but the lesson learned during past incidents
 is clear: Phobos contributors should conservatively avoid looking at
 Tango. This is not difficult because there are many XML libraries of
 good quality and performance. So let's.


Agreed.

=2D Jonathan M Davis
Feb 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 03, 2011 13:51:41 Gary Whatmore wrote:

 Steven Schveighoffer Wrote:

 On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson <metalcaedes gmail.co=




m>

=20
 wrote:

 Am 03.02.2011 22:26, schrieb Steven Schveighoffer:

 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
=20
 <metalcaedes gmail.com> wrote:

 Am 03.02.2011 21:48, schrieb Tomek Sowi=C5=84ski:

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


=20
 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
 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.
=20
 http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
=20
 The pertinent quote from there:
=20
 "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)."


=20
 They can claim whatever they want.. if Tomek says he only looked at t=






he

 documentation (for an idea how a good interface for a XML lib may look
 like)
 they can hardly prove anything.


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


=20
 It's sad to read how much these Tango assholes are trying to wreck the
 whole language. I doubt their implementation is any better than the high
 performance C++ libraries. I've been using RapidXML before and it's damn
 fast. My recipe for success would be: use the Boost license, do a clean
 room implementation inspired by the best C++ code, use ranges instead of
 slices or iterators, use Phobos free function and naming conventions, get
 Andrei's blessing. This will teach the Tango douchebags a lesson or two.
=20
 They always complain about us doing NIH code. But they're forcing us!


There's no need to be rude. The Tango guys have done some great stuff. Benc=
hmarks=20
have shown that Tango creams most (if not all) other major xml libraries ou=
t=20
there. It's lightning fast, and they've done solid work.

But they're using a different license and don't necessarily like the direct=
ion=20
that D2 or Phobos has gone, since it's definitely different than what they'=
ve been=20
doing, and they don't want people copying their code and putting it under a=
 more=20
permissive license. I don't happen to agree with them, but I see no reason =
to be=20
rude to them about it.

Now, in some cases, if you can get ahold of the people who worked on a=20
particular set of code in Tango, it _is_ possible to get them to agree to l=
et=20
you port their code to Phobos and the Boost license. However, that requires=
=20
getting ahold of them and getting their consent, which isn't always easy. A=
nd=20
they have every right to refuse if that's what they want.

Regardless, being rude doesn't help. All that's likely to do is beget ruden=
ess=20
on their part. Let's try and be civil.

=2D Jonathan M Davis
Feb 03 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Gary Whatmore" <no spam.sp> wrote in message 
news:iif81d$1ch8$1 digitalmars.com...

 Steven Schveighoffer Wrote:


 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.


 It's sad to read how much these Tango assholes are trying to wreck the 
 whole language. I doubt their implementation is any better than the high 
 performance C++ libraries. I've been using RapidXML before and it's damn 
 fast. My recipe for success would be: use the Boost license, do a clean 
 room implementation inspired by the best C++ code, use ranges instead of 
 slices or iterators, use Phobos free function and naming conventions, get 
 Andrei's blessing. This will teach the Tango douchebags a lesson or two.

 They always complain about us doing NIH code. But they're forcing us!


Nothing of that sort happened. One of the Tango guys was thoughtful enough 
to inform Walter of a situation that *could* be viewed by a purely 
hypothetical super-uptight third person as being potentially infringing. 
Walter is (perhaps understandably) paranoid about potential accusations so 
disallowed the code in question. This NG then exploded in speculation, and 
the Tango guys fueled that fire by being extremely reluctant to say anything 
at all about the matter. The problem was miscommunication and legal 
bullshit, *not* a "good guys vs bad guys" situation (if there was *any* "bad 
guys" side it's the court/legal system).
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.



BCS's units ?

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.



What does that mean? Top down OOP?



 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.



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.



 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.



 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 reply "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
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
next sibling 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 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 reply 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
next sibling parent reply 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
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 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 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
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 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 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 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 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 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
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
parent reply 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
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 reply 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
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 reply 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.


=20
 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),


=20
 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.


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


=20
 Hol=C3=A0 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?


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
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 reply "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
parent reply 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
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 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


Will send you an email containing a skiplist based rudimentary 
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


 Will send you an email containing a skiplist based rudimentary
 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 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 parent Kagamin <spam here.lot> 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.
Feb 04 2011