Piotrek <starpit tlen.pl> writes:

Hello!

It's just an idea. After reading about issues on disallowing DWT to stay 
in standardization area (Anomaly on Wiki4D GuiLibraries page) some 
question appeared in my mind. For propaganda sake isn't it better to not 
make such a big division between phobos and tango in the module naming? 
Logically:

phobos -> std
tango  -> stdex (not tango -> tango)


Module naming example:
import std.stdio;
import std.string;

import stdex.io.Stdout;
import stdex.text.Util;

Doesn't it look fine? (Also note that alphabetical order is preserved).

After all tango is a standard library. Currently from incomer/observer 
point of view tango could be seen as an rebel initiative. But thanks to 
druntime phobos and tango can live in harmony and take advantage of each 
other.
Another good thing is that one could write in his project documentation:
Extended Standard Library (Tango) needed
instead of
Tango library needed.

In addition some information could be added on the digitalmars.com website.

Cheers

"Denis Koroskin" <2korden gmail.com> writes:

On Sat, 17 Jan 2009 15:48:14 +0300, Piotrek <starpit tlen.pl> wrote:

 Hello!

 It's just an idea. After reading about issues on disallowing DWT to stay  
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some  
 question appeared in my mind. For propaganda sake isn't it better to not  
 make such a big division between phobos and tango in the module naming?  
 Logically:

 phobos -> std
 tango  -> stdex (not tango -> tango)


 Module naming example:
 import std.stdio;
 import std.string;

 import stdex.io.Stdout;
 import stdex.text.Util;

 Doesn't it look fine? (Also note that alphabetical order is preserved).

 After all tango is a standard library. Currently from incomer/observer  
 point of view tango could be seen as an rebel initiative. But thanks to  
 druntime phobos and tango can live in harmony and take advantage of each  
 other.
 Another good thing is that one could write in his project documentation:
 Extended Standard Library (Tango) needed
 instead of
 Tango library needed.

 In addition some information could be added on the digitalmars.com  
 website.

 Cheers

I like the idea.

Other thing I constantly think about is that once Tango is ported to D2, it
should start being distributed alongside the Phobos (just the way it comes with
LDC). I believe there are a lot of advantages for Tango library developers, its
users and D in general.

Lars Ivar Igesund <larsivar igesund.net> writes:

Piotrek wrote:

 Hello!
 
 It's just an idea. After reading about issues on disallowing DWT to stay
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some
 question appeared in my mind. For propaganda sake isn't it better to not
 make such a big division between phobos and tango in the module naming?
 Logically:
 
 phobos -> std
 tango  -> stdex (not tango -> tango)

Tango will stay Tango (and tango.*). The above naming assumes that Tango will
depend on Phobos, and it will not.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

IUnknown <a b.com> writes:

To D gods,

Having to learn and choose between two libraries is a big -ve point in adopting
D. Many people would also like to use D on ARM if possible in the future so
dividing the library into two parts would help as then only the core lib can be
linked in. 

Really, D's community needs to grow up and create ONE standard library for D2.
D2 would be a nice time to break backwards compatibility in the libraries. 

 A language needs large scale adoption to be successful and its implementations
must be delivered in a ready to use manner. Many people find D interesting but
not sufficiently interesting to switch away from the pain of C++. 
If D also has other pain points, how do you think it will get adopted? 
dmd seems lacking on floating point optimization. Not many platforms are
supported. While platform support is an understandable problem and is something
that happens over time. Having two competing libraries is simply either
egoistic or retarded from an outsider's perspective. 

Programmers simply don't seem to want to do the necessary work to make the
software appealing to use. Many people want to use a powerful editor like vim,
but then find that all the standard features they find in other editors are
extensions in vim and the simple act of finding the right scripts even from
vim's homepage is a deterrent. 

Please, the worst thing you can do in deterring a person from trying out
something new is in giving him options with no clear way to choose. Can't you
learn this from python? Of often having one way to accomplish something? Merge
the libs, pretty pretty please.

Lars Ivar Igesund Wrote:

 Piotrek wrote:
 
 Hello!
 
 It's just an idea. After reading about issues on disallowing DWT to stay
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some
 question appeared in my mind. For propaganda sake isn't it better to not
 make such a big division between phobos and tango in the module naming?
 Logically:
 
 phobos -> std
 tango  -> stdex (not tango -> tango)

 
 Tango will stay Tango (and tango.*). The above naming assumes that Tango will
depend on Phobos, and it will not.
 
 -- 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango

John Reimer <terminal.node gmail.com> writes:

Hello IUnknown,

 To D gods,
 
 Having to learn and choose between two libraries is a big -ve point in
 adopting D. Many people would also like to use D on ARM if possible in
 the future so dividing the library into two parts would help as then
 only the core lib can be linked in.
 


Yes, this is true.



 Really, D's community needs to grow up and create ONE standard library
 for D2. D2 would be a nice time to break backwards compatibility in
 the libraries.
 



He he... well, you have to understand the dynamics of this D community to 
understand why the problem exists.  The D community /has/ created such a 
library: it's called Tango for D1.  I doubt the community will implement 
one for D2 until it is stable because the time and effort of chasing
experimental 
language design is far too great: that area is completely reserved for the 
D core team and its Phobos.  Even if Tango were complete for D 2.0, the
community 
has absolutely no say on whether it becomes the ONE standard library or not. 
 Historically, Tango was a somewhat reactive process resulting from the
community 
feeling unable to influence the growth of the standard library and D 1.0.  


This is the point:  it has nothing to do with the D community as far as I 
understand it.  You'll have to talk to the D core team about this one.  They 
control what is and what is not the standard library.   They do tend to accept 
portions from the community, but not to the extent that you are going to 
see a community managed standard library.  The problem tends to be that the 
core team has one set of ideas about D's future while the community
(specifically 
Tango for D 1.0) has a different set of ideas.  Sometimes the sets intersect, 
often not...  Sometimes the community has some influence on ideas, sometimes 
not.


The process of communication of this core team with the community is what 
allows the D language design to grow.  But I think it's important to erase 
the notion that the community has to get its act together.   Perhaps both 
the core team and the community should get it's act together, but then who 
speaks for the community (not everyone is involved in the Tango aspect of 
it)?  What's hugely missing is face to face communication between the two 
with the determined purpose of resolving the problem.  I've seen no evidence 
that this will happen beyond the initiation of druntime for d2.0 (a good 
start... but where does it go from there?); but I think the core team, who 
has a vested interest in D, should initiate such a venture soon if they want 
to see D succeed in the long term.


The other thing to remember is that since there is no Tango for D 2.0... 
there is no competing libraries for D 2.0 yet.  So there isn't really an 
issue there, just an odd realization that D 2.0 is a different language then 
D 1.0 where Tango is by far the most popular library.... yep it's complicated.


 A language needs large scale adoption to be successful and its
 implementations must be delivered in a ready to use manner. Many
 people find D interesting but not sufficiently interesting to switch
 away from the pain of C++. If D also has other pain points, how do you
 think it will get adopted? dmd seems lacking on floating point
 optimization. Not many platforms are supported. While platform support
 is an understandable problem and is something that happens over time.
 Having two competing libraries is simply either egoistic or retarded
 from an outsider's perspective.
 
 Programmers simply don't seem to want to do the necessary work to make
 the software appealing to use. Many people want to use a powerful
 editor like vim, but then find that all the standard features they
 find in other editors are extensions in vim and the simple act of
 finding the right scripts even from vim's homepage is a deterrent.
 
 Please, the worst thing you can do in deterring a person from trying
 out something new is in giving him options with no clear way to
 choose. Can't you learn this from python? Of often having one way to
 accomplish something? Merge the libs, pretty pretty please.
 



This is a specific problem with the D langauge design process, and it is 
very hard to know what the solution to it is.  At the very least, maybe it 
would be nice to have the structure of the D design progress layed out on 
a wiki, so newcomers can better understand how D progresses.  This is D's 
handicap.  And I think most people here realize this now.


-JJR

Bill Baxter <wbaxter gmail.com> writes:

On Sun, Jan 18, 2009 at 4:35 AM, IUnknown <a b.com> wrote:
 To D gods,

 Having to learn and choose between two libraries is a big -ve point in ad=

opting D. Many people would also like to use D on ARM if possible in the fu=
ture so dividing the library into two parts would help as then only the cor=
e lib can be linked in.
 Really, D's community needs to grow up and create ONE standard library fo=

r D2. D2 would be a nice time to break backwards compatibility in the libra=
ries.
  A language needs large scale adoption to be successful and its implement=

ations must be delivered in a ready to use manner. Many people find D inter=
esting but not sufficiently interesting to switch away from the pain of C++=
.
 If D also has other pain points, how do you think it will get adopted?
 dmd seems lacking on floating point optimization. Not many platforms are =

supported. While platform support is an understandable problem and is somet=
hing that happens over time. Having two competing libraries is simply eithe=
r egoistic or retarded from an outsider's perspective.
 Programmers simply don't seem to want to do the necessary work to make th=

e software appealing to use. Many people want to use a powerful editor like=
 vim, but then find that all the standard features they find in other edito=
rs are extensions in vim and the simple act of finding the right scripts ev=
en from vim's homepage is a deterrent.
 Please, the worst thing you can do in deterring a person from trying out =

something new is in giving him options with no clear way to choose. Can't y=
ou learn this from python? Of often having one way to accomplish something?=
 Merge the libs, pretty pretty please.

Preach it brutha'.

It is ridiculous for a niche language to allow a split like this to
happen.  Fortunately, things are moving to repair the schism at last
in D2.

And finally if you don't like to choose, then there is Tangobos, which
lets you use either Tango or Phobos as you please.  It's my preferred
platform because generally I like Phobo's minimal style, but Tango
just has a lot more stuff in it for those odd occasions when I do need
something beyond what Phobos has.

--bb

Stewart Gordon <smjg_1998 yahoo.com> writes:

IUnknown wrote:
<snip>
 Really, D's community needs to grow up and create ONE standard 
 library for D2. D2 would be a nice time to break backwards 
 compatibility in the libraries.

<snip>

D already has ONE standard library.  It's called Phobos.

http://www.digitalmars.com/d/archives/digitalmars/D/Two_standard_libraries_58530.html

Stewart.

"Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:

On Sun, Jan 18, 2009 at 12:17 PM, Stewart Gordon <smjg_1998 yahoo.com> wrote:
 IUnknown wrote:
 <snip>
 Really, D's community needs to grow up and create ONE standard library for
 D2. D2 would be a nice time to break backwards compatibility in the
 libraries.

 <snip>

 D already has ONE standard library.  It's called Phobos.

 http://www.digitalmars.com/d/archives/digitalmars/D/Two_standard_libraries_58530.html

Yes Stewart, we know you love semantics.  You know what is being discussed here.

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

Stewart Gordon wrote:
 IUnknown wrote:
 <snip>
 Really, D's community needs to grow up and create ONE standard library 
 for D2. D2 would be a nice time to break backwards compatibility in 
 the libraries.

 <snip>
 
 D already has ONE standard library.  It's called Phobos.

*yawn*

Don’t you get tired of this?

Stewart Gordon <smjg_1998 yahoo.com> writes:

Alexander Pánek wrote:
 Stewart Gordon wrote:

<snip>
 D already has ONE standard library.  It's called Phobos.

 
 *yawn*
 
 Don’t you get tired of this?

I do get tired of the misunderstanding of what Tango is that seems to 
have arisen from the misterminology.

Stewart.

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

Stewart Gordon wrote:
 Alexander Pánek wrote:
 Stewart Gordon wrote:

 <snip>
 D already has ONE standard library.  It's called Phobos.

 *yawn*

 Don’t you get tired of this?

 
 I do get tired of the misunderstanding of what Tango is that seems to 
 have arisen from the misterminology.

It didn’t arise from misterminology, but people who do call it their 
(de-facto, but nonetheless) standard D library. You might not accept, 
respect or acknowledge this in any way, but then again you seem to be 
all into semantics.

“A standard library for a programming language is the library that is 
conventionally made available in every implementation of that language. 
In some cases, the library is described directly in the programming 
language specification; in other cases, the contents of the standard 
library are determined by more informal social practices in the 
programming community.”

I think Tango meets every but the first (conventional) “rule”. So there 
might have been a misunderstanding I do get tired of on your side.

Kind regards,
Alex

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

Alexander Pánek wrote:
 Stewart Gordon wrote:
 Alexander Pánek wrote:
 Stewart Gordon wrote:

 <snip>
 D already has ONE standard library.  It's called Phobos.

 *yawn*

 Don’t you get tired of this?

 I do get tired of the misunderstanding of what Tango is that seems to 
 have arisen from the misterminology.

 
 It didn’t arise from misterminology, but people who do call it their 
 (de-facto, but nonetheless) standard D library. You might not accept, 
 respect or acknowledge this in any way, but then again you seem to be 
 all into semantics.
 
 “A standard library for a programming language is the library that is 
 conventionally made available in every implementation of that language. 
 In some cases, the library is described directly in the programming 
 language specification; in other cases, the contents of the standard 
 library are determined by more informal social practices in the 
 programming community.”

Source: http://en.wikipedia.org/wiki/Standard_library

 I think Tango meets every but the first (conventional) “rule”. So there 
 might have been a misunderstanding I do get tired of on your side.

Piotrek <starpit tlen.pl> writes:

Lars Ivar Igesund wrote:
 Tango will stay Tango (and tango.*). The above naming assumes that Tango will
depend on Phobos, and it will not.
 

I see.

Cheers

Daniel Keep <daniel.keep.lists gmail.com> writes:

Piotrek wrote:
 Lars Ivar Igesund wrote:
 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.

 
 I see.
 
 Cheers

(Note: speaking as merely an infrequent contributor to Tango; my opinion
is my own and does not reflect on those of the Master Dancers, or the
ruling council of glittery-shoed programmers.)

(Warning: semi-rant ahead.)

The problem is that Phobos and Tango are diametrically opposed in almost
every conceivable way.  Bringing them together would be like trying to
bring matter and anti-matter together; you're just going to blow
yourself up.

It's best if you think of Phobos as being Python and Tango as being
Java.  Phobos implements a relatively flat (if messy) hierarchy of
simple, fat classes.  For example, IO is done using the Stream
interfaces, each one implements all the methods you'd probably need to
work with streams.

Tango, on the other hand, implements a very deep (if confusing)
hierarchy of simple, component interfaces that get plugged together.
Unlike Phobos, IO in Tango has many layers and components, each of which
is very narrowly defined, allowing you to plug them together however you
like.

The problem is that neither of these approaches is WRONG.  They're both
valid and arguably better in certain circumstances.  What's more, the
continued existence of both shows that there are people who believe in
each of them (not necessarily at the same time, but there you go.)

So let's say we combined them into std.* and stdex.*.  Why is Tango
stdex?  Why isn't Tango std.* and Phobos stdsimple?

Ok, ignoring egos, the problem is that they wouldn't work together
anyway.  An old favourite of mine is (again, sorry about this) IO.

Phobos strives to be compatible with the C IO library; so you can
interleave Phobos and C IO calls and it's all gravy.

Tango takes C out the back and shoots it before burying it upside-down
at a crossroads with a steak through the heart and salting the earth.
You CAN mix Tango and C IO calls, but you really have no idea what order
the output's going to arrive in.

I remember Andrei getting antsy about this a while back; why break
compatibility?!  Because Tango's IO was faster this way.  Neither one of
them was 'right' because they both had legitimate points of view.

Really, it all boils down to this: there *is no* one right way.  Yes,
it's more confusing.  But it's a problem with programming in general;
programming is all about looking at your options and making a decision
on the matter.

  -- Daniel

John Reimer <terminal.node gmail.com> writes:

Hello Daniel,

 Piotrek wrote:
 
 Lars Ivar Igesund wrote:
 
 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.
 

 I see.
 
 Cheers
 

 (Note: speaking as merely an infrequent contributor to Tango; my
 opinion is my own and does not reflect on those of the Master Dancers,
 or the ruling council of glittery-shoed programmers.)
 
 (Warning: semi-rant ahead.)
 
 The problem is that Phobos and Tango are diametrically opposed in
 almost every conceivable way.  Bringing them together would be like
 trying to bring matter and anti-matter together; you're just going to
 blow yourself up.
 
 It's best if you think of Phobos as being Python and Tango as being
 Java.  Phobos implements a relatively flat (if messy) hierarchy of
 simple, fat classes.  For example, IO is done using the Stream
 interfaces, each one implements all the methods you'd probably need to
 work with streams.
 
 Tango, on the other hand, implements a very deep (if confusing)
 hierarchy of simple, component interfaces that get plugged together.
 Unlike Phobos, IO in Tango has many layers and components, each of
 which is very narrowly defined, allowing you to plug them together
 however you like.
 
 The problem is that neither of these approaches is WRONG.  They're
 both valid and arguably better in certain circumstances.  What's more,
 the continued existence of both shows that there are people who
 believe in each of them (not necessarily at the same time, but there
 you go.)
 
 So let's say we combined them into std.* and stdex.*.  Why is Tango
 stdex?  Why isn't Tango std.* and Phobos stdsimple?
 
 Ok, ignoring egos, the problem is that they wouldn't work together
 anyway.  An old favourite of mine is (again, sorry about this) IO.
 
 Phobos strives to be compatible with the C IO library; so you can
 interleave Phobos and C IO calls and it's all gravy.
 
 Tango takes C out the back and shoots it before burying it upside-down
 at a crossroads with a steak through the heart and salting the earth.
 You CAN mix Tango and C IO calls, but you really have no idea what
 order the output's going to arrive in.
 
 I remember Andrei getting antsy about this a while back; why break
 compatibility?!  Because Tango's IO was faster this way.  Neither one
 of them was 'right' because they both had legitimate points of view.
 
 Really, it all boils down to this: there *is no* one right way.  Yes,
 it's more confusing.  But it's a problem with programming in general;
 programming is all about looking at your options and making a decision
 on the matter.
 
 -- Daniel
 


That's a very good description of the situation, I think.  Thanks.


-JJR

dsimcha <dsimcha yahoo.com> writes:

== Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 Piotrek wrote:
 Lars Ivar Igesund wrote:
 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.

 I see.

 Cheers

 (Note: speaking as merely an infrequent contributor to Tango; my opinion
 is my own and does not reflect on those of the Master Dancers, or the
 ruling council of glittery-shoed programmers.)
 (Warning: semi-rant ahead.)
 The problem is that Phobos and Tango are diametrically opposed in almost
 every conceivable way.  Bringing them together would be like trying to
 bring matter and anti-matter together; you're just going to blow
 yourself up.
 It's best if you think of Phobos as being Python and Tango as being
 Java.  Phobos implements a relatively flat (if messy) hierarchy of
 simple, fat classes.  For example, IO is done using the Stream
 interfaces, each one implements all the methods you'd probably need to
 work with streams.
 Tango, on the other hand, implements a very deep (if confusing)
 hierarchy of simple, component interfaces that get plugged together.
 Unlike Phobos, IO in Tango has many layers and components, each of which
 is very narrowly defined, allowing you to plug them together however you
 like.
 The problem is that neither of these approaches is WRONG.  They're both
 valid and arguably better in certain circumstances.  What's more, the
 continued existence of both shows that there are people who believe in
 each of them (not necessarily at the same time, but there you go.)
 So let's say we combined them into std.* and stdex.*.  Why is Tango
 stdex?  Why isn't Tango std.* and Phobos stdsimple?
 Ok, ignoring egos, the problem is that they wouldn't work together
 anyway.  An old favourite of mine is (again, sorry about this) IO.
 Phobos strives to be compatible with the C IO library; so you can
 interleave Phobos and C IO calls and it's all gravy.
 Tango takes C out the back and shoots it before burying it upside-down
 at a crossroads with a steak through the heart and salting the earth.
 You CAN mix Tango and C IO calls, but you really have no idea what order
 the output's going to arrive in.
 I remember Andrei getting antsy about this a while back; why break
 compatibility?!  Because Tango's IO was faster this way.  Neither one of
 them was 'right' because they both had legitimate points of view.
 Really, it all boils down to this: there *is no* one right way.  Yes,
 it's more confusing.  But it's a problem with programming in general;
 programming is all about looking at your options and making a decision
 on the matter.
   -- Daniel

Wow.  Excellent analysis.  One thing I'd like to add is that Phobos tends to be
much more focused on the bleeding edge, with pretty much all development
happening
on the D2 branch, while Tango is more focused on targeting stable compilers.
Also, another way I would summarize the situation is that Phobos focuses on
first
making simple operations simple first and foremost, and then worries about
making
complicated operations possible, while Tango does just the opposite.

I've said this before, but I think it's not so bad for D to have two standard
libraries with different design philosophies, at least in principle, though the
inability to use both side by side on D1 is obviously a bad thing.  There are
times when I like the Phobos "keep it simple, stupid" approach and times when I
want Tango's "everything but the kitchen sink" approach.  There are a few things
that I think would help a lot here:

1.  Both Phobos and Tango should adopt these opposite design philosophies, which
are true de facto anyhow, officially.  This will prevent excessive feature envy
and duplication of effort and allow newcomers to determine which is best for
their
everyday use.

2.  The creation of druntime so that Phobos and Tango can be used side by side
is
a huge step forward.  Once D2 is out of alpha and Tango is ported to D2, people
will be able to use their preferred lib most of the time and the other when
their
preferred lib has some missing functionality.  This will also greatly simplify
3rd
party libs.

John Reimer <terminal.node gmail.com> writes:

Hello dsimcha,

 == Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 
 Piotrek wrote:
 
 Lars Ivar Igesund wrote:
 
 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.
 

 I see.
 
 Cheers
 

 (Note: speaking as merely an infrequent contributor to Tango; my
 opinion
 is my own and does not reflect on those of the Master Dancers, or the
 ruling council of glittery-shoed programmers.)
 (Warning: semi-rant ahead.)
 The problem is that Phobos and Tango are diametrically opposed in
 almost
 every conceivable way.  Bringing them together would be like trying
 to
 bring matter and anti-matter together; you're just going to blow
 yourself up.
 It's best if you think of Phobos as being Python and Tango as being
 Java.  Phobos implements a relatively flat (if messy) hierarchy of
 simple, fat classes.  For example, IO is done using the Stream
 interfaces, each one implements all the methods you'd probably need
 to
 work with streams.
 Tango, on the other hand, implements a very deep (if confusing)
 hierarchy of simple, component interfaces that get plugged together.
 Unlike Phobos, IO in Tango has many layers and components, each of
 which
 is very narrowly defined, allowing you to plug them together however
 you
 like.
 The problem is that neither of these approaches is WRONG.  They're
 both
 valid and arguably better in certain circumstances.  What's more, the
 continued existence of both shows that there are people who believe
 in
 each of them (not necessarily at the same time, but there you go.)
 So let's say we combined them into std.* and stdex.*.  Why is Tango
 stdex?  Why isn't Tango std.* and Phobos stdsimple?
 Ok, ignoring egos, the problem is that they wouldn't work together
 anyway.  An old favourite of mine is (again, sorry about this) IO.
 Phobos strives to be compatible with the C IO library; so you can
 interleave Phobos and C IO calls and it's all gravy.
 Tango takes C out the back and shoots it before burying it
 upside-down
 at a crossroads with a steak through the heart and salting the earth.
 You CAN mix Tango and C IO calls, but you really have no idea what
 order
 the output's going to arrive in.
 I remember Andrei getting antsy about this a while back; why break
 compatibility?!  Because Tango's IO was faster this way.  Neither one
 of
 them was 'right' because they both had legitimate points of view.
 Really, it all boils down to this: there *is no* one right way.  Yes,
 it's more confusing.  But it's a problem with programming in general;
 programming is all about looking at your options and making a
 decision
 on the matter.
 -- Daniel

 Wow.  Excellent analysis.  One thing I'd like to add is that Phobos
 tends to be
 much more focused on the bleeding edge, with pretty much all
 development happening
 on the D2 branch, while Tango is more focused on targeting stable
 compilers.
 Also, another way I would summarize the situation is that Phobos
 focuses on first
 making simple operations simple first and foremost, and then worries
 about making
 complicated operations possible, while Tango does just the opposite.



I don't know if that is strictly true.  In Tango's defense, I believe it 
has tried quite hard to move in the direction of making simple things simple 
even under the restrictions of its own philosophy :).  If you examine the 
progression of Tango revisions, there has been a significant "cleanup" in 
progress that appears to be simplifying what was originally verbose.



 I've said this before, but I think it's not so bad for D to have two
 standard libraries with different design philosophies, at least in
 principle, though the inability to use both side by side on D1 is
 obviously a bad thing.  There are times when I like the Phobos "keep
 it simple, stupid" approach and times when I want Tango's "everything
 but the kitchen sink" approach.  There are a few things that I think
 would help a lot here:
 

 1.  Both Phobos and Tango should adopt these opposite design
 philosophies, which are true de facto anyhow, officially.  This will
 prevent excessive feature envy and duplication of effort and allow
 newcomers to determine which is best for their everyday use.
 


Like I said, I believe Tango has worked harder at doing this than you might 
think.  I don't think Phobos cares to look at the opposite philosophy because 
it really doesn't merge well with it's intended goals.  Tango can afford 
some brevity because it started at the verbose end.


 2.  The creation of druntime so that Phobos and Tango can be used side
 by side is a huge step forward.  Once D2 is out of alpha and Tango is
 ported to D2, people will be able to use their preferred lib most of
 the time and the other when their preferred lib has some missing
 functionality.  This will also greatly simplify 3rd party libs.
 


This somehow parallels my original thinking too which I've mentioned before. 
 I am all for the druntime, and it certainly will be a net gain if both Tango 
V2 (if it ever surfaces complete) and Phobos can share it once D2 is stable. 
  But I'm afraid, it is still a grave difficulty for new users to face two 
different libraries.  Now that I've waited and think about it longer, I'm 
not sure what to make of it.  How does one promote this twin package deal 
for D.  I predict that the first person that finds a clever way to promote 
D 2.0 and it's shiny new twin-library / pick-your-style feature will be a 
D hero forever. ;-)   


No, it's not bad.  It's just rather... new... and it will take some very 
fancy promotion to get people to digest it.  I'm not sure if I'm up to the 
challenge.   That said, I guess I'm kind of jumping to conclusions if I even 
attempt to figure out what the D team is going to do about this.  Maybe they 
have no plans to ship two libraries together.  They may just continue to 
ship d2.0 with Phobos only... in which case Tango will indeed become a third 
party library.  Perhaps for the best?  I really don't know.


-JJR

Don <nospam nospam.com> writes:

John Reimer wrote:
 Hello dsimcha,
 
 == Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article

 Piotrek wrote:

 Lars Ivar Igesund wrote:

 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.

 I see.

 Cheers

 (Note: speaking as merely an infrequent contributor to Tango; my
 opinion
 is my own and does not reflect on those of the Master Dancers, or the
 ruling council of glittery-shoed programmers.)
 (Warning: semi-rant ahead.)
 The problem is that Phobos and Tango are diametrically opposed in
 almost
 every conceivable way.  Bringing them together would be like trying
 to
 bring matter and anti-matter together; you're just going to blow
 yourself up.
 It's best if you think of Phobos as being Python and Tango as being
 Java.  Phobos implements a relatively flat (if messy) hierarchy of
 simple, fat classes.  For example, IO is done using the Stream
 interfaces, each one implements all the methods you'd probably need
 to
 work with streams.
 Tango, on the other hand, implements a very deep (if confusing)
 hierarchy of simple, component interfaces that get plugged together.
 Unlike Phobos, IO in Tango has many layers and components, each of
 which
 is very narrowly defined, allowing you to plug them together however
 you
 like.
 The problem is that neither of these approaches is WRONG.  They're
 both
 valid and arguably better in certain circumstances.  What's more, the
 continued existence of both shows that there are people who believe
 in
 each of them (not necessarily at the same time, but there you go.)
 So let's say we combined them into std.* and stdex.*.  Why is Tango
 stdex?  Why isn't Tango std.* and Phobos stdsimple?
 Ok, ignoring egos, the problem is that they wouldn't work together
 anyway.  An old favourite of mine is (again, sorry about this) IO.
 Phobos strives to be compatible with the C IO library; so you can
 interleave Phobos and C IO calls and it's all gravy.
 Tango takes C out the back and shoots it before burying it
 upside-down
 at a crossroads with a steak through the heart and salting the earth.
 You CAN mix Tango and C IO calls, but you really have no idea what
 order
 the output's going to arrive in.
 I remember Andrei getting antsy about this a while back; why break
 compatibility?!  Because Tango's IO was faster this way.  Neither one
 of
 them was 'right' because they both had legitimate points of view.
 Really, it all boils down to this: there *is no* one right way.  Yes,
 it's more confusing.  But it's a problem with programming in general;
 programming is all about looking at your options and making a
 decision
 on the matter.
 -- Daniel

 Wow.  Excellent analysis.  One thing I'd like to add is that Phobos
 tends to be
 much more focused on the bleeding edge, with pretty much all
 development happening
 on the D2 branch, while Tango is more focused on targeting stable
 compilers.


 Also, another way I would summarize the situation is that Phobos
 focuses on first
 making simple operations simple first and foremost, and then worries
 about making
 complicated operations possible, while Tango does just the opposite.

 
 I don't know if that is strictly true.  In Tango's defense, I believe it 
 has tried quite hard to move in the direction of making simple things 
 simple even under the restrictions of its own philosophy :).  If you 
 examine the progression of Tango revisions, there has been a significant 
 "cleanup" in progress that appears to be simplifying what was originally 
 verbose.
 
 I've said this before, but I think it's not so bad for D to have two
 standard libraries with different design philosophies, at least in
 principle, though the inability to use both side by side on D1 is
 obviously a bad thing.  There are times when I like the Phobos "keep
 it simple, stupid" approach and times when I want Tango's "everything
 but the kitchen sink" approach.  There are a few things that I think
 would help a lot here:

 
 1.  Both Phobos and Tango should adopt these opposite design
 philosophies, which are true de facto anyhow, officially.  This will
 prevent excessive feature envy and duplication of effort and allow
 newcomers to determine which is best for their everyday use.

 Like I said, I believe Tango has worked harder at doing this than you 
 might think.  I don't think Phobos cares to look at the opposite 
 philosophy because it really doesn't merge well with it's intended 
 goals.  Tango can afford some brevity because it started at the verbose 
 end.
 
 
 2.  The creation of druntime so that Phobos and Tango can be used side
 by side is a huge step forward.  Once D2 is out of alpha and Tango is
 ported to D2, people will be able to use their preferred lib most of
 the time and the other when their preferred lib has some missing
 functionality.  This will also greatly simplify 3rd party libs.

 
 
 This somehow parallels my original thinking too which I've mentioned 
 before. I am all for the druntime, and it certainly will be a net gain 
 if both Tango V2 (if it ever surfaces complete) and Phobos can share it 
 once D2 is stable.  But I'm afraid, it is still a grave difficulty for 
 new users to face two different libraries.  Now that I've waited and 
 think about it longer, I'm not sure what to make of it.  How does one 
 promote this twin package deal for D.  I predict that the first person 
 that finds a clever way to promote D 2.0 and it's shiny new twin-library 
 / pick-your-style feature will be a D hero forever. ;-)  
 
 No, it's not bad.

<small rant>
I completely disagree. I think the two libraries is a disaster. I can 
see that so many people have been exposed to a lifetime of propaganda 
that "competition is a good thing", but it's just propaganda. 
Competition inevitably means wasted effort, and it's obvious in D.
</small rant>

Note, however that the gulf between Phobos and Tango mostly exists in 
I/O; and C++ also has two I/O packages (the one inherited from C, and 
the awful iostreams). So I don't think this is a big a problem as 
stated. If we work at it, we could move the difference to be entirely a 
I/O difference. But that would require willingless to do it, and I'm not 
sure that it's really there.

<big rant>
In my attempt to bring both libraries together I have experienced 
reactions from both sides which appeared hostile (or at least reluctant) 
to a merger. Apart from Sean and myself, I don't see much evidence that 
people actually want them to merge. They just want the other one to 
disappear.
</big rant>

John Reimer <terminal.node gmail.com> writes:

Hello Don,

 This somehow parallels my original thinking too which I've mentioned
 before. I am all for the druntime, and it certainly will be a net
 gain if both Tango V2 (if it ever surfaces complete) and Phobos can
 share it once D2 is stable.  But I'm afraid, it is still a grave
 difficulty for new users to face two different libraries.  Now that
 I've waited and think about it longer, I'm not sure what to make of
 it.  How does one promote this twin package deal for D.  I predict
 that the first person that finds a clever way to promote D 2.0 and
 it's shiny new twin-library / pick-your-style feature will be a D
 hero forever. ;-)
 
 No, it's not bad.
 

 <small rant>
 I completely disagree. I think the two libraries is a disaster. I can
 see that so many people have been exposed to a lifetime of propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>


No, Don, some of it may be propoganda when that is the only reason put forward 
(ie. that competition is always a good thing).  Others may merely be trying 
to be hopeful.  In my case, you may call my hopefulness a delusion, but I 
think you will see by the context of my post that I'm rather clueless to 
know how it will work.  I'm completely baffled to know how it can go forward, 
but I don't want to be the Spreader of Doom and Gloom if I don't know all 
the details that are going on behind the scenes.  That's where I think more 
communication is absolutely critical for D to get along well.


More honest perhaps would have been for me just to remove "it's not bad".
 

 Note, however that the gulf between Phobos and Tango mostly exists in
 I/O; and C++ also has two I/O packages (the one inherited from C, and
 the awful iostreams). So I don't think this is a big a problem as
 stated. If we work at it, we could move the difference to be entirely
 a I/O difference. But that would require willingless to do it, and I'm
 not sure that it's really there.
 
 <big rant>
 In my attempt to bring both libraries together I have experienced
 reactions from both sides which appeared hostile (or at least
 reluctant)
 to a merger. Apart from Sean and myself, I don't see much evidence
 that
 people actually want them to merge. They just want the other one to
 disappear.
 </big rant>


At this point, I think people (those not involved in Phobos or Tango
development) 
would take it anyway it could be made to work.  The reluctance appears mostly 
from those involved in both libraries.   If there is a creative way to merge 
two very different styles, then I think it would be amazing.  But, from what 
I see, there would have to be more interaction and dicussion among both project 
developers because the core team is the one carrying the D design banner. 
  My personal opinion is that I don't know how a merger would work anymore. 
 If you or anybody has got some detailed ideas, it would be fun to see them. 
:-P


/How-to-do-an-about-face-on-"No, it's not bad"/


The danger, of course, is that Tango will not be taken seriously again for 
D 2.0.  If Tango manages to garner the lion-share of popularity as they did 
with D 1.0 (LDC compiler suite is one example of the significant sway Tango 
has had on D 1.0 ), then I think I'm going to just throw up my hands.  Yes, 
I think something has to be done: ignoring Tango is not going to be a healthy 
option for D.  Either that or Phobos2 will have to be so good that people 
will drop Tango faster than they would a red-hot frying pan.  Frankly, it 
will have to be absolutely extraordinary to manage that.  Or maybe Tango 
v2 just won't appear because it lacks the d-insider connection.  How's that 
for Doom and Gloom? :-(


-JJR

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

John Reimer wrote:
 The danger, of course, is that Tango will not be taken seriously again 
 for D 2.0.  If Tango manages to garner the lion-share of popularity as 
 they did with D 1.0 (LDC compiler suite is one example of the 
 significant sway Tango has had on D 1.0 ), then I think I'm going to 
 just throw up my hands.  Yes, I think something has to be done: ignoring 
 Tango is not going to be a healthy option for D.  Either that or Phobos2 
 will have to be so good that people will drop Tango faster than they 
 would a red-hot frying pan.

Beware of the false choice. Ideally, Phobos2 will be so good, and Tango2 
will be so good, that people will enjoy using either or both together.

Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 John Reimer wrote:
 
 The danger, of course, is that Tango will not be taken seriously
 again for D 2.0.  If Tango manages to garner the lion-share of
 popularity as they did with D 1.0 (LDC compiler suite is one example
 of the significant sway Tango has had on D 1.0 ), then I think I'm
 going to just throw up my hands.  Yes, I think something has to be
 done: ignoring Tango is not going to be a healthy option for D.
 Either that or Phobos2 will have to be so good that people will drop
 Tango faster than they would a red-hot frying pan.
 

 Beware of the false choice. Ideally, Phobos2 will be so good, and
 Tango2 will be so good, that people will enjoy using either or both
 together.
 
 Andrei
 



Heh,  I forgot to enumerate that one at the spur of the moment in /this/ 
post.  :P


Like I said in my early post, you guys will have to be /very/ creative at 
promoting D to make that one work.  I know I want to promote D, but I'm not 
sure I have the same optimism in this particular detail.


I guess we'll see.  In the meantime, I think the best approach is to keep 
"talking" to us.  You and Walter's optimisim is important to keep things 
moving in some perceivable direction.


At any rate, thank you both for your efforts... and restraint.


-JJR

Christopher Wright <dhasenan gmail.com> writes:

Andrei Alexandrescu wrote:
 John Reimer wrote:
 The danger, of course, is that Tango will not be taken seriously again 
 for D 2.0.  If Tango manages to garner the lion-share of popularity as 
 they did with D 1.0 (LDC compiler suite is one example of the 
 significant sway Tango has had on D 1.0 ), then I think I'm going to 
 just throw up my hands.  Yes, I think something has to be done: 
 ignoring Tango is not going to be a healthy option for D.  Either that 
 or Phobos2 will have to be so good that people will drop Tango faster 
 than they would a red-hot frying pan.

 
 Beware of the false choice. Ideally, Phobos2 will be so good, and Tango2 
 will be so good, that people will enjoy using either or both together.
 
 Andrei

People will be forced to use both together, which will be annoying, 
since they overlap. A third party library depending on Phobos will use 
Phobos time types and functions; one using Tango will depend on Tango 
time stuff; client code will be forced to convert back and forth.

Or, for example, subtle differences in file path handling between Phobos 
and Tango (I recall some people on IRC having minor issues with Tango's 
path handling in obscure cases that were contrary to specifications but 
occasionally used).

That sort of annoyance will not be extremely common, but it'll happen. 
It's another source of friction. It's a bad thing.

It's okay if the means of working with data types are entirely different 
in Phobos and Tango. The types themselves should be the same.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Christopher Wright wrote:
 Andrei Alexandrescu wrote:
 John Reimer wrote:
 The danger, of course, is that Tango will not be taken seriously 
 again for D 2.0.  If Tango manages to garner the lion-share of 
 popularity as they did with D 1.0 (LDC compiler suite is one example 
 of the significant sway Tango has had on D 1.0 ), then I think I'm 
 going to just throw up my hands.  Yes, I think something has to be 
 done: ignoring Tango is not going to be a healthy option for D.  
 Either that or Phobos2 will have to be so good that people will drop 
 Tango faster than they would a red-hot frying pan.

 Beware of the false choice. Ideally, Phobos2 will be so good, and 
 Tango2 will be so good, that people will enjoy using either or both 
 together.

 Andrei

 
 People will be forced to use both together, which will be annoying, 
 since they overlap. A third party library depending on Phobos will use 
 Phobos time types and functions; one using Tango will depend on Tango 
 time stuff; client code will be forced to convert back and forth.
 
 Or, for example, subtle differences in file path handling between Phobos 
 and Tango (I recall some people on IRC having minor issues with Tango's 
 path handling in obscure cases that were contrary to specifications but 
 occasionally used).
 
 That sort of annoyance will not be extremely common, but it'll happen. 
 It's another source of friction. It's a bad thing.

I agree, but I don't quite see a solution to this.

 It's okay if the means of working with data types are entirely different 
 in Phobos and Tango. The types themselves should be the same.

Couldn't this cause trouble for code that is ported from one library to 
another? It may compile and then do unexpected things.


Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Don wrote:
 <small rant>
 I completely disagree. I think the two libraries is a disaster. I can 
 see that so many people have been exposed to a lifetime of propaganda 
 that "competition is a good thing", but it's just propaganda. 
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

Well I've been exposed to "competition is wasted effort" for the first 
19 years of my life, and believe me, you wouldn't want to be subjected 
to that :o). But, I hear your point.

 Note, however that the gulf between Phobos and Tango mostly exists in 
 I/O; and C++ also has two I/O packages (the one inherited from C, and 
 the awful iostreams). So I don't think this is a big a problem as 
 stated. If we work at it, we could move the difference to be entirely a 
 I/O difference. But that would require willingless to do it, and I'm not 
 sure that it's really there.
 
 <big rant>
 In my attempt to bring both libraries together I have experienced 
 reactions from both sides which appeared hostile (or at least reluctant) 
 to a merger. Apart from Sean and myself, I don't see much evidence that 
 people actually want them to merge. They just want the other one to 
 disappear.
 </big rant>

Well then you better start naming names :o). As far as yours truly is 
concerned, it's a good thing to be able to work on a library that meshes 
well with the power of D2. In many ways it's a dream language (sometimes 
literally so...), and it ought to come with a dream library.


Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 Don wrote:
 
 <small rant>
 I completely disagree. I think the two libraries is a disaster. I can
 see that so many people have been exposed to a lifetime of propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

 Well I've been exposed to "competition is wasted effort" for the first
 19 years of my life, and believe me, you wouldn't want to be subjected
 to that :o). But, I hear your point.
 


I've read a little bit of history on Romania and the conditions under Nicolae 
Ceauşescu's reign.  I'd be interested to sit down with you sometime and hear 
your perspective as one who had first hand experience of it.   It sounded 
pretty bad -- conditions with which most of our Western culture is completely 
unfamiliar.


All the best,


-JJR

John Reimer <terminal.node gmail.com> writes:

Hello John,

 Hello Andrei,
 
 Don wrote:
 
 <small rant>
 I completely disagree. I think the two libraries is a disaster. I
 can
 see that so many people have been exposed to a lifetime of
 propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

 Well I've been exposed to "competition is wasted effort" for the
 first 19 years of my life, and believe me, you wouldn't want to be
 subjected to that :o). But, I hear your point.
 

 I've read a little bit of history on Romania and the conditions under
 Nicolae Ceauşescu's reign.  I'd be interested to sit down with you
 sometime and hear your perspective as one who had first hand
 experience of it.   It sounded pretty bad -- conditions with which
 most of our Western culture is completely unfamiliar.
 
 All the best,
 
 -JJR
 


I hope that didn't come across rude or presumptuous; I'm interested in people, 
history, and experience. :P


-JJR

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

John Reimer wrote:
 Hello John,
 
 Hello Andrei,

 Don wrote:

 <small rant>
 I completely disagree. I think the two libraries is a disaster. I
 can
 see that so many people have been exposed to a lifetime of
 propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

 Well I've been exposed to "competition is wasted effort" for the
 first 19 years of my life, and believe me, you wouldn't want to be
 subjected to that :o). But, I hear your point.

 I've read a little bit of history on Romania and the conditions under
 Nicolae Ceauşescu's reign.  I'd be interested to sit down with you
 sometime and hear your perspective as one who had first hand
 experience of it.   It sounded pretty bad -- conditions with which
 most of our Western culture is completely unfamiliar.

 All the best,

 -JJR

 
 
 I hope that didn't come across rude or presumptuous; I'm interested in 
 people, history, and experience. :P

Sure. In all likelihood many of us will bump into one another at a 
conference sooner rather than later.

Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

<snip>

 

 I hope that didn't come across rude or presumptuous; I'm interested
 in people, history, and experience. :P
 

 Sure. In all likelihood many of us will bump into one another at a
 conference sooner rather than later.
 
 Andrei
 


True! :)


-JJR

dsimcha <dsimcha yahoo.com> writes:

== Quote from Don (nospam nospam.com)'s article

 <small rant>
 I completely disagree. I think the two libraries is a disaster. I can
 see that so many people have been exposed to a lifetime of propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

On a purely philosopical note, yes, cooperation is better than competition *if*
there's enough of a consensus among the parties involved as to how things should
be run.  However, this is a *BIG* if.  The problem with ideologies that are
strongly against competition is that this is very seldom true in the real world.
(Phobos vs. Tango is one example)  In these cases, where there is simply no
consensus, the only realistic alternative to competition is to have winners and
losers picked in a dictatorial fashion by some form of authority.  Yes, this
authority could be selected democratically by voting, but tyranny of the
majority
is still tyranny.  In the case of Phobos vs. Tango, Walter could hypothetically
just try his absolute hardest to kill off Tango, in the name of preventing
competition, but I'm sure noone wants that.  Therefore, where no true consensus
exists or ever realistically will exist, competition is often a lesser evil than
having a winner arbitrarily picked by some form of authority.

Don <nospam nospam.com> writes:

dsimcha wrote:
 == Quote from Don (nospam nospam.com)'s article
 
 <small rant>
 I completely disagree. I think the two libraries is a disaster. I can
 see that so many people have been exposed to a lifetime of propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

 
 On a purely philosopical note, yes, cooperation is better than competition *if*
 there's enough of a consensus among the parties involved as to how things
should
 be run.  However, this is a *BIG* if.  The problem with ideologies that are
 strongly against competition is that this is very seldom true in the real
world.
 (Phobos vs. Tango is one example)  In these cases, where there is simply no
 consensus, the only realistic alternative to competition is to have winners and
 losers picked in a dictatorial fashion by some form of authority.  Yes, this
 authority could be selected democratically by voting, but tyranny of the
majority
 is still tyranny.  In the case of Phobos vs. Tango, Walter could hypothetically
 just try his absolute hardest to kill off Tango, in the name of preventing
 competition, but I'm sure noone wants that.  Therefore, where no true consensus
 exists or ever realistically will exist, competition is often a lesser evil
than
 having a winner arbitrarily picked by some form of authority.

I'm not convinced that there really is a major idealogical difference 
between Phobos and Tango. At the time Tango was formed, Phobos was 
virtually stagnant. It was a random accretion of contributions by 
various authors from various points in D's history. All changes to 
Phobos were manually made by Walter, who had too much on his plate 
already. _Nobody_ thought that that situation was ideal.

Tango1 is in direct competition with Phobos1, but Phobos1 is frozen. 
Phobos2 is _not_ the same as Phobos1, and breaks compatibility with it 
in many serious ways. And Phobos1 and 2 are likely to diverge even more 
with time.

There are in fact many similarities between Phobos2 and Tango1.

Now we're getting some genuinely different approaches between Phobos2 
and Tango1, but they seem to be driven as much by the new capabilities 
in D2, as by philosophical differences. So I see two critical questions:
(1) to what extent will Tango2 embrace D2 features, at the expense of 
backward compatibility with Tango1? (The more it embraces D2, the closer 
it will become to Phobos2); and
(2) are both libraries prepared to eliminate the many superficial 
differences between them?

Can we merge Tango2 and Phobos2, given that neither of them completely 
exist yet?

John Reimer <terminal.node gmail.com> writes:

Hello Don,

 dsimcha wrote:
 
 == Quote from Don (nospam nospam.com)'s article
 
 <small rant>
 I completely disagree. I think the two libraries is a disaster. I
 can
 see that so many people have been exposed to a lifetime of
 propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

 On a purely philosopical note, yes, cooperation is better than
 competition *if* there's enough of a consensus among the parties
 involved as to how things should be run.  However, this is a *BIG*
 if.  The problem with ideologies that are strongly against
 competition is that this is very seldom true in the real world.
 (Phobos vs. Tango is one example)  In these cases, where there is
 simply no consensus, the only realistic alternative to competition is
 to have winners and losers picked in a dictatorial fashion by some
 form of authority.  Yes, this authority could be selected
 democratically by voting, but tyranny of the majority is still
 tyranny.  In the case of Phobos vs. Tango, Walter could
 hypothetically just try his absolute hardest to kill off Tango, in
 the name of preventing competition, but I'm sure noone wants that.
 Therefore, where no true consensus exists or ever realistically will
 exist, competition is often a lesser evil than having a winner
 arbitrarily picked by some form of authority.
 

 I'm not convinced that there really is a major idealogical difference
 between Phobos and Tango. At the time Tango was formed, Phobos was
 virtually stagnant. It was a random accretion of contributions by
 various authors from various points in D's history. All changes to
 Phobos were manually made by Walter, who had too much on his plate
 already. _Nobody_ thought that that situation was ideal.
 
 Tango1 is in direct competition with Phobos1, but Phobos1 is frozen.
 Phobos2 is _not_ the same as Phobos1, and breaks compatibility with it
 in many serious ways. And Phobos1 and 2 are likely to diverge even
 more with time.
 
 There are in fact many similarities between Phobos2 and Tango1.
 
 Now we're getting some genuinely different approaches between Phobos2
 and Tango1, but they seem to be driven as much by the new capabilities
 in D2, as by philosophical differences. So I see two critical
 questions:
 (1) to what extent will Tango2 embrace D2 features, at the expense of
 backward compatibility with Tango1? (The more it embraces D2, the
 closer
 it will become to Phobos2); and
 (2) are both libraries prepared to eliminate the many superficial
 differences between them?
 Can we merge Tango2 and Phobos2, given that neither of them completely
 exist yet?
 


I agree that these are the critical questions, and we will need to see them 
answered eventually.  The question is "when?"   I suppose, the Tango people 
probably can't answer that until they see a stable D 2.0 and a complete Phobos 
2.  On the other hand, perhaps its a very good time for Tango guys to be 
introduced to the Phobos 2 floor plan so that both sides can see if their 
goals can merge somehow.


-JJR

Don <nospam nospam.com> writes:

John Reimer wrote:
 Hello Don,
 
 dsimcha wrote:

 == Quote from Don (nospam nospam.com)'s article

 <small rant>
 I completely disagree. I think the two libraries is a disaster. I
 can
 see that so many people have been exposed to a lifetime of
 propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>

 On a purely philosopical note, yes, cooperation is better than
 competition *if* there's enough of a consensus among the parties
 involved as to how things should be run.  However, this is a *BIG*
 if.  The problem with ideologies that are strongly against
 competition is that this is very seldom true in the real world.
 (Phobos vs. Tango is one example)  In these cases, where there is
 simply no consensus, the only realistic alternative to competition is
 to have winners and losers picked in a dictatorial fashion by some
 form of authority.  Yes, this authority could be selected
 democratically by voting, but tyranny of the majority is still
 tyranny.  In the case of Phobos vs. Tango, Walter could
 hypothetically just try his absolute hardest to kill off Tango, in
 the name of preventing competition, but I'm sure noone wants that.
 Therefore, where no true consensus exists or ever realistically will
 exist, competition is often a lesser evil than having a winner
 arbitrarily picked by some form of authority.

 I'm not convinced that there really is a major idealogical difference
 between Phobos and Tango. At the time Tango was formed, Phobos was
 virtually stagnant. It was a random accretion of contributions by
 various authors from various points in D's history. All changes to
 Phobos were manually made by Walter, who had too much on his plate
 already. _Nobody_ thought that that situation was ideal.

 Tango1 is in direct competition with Phobos1, but Phobos1 is frozen.
 Phobos2 is _not_ the same as Phobos1, and breaks compatibility with it
 in many serious ways. And Phobos1 and 2 are likely to diverge even
 more with time.

 There are in fact many similarities between Phobos2 and Tango1.

 Now we're getting some genuinely different approaches between Phobos2
 and Tango1, but they seem to be driven as much by the new capabilities
 in D2, as by philosophical differences. So I see two critical
 questions:
 (1) to what extent will Tango2 embrace D2 features, at the expense of
 backward compatibility with Tango1? (The more it embraces D2, the
 closer
 it will become to Phobos2); and
 (2) are both libraries prepared to eliminate the many superficial
 differences between them?
 Can we merge Tango2 and Phobos2, given that neither of them completely
 exist yet?

 
 
 I agree that these are the critical questions, and we will need to see 
 them answered eventually.  The question is "when?"   I suppose, the 
 Tango people probably can't answer that until they see a stable D 2.0 
 and a complete Phobos 2.  On the other hand, perhaps its a very good 
 time for Tango guys to be introduced to the Phobos 2 floor plan so that 
 both sides can see if their goals can merge somehow.
 
 -JJR

And in fact, a Tango2 floor plan would be a good idea, too. For example, 
now that D2 supports foreach ranges, Tango containers will almost 
certainly want to support them.

Daniel Keep <daniel.keep.lists gmail.com> writes:

Don wrote:
 [snip]
 
 And in fact, a Tango2 floor plan would be a good idea, too. For example,
 now that D2 supports foreach ranges, Tango containers will almost
 certainly want to support them.

For reference, from tango.util.collection.model.Iterator:

public interface Iterator(V)
{
        public bool more();

        public V get();

        int opApply (int delegate (inout V value) dg);
}

Basically, Tango's iterators use more (negation of empty,) and get
(which is next and head combined.)

This brings up a request I have for Andrei: please ensure there is an
actual interface for ranges (preferably enforced.)  Compile-time duck
typing [1] is awesome, but sometimes you need run-time polymorphism.

  -- Daniel



moderately useful, you had to use interfaces to tell the compiler what
was acceptable to pass.

Of course, you can't have operator overloads in interfaces, which meant

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Daniel Keep wrote:
 
 Don wrote:
 [snip]

 And in fact, a Tango2 floor plan would be a good idea, too. For example,
 now that D2 supports foreach ranges, Tango containers will almost
 certainly want to support them.

 
 For reference, from tango.util.collection.model.Iterator:
 
 public interface Iterator(V)
 {
         public bool more();
 
         public V get();
 
         int opApply (int delegate (inout V value) dg);
 }
 
 Basically, Tango's iterators use more (negation of empty,) and get
 (which is next and head combined.)
 
 This brings up a request I have for Andrei: please ensure there is an
 actual interface for ranges (preferably enforced.)  Compile-time duck
 typing [1] is awesome, but sometimes you need run-time polymorphism.

There is a persistent misunderstanding about the two. They're not 
competing. Duck typing as used in foreach and ranges does not preclude 
definition and use of explicit interfaces and dynamic polymorphism.

Andrei

Johan Granberg <lijat.meREM OVEgmail.com> writes:

Don wrote:

 John Reimer wrote:
 Hello dsimcha,
 
 == Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article

 Piotrek wrote:

 Lars Ivar Igesund wrote:

 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.

 I see.

 Cheers

 (Note: speaking as merely an infrequent contributor to Tango; my
 opinion
 is my own and does not reflect on those of the Master Dancers, or the
 ruling council of glittery-shoed programmers.)
 (Warning: semi-rant ahead.)
 The problem is that Phobos and Tango are diametrically opposed in
 almost
 every conceivable way.  Bringing them together would be like trying
 to
 bring matter and anti-matter together; you're just going to blow
 yourself up.
 It's best if you think of Phobos as being Python and Tango as being
 Java.  Phobos implements a relatively flat (if messy) hierarchy of
 simple, fat classes.  For example, IO is done using the Stream
 interfaces, each one implements all the methods you'd probably need
 to
 work with streams.
 Tango, on the other hand, implements a very deep (if confusing)
 hierarchy of simple, component interfaces that get plugged together.
 Unlike Phobos, IO in Tango has many layers and components, each of
 which
 is very narrowly defined, allowing you to plug them together however
 you
 like.
 The problem is that neither of these approaches is WRONG.  They're
 both
 valid and arguably better in certain circumstances.  What's more, the
 continued existence of both shows that there are people who believe
 in
 each of them (not necessarily at the same time, but there you go.)
 So let's say we combined them into std.* and stdex.*.  Why is Tango
 stdex?  Why isn't Tango std.* and Phobos stdsimple?
 Ok, ignoring egos, the problem is that they wouldn't work together
 anyway.  An old favourite of mine is (again, sorry about this) IO.
 Phobos strives to be compatible with the C IO library; so you can
 interleave Phobos and C IO calls and it's all gravy.
 Tango takes C out the back and shoots it before burying it
 upside-down
 at a crossroads with a steak through the heart and salting the earth.
 You CAN mix Tango and C IO calls, but you really have no idea what
 order
 the output's going to arrive in.
 I remember Andrei getting antsy about this a while back; why break
 compatibility?!  Because Tango's IO was faster this way.  Neither one
 of
 them was 'right' because they both had legitimate points of view.
 Really, it all boils down to this: there *is no* one right way.  Yes,
 it's more confusing.  But it's a problem with programming in general;
 programming is all about looking at your options and making a
 decision
 on the matter.
 -- Daniel

 Wow.  Excellent analysis.  One thing I'd like to add is that Phobos
 tends to be
 much more focused on the bleeding edge, with pretty much all
 development happening
 on the D2 branch, while Tango is more focused on targeting stable
 compilers.


 
 Also, another way I would summarize the situation is that Phobos
 focuses on first
 making simple operations simple first and foremost, and then worries
 about making
 complicated operations possible, while Tango does just the opposite.

 
 I don't know if that is strictly true.  In Tango's defense, I believe it
 has tried quite hard to move in the direction of making simple things
 simple even under the restrictions of its own philosophy :).  If you
 examine the progression of Tango revisions, there has been a significant
 "cleanup" in progress that appears to be simplifying what was originally
 verbose.
 
 I've said this before, but I think it's not so bad for D to have two
 standard libraries with different design philosophies, at least in
 principle, though the inability to use both side by side on D1 is
 obviously a bad thing.  There are times when I like the Phobos "keep
 it simple, stupid" approach and times when I want Tango's "everything
 but the kitchen sink" approach.  There are a few things that I think
 would help a lot here:

 
 1.  Both Phobos and Tango should adopt these opposite design
 philosophies, which are true de facto anyhow, officially.  This will
 prevent excessive feature envy and duplication of effort and allow
 newcomers to determine which is best for their everyday use.

 Like I said, I believe Tango has worked harder at doing this than you
 might think.  I don't think Phobos cares to look at the opposite
 philosophy because it really doesn't merge well with it's intended
 goals.  Tango can afford some brevity because it started at the verbose
 end.
 
 
 2.  The creation of druntime so that Phobos and Tango can be used side
 by side is a huge step forward.  Once D2 is out of alpha and Tango is
 ported to D2, people will be able to use their preferred lib most of
 the time and the other when their preferred lib has some missing
 functionality.  This will also greatly simplify 3rd party libs.

 
 
 This somehow parallels my original thinking too which I've mentioned
 before. I am all for the druntime, and it certainly will be a net gain
 if both Tango V2 (if it ever surfaces complete) and Phobos can share it
 once D2 is stable.  But I'm afraid, it is still a grave difficulty for
 new users to face two different libraries.  Now that I've waited and
 think about it longer, I'm not sure what to make of it.  How does one
 promote this twin package deal for D.  I predict that the first person
 that finds a clever way to promote D 2.0 and it's shiny new twin-library
 / pick-your-style feature will be a D hero forever. ;-)
 
 No, it's not bad.

 
 <small rant>
 I completely disagree. I think the two libraries is a disaster. I can
 see that so many people have been exposed to a lifetime of propaganda
 that "competition is a good thing", but it's just propaganda.
 Competition inevitably means wasted effort, and it's obvious in D.
 </small rant>
 
 Note, however that the gulf between Phobos and Tango mostly exists in
 I/O; and C++ also has two I/O packages (the one inherited from C, and
 the awful iostreams). So I don't think this is a big a problem as
 stated. If we work at it, we could move the difference to be entirely a
 I/O difference. But that would require willingless to do it, and I'm not
 sure that it's really there.
 
 <big rant>
 In my attempt to bring both libraries together I have experienced
 reactions from both sides which appeared hostile (or at least reluctant)
 to a merger. Apart from Sean and myself, I don't see much evidence that
 people actually want them to merge. They just want the other one to
 disappear.
 </big rant>

As a user of D primarily and of the standard libraries secondly I see this
reluctance to solve the library situation as the single biggest threat to
D. It creates a division in the community and an uncertainty of which
library to base my own libraries on. If I use one and the other wins the
competition I have to redo a lot of work. It's also a headache when
distributing code as I don't know which functions and packages I can assume
exists. 

This split actually has made me put some of my own projects on hold while
trying to see if we eventually get a merge or one side wins. Through here
lack of time also contributes.

I sinercelly hope this situation gets resolved as the current situation can
be really discoraging for both new and old D developers.

John Reimer <terminal.node gmail.com> writes:

Hello Johan,


 As a user of D primarily and of the standard libraries secondly I see
 this reluctance to solve the library situation as the single biggest
 threat to D. It creates a division in the community and an uncertainty
 of which library to base my own libraries on. If I use one and the
 other wins the competition I have to redo a lot of work. It's also a
 headache when distributing code as I don't know which functions and
 packages I can assume exists.
 


I hear you.   But the argument against this would probably be that you would 
not have to redo all your work... you just start integrating the use of the 
other (more popular) library in your work (since they have common runtimes). 
 While this is convenient, yet it would seem to be cumbersome.  Now projects 
will have dependencies on both full libraries including the libary that falls 
from favour (if that in fact happens).  


On the other hand, it wouldn't be so bad if one of Tango or Phobos became 
a 3rd-party/extension library (more suitably this should be Tango), in which 
case it would seem more natural and familiar to use it as an addon to the 
other library.


-JJR

Don <nospam nospam.com> writes:

John Reimer wrote:
 Hello Johan,
 
 
 As a user of D primarily and of the standard libraries secondly I see
 this reluctance to solve the library situation as the single biggest
 threat to D. It creates a division in the community and an uncertainty
 of which library to base my own libraries on. If I use one and the
 other wins the competition I have to redo a lot of work. It's also a
 headache when distributing code as I don't know which functions and
 packages I can assume exists.

 
 
 I hear you.   But the argument against this would probably be that you 
 would not have to redo all your work... you just start integrating the 
 use of the other (more popular) library in your work (since they have 
 common runtimes). While this is convenient, yet it would seem to be 
 cumbersome.  Now projects will have dependencies on both full libraries 
 including the libary that falls from favour (if that in fact happens). 
 
 On the other hand, it wouldn't be so bad if one of Tango or Phobos 
 became a 3rd-party/extension library (more suitably this should be 
 Tango), in which case it would seem more natural and familiar to use it 
 as an addon to the other library.
 
 
 -JJR
 
 

The other option (which I would prefer) is for druntime to get bigger, 
and encompass more of the common code from both. So that both Phobos and 
Tango became (crucial) extension libraries over a small core. And the 
bigger that common core becomes, the smaller the library problem becomes.

John Reimer <terminal.node gmail.com> writes:

Hello Don,

 John Reimer wrote:
 
 Hello Johan,
 
 As a user of D primarily and of the standard libraries secondly I
 see this reluctance to solve the library situation as the single
 biggest threat to D. It creates a division in the community and an
 uncertainty of which library to base my own libraries on. If I use
 one and the other wins the competition I have to redo a lot of work.
 It's also a headache when distributing code as I don't know which
 functions and packages I can assume exists.
 

 I hear you.   But the argument against this would probably be that
 you would not have to redo all your work... you just start
 integrating the use of the other (more popular) library in your work
 (since they have common runtimes). While this is convenient, yet it
 would seem to be cumbersome.  Now projects will have dependencies on
 both full libraries including the libary that falls from favour (if
 that in fact happens).
 
 On the other hand, it wouldn't be so bad if one of Tango or Phobos
 became a 3rd-party/extension library (more suitably this should be
 Tango), in which case it would seem more natural and familiar to use
 it as an addon to the other library.
 
 -JJR
 

 The other option (which I would prefer) is for druntime to get bigger,
 and encompass more of the common code from both. So that both Phobos
 and Tango became (crucial) extension libraries over a small core. And
 the bigger that common core becomes, the smaller the library problem
 becomes.
 


Actually, I very much like that idea.  And it seems to make sense too.


-JJR

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

John Reimer wrote:
 Don wrote:
 The other option (which I would prefer) is for druntime to get bigger,
 and encompass more of the common code from both. So that both Phobos
 and Tango became (crucial) extension libraries over a small core. And
 the bigger that common core becomes, the smaller the library problem
 becomes.

 
 Actually, I very much like that idea.  And it seems to make sense too.

Seconded! That’s a nice idea.

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Thu, Jan 22, 2009 at 1:53 AM, Alexander P=E1nek
<alexander.panek brainsware.org> wrote:
 John Reimer wrote:
 Don wrote:
 The other option (which I would prefer) is for druntime to get bigger,
 and encompass more of the common code from both. So that both Phobos
 and Tango became (crucial) extension libraries over a small core. And
 the bigger that common core becomes, the smaller the library problem
 becomes.

 Actually, I very much like that idea.  And it seems to make sense too.

 Seconded! That's a nice idea.

Thirded.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Thu, 22 Jan 2009 18:11:02 +0100, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 On Thu, Jan 22, 2009 at 1:53 AM, Alexander Pánek
 <alexander.panek brainsware.org> wrote:
 John Reimer wrote:
 Don wrote:
 The other option (which I would prefer) is for druntime to get bigger,
 and encompass more of the common code from both. So that both Phobos
 and Tango became (crucial) extension libraries over a small core. And
 the bigger that common core becomes, the smaller the library problem
 becomes.

 Actually, I very much like that idea.  And it seems to make sense too.

 Seconded! That's a nice idea.

 Thirded.

Fourthed!

-- 
Simen

Stewart Gordon <smjg_1998 yahoo.com> writes:

Don wrote:
<snip>
 The other option (which I would prefer) is for druntime to get bigger, 
 and encompass more of the common code from both. So that both Phobos and 
 Tango became (crucial) extension libraries over a small core. And the 
 bigger that common core becomes, the smaller the library problem becomes.

Up until the point at which somebody decides it's time to develop a 
library to rival druntime.

Stewart.

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Thu, Jan 22, 2009 at 8:13 PM, Stewart Gordon <smjg_1998 yahoo.com> wrote:
 Don wrote:
 <snip>
 The other option (which I would prefer) is for druntime to get bigger, and
 encompass more of the common code from both. So that both Phobos and Tango
 became (crucial) extension libraries over a small core. And the bigger that
 common core becomes, the smaller the library problem becomes.

 Up until the point at which somebody decides it's time to develop a library
 to rival druntime.

And we prevent that from happening by making as many people as
possible happy with the development and features of druntime/core.
This is exactly what caused the split in libraries in the first place
- a sizable contingent of users who _weren't_ happy with the existing
library or its development.

In the end though, of course there's nothing we can do from stopping
people from developing yet another library.  But we can at least try
to reduce the likelihood of it.

Lars Ivar Igesund <larsivar igesund.net> writes:

Don wrote:

 John Reimer wrote:
 Hello Johan,
 
 
 As a user of D primarily and of the standard libraries secondly I see
 this reluctance to solve the library situation as the single biggest
 threat to D. It creates a division in the community and an uncertainty
 of which library to base my own libraries on. If I use one and the
 other wins the competition I have to redo a lot of work. It's also a
 headache when distributing code as I don't know which functions and
 packages I can assume exists.

 
 
 I hear you.   But the argument against this would probably be that you
 would not have to redo all your work... you just start integrating the
 use of the other (more popular) library in your work (since they have
 common runtimes). While this is convenient, yet it would seem to be
 cumbersome.  Now projects will have dependencies on both full libraries
 including the libary that falls from favour (if that in fact happens).
 
 On the other hand, it wouldn't be so bad if one of Tango or Phobos
 became a 3rd-party/extension library (more suitably this should be
 Tango), in which case it would seem more natural and familiar to use it
 as an addon to the other library.
 
 
 -JJR
 
 

 The other option (which I would prefer) is for druntime to get bigger,
 and encompass more of the common code from both. So that both Phobos and
 Tango became (crucial) extension libraries over a small core. And the
 bigger that common core becomes, the smaller the library problem becomes.

druntime should certainly not become any bigger (in scope), as that would
defeat the purpose of separating the runtime from userspace in the first place.
The topic of common userspace functionality should be kept separate from the
topic of druntime.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Christopher Wright <dhasenan gmail.com> writes:

Lars Ivar Igesund wrote:
 druntime should certainly not become any bigger (in scope), as that would
defeat the purpose of separating the runtime from userspace in the first place.
The topic of common userspace functionality should be kept separate from the
topic of druntime.

Okay, how about another library with shared Phobos / Tango components 
that do not fit in the runtime?

Don <nospam nospam.com> writes:

Lars Ivar Igesund wrote:
 Don wrote:
 
 John Reimer wrote:
 Hello Johan,


 As a user of D primarily and of the standard libraries secondly I see
 this reluctance to solve the library situation as the single biggest
 threat to D. It creates a division in the community and an uncertainty
 of which library to base my own libraries on. If I use one and the
 other wins the competition I have to redo a lot of work. It's also a
 headache when distributing code as I don't know which functions and
 packages I can assume exists.

 I hear you.   But the argument against this would probably be that you
 would not have to redo all your work... you just start integrating the
 use of the other (more popular) library in your work (since they have
 common runtimes). While this is convenient, yet it would seem to be
 cumbersome.  Now projects will have dependencies on both full libraries
 including the libary that falls from favour (if that in fact happens).

 On the other hand, it wouldn't be so bad if one of Tango or Phobos
 became a 3rd-party/extension library (more suitably this should be
 Tango), in which case it would seem more natural and familiar to use it
 as an addon to the other library.


 -JJR

 The other option (which I would prefer) is for druntime to get bigger,
 and encompass more of the common code from both. So that both Phobos and
 Tango became (crucial) extension libraries over a small core. And the
 bigger that common core becomes, the smaller the library problem becomes.

 
 druntime should certainly not become any bigger (in scope), as that would
defeat the purpose of separating the runtime from userspace in the first place.
The topic of common userspace functionality should be kept separate from the
topic of druntime.
 

I think you are confusing druntime (the project) with the D runtime. 
druntime includes the gc as well the runtime, though they are seperate.
I see no reason why including core modules in the druntime project would 
  destroy the seperation.

Really, this is entirely a question of naming.

core.XXX seems to me to be the perfect namespace, certainly for the key 
math modules which I'm most concerned about (std.math/(tango.math.Math, 
tango.math.IEEE), and possibly also the low-level bigint routines. These 
are all functionality which is closely tied to the compiler).

Benji Smith <dlanguage benjismith.net> writes:

Don wrote:
 Lars Ivar Igesund wrote:
 Don wrote:
 druntime should certainly not become any bigger (in scope), as that 
 would defeat the purpose of separating the runtime from userspace in 
 the first place. The topic of common userspace functionality should be 
 kept separate from the topic of druntime.

 
 I think you are confusing druntime (the project) with the D runtime. 
 druntime includes the gc as well the runtime, though they are seperate.
 I see no reason why including core modules in the druntime project would 
  destroy the seperation.
 
 Really, this is entirely a question of naming.
 
 core.XXX seems to me to be the perfect namespace, certainly for the key 
 math modules which I'm most concerned about (std.math/(tango.math.Math, 
 tango.math.IEEE), and possibly also the low-level bigint routines. These 
 are all functionality which is closely tied to the compiler).

Totally agree.

Although the name 'druntime' implies it'll only contain the runtime, I 
think it ought to contain all the common functionality that virtually 
all applications and libraries will absolutely need: the runtime itself, 
gc, TypeInfo, math, containers (including ranges), algorithms, string 
processing, date/time, and IO.

Without those commonalities, any "compatibility" between Phobos and 
Tango will be purely illusory.

Whether the commonality is realized within druntime, or within some 
other low-level common library (like "dcore"), is immaterial to me. And 
actually, I don't really care whether Phobos and Tango have their own 
implementations. But there should be an API (interfaces? concepts? some 
new template-interface mechanism? doesn't matter.) that both Phobos and 
Tango implement, so that library consumers can seamlessly pass low-level 
objects between Phobos and Tango dependent libraries.

--benji

Sean Kelly <sean invisibleduck.org> writes:

Benji Smith wrote:
 Don wrote:
 Lars Ivar Igesund wrote:
 Don wrote:
 druntime should certainly not become any bigger (in scope), as that 
 would defeat the purpose of separating the runtime from userspace in 
 the first place. The topic of common userspace functionality should 
 be kept separate from the topic of druntime.

 I think you are confusing druntime (the project) with the D runtime. 
 druntime includes the gc as well the runtime, though they are seperate.
 I see no reason why including core modules in the druntime project 
 would  destroy the seperation.

 Really, this is entirely a question of naming.

 core.XXX seems to me to be the perfect namespace, certainly for the 
 key math modules which I'm most concerned about 
 (std.math/(tango.math.Math, tango.math.IEEE), and possibly also the 
 low-level bigint routines. These are all functionality which is 
 closely tied to the compiler).

 
 Totally agree.
 
 Although the name 'druntime' implies it'll only contain the runtime, I 
 think it ought to contain all the common functionality that virtually 
 all applications and libraries will absolutely need: the runtime itself, 
 gc, TypeInfo, math, containers (including ranges), algorithms, string 
 processing, date/time, and IO.

After the dsource project was created, someone suggested using the name 
'd-core' instead--I think it's more appropriate than 'd-runtime'.  That 
aside, I personally see the visible portion of the runtime to be roughly 
similar to java.lang.  Basically, I think it should contain the stuff 
that's required for a D app to simply load and run, but anything that's 
sufficiently intrinsic to the language or language philosophy is 
appropriate as well.  In addition to what's already there, I think an 
argument could be made for a range definition, essential math routines, 
and probably  a few other things.  But things that are simply commonly 
used belong in the standard library.

 Without those commonalities, any "compatibility" between Phobos and 
 Tango will be purely illusory.

True enough.  But attempting to include all of the stuff you mentioned 
above would require design agreement between the Phobos and Tango folks 
on quite a bit in terms of API philosophy.

 Whether the commonality is realized within druntime, or within some 
 other low-level common library (like "dcore"), is immaterial to me. And 
 actually, I don't really care whether Phobos and Tango have their own 
 implementations. But there should be an API (interfaces? concepts? some 
 new template-interface mechanism? doesn't matter.) that both Phobos and 
 Tango implement, so that library consumers can seamlessly pass low-level 
 objects between Phobos and Tango dependent libraries.

I agree that this is a fine goal.  It just isn't a task I have any 
intention of pursuing, personally.


Sean

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Daniel Keep wrote:
 Piotrek wrote:
 Lars Ivar Igesund wrote:
 Tango will stay Tango (and tango.*). The above naming assumes that
 Tango will depend on Phobos, and it will not.

 I see.

 Cheers

 
 (Note: speaking as merely an infrequent contributor to Tango; my opinion
 is my own and does not reflect on those of the Master Dancers, or the
 ruling council of glittery-shoed programmers.)
 
 (Warning: semi-rant ahead.)
 
 The problem is that Phobos and Tango are diametrically opposed in almost
 every conceivable way.  Bringing them together would be like trying to
 bring matter and anti-matter together; you're just going to blow
 yourself up.

Nice comparison, but maybe a tad exaggerated. The two libraries are 
different in a number of ways, and reuniting them together might be 
difficult as they sometimes present different ways of approaching 
similar problems. For example, I'm not sure how code in std.algorithm 
could help containers or streams in Tango (as it should), or how to 
reconcile std.algorithm with std.core.array.

One other issue is that phobos2 has the mixed blessing of a clean slate, 
or at least a slate that can be partially cleaned as needed without 
worrying about breaking backwards compatibility. D2 has made a definite 
departure from some of the styles and idioms of D1, and with the advent 
of the new threading model that departure will only be more pronounced. 
The capabilities of a language strongly influence its standard library, 
and at best Phobos2 will espouse and promote the idioms that we strove 
to make possible. After all, we wanted to introduce new features because 
they'd help in writing good code, so the standard library should take 
advantage of them almost by definition. That's why phobos is not being 
"ported" to D2, it is being rewritten for D2.

 It's best if you think of Phobos as being Python and Tango as being
 Java.  Phobos implements a relatively flat (if messy) hierarchy of
 simple, fat classes.  For example, IO is done using the Stream
 interfaces, each one implements all the methods you'd probably need to
 work with streams.

Well, I am really looking forward to deprecating the Stream interfaces. 
I think it's an ok design (alright: I actively dislike certain parts of 
it), it's just that a much better design can be put forth with D2's 
capabilities.

 Tango, on the other hand, implements a very deep (if confusing)
 hierarchy of simple, component interfaces that get plugged together.
 Unlike Phobos, IO in Tango has many layers and components, each of which
 is very narrowly defined, allowing you to plug them together however you
 like.
 
 The problem is that neither of these approaches is WRONG.  They're both
 valid and arguably better in certain circumstances.  What's more, the
 continued existence of both shows that there are people who believe in
 each of them (not necessarily at the same time, but there you go.)
 
 So let's say we combined them into std.* and stdex.*.  Why is Tango
 stdex?  Why isn't Tango std.* and Phobos stdsimple?
 
 Ok, ignoring egos, the problem is that they wouldn't work together
 anyway.  An old favourite of mine is (again, sorry about this) IO.
 
 Phobos strives to be compatible with the C IO library; so you can
 interleave Phobos and C IO calls and it's all gravy.
 
 Tango takes C out the back and shoots it before burying it upside-down
 at a crossroads with a steak through the heart and salting the earth.

Sweet. I mean salty.

 You CAN mix Tango and C IO calls, but you really have no idea what order
 the output's going to arrive in.
 
 I remember Andrei getting antsy about this a while back; why break
 compatibility?!  Because Tango's IO was faster this way.  Neither one of
 them was 'right' because they both had legitimate points of view.
 
 Really, it all boils down to this: there *is no* one right way.  Yes,
 it's more confusing.  But it's a problem with programming in general;
 programming is all about looking at your options and making a decision
 on the matter.

In wake of some recent trials, it looks like I/O can be sped up without 
necessarily giving up on C compatibility. The range design, which will 
be central to much of Phobos2 (notably I/O) will pay close attention to 
not stand in the way of streamlined transfers.

In my opinion an embarrassment of riches isn't necessarily bad. It was 
real bad only when using one library precluded using the other.

Speaking of D2 in general, I think 2009 will be a big year. There has 
been a lot of great work done on D2 in the past couple of years, but 
quite little to show for it in terms of code and publications. This has 
frustrated Walter and myself at times, but when we talked about it we 
always reached the conclusion that we have a sound plan and that 
sometimes you just have to keep on working for those mythical delayed 
rewards. Well, this year it looks like at least some of those rewards 
will materialize.  Speaking of Phobos2 in particular, if I manage to 
execute at least part of my vision on Phobos2, it will become a powerful 
and thoroughly pleasant to use library.


Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,


 In my opinion an embarrassment of riches isn't necessarily bad. It was
 real bad only when using one library precluded using the other.


True.


 Speaking of D2 in general, I think 2009 will be a big year. There has
 been a lot of great work done on D2 in the past couple of years, but
 quite little to show for it in terms of code and publications. This
 has frustrated Walter and myself at times, but when we talked about it
 we always reached the conclusion that we have a sound plan and that
 sometimes you just have to keep on working for those mythical delayed
 rewards. Well, this year it looks like at least some of those rewards
 will materialize.  Speaking of Phobos2 in particular, if I manage to
 execute at least part of my vision on Phobos2, it will become a
 powerful and thoroughly pleasant to use library.
 
 Andrei
 


Sounds exciting.  Hope it all works out. 

It's especially nice to hear even a general statement of direction here now 
and again. So thank-you.  I know it must be tough slogging. :)


-JJR

Walter Bright <newshound1 digitalmars.com> writes:

John Reimer wrote:
 Sounds exciting.  Hope it all works out.
 It's especially nice to hear even a general statement of direction here 
 now and again. So thank-you.  I know it must be tough slogging. :)

I know I've been quiet lately, but that doesn't mean I'm not working on 
D. In fact, I've been spending more hours on it than ever. There's a lot 
of cool stuff coming!

Jason House <jason.james.house gmail.com> writes:

Walter Bright Wrote:

 John Reimer wrote:
 Sounds exciting.  Hope it all works out.
 It's especially nice to hear even a general statement of direction here 
 now and again. So thank-you.  I know it must be tough slogging. :)

 
 I know I've been quiet lately, but that doesn't mean I'm not working on 
 D. In fact, I've been spending more hours on it than ever. There's a lot 
 of cool stuff coming!

Care to share your top 5 priorities? IIRC, when the user community was polled
for their top 5, fixing the Tango/Phobos thing was on top of most lists.
Druntime is a great step in that direction, but it's not enough. Without other
communication on the topic from either side, it appears that the merger effort
has fizzled and died. Can you (or whoever is qualified to answer) shed light on
what's going on there?

Walter Bright <newshound1 digitalmars.com> writes:

Jason House wrote:
 Care to share your top 5 priorities?

Support for threading is the biggest.

 IIRC, when the user community
 was polled for their top 5, fixing the Tango/Phobos thing was on top
 of most lists. Druntime is a great step in that direction, but it's
 not enough. Without other communication on the topic from either
 side, it appears that the merger effort has fizzled and died. Can you
 (or whoever is qualified to answer) shed light on what's going on
 there?

Druntime is there, and it's up to the Tango team now.

John Reimer <terminal.node gmail.com> writes:

Hello Walter,

 Jason House wrote:
 
 Care to share your top 5 priorities?
 

 Support for threading is the biggest.
 
 IIRC, when the user community
 was polled for their top 5, fixing the Tango/Phobos thing was on top
 of most lists. Druntime is a great step in that direction, but it's
 not enough. Without other communication on the topic from either
 side, it appears that the merger effort has fizzled and died. Can you
 (or whoever is qualified to answer) shed light on what's going on
 there?

 Druntime is there, and it's up to the Tango team now.
 



Well, it's probably best to be a little more specific here.  I'm assuming 
you mean to say that it's up to Tango to port to D2.0 and then integrate 
the druntime.  This is true if we are merely talking about the common base. 
 That step is not likely to happen until D2.0 is finalized (in the sense 
that there will be no support for the Tango 2 port until D2.0 is stable).  


In this regard, there's nothing to be done right now until that happens because 
it's not yet clear what Tango's plans are for D 2.0.  But it appears that 
a port will happen (it's already partially done).  And if it is completed, 
 the Phobos 2 and Tango 2 /might/ be revisited at a higher level (now with 
a common druntime making things easier).  As Andrei will be releasing a book 
in 2009, Phobos 2 will be the only library immediately visible to the public 
for the D 2.0 language.  If Tango V2 popularity surges again... well, we 
just might have the same problem.  I guess it's just a little "iffy", and 
it's good to be aware of this.  I think it's good to keep brainstorming on 
it in case there is some sort of solution lurking in the dark recesses of 
this community or elsewhere.


-JJR

Jason House <jason.james.house gmail.com> writes:

Walter Bright wrote:

 Druntime is there, and it's up to the Tango team now.

As I understand it, the biggest fear of the Tango team is to make an official
D2 version and then have to chase after a moving standard.  If an official port
of Tango 0.99.7 was ported to work with dmd v2.023 how willing would you be to
ensure that the D2 Tango was functional prior to new releases of dmd?  I don't
necessarily mean that you personally hack at Tango D2 for every release with
breaking changes but rather that you have people lined up to compile and run
unit tests, and fix problems prior to each release?

If the answer to that is yes, I'd be happy to sign up as a tester/fixer.  I can
guarantee that I won't be able to do a large number of fixes before a release,
but would be able to do some.  For most releases, that may be enough.  For big
breaking changes, we'd need several tester/fixer people.  I also can't do a D2
+ druntime port.  I think there's already a pre-druntime port of Tango to D2. 
I doubt I could do that job, and won't sign up for it.  I also won't sign up
for porting new Tango functionality to D2 either.  

Even with all of these restrictions, I believe that this could work for the
next year or two while D2 solidifies its design.  I'd absolutely love to see
this, which is why I'm willing to help maintain it.  Maybe there will be other
inspired individuals who would do the initial Tango D2 port and others who may
periodically update D2 Tango to match the latest and greatest Tango D1 release.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Jason House" wrote
 Walter Bright wrote:

 Druntime is there, and it's up to the Tango team now.

 As I understand it, the biggest fear of the Tango team is to make an 
 official D2 version and then have to chase after a moving standard.  If an 
 official port of Tango 0.99.7 was ported to work with dmd v2.023 how 
 willing would you be to ensure that the D2 Tango was functional prior to 
 new releases of dmd?  I don't necessarily mean that you personally hack at 
 Tango D2 for every release with breaking changes but rather that you have 
 people lined up to compile and run unit tests, and fix problems prior to 
 each release?

As far as I know, Walter has stated that he is willing to issue a quick fix 
release for easily fixed bugs that hurt Tango.  This already happens with 
the D1 releases, and I'm sure he'd extend that courtesy for D2 releases once 
Tango D2 is relatively stable.  I agree with Walter that the ball is fully 
in Tango's court.

D2 not being stable is probably the largest reason that most of the Tango 
devs aren't yet interested, but it doesn't stop some of us from trying :) 
Probably the largest hurdle right now is const-ifying all of Tango.  Most of 
the time, this doesn't just imply slapping a const or immutable label on 
something, but really rethinking how a particular module is implemented to 
cater to const properly.  Thankfully, however, const is now a stable target. 
Once pure/shared/unshared gets introduced, it will probably require more 
effort, but probably not as much as with const.

 If the answer to that is yes, I'd be happy to sign up as a tester/fixer. 
 I can guarantee that I won't be able to do a large number of fixes before 
 a release, but would be able to do some.  For most releases, that may be 
 enough.  For big breaking changes, we'd need several tester/fixer people. 
 I also can't do a D2 + druntime port.  I think there's already a 
 pre-druntime port of Tango to D2.  I doubt I could do that job, and won't 
 sign up for it.  I also won't sign up for porting new Tango functionality 
 to D2 either.

 Even with all of these restrictions, I believe that this could work for 
 the next year or two while D2 solidifies its design.  I'd absolutely love 
 to see this, which is why I'm willing to help maintain it.  Maybe there 
 will be other inspired individuals who would do the initial Tango D2 port 
 and others who may periodically update D2 Tango to match the latest and 
 greatest Tango D1 release.

It's already being worked on, albeit slowly...  Need more free time :)  Any 
help is appreciated.  My motivation for doing the port is to ensure D2's 
design is tested fully, as I believe many of the features aren't completely 
tested with Phobos alone.  I've already found several D2 bugs just by 
porting some of Tango.  My biggest fear is that D2 is released with some 
design decision that makes Tango impossible to port.

-Steve 

Lars Ivar Igesund <larsivar igesund.net> writes:

Steven Schveighoffer wrote:

 "Jason House" wrote
 Walter Bright wrote:

 Druntime is there, and it's up to the Tango team now.

 As I understand it, the biggest fear of the Tango team is to make an
 official D2 version and then have to chase after a moving standard.  If
 an official port of Tango 0.99.7 was ported to work with dmd v2.023 how
 willing would you be to ensure that the D2 Tango was functional prior to
 new releases of dmd?  I don't necessarily mean that you personally hack
 at Tango D2 for every release with breaking changes but rather that you
 have people lined up to compile and run unit tests, and fix problems
 prior to each release?

 
 As far as I know, Walter has stated that he is willing to issue a quick
 fix
 release for easily fixed bugs that hurt Tango.  This already happens with
 the D1 releases, and I'm sure he'd extend that courtesy for D2 releases
 once
 Tango D2 is relatively stable.  I agree with Walter that the ball is fully
 in Tango's court.
 
 D2 not being stable is probably the largest reason that most of the Tango
 devs aren't yet interested, but it doesn't stop some of us from trying :)
 Probably the largest hurdle right now is const-ifying all of Tango.  Most
 of the time, this doesn't just imply slapping a const or immutable label
 on something, but really rethinking how a particular module is implemented
 to
 cater to const properly.  Thankfully, however, const is now a stable
 target. Once pure/shared/unshared gets introduced, it will probably
 require more effort, but probably not as much as with const.

There is also the question of how SafeD should be catered for.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Walter Bright <newshound1 digitalmars.com> writes:

Jason House wrote:
 Walter Bright wrote:
 
 Druntime is there, and it's up to the Tango team now.

 
 As I understand it, the biggest fear of the Tango team is to make an
 official D2 version and then have to chase after a moving standard.
 If an official port of Tango 0.99.7 was ported to work with dmd
 v2.023 how willing would you be to ensure that the D2 Tango was
 functional prior to new releases of dmd?  I don't necessarily mean
 that you personally hack at Tango D2 for every release with breaking
 changes but rather that you have people lined up to compile and run
 unit tests, and fix problems prior to each release?

Prior to a release, I send it around to a few people who build and check 
Tango and a couple other things against it.


 If the answer to that is yes, I'd be happy to sign up as a
 tester/fixer.  I can guarantee that I won't be able to do a large
 number of fixes before a release, but would be able to do some.  For
 most releases, that may be enough.  For big breaking changes, we'd
 need several tester/fixer people.  I also can't do a D2 + druntime
 port.  I think there's already a pre-druntime port of Tango to D2.  I
 doubt I could do that job, and won't sign up for it.  I also won't
 sign up for porting new Tango functionality to D2 either.
 
 Even with all of these restrictions, I believe that this could work
 for the next year or two while D2 solidifies its design.  I'd
 absolutely love to see this, which is why I'm willing to help
 maintain it.  Maybe there will be other inspired individuals who
 would do the initial Tango D2 port and others who may periodically
 update D2 Tango to match the latest and greatest Tango D1 release.

I (and others) keep Phobos2 up to date with every iteration of D2. It 
hasn't been much work, primarily because I avoid making changes in D2 
that will silently break code. So when things break, they break noisily 
<g> and are easy to fix.

Also contributing to the ease of keeping it up to date is a good set of 
unittests, although they could be better still. Even the simplest of 
unit tests save boatloads of grief down the line. I've got plenty of 
experience with them now <g>.

I'm sure the Tango team will welcome your help!

John Reimer <terminal.node gmail.com> writes:

Hello Walter,

 John Reimer wrote:
 
 Sounds exciting.  Hope it all works out.
 It's especially nice to hear even a general statement of direction
 here
 now and again. So thank-you.  I know it must be tough slogging. :)

 I know I've been quiet lately, but that doesn't mean I'm not working
 on D. In fact, I've been spending more hours on it than ever. There's
 a lot of cool stuff coming!
 


Thank you much for the feedback.  I think the posts here are just a reminder 
that dealing with the human element is just as important (if not more
important) 
than working with the design and implementation element... simply because 
without the former, the latter can fall flat.


Perhaps I should have shown more restraint in my prior posts.  I've persisted 
because I am really just hoping that you are aware of significance of the 
problem you are facing.  The general silence on the matter makes things
horribly 
inconclusive.   At the same time, I don't like to be pushing a gloomy
perspective 
on it all, but this particular point is something that really needs defusing... 
not with placations but with a clearly laid out game plan that shows you 
have it all in hand.


I guess we'll see what 2009 holds and whether we can be as optimistic and 
you and Andrei are. :)


-JJR

Piotrek <starpit tlen.pl> writes:

Andrei Alexandrescu pisze:

 The capabilities of a language strongly influence its standard library, 
 and at best Phobos2 will espouse and promote the idioms that we strove 
 to make possible. After all, we wanted to introduce new features because 
 they'd help in writing good code, so the standard library should take 
 advantage of them almost by definition. That's why phobos is not being 
 "ported" to D2, it is being rewritten for D2.

I'm 100% for that.

To be clear. It wasn't my intention to ask for merging those libraries 
(in terms of philosophy, design strategy and development). I'm really 
happy as it is now (druntime for my future D2 usage). All I wanted was 
simple renaming (simple from my point of view - not from developers and 
maintainers) which in my opinion (not advanced programmer) could be cool.

 Speaking of D2 in general, I think 2009 will be a big year. There has 
 been a lot of great work done on D2 in the past couple of years, but 
 quite little to show for it in terms of code and publications. This has 
 frustrated Walter and myself at times, but when we talked about it we 
 always reached the conclusion that we have a sound plan and that 
 sometimes you just have to keep on working for those mythical delayed 
 rewards. 

I hope it will be like all you said. I'm really grateful for all you do 
(also Tango Team and all developers on dsource). And when I am good 
enough I will give my contribution too.

Cheers

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 For example, I'm not sure how code in std.algorithm
 could help containers or streams in Tango (as it should), or how to
 reconcile std.algorithm with std.core.array.

If the language (D2++) will have a new way of iteration and ranges known and
enforced by the compiler, then I expect Tango to support those at some point,
and std.algorithm would presumably just work. However, if it is based on some
interface, ad hoc (these methods must be present) or properly via an interface
Range { }, I would expect Tango developers to be involved in the process of
defining those interfaces (if Tango is meant to use/know about them). Since I
have seen neither, it is somewhat difficult to make a well informed comment on
the subject.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

BLS <nanali nospam.wanadoo.fr> writes:

Lars Ivar Igesund schrieb:
 Andrei Alexandrescu wrote:
 
 For example, I'm not sure how code in std.algorithm
 could help containers or streams in Tango (as it should), or how to
 reconcile std.algorithm with std.core.array.

 
 If the language (D2++) will have a new way of iteration and ranges known and
enforced by the compiler, then I expect Tango to support those at some point,
and std.algorithm would presumably just work. However, if it is based on some
interface, ad hoc (these methods must be present) or properly via an interface
Range { }, I would expect Tango developers to be involved in the process of
defining those interfaces (if Tango is meant to use/know about them). Since I
have seen neither, it is somewhat difficult to make a well informed comment on
the subject.
 

I wish Phobos2 will have some containers showing the new way of 
iteration.  would be a proof of product too.
Bjoern

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

 
 If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

It's been there for a while now (since 25 Nov 2008).

http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

Scroll down to "Foreach over Structs and Classes with Ranges". The 
changelog reflects that too:

http://www.digitalmars.com/d/2.0/changelog.html

Version 2.021 mentions "Added range support to foreach statement."


Andrei

Sergey Gromov <snake.scaly gmail.com> writes:

Sun, 18 Jan 2009 07:21:55 -0800, Andrei Alexandrescu wrote:

 It's been there for a while now (since 25 Nov 2008).
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 
 Scroll down to "Foreach over Structs and Classes with Ranges".

Nice to finally have it in the docs.

The properties table says '.rear', and an example says '.tail', which is
correct?

Walter Bright <newshound1 digitalmars.com> writes:

Sergey Gromov wrote:
 The properties table says '.rear', and an example says '.tail', which is
 correct?

Neither. It's ".toe". I've corrected the docs.

"Denis Koroskin" <2korden gmail.com> writes:

On Sun, 18 Jan 2009 18:21:55 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

  If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The  
 changelog reflects that too:

 http://www.digitalmars.com/d/2.0/changelog.html

 Version 2.021 mentions "Added range support to foreach statement."


 Andrei

There is a typo in docs
(http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement):

Foreach Range Properties:
.rear	return the rightmost element of the range

...

for (auto __r = range; !__r.empty; __r.retreat)
{   auto e = __r.tail; //<- tail or rear?
   ...
}

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Denis Koroskin wrote:
 On Sun, 18 Jan 2009 18:21:55 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

  If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The 
 changelog reflects that too:

 http://www.digitalmars.com/d/2.0/changelog.html

 Version 2.021 mentions "Added range support to foreach statement."


 Andrei

 
 There is a typo in docs 
 (http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement):
 
 Foreach Range Properties:
 .rear    return the rightmost element of the range
 
 ...
 
 for (auto __r = range; !__r.empty; __r.retreat)
 {   auto e = __r.tail; //<- tail or rear?
   ...
 }
 

Turns out Walter didn't like "rear" for a certain reason. :o) He did 
take to my cute "toe" but in the end did not reflect that in the dox. 
The following code compiles and runs:

struct S
{
     bool empty() {return true;}
     void next() {}
     void retreat() {}
     int head() { return 0; }
     int toe() { return 0; }
}

void main() {
     S s;
     foreach (e; s) {}
     foreach_reverse (e; s) {}
}


Andrei

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Denis Koroskin wrote:
 On Sun, 18 Jan 2009 18:21:55 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

  If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The
 changelog reflects that too:

 http://www.digitalmars.com/d/2.0/changelog.html

 Version 2.021 mentions "Added range support to foreach statement."


 Andrei

 
 There is a typo in docs
 (http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement):
 
 Foreach Range Properties:
 .rear    return the rightmost element of the range
 
 ...
 
 for (auto __r = range; !__r.empty; __r.retreat)
 {   auto e = __r.tail; //<- tail or rear?
   ...
 }
 

 
 Turns out Walter didn't like "rear" for a certain reason. :o) He did
 take to my cute "toe" but in the end did not reflect that in the dox.
 The following code compiles and runs:
 
 struct S
 {
      bool empty() {return true;}
      void next() {}
      void retreat() {}
      int head() { return 0; }
      int toe() { return 0; }
 }
 
 void main() {
      S s;
      foreach (e; s) {}
      foreach_reverse (e; s) {}
 }
 
 
 Andrei

toe() ?! tail() good, rear() not so good, toe() sucks. 

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund <larsivar igesund.net> writes:

Lars Ivar Igesund wrote:

 Andrei Alexandrescu wrote:
 
 Denis Koroskin wrote:
 On Sun, 18 Jan 2009 18:21:55 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

  If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The
 changelog reflects that too:

 http://www.digitalmars.com/d/2.0/changelog.html

 Version 2.021 mentions "Added range support to foreach statement."


 Andrei

 
 There is a typo in docs
 (http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement):
 
 Foreach Range Properties:
 .rear    return the rightmost element of the range
 
 ...
 
 for (auto __r = range; !__r.empty; __r.retreat)
 {   auto e = __r.tail; //<- tail or rear?
   ...
 }
 

 
 Turns out Walter didn't like "rear" for a certain reason. :o) He did
 take to my cute "toe" but in the end did not reflect that in the dox.
 The following code compiles and runs:
 
 struct S
 {
      bool empty() {return true;}
      void next() {}
      void retreat() {}
      int head() { return 0; }
      int toe() { return 0; }
 }
 
 void main() {
      S s;
      foreach (e; s) {}
      foreach_reverse (e; s) {}
 }
 
 
 Andrei

 
 toe() ?! tail() good, rear() not so good, toe() sucks.

I think I remember there being a discussion about this, but I wasn't aware that
the outcome was this bad so let me qualify my opinion.

Only on humans (and possibly some apes) can toe be considered the other end,
but even with humans the heel is more correct with the toes being a sort of
peripherals. On most animals (and birds), the tail will be the other end of the
head.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Walter Bright <newshound1 digitalmars.com> writes:

Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks. 

tail() is no good because it has a well-established meaning in 
programming of being everything but the first element of a list. I just 
didn't like rear(), as it is not normally thought of as the opposite of 
head().

Yigal Chripun <yigal100 gmail.com> writes:

Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

What was the reason for the use of body parts in the first place?
What's wrong with:
a) begin, end
b) start, finish
c) initial, final
d) first, last
etc...

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-01-18 16:43:30 -0500, Yigal Chripun <yigal100 gmail.com> said:

 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 
 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 
 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...

e) front, back.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Walter Bright <newshound1 digitalmars.com> writes:

Yigal Chripun wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 
 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...


There doesn't really need to be anything wrong with them. What's wrong 
with head/toe?

Christopher Wright <dhasenan gmail.com> writes:

Walter Bright wrote:
 Yigal Chripun wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...

 
 
 There doesn't really need to be anything wrong with them. What's wrong 
 with head/toe?

It sounds stupid.

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Jan 19, 2009 at 2:00 PM, Christopher Wright <dhasenan gmail.com> wrote:
 Walter Bright wrote:
 Yigal Chripun wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...


 There doesn't really need to be anything wrong with them. What's wrong
 with head/toe?

 It sounds stupid.

Here's from the previous discussion:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_Revised_RFC_on_range_design_for_D2_13303.html

I think toe sounds fine.  I'm just glad 'tip' was abandoned in favor of 'head'.

--bb

Yigal Chripun <yigal100 gmail.com> writes:

Christopher Wright wrote:
 Walter Bright wrote:
 Yigal Chripun wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...


 There doesn't really need to be anything wrong with them. What's wrong
 with head/toe?

 It sounds stupid.

it sounds stupid and is uninformative. for example,
auto cars = new BinaryTree!(Car)();
auto a = cars.toe;
auto b = cars.last;

now, reading the above, what's the toe of cars? that's just silly.

Does this make sense to English speakers? most likly. but for say, 
chinese? I don't know.

instead of inveting terms than imply something based on some phrase that 
not all non-native English speakers will recognize, it is far better to 
just use the proper English term for the last item - "last". KISS solution.

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Jan 19, 2009 at 3:57 PM, Yigal Chripun <yigal100 gmail.com> wrote:
 Christopher Wright wrote:
 Walter Bright wrote:
 Yigal Chripun wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...


 There doesn't really need to be anything wrong with them. What's wrong
 with head/toe?

 It sounds stupid.

 it sounds stupid and is uninformative. for example,
 auto cars = new BinaryTree!(Car)();
 auto a = cars.toe;
 auto b = cars.last;

 now, reading the above, what's the toe of cars? that's just silly.

 Does this make sense to English speakers? most likly. but for say, chinese?
 I don't know.

 instead of inveting terms than imply something based on some phrase that not
 all non-native English speakers will recognize, it is far better to just use
 the proper English term for the last item - "last". KISS solution.

Hmm, what *is* the problem with first/last?  I seem to remember there
was something against it but I think that was when the semantics were
slightly different and .last was going to mean one past the end.
Current docs make it looks like it .toe does mean the last element
itself, not the one just past.

--bb

John Reimer <terminal.node gmail.com> writes:

Hello Christopher,

 Walter Bright wrote:
 
 Yigal Chripun wrote:
 
 Walter Bright wrote:
 
 Lars Ivar Igesund wrote:
 
 toe() ?! tail() good, rear() not so good, toe() sucks.
 

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I
 just didn't like rear(), as it is not normally thought of as the
 opposite of head().
 

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...

 There doesn't really need to be anything wrong with them. What's
 wrong with head/toe?
 

 It sounds stupid.
 


I agree that its ugly.  Although, be prepared to see it turn into just another 
feature that we're going to have to get used to. :)


-JJR

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

John Reimer wrote:
 Hello Christopher,
 
 Walter Bright wrote:

 Yigal Chripun wrote:

 Walter Bright wrote:

 Lars Ivar Igesund wrote:

 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I
 just didn't like rear(), as it is not normally thought of as the
 opposite of head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...

 There doesn't really need to be anything wrong with them. What's
 wrong with head/toe?

 It sounds stupid.

 
 
 I agree that its ugly.  Although, be prepared to see it turn into just 
 another feature that we're going to have to get used to. :)

If there's widespread opinion that the current choice of names is 
unfortunate, now is the perfect time to fix that as the names haven't 
been put in heavy use.

Things to keep in mind:

* The operations next and retreat are not necessarily antonyms. I mean 
retreat does NOT undo what next does. So next and previous aren't quite 
desirable.

* "head" will be used much more often than "toe". Most of the time, 
empty, head, and next will be used. These are the elements that support 
input ranges. "toe" and "retreat" are for bidirectional ranges.

* The terms should be applicable equally well to generators (series, 
random numbers...), streams (files, sockets...), collections (lists, 
arrays...) and the such.

* Short, one-word terms are preferred.

Last but not least, keep in mind that these discussions could go on 
forever and that someone's best naming convention is another's worst. 
Happy hunting :o).


Andrei

aarti_pl <aarti interia.pl> writes:

Andrei Alexandrescu pisze:
 John Reimer wrote:
 Hello Christopher,

 Walter Bright wrote:

 Yigal Chripun wrote:

 Walter Bright wrote:

 Lars Ivar Igesund wrote:

 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I
 just didn't like rear(), as it is not normally thought of as the
 opposite of head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...

 There doesn't really need to be anything wrong with them. What's
 wrong with head/toe?

 It sounds stupid.


 I agree that its ugly.  Although, be prepared to see it turn into just 
 another feature that we're going to have to get used to. :)

 
 If there's widespread opinion that the current choice of names is 
 unfortunate, now is the perfect time to fix that as the names haven't 
 been put in heavy use.
 
 Things to keep in mind:
 
 * The operations next and retreat are not necessarily antonyms. I mean 
 retreat does NOT undo what next does. So next and previous aren't quite 
 desirable.
 
 * "head" will be used much more often than "toe". Most of the time, 
 empty, head, and next will be used. These are the elements that support 
 input ranges. "toe" and "retreat" are for bidirectional ranges.
 
 * The terms should be applicable equally well to generators (series, 
 random numbers...), streams (files, sockets...), collections (lists, 
 arrays...) and the such.
 
 * Short, one-word terms are preferred.
 
 Last but not least, keep in mind that these discussions could go on 
 forever and that someone's best naming convention is another's worst. 
 Happy hunting :o).
 
 
 Andrei

first - last
advance - retreat

Above seems to me much more streamlined, than current choice.

BR
Marcin Kuszczak
(aarti_pl)

Rainer Deyke <rainerd eldwood.com> writes:

aarti_pl wrote:
 first - last
 advance - retreat

My preference:
  head - rhead
  next - rnext (or advance - radvance)

The purpose of "retreat" and "toe" is to allow reverse iteration.
"retreat" in not the opposite of "advance"/"next", it's the same
operation applied to the other end of the range.  So why not make this
explicit by prefixing an 'r' to these reverse iteration functions?


-- 
Rainer Deyke - rainerd eldwood.com

Lars Ivar Igesund <larsivar igesund.net> writes:

Christopher Wright wrote:

 Walter Bright wrote:
 Yigal Chripun wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 toe() ?! tail() good, rear() not so good, toe() sucks.

 tail() is no good because it has a well-established meaning in
 programming of being everything but the first element of a list. I just
 didn't like rear(), as it is not normally thought of as the opposite of
 head().

 What was the reason for the use of body parts in the first place?
 What's wrong with:
 a) begin, end
 b) start, finish
 c) initial, final
 d) first, last
 etc...

 
 
 There doesn't really need to be anything wrong with them. What's wrong
 with head/toe?

 
 It sounds stupid.

Wholeheartedly agree.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

"Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:

On Tue, Jan 20, 2009 at 12:50 PM, Lars Ivar Igesund
<larsivar igesund.net> wrote:
 There doesn't really need to be anything wrong with them. What's wrong
 with head/toe?

 It sounds stupid.

 Wholeheartedly agree.

Agreed too, what's wrong with first/last?  They're completely obvious
and have no connotations.

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

 
 If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

 
 It's been there for a while now (since 25 Nov 2008).
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 
 Scroll down to "Foreach over Structs and Classes with Ranges". The
 changelog reflects that too:
 
 http://www.digitalmars.com/d/2.0/changelog.html
 
 Version 2.021 mentions "Added range support to foreach statement."

Ah, thanks :)

However, replacing the "single" opApply with 5 properties seems somewhat
excessive? At least it becomes even more obvious that a form of (runtime
queryable) struct interfaces will be necessary - the one and only feature I
really really want in D2.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 For example, I'm not sure how code in std.algorithm could help 
 containers or streams in Tango (as it should), or how to
 reconcile std.algorithm with std.core.array.

 If the language (D2++) will have a new way of iteration and
 ranges known and enforced by the compiler, then I expect Tango to
 support those at some point, and std.algorithm would presumably
 just work. However, if it is based on some interface, ad hoc
 (these methods must be present) or properly via an interface
 Range { }, I would expect Tango developers to be involved in the
 process of defining those interfaces (if Tango is meant to
 use/know about them). Since I have seen neither, it is somewhat
 difficult to make a well informed comment on the subject.

 It's been there for a while now (since 25 Nov 2008).
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 
 Scroll down to "Foreach over Structs and Classes with Ranges". The 
 changelog reflects that too:
 
 http://www.digitalmars.com/d/2.0/changelog.html
 
 Version 2.021 mentions "Added range support to foreach statement."

 
 Ah, thanks :)
 
 However, replacing the "single" opApply with 5 properties seems
 somewhat excessive? At least it becomes even more obvious that a form
 of (runtime queryable) struct interfaces will be necessary - the one
 and only feature I really really want in D2.

opApply was very inefficient and defining an abstraction that allows 
efficient iteration was a key goal of range design and foreach overhaul. 
Using duck typing and implicit interfaces was a tried and true 
technique. On top of this framework it is easy to define and use 
explicit interfaces. Using classic interfaces would have hamstrung 
efficiency of iteration from day one.

I'd be curious to find out more about a runtime queryable struct 
interface. How would it work? What idioms would it enable?


Andrei

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to
 reconcile std.algorithm with std.core.array.

 If the language (D2++) will have a new way of iteration and
 ranges known and enforced by the compiler, then I expect Tango to
 support those at some point, and std.algorithm would presumably
 just work. However, if it is based on some interface, ad hoc
 (these methods must be present) or properly via an interface
 Range { }, I would expect Tango developers to be involved in the
 process of defining those interfaces (if Tango is meant to
 use/know about them). Since I have seen neither, it is somewhat
 difficult to make a well informed comment on the subject.

 It's been there for a while now (since 25 Nov 2008).
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 
 Scroll down to "Foreach over Structs and Classes with Ranges". The
 changelog reflects that too:
 
 http://www.digitalmars.com/d/2.0/changelog.html
 
 Version 2.021 mentions "Added range support to foreach statement."

 
 Ah, thanks :)
 
 However, replacing the "single" opApply with 5 properties seems
 somewhat excessive? At least it becomes even more obvious that a form
 of (runtime queryable) struct interfaces will be necessary - the one
 and only feature I really really want in D2.

 
 opApply was very inefficient and defining an abstraction that allows
 efficient iteration was a key goal of range design and foreach overhaul.
 Using duck typing and implicit interfaces was a tried and true
 technique. On top of this framework it is easy to define and use
 explicit interfaces. Using classic interfaces would have hamstrung
 efficiency of iteration from day one.
 
 I'd be curious to find out more about a runtime queryable struct
 interface. How would it work? What idioms would it enable?

The point is that with classes and interfaces, you can query the class (at
runtime) for whether it contains a certain set of functionality. Now, I know
that the virtuality of doing so isn't the most efficient in most cases, but
that is besides the point - if there is an efficient way of doing this with
structs, then that should work with classes too. 

When you have functionality (at runtime) that relies only on a container to
have a specific set of functions/properties/methods, then it seems unfair to
restrict that to classes. In practice I see this as something that operates via
additional type info.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 For example, I'm not sure how code in std.algorithm could 
 help containers or streams in Tango (as it should), or how 
 to reconcile std.algorithm with std.core.array.

 If the language (D2++) will have a new way of iteration and 
 ranges known and enforced by the compiler, then I expect 
 Tango to support those at some point, and std.algorithm would
  presumably just work. However, if it is based on some 
 interface, ad hoc (these methods must be present) or properly
  via an interface Range { }, I would expect Tango developers 
 to be involved in the process of defining those interfaces 
 (if Tango is meant to use/know about them). Since I have seen
  neither, it is somewhat difficult to make a well informed 
 comment on the subject.

 It's been there for a while now (since 25 Nov 2008).
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 
 
 
 Scroll down to "Foreach over Structs and Classes with Ranges". 
 The changelog reflects that too:
 
 http://www.digitalmars.com/d/2.0/changelog.html
 
 Version 2.021 mentions "Added range support to foreach 
 statement."

 Ah, thanks :)
 
 However, replacing the "single" opApply with 5 properties seems 
 somewhat excessive? At least it becomes even more obvious that a 
 form of (runtime queryable) struct interfaces will be necessary -
  the one and only feature I really really want in D2.

 opApply was very inefficient and defining an abstraction that 
 allows efficient iteration was a key goal of range design and 
 foreach overhaul. Using duck typing and implicit interfaces was a 
 tried and true technique. On top of this framework it is easy to 
 define and use explicit interfaces. Using classic interfaces would 
 have hamstrung efficiency of iteration from day one.
 
 I'd be curious to find out more about a runtime queryable struct 
 interface. How would it work? What idioms would it enable?

 
 The point is that with classes and interfaces, you can query the 
 class (at runtime) for whether it contains a certain set of 
 functionality.

I think there are a number of confusions and misunderstandings at work
here on top of one another, so allow me to try and clarify a couple.

"Five properties versus one opApply seems excessive. Therefore, a
form of runtime-queryable interface for struct is necessary."

The latter doesn't follow from the former. If five properties in an
implicit interface seems too many, then what you might be asking for is 
explicit interfaces, not dynamic-polymorphic interfaces. Something along 
the lines of:

interface InputRange(T)
{
     void next();
     bool empty();
     T head();
}

struct RandomGenerator : InputRange!(int) { ... }
class IntStream : InputRange!(int) { ... }

The two would follow different implementation strategies. For structs 
the interface would be statically checked. In all likelihood, this 
feature will be part of D2 because it allows for easy concept checking.

 Now, I know that the virtuality of doing so isn't the most efficient
 in most cases, but that is besides the point - if there is an
 efficient way of doing this with structs, then that should work with
 classes too.

This I don't understand at all. Yes, implicit interfaces do work with 
structs and classes and equally well.

 When you have functionality (at runtime) that relies only on a 
 container to have a specific set of functions/properties/methods, 
 then it seems unfair to restrict that to classes. In practice I see 
 this as something that operates via additional type info.

I confess I read this one more than a few times and couldn't understand 
it. So let me read it back in my own words: "You want to implement 
runtime functionality (?) by relying on the existence of a specific set 
of functions/properties/methods. It is unfair to restrict that to 
classes, so I'd like that to work for structs too. The way I see this 
working is by adding extra type info to structs." This doesn't do 
anything in terms of clarifying things for me, so I'd appreciate more info.


Andrei

Jason House <jason.james.house gmail.com> writes:

Andrei Alexandrescu wrote:

 I'd be curious to find out more about a runtime queryable struct
 interface. How would it work? What idioms would it enable?

I don't know what Lars is thinking of, but I think of struct interfaces as a
non-polymorphic / compile-time inheritance.  AKA, you can have a struct
implement it, but you can't cast it to a base struct/interface.  Outside of
defining the struct, I'd expect it to only be usable in templates and
is-expressions

e.g.

template usesRanges( T : ForwardRange ){
  ...
}

usesRanges!(int) x;

LameExample.d: 243: Error int does not implement ForwardRange concept
Ranges.d: 12: head() not implemented
Ranges.d: 13: empty() not implemented
Ranges.d: 14: next() not implemented

Looking really quickly at http://en.wikipedia.org/wiki/C%2B%2B0x#Concepts I
think I'm probably thinking of what C++0x calls Concepts.  I didn't read enough
to see if it's exactly what I'm thinking or just a close match.  While every
template that uses forward ranges could make a messy criteria using if clauses
after the template, it may simply be too hard to read and too long to write. 
The template above would work without any extra if criteria...  Misuse of the
template will give cryptic compiler errors oddly reminiscent of STL...

Lars Ivar Igesund <larsivar igesund.net> writes:

Jason House wrote:

 Andrei Alexandrescu wrote:
 
 I'd be curious to find out more about a runtime queryable struct
 interface. How would it work? What idioms would it enable?

 
 I don't know what Lars is thinking of, but I think of struct interfaces as
 a non-polymorphic / compile-time inheritance.  AKA, you can have a struct
 implement it, but you can't cast it to a base struct/interface.  Outside
 of defining the struct, I'd expect it to only be usable in templates and
 is-expressions

Nope, I want something that works at runtime. Inheritance could/should be
non-polymorphic and compile-time, but I want to know at runtime that a void*
has implemented a given interface.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Jason House wrote:
 
 Andrei Alexandrescu wrote:
 
 I'd be curious to find out more about a runtime queryable struct 
 interface. How would it work? What idioms would it enable?

 I don't know what Lars is thinking of, but I think of struct
 interfaces as a non-polymorphic / compile-time inheritance.  AKA,
 you can have a struct implement it, but you can't cast it to a base
 struct/interface.  Outside of defining the struct, I'd expect it to
 only be usable in templates and is-expressions

 
 Nope, I want something that works at runtime. Inheritance
 could/should be non-polymorphic and compile-time, but I want to know
 at runtime that a void* has implemented a given interface.

Consider you can avail yourself of a function:

bool implements(Interface)(void* p);

What would you do with it?


Andrei

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 Jason House wrote:
 
 Andrei Alexandrescu wrote:
 
 I'd be curious to find out more about a runtime queryable struct
 interface. How would it work? What idioms would it enable?

 I don't know what Lars is thinking of, but I think of struct
 interfaces as a non-polymorphic / compile-time inheritance.  AKA,
 you can have a struct implement it, but you can't cast it to a base
 struct/interface.  Outside of defining the struct, I'd expect it to
 only be usable in templates and is-expressions

 
 Nope, I want something that works at runtime. Inheritance
 could/should be non-polymorphic and compile-time, but I want to know
 at runtime that a void* has implemented a given interface.

 
 Consider you can avail yourself of a function:
 
 bool implements(Interface)(void* p);
 
 What would you do with it?

Assuming that I (after getting a positive result from a call to the above, and
that I have an interface with the member foo) can then safely call p.foo, I
could do a lot of stuff that I can't do today.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Jason House wrote:
 
 Andrei Alexandrescu wrote:
 
 I'd be curious to find out more about a runtime queryable
 struct interface. How would it work? What idioms would it
 enable?

 I don't know what Lars is thinking of, but I think of struct 
 interfaces as a non-polymorphic / compile-time inheritance.
 AKA, you can have a struct implement it, but you can't cast it
 to a base struct/interface.  Outside of defining the struct,
 I'd expect it to only be usable in templates and is-expressions
 

 Nope, I want something that works at runtime. Inheritance 
 could/should be non-polymorphic and compile-time, but I want to
 know at runtime that a void* has implemented a given interface.

 Consider you can avail yourself of a function:
 
 bool implements(Interface)(void* p);
 
 What would you do with it?

 
 Assuming that I (after getting a positive result from a call to the
 above, and that I have an interface with the member foo) can then
 safely call p.foo, I could do a lot of stuff that I can't do today.

I understand. So essentially you don't want to see whether a void* 
implements an interface, but instead you want to get that interface, 
i.e. obtain the pointers to the functions in the interface as 
implemented by whatever struct that void* stands for. In doing so you 
also claim that all of that is entirely possible to do so at low or no 
cost. After the functions in that interface are obtained, you also 
implicitly claim that they won't hurt performance of the design by using 
indirect calls.

If my understanding of the above is correct, this is an extraordinary 
claim. It is, in fact, so extraordinary that I'll bite the bullet and 
claim myself that you are thoroughly confused about what you want and to 
what extent it is realizable. My guess is that if you follow your idea 
to its ultimate conclusion, you will be inexorably drawn to 
rediscovering how vtables work and what tradeoffs they embed when 
compared to direct function calls.


Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 Lars Ivar Igesund wrote:
 
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 
 Jason House wrote:
 
 Andrei Alexandrescu wrote:
 
 I'd be curious to find out more about a runtime queryable struct
 interface. How would it work? What idioms would it enable?
 

 I don't know what Lars is thinking of, but I think of struct
 interfaces as a non-polymorphic / compile-time inheritance. AKA,
 you can have a struct implement it, but you can't cast it to a
 base struct/interface.  Outside of defining the struct, I'd expect
 it to only be usable in templates and is-expressions
 

 Nope, I want something that works at runtime. Inheritance
 could/should be non-polymorphic and compile-time, but I want to
 know at runtime that a void* has implemented a given interface.
 

 Consider you can avail yourself of a function:
 
 bool implements(Interface)(void* p);
 
 What would you do with it?
 

 Assuming that I (after getting a positive result from a call to the
 above, and that I have an interface with the member foo) can then
 safely call p.foo, I could do a lot of stuff that I can't do today.
 

 I understand. So essentially you don't want to see whether a void*
 implements an interface, but instead you want to get that interface,
 i.e. obtain the pointers to the functions in the interface as
 implemented by whatever struct that void* stands for. In doing so you
 also claim that all of that is entirely possible to do so at low or no
 cost. After the functions in that interface are obtained, you also
 implicitly claim that they won't hurt performance of the design by
 using indirect calls.
 
 If my understanding of the above is correct, this is an extraordinary
 claim. It is, in fact, so extraordinary that I'll bite the bullet and
 claim myself that you are thoroughly confused about what you want and
 to what extent it is realizable. My guess is that if you follow your
 idea to its ultimate conclusion, you will be inexorably drawn to
 rediscovering how vtables work and what tradeoffs they embed when
 compared to direct function calls.
 
 Andrei
 


I wonder if anybody finds you intimidating in person. :D

-JJR

Walter Bright <newshound1 digitalmars.com> writes:

John Reimer wrote:
 I wonder if anybody finds you intimidating in person. :D

That depends on who is buying the beer <g>.

John Reimer <terminal.node gmail.com> writes:

Hello Walter,

 John Reimer wrote:
 
 I wonder if anybody finds you intimidating in person. :D
 

 That depends on who is buying the beer <g>.
 


I'm bet its always free for him. ;-D


-JJR

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Jason House wrote:
 
 Andrei Alexandrescu wrote:
 
 I'd be curious to find out more about a runtime queryable
 struct interface. How would it work? What idioms would it
 enable?

 I don't know what Lars is thinking of, but I think of struct
 interfaces as a non-polymorphic / compile-time inheritance.
 AKA, you can have a struct implement it, but you can't cast it
 to a base struct/interface.  Outside of defining the struct,
 I'd expect it to only be usable in templates and is-expressions
 

 Nope, I want something that works at runtime. Inheritance
 could/should be non-polymorphic and compile-time, but I want to
 know at runtime that a void* has implemented a given interface.

 Consider you can avail yourself of a function:
 
 bool implements(Interface)(void* p);
 
 What would you do with it?

 
 Assuming that I (after getting a positive result from a call to the
 above, and that I have an interface with the member foo) can then
 safely call p.foo, I could do a lot of stuff that I can't do today.

 
 I understand. So essentially you don't want to see whether a void*
 implements an interface, but instead you want to get that interface,
 i.e. obtain the pointers to the functions in the interface as
 implemented by whatever struct that void* stands for. In doing so you
 also claim that all of that is entirely possible to do so at low or no
 cost. After the functions in that interface are obtained, you also
 implicitly claim that they won't hurt performance of the design by using
 indirect calls.
 
 If my understanding of the above is correct, this is an extraordinary
 claim. It is, in fact, so extraordinary that I'll bite the bullet and
 claim myself that you are thoroughly confused about what you want and to
 what extent it is realizable. My guess is that if you follow your idea
 to its ultimate conclusion, you will be inexorably drawn to
 rediscovering how vtables work and what tradeoffs they embed when
 compared to direct function calls.

No, you misunderstand. I said safely call, not exceptionally efficient. To me a
virtual call would be acceptable. However, at least in my cases, there would
normally not be more than one imlemented interface and such it would be a tiny
vtable.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not exceptionally
 efficient. To me a virtual call would be acceptable. However, at
 least in my cases, there would normally not be more than one
 imlemented interface and such it would be a tiny vtable.

Ok, so the scope is reducing nicely. We now have a few problems to solve 
(some details glossed over for simplicity).

a) Get from void* to the TypeInfo that's typing that void*. This will 
involve a search as the void* could point really anywhere, including 
untyped memory. So we have a core function:

TypeInfo fromAddress(void * p);

b) Starting from a TypeInfo, get an interface in case the underlying 
struct implements that interface:

Object TypeInfo.QueryInterface(TypeInfo someInterface);

c) Finally, given a void* and an interface, invoke a method of that 
interface:

T structCast!(Interface)(p).method(arguments);

where T is the result type of Interface.method.

Is this what you want?


Andrei

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not exceptionally
 efficient. To me a virtual call would be acceptable. However, at
 least in my cases, there would normally not be more than one
 imlemented interface and such it would be a tiny vtable.

 
 Ok, so the scope is reducing nicely. We now have a few problems to solve
 (some details glossed over for simplicity).
 
 a) Get from void* to the TypeInfo that's typing that void*. This will
 involve a search as the void* could point really anywhere, including
 untyped memory. So we have a core function:
 
 TypeInfo fromAddress(void * p);
 
 b) Starting from a TypeInfo, get an interface in case the underlying
 struct implements that interface:
 
 Object TypeInfo.QueryInterface(TypeInfo someInterface);
 
 c) Finally, given a void* and an interface, invoke a method of that
 interface:
 
 T structCast!(Interface)(p).method(arguments);

Since you used template lingo, it looks a bit like compile time functionality,
but yes, very close now :)

Also (I keep forgetting to mention important details) - I typically see this
used in variadic functions, such that the typeinfo already is there.

And an additional question only semi-related to the above; is it possible to
have a function that works as a variadic function, but where the number of
arguments is restricted to 1 (or 2 or 3 but not unbounded).

Oh oh, I'm getting into a steam (and even less related ...) - variadic ref
parameters.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not exceptionally 
 efficient. To me a virtual call would be acceptable. However, at 
 least in my cases, there would normally not be more than one 
 imlemented interface and such it would be a tiny vtable.

 Ok, so the scope is reducing nicely. We now have a few problems to
 solve (some details glossed over for simplicity).
 
 a) Get from void* to the TypeInfo that's typing that void*. This
 will involve a search as the void* could point really anywhere,
 including untyped memory. So we have a core function:
 
 TypeInfo fromAddress(void * p);
 
 b) Starting from a TypeInfo, get an interface in case the
 underlying struct implements that interface:
 
 Object TypeInfo.QueryInterface(TypeInfo someInterface);
 
 c) Finally, given a void* and an interface, invoke a method of that
  interface:
 
 T structCast!(Interface)(p).method(arguments);

 
 Since you used template lingo, it looks a bit like compile time
 functionality, but yes, very close now :)
 
 Also (I keep forgetting to mention important details) - I typically
 see this used in variadic functions, such that the typeinfo already
 is there.

But what are you ultimately trying to accomplish, and why do you must 
lose all static information since it was just available to the caller? 
Isn't there a simpler way to achieve your goal (e.g. using the new 
variadics)? You are essentially asking for full-blown runtime scripting 
for all structs.

 And an additional question only semi-related to the above; is it
 possible to have a function that works as a variadic function, but
 where the number of arguments is restricted to 1 (or 2 or 3 but not
 unbounded).

void foo(R..)(R args) if (R.length == 2)
{
     ...
}

It doesn't work now due to a bug in the compiler, you may want to submit it.

 Oh oh, I'm getting into a steam (and even less related ...) -
 variadic ref parameters.
 

That will be fixed.


Andrei

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not exceptionally
 efficient. To me a virtual call would be acceptable. However, at
 least in my cases, there would normally not be more than one
 imlemented interface and such it would be a tiny vtable.

 Ok, so the scope is reducing nicely. We now have a few problems to
 solve (some details glossed over for simplicity).
 
 a) Get from void* to the TypeInfo that's typing that void*. This
 will involve a search as the void* could point really anywhere,
 including untyped memory. So we have a core function:
 
 TypeInfo fromAddress(void * p);
 
 b) Starting from a TypeInfo, get an interface in case the
 underlying struct implements that interface:
 
 Object TypeInfo.QueryInterface(TypeInfo someInterface);
 
 c) Finally, given a void* and an interface, invoke a method of that
  interface:
 
 T structCast!(Interface)(p).method(arguments);

 
 Since you used template lingo, it looks a bit like compile time
 functionality, but yes, very close now :)
 
 Also (I keep forgetting to mention important details) - I typically
 see this used in variadic functions, such that the typeinfo already
 is there.

 
 But what are you ultimately trying to accomplish, and why do you must
 lose all static information since it was just available to the caller?
 Isn't there a simpler way to achieve your goal (e.g. using the new
 variadics)? You are essentially asking for full-blown runtime scripting
 for all structs.

Sorry; new variadics?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not exceptionally
 efficient. To me a virtual call would be acceptable. However, at
 least in my cases, there would normally not be more than one
 imlemented interface and such it would be a tiny vtable.

 Ok, so the scope is reducing nicely. We now have a few problems to
 solve (some details glossed over for simplicity).

 a) Get from void* to the TypeInfo that's typing that void*. This
 will involve a search as the void* could point really anywhere,
 including untyped memory. So we have a core function:

 TypeInfo fromAddress(void * p);

 b) Starting from a TypeInfo, get an interface in case the
 underlying struct implements that interface:

 Object TypeInfo.QueryInterface(TypeInfo someInterface);

 c) Finally, given a void* and an interface, invoke a method of that
  interface:

 T structCast!(Interface)(p).method(arguments);

 Since you used template lingo, it looks a bit like compile time
 functionality, but yes, very close now :)

 Also (I keep forgetting to mention important details) - I typically
 see this used in variadic functions, such that the typeinfo already
 is there.

 But what are you ultimately trying to accomplish, and why do you must
 lose all static information since it was just available to the caller?
 Isn't there a simpler way to achieve your goal (e.g. using the new
 variadics)? You are essentially asking for full-blown runtime scripting
 for all structs.

 
 Sorry; new variadics?

http://www.digitalmars.com/d/2.0/variadic-function-templates.html

Your use case suggests you are using the "look, ma, no templates" 
solution, whereas the new variadics are shown below that section.


Andrei

Lars Ivar Igesund <larsivar igesund.net> writes:

Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not exceptionally
 efficient. To me a virtual call would be acceptable. However, at
 least in my cases, there would normally not be more than one
 imlemented interface and such it would be a tiny vtable.

 Ok, so the scope is reducing nicely. We now have a few problems to
 solve (some details glossed over for simplicity).

 a) Get from void* to the TypeInfo that's typing that void*. This
 will involve a search as the void* could point really anywhere,
 including untyped memory. So we have a core function:

 TypeInfo fromAddress(void * p);

 b) Starting from a TypeInfo, get an interface in case the
 underlying struct implements that interface:

 Object TypeInfo.QueryInterface(TypeInfo someInterface);

 c) Finally, given a void* and an interface, invoke a method of that
  interface:

 T structCast!(Interface)(p).method(arguments);

 Since you used template lingo, it looks a bit like compile time
 functionality, but yes, very close now :)

 Also (I keep forgetting to mention important details) - I typically
 see this used in variadic functions, such that the typeinfo already
 is there.

 But what are you ultimately trying to accomplish, and why do you must
 lose all static information since it was just available to the caller?
 Isn't there a simpler way to achieve your goal (e.g. using the new
 variadics)? You are essentially asking for full-blown runtime scripting
 for all structs.

 
 Sorry; new variadics?

 
 http://www.digitalmars.com/d/2.0/variadic-function-templates.html
 
 Your use case suggests you are using the "look, ma, no templates"
 solution, whereas the new variadics are shown below that section.

Right,  but the "new variadics" cannot (being templates) be virtual (which at
least sometimes is useful).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:
 
 Lars Ivar Igesund wrote:
 No, you misunderstand. I said safely call, not
 exceptionally efficient. To me a virtual call would be
 acceptable. However, at least in my cases, there would
 normally not be more than one imlemented interface and
 such it would be a tiny vtable.

 Ok, so the scope is reducing nicely. We now have a few
 problems to solve (some details glossed over for
 simplicity).
 
 a) Get from void* to the TypeInfo that's typing that void*.
 This will involve a search as the void* could point really
 anywhere, including untyped memory. So we have a core
 function:
 
 TypeInfo fromAddress(void * p);
 
 b) Starting from a TypeInfo, get an interface in case the 
 underlying struct implements that interface:
 
 Object TypeInfo.QueryInterface(TypeInfo someInterface);
 
 c) Finally, given a void* and an interface, invoke a method
 of that interface:
 
 T structCast!(Interface)(p).method(arguments);

 Since you used template lingo, it looks a bit like compile
 time functionality, but yes, very close now :)
 
 Also (I keep forgetting to mention important details) - I
 typically see this used in variadic functions, such that the
 typeinfo already is there.

 But what are you ultimately trying to accomplish, and why do
 you must lose all static information since it was just
 available to the caller? Isn't there a simpler way to achieve
 your goal (e.g. using the new variadics)? You are essentially
 asking for full-blown runtime scripting for all structs.

 Sorry; new variadics?

 http://www.digitalmars.com/d/2.0/variadic-function-templates.html
 
 Your use case suggests you are using the "look, ma, no templates" 
 solution, whereas the new variadics are shown below that section.

 
 Right,  but the "new variadics" cannot (being templates) be virtual
 (which at least sometimes is useful).

Templates can always forward to non-templates the void* and pointers to 
functions of interest that know how to handle the void*. The new code in 
std.format does that. The solution can be easily extended to forward to 
interfaces that are created and allocated suitably.

Essentially what I'm saying is, if you're asking for a feature there 
should be a reasonably clear picture of the implementation possible 
attacks and of the various consequences of the tradeoffs involved. I 
understand it would be nice to have structs automatically offer 
runtime-queriable interfaces at no per-instance cost, no dynamic 
allocation, and with free bonus miles, but then that's only a 
deceptively little part of the story.


Andrei

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Jason House" wrote
 Andrei Alexandrescu wrote:

 I'd be curious to find out more about a runtime queryable struct
 interface. How would it work? What idioms would it enable?

 I don't know what Lars is thinking of, but I think of struct interfaces as 
 a non-polymorphic / compile-time inheritance.  AKA, you can have a struct 
 implement it, but you can't cast it to a base struct/interface.  Outside 
 of defining the struct, I'd expect it to only be usable in templates and 
 is-expressions

I would expect a struct interface to be castable to the interface. 
Otherwise, you get no benefit from having it.  You can already use 
compile-time interfaces with concepts and templates.

The issue then becomes to make a struct interface act the same as a class 
interface.  Unfortunately, a class interface value only contains a vtable 
pointer (I think), which contains the offset to get to the actual class 
pointer.  If the class pointer was passed with the interface, this would be 
much easier, but might be slower when doing class interfaces (passing 2 
pointers instead of 1).

You could put an interface vtable pointer at the beginning of a struct, 
which then makes every struct carry that extra baggage.  And then a virtual 
call is required, but would allow much more dynamic behavior.

You could build a temporary interface "structure" which does the thunk to 
point to the real struct, since you don't have to deal with possible 
inheritance, to avoid putting a vtable in the struct.

There are probably other ways.

In any case, having struct interfaces probably is not the best method for 
ranges, where you would be doing a virtual call over and over again.  But it 
would be hugely beneficial for things like non-templated I/O, or 
serialization.

One problem to consider is that it is much easier for a struct to escape 
it's scope, so you may have to require a scope parameter to pass a struct as 
an interface.

-Steve 

dsimcha <dsimcha yahoo.com> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Lars Ivar Igesund wrote:
 Andrei Alexandrescu wrote:

 For example, I'm not sure how code in std.algorithm could help
 containers or streams in Tango (as it should), or how to reconcile
 std.algorithm with std.core.array.

 If the language (D2++) will have a new way of iteration and ranges
 known and enforced by the compiler, then I expect Tango to support
 those at some point, and std.algorithm would presumably just work.
 However, if it is based on some interface, ad hoc (these methods must
 be present) or properly via an interface Range { }, I would expect
 Tango developers to be involved in the process of defining those
 interfaces (if Tango is meant to use/know about them). Since I have
 seen neither, it is somewhat difficult to make a well informed
 comment on the subject.

 It's been there for a while now (since 25 Nov 2008).
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 Scroll down to "Foreach over Structs and Classes with Ranges". The
 changelog reflects that too:
 http://www.digitalmars.com/d/2.0/changelog.html
 Version 2.021 mentions "Added range support to foreach statement."
 Andrei

Nice.  Glad to see that this is documented somewhere so I can start playing with
it.  One thing, though:  In my dstats library, I have a custom hash table
implementation that's used very heavily in my information theory module.  (I
have
my reasons for using a custom hash table instead of the builtin, but they're
beyond the scope of this post.)  Right now, the hash table uses opApply.  Now
that
I realize how horribly slow opApply is, I'd like to port this to ranges. 
However,
I need to be able to iterate over either key, value pairs or just values.  Is
there any way to make this work with ranges?

"Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:

On Sun, Jan 18, 2009 at 1:00 PM, dsimcha <dsimcha yahoo.com> wrote:
 Nice.  Glad to see that this is documented somewhere so I can start playing
with
 it.  One thing, though:  In my dstats library, I have a custom hash table
 implementation that's used very heavily in my information theory module.  (I
have
 my reasons for using a custom hash table instead of the builtin, but they're
 beyond the scope of this post.)  Right now, the hash table uses opApply.  Now
that
 I realize how horribly slow opApply is, I'd like to port this to ranges. 
However,
 I need to be able to iterate over either key, value pairs or just values.  Is
 there any way to make this work with ranges?

You could handle key or value iteration by using a proxy struct type
that follows the range protocol, and have your hash table return one
of those structs from methods such as "keysIter" or "valuesIter".  But
unless I'm mistaken, D2 still doesn't support returning tuples, so you
still can't have keys _and_ values at the same time.  (Unless you're
content with using a Pair or something.)

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Jarrett Billingsley wrote:
 On Sun, Jan 18, 2009 at 1:00 PM, dsimcha <dsimcha yahoo.com> wrote:
 Nice.  Glad to see that this is documented somewhere so I can start playing
with
 it.  One thing, though:  In my dstats library, I have a custom hash table
 implementation that's used very heavily in my information theory module.  (I
have
 my reasons for using a custom hash table instead of the builtin, but they're
 beyond the scope of this post.)  Right now, the hash table uses opApply.  Now
that
 I realize how horribly slow opApply is, I'd like to port this to ranges. 
However,
 I need to be able to iterate over either key, value pairs or just values.  Is
 there any way to make this work with ranges?

 
 You could handle key or value iteration by using a proxy struct type
 that follows the range protocol, and have your hash table return one
 of those structs from methods such as "keysIter" or "valuesIter".  But
 unless I'm mistaken, D2 still doesn't support returning tuples, so you
 still can't have keys _and_ values at the same time.  (Unless you're
 content with using a Pair or something.)

Returning a std.typecons.Tuple is entirely possible.

Andrei

BLS <nanali nospam.wanadoo.fr> writes:

Andrei Alexandrescu schrieb:
 Jarrett Billingsley wrote:
 On Sun, Jan 18, 2009 at 1:00 PM, dsimcha <dsimcha yahoo.com> wrote:
 Nice.  Glad to see that this is documented somewhere so I can start 
 playing with
 it.  One thing, though:  In my dstats library, I have a custom hash 
 table
 implementation that's used very heavily in my information theory 
 module.  (I have
 my reasons for using a custom hash table instead of the builtin, but 
 they're
 beyond the scope of this post.)  Right now, the hash table uses 
 opApply.  Now that
 I realize how horribly slow opApply is, I'd like to port this to 
 ranges.  However,
 I need to be able to iterate over either key, value pairs or just 
 values.  Is
 there any way to make this work with ranges?

 You could handle key or value iteration by using a proxy struct type
 that follows the range protocol, and have your hash table return one
 of those structs from methods such as "keysIter" or "valuesIter".  But
 unless I'm mistaken, D2 still doesn't support returning tuples, so you
 still can't have keys _and_ values at the same time.  (Unless you're
 content with using a Pair or something.)

 
 Returning a std.typecons.Tuple is entirely possible.
 
 Andrei

tuple(K,V) foo(K,V)(K k, V v)
{
   ...
}
????, I have no idea, pls help Bjoern

BLS <nanali nospam.wanadoo.fr> writes:

BLS schrieb:
 Andrei Alexandrescu schrieb:
 Jarrett Billingsley wrote:
 On Sun, Jan 18, 2009 at 1:00 PM, dsimcha <dsimcha yahoo.com> wrote:
 Nice.  Glad to see that this is documented somewhere so I can start 
 playing with
 it.  One thing, though:  In my dstats library, I have a custom hash 
 table
 implementation that's used very heavily in my information theory 
 module.  (I have
 my reasons for using a custom hash table instead of the builtin, but 
 they're
 beyond the scope of this post.)  Right now, the hash table uses 
 opApply.  Now that
 I realize how horribly slow opApply is, I'd like to port this to 
 ranges.  However,
 I need to be able to iterate over either key, value pairs or just 
 values.  Is
 there any way to make this work with ranges?

 You could handle key or value iteration by using a proxy struct type
 that follows the range protocol, and have your hash table return one
 of those structs from methods such as "keysIter" or "valuesIter".  But
 unless I'm mistaken, D2 still doesn't support returning tuples, so you
 still can't have keys _and_ values at the same time.  (Unless you're
 content with using a Pair or something.)

 Returning a std.typecons.Tuple is entirely possible.

 Andrei

 
 tuple(K,V) foo(K,V)(K k, V v)
 {
   ...
 }
 ????, I have no idea, pls help Bjoern
 

Look like this works... However it would be nice if we could place the 
alias Tuple Pair stuff outside of foo()
module tt;
import std.stdio;
import std.typecons;

//alias Tuple!(K, "key", V, "value") Pair; This don't work

auto foo(K,V)(K k, V v)
{
	alias Tuple!(K, "key", V, "value") Pair;

   	Pair P;
   	P.key = ++k;
   	P.value = v;

   	return P;
}

void main()
{
	//Pair KV;
	auto KV = foo!(int,string) (10,"Hello");
	writefln("%8s %s\n", KV.key, KV.value);
	
}
This is a really nice feature, guess there are smarter ways to implement 
tuple returns..
Bjoern

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

BLS wrote:
 Look like this works... However it would be nice if we could place the 
 alias Tuple Pair stuff outside of foo()

I'm glad I waited a bit on that one :o). Nice work.

 module tt;
 import std.stdio;
 import std.typecons;
 
 //alias Tuple!(K, "key", V, "value") Pair; This don't work

It doesn't work because at that time the symbols K and V are not 
visible. But this little simplification should work:

template Pair(K, V) {
     alias Tuple!(K, "key", V, "value") Pair;
}


Andrei

BLS <nanali nospam.wanadoo.fr> writes:

Andrei Alexandrescu schrieb:
 BLS wrote:
 Look like this works... However it would be nice if we could place the 
 alias Tuple Pair stuff outside of foo()

 
 I'm glad I waited a bit on that one :o). Nice work.
 
 module tt;
 import std.stdio;
 import std.typecons;

 //alias Tuple!(K, "key", V, "value") Pair; This don't work

 
 It doesn't work because at that time the symbols K and V are not 
 visible. But this little simplification should work:
 
 template Pair(K, V) {
     alias Tuple!(K, "key", V, "value") Pair;
 }
 
 
 Andrei

Thanks :) Would be nice to have a Tuple return sample in the 
std.typecons docs. IMO this a not very well known cool D2 feature.
Bjoern

Daniel Keep <daniel.keep.lists gmail.com> writes:

BLS wrote:
 Andrei Alexandrescu schrieb:
 BLS wrote:
 Look like this works... However it would be nice if we could place
 the alias Tuple Pair stuff outside of foo()

 I'm glad I waited a bit on that one :o). Nice work.

 module tt;
 import std.stdio;
 import std.typecons;

 //alias Tuple!(K, "key", V, "value") Pair; This don't work

 It doesn't work because at that time the symbols K and V are not
 visible. But this little simplification should work:

 template Pair(K, V) {
     alias Tuple!(K, "key", V, "value") Pair;
 }


 Andrei

 Thanks :) Would be nice to have a Tuple return sample in the
 std.typecons docs. IMO this a not very well known cool D2 feature.
 Bjoern

auto cheez()
{
    return tuple(42, "burger");
}

void main()
{
    auto a,b = cheez();
}

http://mine.icanhascheezburger.com/view.aspx?ciid=3163244

  -- Daniel

dsimcha <dsimcha yahoo.com> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Jarrett Billingsley wrote:
 On Sun, Jan 18, 2009 at 1:00 PM, dsimcha <dsimcha yahoo.com> wrote:
 Nice.  Glad to see that this is documented somewhere so I can start playing
with
 it.  One thing, though:  In my dstats library, I have a custom hash table
 implementation that's used very heavily in my information theory module.  (I
have
 my reasons for using a custom hash table instead of the builtin, but they're
 beyond the scope of this post.)  Right now, the hash table uses opApply.  Now



that
 I realize how horribly slow opApply is, I'd like to port this to ranges.



However,
 I need to be able to iterate over either key, value pairs or just values.  Is
 there any way to make this work with ranges?

 You could handle key or value iteration by using a proxy struct type
 that follows the range protocol, and have your hash table return one
 of those structs from methods such as "keysIter" or "valuesIter".  But
 unless I'm mistaken, D2 still doesn't support returning tuples, so you
 still can't have keys _and_ values at the same time.  (Unless you're
 content with using a Pair or something.)

 Returning a std.typecons.Tuple is entirely possible.
 Andrei

So there's no way to do this without requiring any extra boilerplate on the
caller's end, i.e. as cleanly (from the caller's perspective) as opApply?

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-01-18 10:21:55 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 It's been there for a while now (since 25 Nov 2008).
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

	.next 	move the left edge of the range right one
	.retreat 	move the right edge of the range left one

Each time I see this I get annoyed by the dissimilarity of the terms. 
"advance" and "retreat" would be much better words. Even if "advance" 
is three more characters, it carries much better the meaning of what is 
happening; "next" isn't even a verb.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Michel Fortin wrote:
 On 2009-01-18 10:21:55 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 
     .next     move the left edge of the range right one
     .retreat     move the right edge of the range left one
 
 Each time I see this I get annoyed by the dissimilarity of the terms. 
 "advance" and "retreat" would be much better words. Even if "advance" is 
 three more characters, it carries much better the meaning of what is 
 happening; "next" isn't even a verb.

I understand. Next was rather consecrated so we used that one. "Toe" 
comes from the "head to toe" phrase; "tail" would have been nice but its 
meaning in all other languages is "everything but the head".

At the highest level, any nomenclature cannot please everybody.


Andrei

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Michel Fortin (michel.fortin michelf.com)'s article
 On 2009-01-18 10:21:55 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:
 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 	.next 	move the left edge of the range right one
 	.retreat 	move the right edge of the range left one
 Each time I see this I get annoyed by the dissimilarity of the terms.
 "advance" and "retreat" would be much better words. Even if "advance"
 is three more characters, it carries much better the meaning of what is
 happening; "next" isn't even a verb.

advance/retreat or next/prev.  I use the latter in my own code, but
perhaps an abbreviation isn't appropriate here.


Sean

Sergey Gromov <snake.scaly gmail.com> writes:

Sun, 18 Jan 2009 07:21:55 -0800, Andrei Alexandrescu wrote:

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
 
 Scroll down to "Foreach over Structs and Classes with Ranges". The 
 changelog reflects that too:

How do I implement a range that supports more than one pass?  From the
docs, all ranges seem to be essentially Input ranges currently.  That is

MyIterable collection;
foreach (element; collection) {} // OK, iterates
foreach (element; collection) {} // oops, it's empty!

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Sergey Gromov wrote:
 Sun, 18 Jan 2009 07:21:55 -0800, Andrei Alexandrescu wrote:
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The 
 changelog reflects that too:

 
 How do I implement a range that supports more than one pass?  From the
 docs, all ranges seem to be essentially Input ranges currently.  That is
 
 MyIterable collection;
 foreach (element; collection) {} // OK, iterates
 foreach (element; collection) {} // oops, it's empty!

Note that the range is being copied into a hidden variable, so after the 
first iteration the collection will still hold its ground.

Andrei

Sergey Gromov <snake.scaly gmail.com> writes:

Sun, 18 Jan 2009 15:32:26 -0800, Andrei Alexandrescu wrote:

 Sergey Gromov wrote:
 Sun, 18 Jan 2009 07:21:55 -0800, Andrei Alexandrescu wrote:
 
 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The 
 changelog reflects that too:

 
 How do I implement a range that supports more than one pass?  From the
 docs, all ranges seem to be essentially Input ranges currently.  That is
 
 MyIterable collection;
 foreach (element; collection) {} // OK, iterates
 foreach (element; collection) {} // oops, it's empty!

 
 Note that the range is being copied into a hidden variable, so after the 
 first iteration the collection will still hold its ground.

Unless it's a class you mean?

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Sergey Gromov wrote:
 Sun, 18 Jan 2009 15:32:26 -0800, Andrei Alexandrescu wrote:
 
 Sergey Gromov wrote:
 Sun, 18 Jan 2009 07:21:55 -0800, Andrei Alexandrescu wrote:

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 Scroll down to "Foreach over Structs and Classes with Ranges". The 
 changelog reflects that too:

 How do I implement a range that supports more than one pass?  From the
 docs, all ranges seem to be essentially Input ranges currently.  That is

 MyIterable collection;
 foreach (element; collection) {} // OK, iterates
 foreach (element; collection) {} // oops, it's empty!

 Note that the range is being copied into a hidden variable, so after the 
 first iteration the collection will still hold its ground.

 
 Unless it's a class you mean?

Yah, ranges are meant to have value semantics. If you have a class 
container exposing ranges, define the range separately from the 
container itself:

MyIterable collection;
foreach (element; collection.all) {}
foreach (element; collection.all) {}


Andrei

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

Add .opRange so that's not necessary?  Or allow opApply to return a range?
Otherwise it looks like a step backwards.

--bb

dsimcha <dsimcha yahoo.com> writes:

== Quote from Bill Baxter (wbaxter gmail.com)'s article
 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 Add .opRange so that's not necessary?  Or allow opApply to return a range?
 Otherwise it looks like a step backwards.
 --bb

One point of clarification:  opApply isn't going to be deprecated anytime soon,
is
it?  It seems like ranges still have a bunch of rough edges, and although I like
the idea in principle, I'm only willing to convert to ranges if I can define
iterable objects with the same level of syntactic sugar as opApply gives me. 
For
simple cases this is already true and I have begun converting some stuff.
However, for more complicated cases, opApply is still a lot more flexible.

Walter Bright <newshound1 digitalmars.com> writes:

dsimcha wrote:
 One point of clarification:  opApply isn't going to be deprecated anytime
soon, is
 it?  It seems like ranges still have a bunch of rough edges, and although I
like
 the idea in principle, I'm only willing to convert to ranges if I can define
 iterable objects with the same level of syntactic sugar as opApply gives me. 
For
 simple cases this is already true and I have begun converting some stuff.
 However, for more complicated cases, opApply is still a lot more flexible.

opApply isn't going away. For one thing, it works very well with 
recursive data structures.

dsimcha <dsimcha yahoo.com> writes:

== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 One point of clarification:  opApply isn't going to be deprecated anytime
soon, is
 it?  It seems like ranges still have a bunch of rough edges, and although I
like
 the idea in principle, I'm only willing to convert to ranges if I can define
 iterable objects with the same level of syntactic sugar as opApply gives me. 
For
 simple cases this is already true and I have begun converting some stuff.
 However, for more complicated cases, opApply is still a lot more flexible.

 opApply isn't going away. For one thing, it works very well with
 recursive data structures.

So besides performance, what advantages does using ranges instead of opApply for
iteration over structs/classes offer?  According to some testing that I just
finished on the hash table implementation I was talking about earlier today, the
penalty for using opApply is small enough that, if using ranges requires a bunch
of extra bookkeeping overhead that opApply doesn't, then opApply can reasonably
be
faster.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 One point of clarification:  opApply isn't going to be deprecated anytime
soon, is
 it?  It seems like ranges still have a bunch of rough edges, and although I
like
 the idea in principle, I'm only willing to convert to ranges if I can define
 iterable objects with the same level of syntactic sugar as opApply gives me. 
For
 simple cases this is already true and I have begun converting some stuff.
 However, for more complicated cases, opApply is still a lot more flexible.

 opApply isn't going away. For one thing, it works very well with
 recursive data structures.

 
 So besides performance, what advantages does using ranges instead of opApply
for
 iteration over structs/classes offer?  According to some testing that I just
 finished on the hash table implementation I was talking about earlier today,
the
 penalty for using opApply is small enough that, if using ranges requires a
bunch
 of extra bookkeeping overhead that opApply doesn't, then opApply can
reasonably be
 faster.

Speed is a small part of the equation, in fact a perk only. Ranges are 
composable; you can combine them to e.g. do parallel iteration over two 
ranges. Ranges really open std.algorithm to all data structures. I find 
opApply incredibly obtuse and fostering bad design. I wish it goes away.

Andrei

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-01-18 22:00:17 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 dsimcha wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 One point of clarification:  opApply isn't going to be deprecated 
 anytime soon, is
 it?  It seems like ranges still have a bunch of rough edges, and 
 although I like
 the idea in principle, I'm only willing to convert to ranges if I can define
 iterable objects with the same level of syntactic sugar as opApply 
 gives me.  For
 simple cases this is already true and I have begun converting some stuff.
 However, for more complicated cases, opApply is still a lot more flexible.

 opApply isn't going away. For one thing, it works very well with
 recursive data structures.

 
 So besides performance, what advantages does using ranges instead of 
 opApply for
 iteration over structs/classes offer?  According to some testing that I just
 finished on the hash table implementation I was talking about earlier 
 today, the
 penalty for using opApply is small enough that, if using ranges 
 requires a bunch
 of extra bookkeeping overhead that opApply doesn't, then opApply can 
 reasonably be
 faster.

 
 Speed is a small part of the equation, in fact a perk only. Ranges are 
 composable; you can combine them to e.g. do parallel iteration over two 
 ranges. Ranges really open std.algorithm to all data structures. I find 
 opApply incredibly obtuse and fostering bad design. I wish it goes away.
 
 Andrei

But if it goes away, that'd prevent a lot of cool things that could be 
done with foreach. You could create a template that automatically 
distributes iterations to various threads with very little code 
(assuming the loop delegate is pure):

	foreach (i; paralelize(myArray))
		doSomethingComplicated();

All the complexity would lay in the opApply. You can't do this with ranges.

Other possible things involves a rudimentary profiler (checking for the 
elapsed time at each loop iteration), or a progress monitoring template 
(notifying another thread of the progress of a particular task).

	foreach (task; progessUpdater(timeProfiler(listOfTasks)))
	{ ... }

For basic data manipulation algorithms, ranges are better. But for more 
fancy stuff, opApply still rules.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Michel Fortin wrote:
 On 2009-01-18 22:00:17 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 dsimcha wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 One point of clarification:  opApply isn't going to be deprecated 
 anytime soon, is
 it?  It seems like ranges still have a bunch of rough edges, and 
 although I like
 the idea in principle, I'm only willing to convert to ranges if I 
 can define
 iterable objects with the same level of syntactic sugar as opApply 
 gives me.  For
 simple cases this is already true and I have begun converting some 
 stuff.
 However, for more complicated cases, opApply is still a lot more 
 flexible.

 opApply isn't going away. For one thing, it works very well with
 recursive data structures.

 So besides performance, what advantages does using ranges instead of 
 opApply for
 iteration over structs/classes offer?  According to some testing that 
 I just
 finished on the hash table implementation I was talking about earlier 
 today, the
 penalty for using opApply is small enough that, if using ranges 
 requires a bunch
 of extra bookkeeping overhead that opApply doesn't, then opApply can 
 reasonably be
 faster.

 Speed is a small part of the equation, in fact a perk only. Ranges are 
 composable; you can combine them to e.g. do parallel iteration over 
 two ranges. Ranges really open std.algorithm to all data structures. I 
 find opApply incredibly obtuse and fostering bad design. I wish it 
 goes away.

 Andrei

 
 But if it goes away, that'd prevent a lot of cool things that could be 
 done with foreach. You could create a template that automatically 
 distributes iterations to various threads with very little code 
 (assuming the loop delegate is pure):
 
     foreach (i; paralelize(myArray))
         doSomethingComplicated();
 
 All the complexity would lay in the opApply. You can't do this with ranges.

Parallelization crossed my mind too, although in the context of finding 
files in subdirectories recursively. Using foreach for such stuff looks 
cute, maybe too cute. Let's not forget that there is always the option 
of calling a higher-order function:

distribute(myArray, &doSomethingComplicated);

 Other possible things involves a rudimentary profiler (checking for the 
 elapsed time at each loop iteration), or a progress monitoring template 
 (notifying another thread of the progress of a particular task).
 
     foreach (task; progessUpdater(timeProfiler(listOfTasks)))
     { ... }

You can't compose iteration based on opApply. How would progessUpdater 
and timeProfiler look like? This example pretty much transforms your 
argument into mine :o).

 For basic data manipulation algorithms, ranges are better. But for more 
 fancy stuff, opApply still rules.

Depends on how you define "fancy". If "fancy" includes "composable", 
opApply isn't that.


Andrei

dsimcha <dsimcha yahoo.com> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Depends on how you define "fancy". If "fancy" includes "composable",
 opApply isn't that.
 Andrei

Can you give an example of composable ranges, because I'm not sure exactly what
you mean or how it works.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Depends on how you define "fancy". If "fancy" includes "composable",
 opApply isn't that.
 Andrei

 
 Can you give an example of composable ranges, because I'm not sure exactly what
 you mean or how it works.

Given two ranges, iterate both in lockstep.

Andrei

Sergey Gromov <snake.scaly gmail.com> writes:

Mon, 19 Jan 2009 06:15:06 -0800, Andrei Alexandrescu wrote:

 Michel Fortin wrote:
 Other possible things involves a rudimentary profiler (checking for the 
 elapsed time at each loop iteration), or a progress monitoring template 
 (notifying another thread of the progress of a particular task).
 
     foreach (task; progessUpdater(timeProfiler(listOfTasks)))
     { ... }

 
 You can't compose iteration based on opApply. How would progessUpdater 
 and timeProfiler look like? This example pretty much transforms your 
 argument into mine :o).

I think "can't" is a bit strong a statement.  Let's see:

With opApply:

class progressUpdater(Collection)
{
  this(Collection c)
  {
    collection_ = c;
  }
  
  int opApply(int delegate(ref ElementType!(Collection)) dg)
  {
    composed_ = dg;
    return collection_.opApply(&fancifier);
  }
  
  private:
  
  int fancifier(ref ElementType!(Collection) el)
  {
    globalOnProgress();
    return composed_(el);
  }
  
  Collection collection_;
  int delegate(ref ElementType!(Collection)) composed_;
}

With ranges:

struct progressUpdater(Collection)
{
  this(Collection c)
  {
    collection_ = c;
  }
  
  typeof(collection_.head) head()
  {
    return collection_.head;
  }
  
  void next()
  {
    globalOnProgress();
    collection_.next();
  }
  
  bool empty()
  {
    return collection_.empty;
  }
  
  private Collection collection_;
}

Cannot see anything impossible with both.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Sergey Gromov wrote:
 Mon, 19 Jan 2009 06:15:06 -0800, Andrei Alexandrescu wrote:
 
 Michel Fortin wrote:
 Other possible things involves a rudimentary profiler (checking for the 
 elapsed time at each loop iteration), or a progress monitoring template 
 (notifying another thread of the progress of a particular task).

     foreach (task; progessUpdater(timeProfiler(listOfTasks)))
     { ... }

 You can't compose iteration based on opApply. How would progessUpdater 
 and timeProfiler look like? This example pretty much transforms your 
 argument into mine :o).

 
 I think "can't" is a bit strong a statement.  Let's see:
 
 With opApply:
 
 class progressUpdater(Collection)
 {
   this(Collection c)
   {
     collection_ = c;
   }
   
   int opApply(int delegate(ref ElementType!(Collection)) dg)
   {
     composed_ = dg;
     return collection_.opApply(&fancifier);
   }
   
   private:
   
   int fancifier(ref ElementType!(Collection) el)
   {
     globalOnProgress();
     return composed_(el);
   }
   
   Collection collection_;
   int delegate(ref ElementType!(Collection)) composed_;
 }

I see. Very ingenious! Reversed flow of control all the way. Thanks.

Andrei

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-01-19 18:11:15 -0500, Sergey Gromov <snake.scaly gmail.com> said:

 I think "can't" is a bit strong a statement.  Let's see:
 
 With opApply:
 
 class progressUpdater(Collection)
 {
   this(Collection c)
   {
     collection_ = c;
   }
 
   int opApply(int delegate(ref ElementType!(Collection)) dg)
   {
     composed_ = dg;
     return collection_.opApply(&fancifier);
   }
 
   private:
 
   int fancifier(ref ElementType!(Collection) el)
   {
     globalOnProgress();
     return composed_(el);
   }
 
   Collection collection_;
   int delegate(ref ElementType!(Collection)) composed_;
 }

I think it's the same as this:


class progressUpdater(Collection)
{
  this(Collection c)
  {
    collection_ = c;
  }

  int opApply(int delegate(ref ElementType!(Collection)) dg)
  {
    int fancifier(ref ElementType!(Collection) el)
    {
      globalOnProgress();
      return composed_(el);
    }

    composed_ = dg;
    return collection_.opApply(&fancifier);
  }

  private:

  Collection collection_;
}


Or this:


class progressUpdater(Collection)
{
  this(Collection c)
  {
    collection_ = c;
  }

  int opApply(int delegate(ref ElementType!(Collection)) dg)
  {
	foreach(ref ElementType!(Collection) el; collection_)
    {
      globalOnProgress();
      if (dg(el))
        return 1;
    }
    return 0;
  }

  private:

  Collection collection_;
}


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Sergey Gromov <snake.scaly gmail.com> writes:

Thu, 22 Jan 2009 21:53:02 -0500, Michel Fortin wrote:

 On 2009-01-19 18:11:15 -0500, Sergey Gromov <snake.scaly gmail.com> said:
 
 I think "can't" is a bit strong a statement.  Let's see:
 
 With opApply:
 
 class progressUpdater(Collection)
 {
   this(Collection c)
   {
     collection_ = c;
   }
 
   int opApply(int delegate(ref ElementType!(Collection)) dg)
   {
     composed_ = dg;
     return collection_.opApply(&fancifier);
   }
 
   private:
 
   int fancifier(ref ElementType!(Collection) el)
   {
     globalOnProgress();
     return composed_(el);
   }
 
   Collection collection_;
   int delegate(ref ElementType!(Collection)) composed_;
 }

 
 I think it's the same as this:
 
 class progressUpdater(Collection)
 {
   this(Collection c)
   {
     collection_ = c;
   }
 
   int opApply(int delegate(ref ElementType!(Collection)) dg)
   {
     int fancifier(ref ElementType!(Collection) el)
     {
       globalOnProgress();
       return composed_(el);
     }
 
     composed_ = dg;
     return collection_.opApply(&fancifier);
   }
 
   private:
 
   Collection collection_;
 }
 
 Or this:
 
 class progressUpdater(Collection)
 {
   this(Collection c)
   {
     collection_ = c;
   }
 
   int opApply(int delegate(ref ElementType!(Collection)) dg)
   {
 	foreach(ref ElementType!(Collection) el; collection_)
     {
       globalOnProgress();
       if (dg(el))
         return 1;
     }
     return 0;
   }
 
   private:
 
   Collection collection_;
 }

Or even this:

class progressUpdater(Collection)
{
  this(Collection c)
  {
    collection_ = c;
  }

  int opApply(int delegate(ref ElementType!(Collection)) dg)
  {
    return collection_.opApply(
      (ref ElementType!(Collection) el)
      {
        globalOnProgress();
        return dg(el);
      }
      );
  }

  private Collection collection_;
}

Jason House <jason.james.house gmail.com> writes:

Andrei Alexandrescu wrote:

 Speed is a small part of the equation, in fact a perk only. Ranges are
 composable; you can combine them to e.g. do parallel iteration over two
 ranges. Ranges really open std.algorithm to all data structures. I find
 opApply incredibly obtuse and fostering bad design. I wish it goes away.

I'd really hate to see opApply go away.  I'm glad Walter says it's sticking
around ;)

opApply is really nice in how *simple* it is to write.  I think it's possible
to use druntime's fibers to convert an opApply implementation into a range
implementation.  It'd be an interesting challenge to write a templated struct
that handles all of this.  Once that is done, maybe someone could discuss using
Fibers to implement opApply in D2.  I suspect the code inside an opApply would
only change a little bit and it'd allow iteration over multiple "ranges" at the
same time.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Jason House wrote:
 Andrei Alexandrescu wrote:
 
 Speed is a small part of the equation, in fact a perk only. Ranges
 are composable; you can combine them to e.g. do parallel iteration
 over two ranges. Ranges really open std.algorithm to all data
 structures. I find opApply incredibly obtuse and fostering bad
 design. I wish it goes away.

 
 I'd really hate to see opApply go away.  I'm glad Walter says it's
 sticking around ;)

I know. Its popularity is part of what makes it dangerous. It's to good 
programming what fast food is to food :o).

 opApply is really nice in how *simple* it is to write.  I think it's
 possible to use druntime's fibers to convert an opApply
 implementation into a range implementation.  It'd be an interesting
 challenge to write a templated struct that handles all of this.  Once
 that is done, maybe someone could discuss using Fibers to implement
 opApply in D2.  I suspect the code inside an opApply would only
 change a little bit and it'd allow iteration over multiple "ranges"
 at the same time.

But that's making the mythical bear dance. Iterating over multiple 
ranges is only one example. How do you feed one range to another range 
with opApply?

At the end of the day, if what you want is to iterate, you need to 
define what the state of iteration is, how to make a step, and how to 
get to the current element being iterated. That is a good design, not 
opApply and fibers!


Andrei

Jason House <jason.james.house gmail.com> writes:

Andrei Alexandrescu wrote:

 Jason House wrote:
 Andrei Alexandrescu wrote:
 
 Speed is a small part of the equation, in fact a perk only. Ranges
 are composable; you can combine them to e.g. do parallel iteration
 over two ranges. Ranges really open std.algorithm to all data
 structures. I find opApply incredibly obtuse and fostering bad
 design. I wish it goes away.

 
 I'd really hate to see opApply go away.  I'm glad Walter says it's
 sticking around ;)

 
 I know. Its popularity is part of what makes it dangerous. It's to good
 programming what fast food is to food :o).
 
 opApply is really nice in how *simple* it is to write.  I think it's
 possible to use druntime's fibers to convert an opApply
 implementation into a range implementation.  It'd be an interesting
 challenge to write a templated struct that handles all of this.  Once
 that is done, maybe someone could discuss using Fibers to implement
 opApply in D2.  I suspect the code inside an opApply would only
 change a little bit and it'd allow iteration over multiple "ranges"
 at the same time.

 
 But that's making the mythical bear dance. Iterating over multiple
 ranges is only one example. How do you feed one range to another range
 with opApply?
 
 At the end of the day, if what you want is to iterate, you need to
 define what the state of iteration is, how to make a step, and how to
 get to the current element being iterated. That is a good design, not
 opApply and fibers!
 
 
 Andrei

Are you saying that nobody should ever use coroutines?  A coroutine version of
opApply keeps the state of iteration as part of the natural flow of making
steps and getting the current element being iterated.  Let's look at various
implementation examples:

current opApply style:

int opApply(int delegate( ref T ) dg){
  int unknown;
  foreach(i; 0..length){
    unknown = dg(arr[i]);
    if (unknown != 0)
      return unknown;
  }
  return 0;
}

With coroutine:

void iterateOverArray(T)(T[] arr){
  foreach (i; 0..arr.length)
    yield(arr[i]);
}

... or maybe something more complex like the following is required?

void iterateOverArray(T)(T[] arr){
  foreach (i; 0..arr.length){
    yield!("empty") = false;
    yield!("next") = arr[i];
  }
  yield!("empty") = true;
}


A range-based struct:

struct arrayIterator(T){
  int _i;
  T[] _arr;
  this(T[] arr){
    arr = _arr;
  }
  T next(){
    return arr[i++];
  }
  bool empty{
    return i<_arr.length;
  }
}

Here are the line counts for the above implementations:
current opApply style: 9
coroutine with implied empty: 4
coroutine with explicit empty: 7
range-based: 13

Which one would D users want to write?  Personally, I want the coroutine with
implied empty.  I could see having to explicitly state empty or at least
specify when it changes.  If the above examples don't convince you that D
should consider allowing alternate implementations to basic range structs, then
I'll stop trying to convince you.  

dsimcha <dsimcha yahoo.com> writes:

== Quote from Jason House (jason.james.house gmail.com)'s article
 Andrei Alexandrescu wrote:
 Jason House wrote:
 Andrei Alexandrescu wrote:

 Speed is a small part of the equation, in fact a perk only. Ranges
 are composable; you can combine them to e.g. do parallel iteration
 over two ranges. Ranges really open std.algorithm to all data
 structures. I find opApply incredibly obtuse and fostering bad
 design. I wish it goes away.

 I'd really hate to see opApply go away.  I'm glad Walter says it's
 sticking around ;)

 I know. Its popularity is part of what makes it dangerous. It's to good
 programming what fast food is to food :o).

 opApply is really nice in how *simple* it is to write.  I think it's
 possible to use druntime's fibers to convert an opApply
 implementation into a range implementation.  It'd be an interesting
 challenge to write a templated struct that handles all of this.  Once
 that is done, maybe someone could discuss using Fibers to implement
 opApply in D2.  I suspect the code inside an opApply would only
 change a little bit and it'd allow iteration over multiple "ranges"
 at the same time.

 But that's making the mythical bear dance. Iterating over multiple
 ranges is only one example. How do you feed one range to another range
 with opApply?

 At the end of the day, if what you want is to iterate, you need to
 define what the state of iteration is, how to make a step, and how to
 get to the current element being iterated. That is a good design, not
 opApply and fibers!


 Andrei

 Are you saying that nobody should ever use coroutines?  A coroutine version of

opApply keeps the state of iteration as part of the natural flow of making steps
and getting the current element being iterated.  Let's look at various
implementation examples:
 current opApply style:
 int opApply(int delegate( ref T ) dg){
   int unknown;
   foreach(i; 0..length){
     unknown = dg(arr[i]);
     if (unknown != 0)
       return unknown;
   }
   return 0;
 }
 With coroutine:
 void iterateOverArray(T)(T[] arr){
   foreach (i; 0..arr.length)
     yield(arr[i]);
 }
 ... or maybe something more complex like the following is required?
 void iterateOverArray(T)(T[] arr){
   foreach (i; 0..arr.length){
     yield!("empty") = false;
     yield!("next") = arr[i];
   }
   yield!("empty") = true;
 }
 A range-based struct:
 struct arrayIterator(T){
   int _i;
   T[] _arr;
   this(T[] arr){
     arr = _arr;
   }
   T next(){
     return arr[i++];
   }
   bool empty{
     return i<_arr.length;
   }
 }
 Here are the line counts for the above implementations:
 current opApply style: 9
 coroutine with implied empty: 4
 coroutine with explicit empty: 7
 range-based: 13
 Which one would D users want to write?  Personally, I want the coroutine with

implied empty.  I could see having to explicitly state empty or at least specify
when it changes.  If the above examples don't convince you that D should
consider
allowing alternate implementations to basic range structs, then I'll stop trying
to convince you.

Yeah, but we also want decent performance and even compared to opApply,
coroutines/fibers are slow as molasses in January at the North Pole during the
last Ice Age.

Christopher Wright <dhasenan gmail.com> writes:

Jason House wrote:
 void iterateOverArray(T)(T[] arr){
   foreach (i; 0..arr.length)
     yield(arr[i]);
 }

Coroutines are the slowest option, but the easiest to write. It takes 32 
instructions or so to switch to or from a coroutine on x86. I'm not sure 
how that translates in terms of memory usage, though. A delegate is 
reasonably fast. A range struct's methods can be inlined (though opApply 
could be, too, in some cases).

However, any collection library using polymorphism will have to use 
polymorphic iterators. This means you probably won't get any benefit in 
terms of speed from using ranges -- quite the opposite. But there are 
benefits.

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

 I know. Its popularity is part of what makes it dangerous. It's to good 
 programming what fast food is to food :o).

I think that's a false analogy: fast food kills you slowly, while experience
shows me that in many programs a significant (large) percentage of lines of
code don't need to be a the top performance.

So a good thing to do in such parts is to use the most handy, easy to remember,
safer (as in anti-bug-prone), and short syntax/semantics you have. In the other
small percentage of the code where performance is all important and/or you need
full flexibility, you can tolerate something less easy to remember and harder
to understand syntax/semantics (that you may also need to look into the docs if
you don't know how to write).

This may lead to have two different syntaxes/solutions in the D2 language.
Duplication is generally bad. But if the first syntax/solution is simple enough
(like, simpler than the current opApply, that I have to look up each time
despite using it often), then the summed complexity of both solutions isn't
much bigger than the complexity of the second solution alone :-)

So I think having a syntax simpler than the opApply plus a full ranged syntax
can be acceptable. The simpler syntax may look for example more or less like
this (as you can see there is very little noise and very little to remember):

struct DoubleRange(int n) {
  int opIter() {
    for (int i; i < n; i++)
      yield(i * 2);
    yield(1000);
  }
}

The following handy lazy iterable may even become syntactic sugar for the
struct I have just shown, as you can see even less noise, for a really common
programming pattern:

yield int doubleRange(int n) {
  for (int i; i < n; i++)
    yield(i * 2);
  yield(1000);
}

Currently with my libs you have to write the following, that is less nice (and
it's not compiler-supported, so it's probably slower than necessary) (idea
adapted and modified from Witold Baryluk):
http://www.fantascienza.net/leonardo/so/dlibs/generators.html

struct DoubleRange(int n) {
  void generator() {
    for (int i; i < n; i++)
      yield(i * 2);
    yield(1000);
  }  
  mixin Generator!(int);
}

Bye,
bearophile

Sean Kelly <sean invisibleduck.org> writes:

== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Andrei Alexandrescu:
 I know. Its popularity is part of what makes it dangerous. It's to good
 programming what fast food is to food :o).

 I think that's a false analogy: fast food kills you slowly, while experience
shows me that in many programs a significant

(large) percentage of lines of code don't need to be a the top performance.
 So a good thing to do in such parts is to use the most handy, easy to
remember, safer (as in anti-bug-prone), and short

syntax/semantics you have. In the other small percentage of the code where
performance is all important and/or you need full
flexibility, you can tolerate something less easy to remember and harder to
understand syntax/semantics (that you may also
need to look into the docs if you don't know how to write).

This assumes that the easy approach is slow and the fast approach is
complex.  I'd hope that we could find something that's both easy and
fast :-)


Sean

bearophile <bearophileHUGS lycos.com> writes:

Sean Kelly:
 This assumes that the easy approach is slow and the fast approach is
 complex.  I'd hope that we could find something that's both easy and
 fast :-)

I agree that certain times it's possible to have something that is both simple,
safe, short and fast (but if that yield can be used for parallel iterations,
then it may become slowish).

But here there's another thing to consider: you may also want something quite
flexible (see the complexity of Range). This is very difficult to do, that's
why I have suggested two syntaxes, one simpler than opApply that requires you
no brain to use it, plus the Range syntax developed so far (that may need small
improvements but I doubt I'll ever be able to improve a lot, because Alex is
good).

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 == Quote from Bill Baxter (wbaxter gmail.com)'s article
 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 Add .opRange so that's not necessary?  Or allow opApply to return a range?
 Otherwise it looks like a step backwards.
 --bb

 
 One point of clarification:  opApply isn't going to be deprecated anytime
soon, is
 it?

I hope to be able to deprecate it.

 It seems like ranges still have a bunch of rough edges, and although I like
 the idea in principle, I'm only willing to convert to ranges if I can define
 iterable objects with the same level of syntactic sugar as opApply gives me. 
For
 simple cases this is already true and I have begun converting some stuff.
 However, for more complicated cases, opApply is still a lot more flexible.

Ranges do have a number of rough edges, and IMHO the best way to address 
those is to improve ranges, not keep opApply.


Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Bill Baxter wrote:
 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 
 Add .opRange so that's not necessary?  Or allow opApply to return a range?
 Otherwise it looks like a step backwards.

Why is it a step backwards? A given container may define a number of 
ranges. Arrays are deceivingly simple because they have one obvious way 
of iteration, but even for them you'd have to write:

int[] a;
foreach (element; a.retro) { ... }


Andrei

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Jan 19, 2009 at 11:54 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class
 container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 Add .opRange so that's not necessary?  Or allow opApply to return a range?
 Otherwise it looks like a step backwards.

 Why is it a step backwards? A given container may define a number of ranges.
 Arrays are deceivingly simple because they have one obvious way of
 iteration, but even for them you'd have to write:

 int[] a;
 foreach (element; a.retro) { ... }

It's a step backwards because with opApply we can define a default
forward iteration scheme that works like so:
   foreach(element; a) { ... }

Now you're saying that'll still work for structs, but for classes
folks will have to use some other convention like .all.  I also
presume built-ins like arrays still won't require you to use "a.all"
to do a basic forward foreach iteration.  If it will, I suppose I
could live with that.  As long as the rules are consistent and don't
make class-based  containters into second class citizens requiring
different syntax.

But there's really no technical reason why we can't have the simpler
syntax work.  As a class writer I would also find myself very tempted
to provide an opApply just to enable that simpler syntax for users,
assuming you stick to your guns and require something like .all to use
ranges.

--bb

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Andrei Alexandrescu" wrote
 Bill Baxter wrote:
 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class 
 container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 Add .opRange so that's not necessary?  Or allow opApply to return a 
 range?
 Otherwise it looks like a step backwards.

 Why is it a step backwards? A given container may define a number of 
 ranges. Arrays are deceivingly simple because they have one obvious way of 
 iteration, but even for them you'd have to write:

 int[] a;
 foreach (element; a.retro) { ... }

I have to side with the others on this.   foreach(element; collection) is so 
damned intuitive ("for each element in a collection"), it should at least 
try to call a default range function first, before trying to use collection 
as a range.  I'm for having opRange, and ditching opApply.  I don't really 
see the need for opApply (and I used a lot of forwarding opApply calls in 
dcollections, so I'll probably have to rewrite that now!).  You could also 
write cool things like (for instance in a string-indexed collection):

foreach(element; collection["a".."m"])

instead of

foreach(element; collection["a".."m"].all)

While we're on the subject of ditching, can we get rid of foreach_reverse? 
How hard is it for a range to just have a reverse property:

foreach(element; myrange.reverse)

Which simply reverses the order of traversal?  That also would moot the 
toe/last/tail/etc. debate ;)

-Steve 

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Bill Baxter wrote:
 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class 
 container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 Add .opRange so that's not necessary?  Or allow opApply to return a 
 range?
 Otherwise it looks like a step backwards.

 Why is it a step backwards? A given container may define a number of 
 ranges. Arrays are deceivingly simple because they have one obvious way of 
 iteration, but even for them you'd have to write:

 int[] a;
 foreach (element; a.retro) { ... }

 
 I have to side with the others on this.   foreach(element; collection) is so 
 damned intuitive ("for each element in a collection"), it should at least 
 try to call a default range function first, before trying to use collection 
 as a range.  I'm for having opRange, and ditching opApply.  I don't really 
 see the need for opApply (and I used a lot of forwarding opApply calls in 
 dcollections, so I'll probably have to rewrite that now!).  You could also 
 write cool things like (for instance in a string-indexed collection):
 
 foreach(element; collection["a".."m"])
 
 instead of
 
 foreach(element; collection["a".."m"].all)

Ok, I understand.

 While we're on the subject of ditching, can we get rid of foreach_reverse? 
 How hard is it for a range to just have a reverse property:
 
 foreach(element; myrange.reverse)
 
 Which simply reverses the order of traversal?  That also would moot the 
 toe/last/tail/etc. debate ;)

I wish that debate went away. But eliminating toe and retreat would 
require requiring .reverse as a primitive for *all* ranges, which is 
wasteful and repetitive. Instead, a better design is to have ranges 
(those that can) offer toe and retreat primitives such that a generic 
function retro offers backward iteration for any range. In addition, 
certain algorithms (such as the one that reverses a range in place) need 
to manipulate the same range from two ends. Implementing them using 
.reverse and a second range would be more difficult.

Andrei

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 While we're on the subject of ditching, can we get rid of 
 foreach_reverse? How hard is it for a range to just have a reverse 
 property:

 foreach(element; myrange.reverse)

 Which simply reverses the order of traversal?  That also would moot the 
 toe/last/tail/etc. debate ;)

 I wish that debate went away. But eliminating toe and retreat would 
 require requiring .reverse as a primitive for *all* ranges, which is 
 wasteful and repetitive. Instead, a better design is to have ranges (those 
 that can) offer toe and retreat primitives such that a generic function 
 retro offers backward iteration for any range. In addition, certain 
 algorithms (such as the one that reverses a range in place) need to 
 manipulate the same range from two ends. Implementing them using .reverse 
 and a second range would be more difficult.

I didn't say you couldn't provide toe and retreat in Phobos' ranges (for the 
reverse-a-range function).  Most likely such an algorithm is not using 
foreach and foreach_reverse, but using the functions directly.

My point was, foreach_reverse is an eyesore and a hack, and there really is 
no need for it.  And what a perfect time to get rid of it, since we are 
already changing how foreach works ;)

I realize that this wouldn't really kill the toe debate for Phobos, but at 
least it would be a library decision, and not part of the compiler.

-Steve 

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 While we're on the subject of ditching, can we get rid of 
 foreach_reverse? How hard is it for a range to just have a reverse 
 property:

 foreach(element; myrange.reverse)

 Which simply reverses the order of traversal?  That also would moot the 
 toe/last/tail/etc. debate ;)

 I wish that debate went away. But eliminating toe and retreat would 
 require requiring .reverse as a primitive for *all* ranges, which is 
 wasteful and repetitive. Instead, a better design is to have ranges (those 
 that can) offer toe and retreat primitives such that a generic function 
 retro offers backward iteration for any range. In addition, certain 
 algorithms (such as the one that reverses a range in place) need to 
 manipulate the same range from two ends. Implementing them using .reverse 
 and a second range would be more difficult.

 
 I didn't say you couldn't provide toe and retreat in Phobos' ranges (for the 
 reverse-a-range function).  Most likely such an algorithm is not using 
 foreach and foreach_reverse, but using the functions directly.
 
 My point was, foreach_reverse is an eyesore and a hack, and there really is 
 no need for it.  And what a perfect time to get rid of it, since we are 
 already changing how foreach works ;)
 
 I realize that this wouldn't really kill the toe debate for Phobos, but at 
 least it would be a library decision, and not part of the compiler.

Yah, that makes sense. I vote for foreach_reverse to go away, too.

Andrei

aarti_pl <aarti interia.pl> writes:

Andrei Alexandrescu pisze:
 Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 While we're on the subject of ditching, can we get rid of 
 foreach_reverse? How hard is it for a range to just have a reverse 
 property:

 foreach(element; myrange.reverse)

 Which simply reverses the order of traversal?  That also would moot 
 the toe/last/tail/etc. debate ;)

 I wish that debate went away. But eliminating toe and retreat would 
 require requiring .reverse as a primitive for *all* ranges, which is 
 wasteful and repetitive. Instead, a better design is to have ranges 
 (those that can) offer toe and retreat primitives such that a generic 
 function retro offers backward iteration for any range. In addition, 
 certain algorithms (such as the one that reverses a range in place) 
 need to manipulate the same range from two ends. Implementing them 
 using .reverse and a second range would be more difficult.

 I didn't say you couldn't provide toe and retreat in Phobos' ranges 
 (for the reverse-a-range function).  Most likely such an algorithm is 
 not using foreach and foreach_reverse, but using the functions directly.

 My point was, foreach_reverse is an eyesore and a hack, and there 
 really is no need for it.  And what a perfect time to get rid of it, 
 since we are already changing how foreach works ;)

 I realize that this wouldn't really kill the toe debate for Phobos, 
 but at least it would be a library decision, and not part of the 
 compiler.

 
 Yah, that makes sense. I vote for foreach_reverse to go away, too.
 
 Andrei

vote++

BR
Marcin Kuszczak
(aarti_pl)

Sergey Gromov <snake.scaly gmail.com> writes:

Mon, 19 Jan 2009 09:47:14 +0900, Bill Baxter wrote:

 On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Unless it's a class you mean?

 Yah, ranges are meant to have value semantics. If you have a class container
 exposing ranges, define the range separately from the container itself:

 MyIterable collection;
 foreach (element; collection.all) {}
 foreach (element; collection.all) {}

 
 Add .opRange so that's not necessary?  Or allow opApply to return a range?
 Otherwise it looks like a step backwards.

I already proposed that foreach should first try collection.opSlice()
and work with that if successful, otherwise resort to iterating over the
collection itself.  You would probably implement opSlice anyway so this
solution comes at little cost.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Andrei Alexandrescu" wrote
 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

Strange that I never noticed that.  I remember when 2.022 came out, I did 
not see it there, but I guess I could have overlooked it.  It definitely was 
not there when 2.021 came out (I remember many people asking for docs on it, 
including myself).

One question, it mentions that you must define all 5 properties.  In the 
case where you are only going to use foreach (and not foreach_reverse) on a 
struct, is it still required that you implement toe and retreat?  If not, 
then that probably should be mentioned in the docs.

-Steve 

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 
 Strange that I never noticed that.  I remember when 2.022 came out, I did 
 not see it there, but I guess I could have overlooked it.  It definitely was 
 not there when 2.021 came out (I remember many people asking for docs on it, 
 including myself).
 
 One question, it mentions that you must define all 5 properties.  In the 
 case where you are only going to use foreach (and not foreach_reverse) on a 
 struct, is it still required that you implement toe and retreat?  If not, 
 then that probably should be mentioned in the docs.

Yah, only the minimum is required. Walter should change the docs :o).

Andrei

IUnknown <a b.com> writes:

Whoa. Toe is really silly. I really don't think its a good name. 

begin/ end OR head/tail OR first / last 
next / prev or advance/ retreat like someone suggested. 

Regarding Phobos + Tango, the minimum I expect is things like containers,
algorithm and common math stuff to be in one core module. And these containers
should be used in both standard and any other libraries. Things like I/O can
have different interfaces to use based on the requirement. 

People have similar problems with OpenGL. No one single location for all
documentation (until recently). Multiple competing ways to do things for
different hardware vendors. Multiple core OpenGL methods to achieve the same
thing. And we have lots of people unable to find which one to use for the best
performance. Direct3D on the other hand has been becoming more streamlined and
centralized. 

How about asking your peers who have successful languages how good an idea this
is? I'm interested to know if only us mortals are not getting it or do people
like Steve Yegge, Steve McConnell, Andy Hunt, Dave Thomas also think its not a
problem to start of a language like this.
 
Just to be clear, I have the utmost respect for each of your skills and
expertise. But I think you guys really underestimate and do not like to focus
on things like presentation and easy communication which are very essential for
spreading software. Your technical goals for D are just great but then so
should the way you deliver it. (I also appreciate that you are giving this away
for free, so I'm not really demanding anything!) 

For peers at my level (4 years experience) I see a lot of uneasiness in trying
out something like D mostly due to reasons like this. 


Andrei Alexandrescu Wrote:

 Michel Fortin wrote:
 On 2009-01-18 10:21:55 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

 
     .next     move the left edge of the range right one
     .retreat     move the right edge of the range left one
 
 Each time I see this I get annoyed by the dissimilarity of the terms. 
 "advance" and "retreat" would be much better words. Even if "advance" is 
 three more characters, it carries much better the meaning of what is 
 happening; "next" isn't even a verb.

 
 I understand. Next was rather consecrated so we used that one. "Toe" 
 comes from the "head to toe" phrase; "tail" would have been nice but its 
 meaning in all other languages is "everything but the head".
 
 At the highest level, any nomenclature cannot please everybody.
 
 
 Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on 
how e.g. containers should look like (Java-style vs. STL-style). Which 
should be chosen? This naturally influences how algorithms are defined.


Andrei

IUnknown <a b.com> writes:

Agree. Which is why I said the problems you are facing seem to be
non-technical. I'm suggesting that the D library developers should pick one and
axe the other. *I* think what more important is to have one single set of
containers in a single style rather than have two separate ones. There is going
to be complaining for sure from the current developers, but in my opinion, the
target of having a single standard library (with core and advanced modules to
suit system/ app programming) is more important than having to make a difficult
choice. 

In other languages/ developer communities, the developers would present the two
alternatives with all the pros and cons on a web page (not email) and the
powers that be should vote on it, make the decision and move on with it. 

You already have this "divide" in C++ on how lots of people won't contribute to
a project unless it employs boost and on the other end you have people who have
not even heard of it or thing its too heavy for the project. The problem is
different here, but it might end up fragmenting the small community. 

D attempts to solve a lot of problems and I think it does it pretty well. There
might be a chance some mistakes creep in -- the "wrong" style might be picked.
It won't be a bigger problem than having two separate libraries IMHO. 

This is why I request you to consult other independent people and see what
their take on it is. From a library developer's perspective you would
invariably pit the decision against the difficulty in doing it. Hence my
suggestion to find out what users would really need and then try to implement
it. 

Andrei Alexandrescu Wrote:

 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

 
 This is already bound to be an issue because there is disagreement on 
 how e.g. containers should look like (Java-style vs. STL-style). Which 
 should be chosen? This naturally influences how algorithms are defined.
 
 
 Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

IUnknown wrote:
 This is why I request you to consult other independent people and see
 what their take on it is. From a library developer's perspective you
 would invariably pit the decision against the difficulty in doing it.
 Hence my suggestion to find out what users would really need and then
 try to implement it.

This I completely disagree with. 360 degrees :o). Good stuff comes from 
good vision, not from doing what people think they want (see PHP, 
American cars, and taking dating advice from female friends). I won't 
continue this because it will go the way philosophical debates usually 
go => a long exchange of long messages leading to nowhere in particular.

Andrei

IUnknown <a b.com> writes:

Andrei Alexandrescu Wrote:
 This I completely disagree with. 360 degrees :o). 

You mean 180? :D

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

IUnknown wrote:
 Andrei Alexandrescu Wrote:
 This I completely disagree with. 360 degrees :o). 

 
 You mean 180? :D

The smiley should have given the joke away.

Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 IUnknown wrote:
 
 This is why I request you to consult other independent people and see
 what their take on it is. From a library developer's perspective you
 would invariably pit the decision against the difficulty in doing it.
 Hence my suggestion to find out what users would really need and then
 try to implement it.
 

 This I completely disagree with. 360 degrees :o). Good stuff comes
 from good vision, not from doing what people think they want (see PHP,
 American cars, and taking dating advice from female friends). I won't
 continue this because it will go the way philosophical debates usually
 go => a long exchange of long messages leading to nowhere in
 particular.
 
 Andrei
 


Oversimplification.  Good stuff does not always come from good vision if 
it is poorly managed.


IUnknown had a fair point that you had the option of taking or leaving.  
The suggestion was to look for advice for a problem to which you admitted 
having no solution.


Obviously, you needn't take the advice.  But reinterpreting his statement 
to a form that is absurd is not fair.  You could have just as easily
interpreted 
him as saying, "look over some historical examples and see if there are similar 
solutions to this problem from another's perspective".


The philosophical debate is completely optional.   On the other hand, a
practical 
one is always available. :-D


-JJR

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

John Reimer wrote:
 Hello Andrei,
 
 IUnknown wrote:

 This is why I request you to consult other independent people and see
 what their take on it is. From a library developer's perspective you
 would invariably pit the decision against the difficulty in doing it.
 Hence my suggestion to find out what users would really need and then
 try to implement it.

 This I completely disagree with. 360 degrees :o). Good stuff comes
 from good vision, not from doing what people think they want (see PHP,
 American cars, and taking dating advice from female friends). I won't
 continue this because it will go the way philosophical debates usually
 go => a long exchange of long messages leading to nowhere in
 particular.

 Andrei

 
 
 Oversimplification.  Good stuff does not always come from good vision if 
 it is poorly managed.

Agreed. I'll also note I didn't claim "always".

 IUnknown had a fair point that you had the option of taking or leaving.  
 The suggestion was to look for advice for a problem to which you 
 admitted having no solution.
 
 
 Obviously, you needn't take the advice.  But reinterpreting his 
 statement to a form that is absurd is not fair.  You could have just as 
 easily interpreted him as saying, "look over some historical examples 
 and see if there are similar solutions to this problem from another's 
 perspective".

Oh, I didn't mean to demean what he said in any way. But taking his 
advice at this point in time is incompatible with my view, for the lack 
of a better word. Most of the issue is that for the most part said 
"view" is not palpable: it's the ranges I haven't implemented yet, the 
I/O I haven't designed yet, the containers I haven't implemented yet, 
and the threading library we haven't designed yet. At the same time, 
Tango as defined today itself does not take advantage of D2. So I'd find 
it odd to ask people at this point whether they'd choose between a 
library that essentially doesn't exist yet, and one that might improve 
by going through one more iteration. It's just too early for D2.


Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 John Reimer wrote:
 
 Hello Andrei,
 
 IUnknown wrote:
 
 This is why I request you to consult other independent people and
 see what their take on it is. From a library developer's
 perspective you would invariably pit the decision against the
 difficulty in doing it. Hence my suggestion to find out what users
 would really need and then try to implement it.
 

 This I completely disagree with. 360 degrees :o). Good stuff comes
 from good vision, not from doing what people think they want (see
 PHP, American cars, and taking dating advice from female friends). I
 won't continue this because it will go the way philosophical debates
 usually go => a long exchange of long messages leading to nowhere in
 particular.
 
 Andrei
 

 Oversimplification.  Good stuff does not always come from good vision
 if it is poorly managed.
 

 Agreed. I'll also note I didn't claim "always".
 


:-)


 IUnknown had a fair point that you had the option of taking or
 leaving.  The suggestion was to look for advice for a problem to
 which you admitted having no solution.
 
 Obviously, you needn't take the advice.  But reinterpreting his
 statement to a form that is absurd is not fair.  You could have just
 as easily interpreted him as saying, "look over some historical
 examples and see if there are similar solutions to this problem from
 another's perspective".
 

 Oh, I didn't mean to demean what he said in any way. But taking his
 advice at this point in time is incompatible with my view, for the
 lack of a better word. Most of the issue is that for the most part
 said "view" is not palpable: it's the ranges I haven't implemented
 yet, the I/O I haven't designed yet, the containers I haven't
 implemented yet, and the threading library we haven't designed yet. At
 the same time, Tango as defined today itself does not take advantage
 of D2. So I'd find it odd to ask people at this point whether they'd
 choose between a library that essentially doesn't exist yet, and one
 that might improve by going through one more iteration. It's just too
 early for D2.
 
 Andrei
 


Ok, I see.


-JJR

Walter Bright <newshound1 digitalmars.com> writes:

Andrei Alexandrescu wrote:
 This I completely disagree with. 360 degrees :o). Good stuff comes from 
 good vision, not from doing what people think they want (see PHP, 
 American cars, and taking dating advice from female friends).

You're still wrong about American cars! 
http://www.seifertbros.com/hemicuda.html

Benji Smith <dlanguage benjismith.net> writes:

IUnknown wrote:
 Agree. Which is why I said the problems you are facing seem to be
non-technical. I'm suggesting that the D library developers should pick one and
axe the other. *I* think what more important is to have one single set of
containers in a single style rather than have two separate ones. There is going
to be complaining for sure from the current developers, but in my opinion, the
target of having a single standard library (with core and advanced modules to
suit system/ app programming) is more important than having to make a difficult
choice. 

Totally agree. While I personally prefer the Java-style containers, I'd 
gladly accept the STL-style containers if it meant unification of Phobos 
and Tango.

Having druntime is nice, sure, but application-level code and high-level 
libraries will bake the container API into their public interfaces, and 
any code that uses both the Phobos and Tango libraries would have to 
perform a zillion tedious conversions.

In my mind, the things that need a unified API are (in order of importance):

1. GC and TypeInfo
2. Data structures
3. Algorithms
4. String processing
5. Date & Time
6. IO

Everything else (encryption, compression, sockets, regular expressions, 
could have a totally different API in Tango & Phobos and I wouldn't care 
much.

Having a common runtime (GC and TypeInfo) is a neat trick, but pretty 
useless if the data structures and algorithms are entirely different.

And, while I'm perfectly willing to accept either Java-style or 
STL-style containers, I'd also really appreciate it if the design 
anticipates and supports custom implementations (because I almost always 
end up implementing my own multimaps, multisets, circular queues etc)

--benji

"Denis Koroskin" <2korden gmail.com> writes:

On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith <dlanguage benjismith.net>
wrote:

 IUnknown wrote:
 Agree. Which is why I said the problems you are facing seem to be  
 non-technical. I'm suggesting that the D library developers should pick  
 one and axe the other. *I* think what more important is to have one  
 single set of containers in a single style rather than have two  
 separate ones. There is going to be complaining for sure from the  
 current developers, but in my opinion, the target of having a single  
 standard library (with core and advanced modules to suit system/ app  
 programming) is more important than having to make a difficult choice.

 Totally agree. While I personally prefer the Java-style containers, I'd  
 gladly accept the STL-style containers if it meant unification of Phobos  
 and Tango.

 Having druntime is nice, sure, but application-level code and high-level  
 libraries will bake the container API into their public interfaces, and  
 any code that uses both the Phobos and Tango libraries would have to  
 perform a zillion tedious conversions.

 In my mind, the things that need a unified API are (in order of  
 importance):

 1. GC and TypeInfo
 2. Data structures
 3. Algorithms
 4. String processing
 5. Date & Time
 6. IO

 Everything else (encryption, compression, sockets, regular expressions,  
 could have a totally different API in Tango & Phobos and I wouldn't care  
 much.

 Having a common runtime (GC and TypeInfo) is a neat trick, but pretty  
 useless if the data structures and algorithms are entirely different.

 And, while I'm perfectly willing to accept either Java-style or  
 STL-style containers, I'd also really appreciate it if the design  
 anticipates and supports custom implementations (because I almost always  
 end up implementing my own multimaps, multisets, circular queues etc)

 --benji

I think believe we could take advantage of current state of both libraries in
D2 - they are both incomplete and being redesigned to fit D2 better.
We could revisit both Tango and Phobos, and clean them up by removing outdated
modules and modules with same functionality. This will make Phobos really small
and much easier to learn.

On the other hand, Tango will continue providing all the extended functionality.

Here is a list of Phobos modules that I believe could be safely removed:

- crc32 and std.md5 - these should be deprecated in favor of
tango.io.digest.Crc32 and tango.io.digest.Md5
Tango is better designed and has support for other algoriths (MD2, MD4, SHA256,
SHA512, Tiger and more).
See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for
details.

- std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing
but CAS anyway).
- std.base64 - deprecate in favor of tango.io.encode.Base64
- std.cover - is it supposed to be visible to user? Should it be in Phobos?
- std.loader - deprecate in favor of tango.sys.SharedLib
- std.bitarray
- std.openrj
- std.process - merge with tango.sys.Process
- std.regexp - buggy, deprecate in favor of tango.text.Regex
- std.socket, std.socketstream - deprecate in favor of tango.net.*
- std.uni - deprecate in favor of tango.text.Unicode
- std.uri - deprecate in favor of tango.net.Uri
- std.xml - deprecate in favor of tango.text.xml.*
- std.zip and std.zlib - deprecate in favor of tango.io.compress.*

In almost *all* cases Tango has cleaner, faster and less buggy implementation
of the same functionality.

Other modules - does anyone use any of these:
std.bitmanip
std.bind
std.boxer
std.outbuffer
std.stdint
std.syserror
std.system
?

There are a lot of modules that only exist in Phobos because of some historical
reasons or because Walter wrote it. Is it a sufficient reason for them to stay?
They are no doubt useful sometimes, but are we going to put everything that is
useful sometimes into Phobos?

I believe it would be better for everyone to keep Phobos simple and prevent the
two libraries from competing by separating the functionality.
Once they don't compete anymore, users won't have to worry about what library
to use how to stay compatible.

Aarti_pl <aarti interia.pl> writes:

Denis Koroskin pisze:
 On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith 
 <dlanguage benjismith.net> wrote:
 
 IUnknown wrote:
 Agree. Which is why I said the problems you are facing seem to be 
 non-technical. I'm suggesting that the D library developers should 
 pick one and axe the other. *I* think what more important is to have 
 one single set of containers in a single style rather than have two 
 separate ones. There is going to be complaining for sure from the 
 current developers, but in my opinion, the target of having a single 
 standard library (with core and advanced modules to suit system/ app 
 programming) is more important than having to make a difficult choice.

 Totally agree. While I personally prefer the Java-style containers, 
 I'd gladly accept the STL-style containers if it meant unification of 
 Phobos and Tango.

 Having druntime is nice, sure, but application-level code and 
 high-level libraries will bake the container API into their public 
 interfaces, and any code that uses both the Phobos and Tango libraries 
 would have to perform a zillion tedious conversions.

 In my mind, the things that need a unified API are (in order of 
 importance):

 1. GC and TypeInfo
 2. Data structures
 3. Algorithms
 4. String processing
 5. Date & Time
 6. IO

 Everything else (encryption, compression, sockets, regular 
 expressions, could have a totally different API in Tango & Phobos and 
 I wouldn't care much.

 Having a common runtime (GC and TypeInfo) is a neat trick, but pretty 
 useless if the data structures and algorithms are entirely different.

 And, while I'm perfectly willing to accept either Java-style or 
 STL-style containers, I'd also really appreciate it if the design 
 anticipates and supports custom implementations (because I almost 
 always end up implementing my own multimaps, multisets, circular 
 queues etc)

 --benji

 
 I think believe we could take advantage of current state of both 
 libraries in D2 - they are both incomplete and being redesigned to fit 
 D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing 
 outdated modules and modules with same functionality. This will make 
 Phobos really small and much easier to learn.
 
 On the other hand, Tango will continue providing all the extended 
 functionality.
 
 Here is a list of Phobos modules that I believe could be safely removed:
 
 - crc32 and std.md5 - these should be deprecated in favor of 
 tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4, 
 SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto 
 for details.
 
 - std.atomics - tango.core.Atomic is superior to it (std.atomics has 
 nothing but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
 
 In almost *all* cases Tango has cleaner, faster and less buggy 
 implementation of the same functionality.
 
 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?
 
 There are a lot of modules that only exist in Phobos because of some 
 historical reasons or because Walter wrote it. Is it a sufficient reason 
 for them to stay?
 They are no doubt useful sometimes, but are we going to put everything 
 that is useful sometimes into Phobos?
 
 I believe it would be better for everyone to keep Phobos simple and 
 prevent the two libraries from competing by separating the functionality.
 Once they don't compete anymore, users won't have to worry about what 
 library to use how to stay compatible.

Also my thoughts. Several months ago I send similar proposition to 
divide libraries responsibilities:
- for Phobos - low level API
- for Tango - higher level API

Stuff which is in both libraries should be designed together by both 
teams. Andrei is talking about new design for IO in Phobos. Why not to 
prepare this new design together with Tango people?

Some differences between philosophies of libraries should not stop 
merging. E.g. Phobos uses IO synchronized with C, but Tango is not. Why 
to divide libraries based on this? I think that there are cases where 
users would want one approach and also cases where they would want the 
other. IMHO standard library should have API allowing one or other 
approach depending on what user wants... So this difference is purely 
rhetorical...

BR
Marcin Kuszczak
(aarti_pl)
www.zapytajmnie.com - my christian site

Jason House <jason.james.house gmail.com> writes:

Denis Koroskin Wrote:

 I think believe we could take advantage of current state of both libraries in
D2 - they are both incomplete and being redesigned to fit D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing outdated
modules and modules with same functionality. This will make Phobos really small
and much easier to learn.
 
 On the other hand, Tango will continue providing all the extended
functionality.
 
 Here is a list of Phobos modules that I believe could be safely removed:
 
 - crc32 and std.md5 - these should be deprecated in favor of
tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4,
SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for
details.
 
 - std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing
but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
 
 In almost *all* cases Tango has cleaner, faster and less buggy implementation
of the same functionality.

That's an interesting list.  Without the ability to distribute Phobos and Tango
together from the digitalmars.com site, I doubt anything will get dropped from
Phobos in favor of what is in Tango.  For a combined distribution to ever occur
requires a whole lot more coordination between Phobos and Tango that I doubt
we'll see for a very long time.



 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?

std.bind is useful for binding data that will change before the delegate is
called.  I've used bind a lot when doing inter-thread communication with queues
of pending commands.

I'd also like to use a variant of bit array with fixed sizes, easier
initialiation, and uses the SSE instruction set.  Right now, neither Phobos nor
Tango contains what I want.

"Denis Koroskin" <2korden gmail.com> writes:

On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house gmail.com>
wrote:

 Denis Koroskin Wrote:

 I think believe we could take advantage of current state of both  
 libraries in D2 - they are both incomplete and being redesigned to fit  
 D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing  
 outdated modules and modules with same functionality. This will make  
 Phobos really small and much easier to learn.

 On the other hand, Tango will continue providing all the extended  
 functionality.

 Here is a list of Phobos modules that I believe could be safely removed:

 - crc32 and std.md5 - these should be deprecated in favor of  
 tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4,  
 SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto  
 for details.

 - std.atomics - tango.core.Atomic is superior to it (std.atomics has  
 nothing but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in  
 Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*

 In almost *all* cases Tango has cleaner, faster and less buggy  
 implementation of the same functionality.

 That's an interesting list.  Without the ability to distribute Phobos  
 and Tango together from the digitalmars.com site, I doubt anything will  
 get dropped from Phobos in favor of what is in Tango.  For a combined  
 distribution to ever occur requires a whole lot more coordination  
 between Phobos and Tango that I doubt we'll see for a very long time.

Is there any problem? Walter gave a special permission to Tango team to
distribute DMD with Tango. I believe Tango team can give similar permission to
distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I
don't see why it can't ship with DMD. Unless Walter is against it.

Oh, and Tango2 should exists, of course.

 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?

 std.bind is useful for binding data that will change before the delegate  
 is called.  I've used bind a lot when doing inter-thread communication  
 with queues of pending commands.

 I'd also like to use a variant of bit array with fixed sizes, easier  
 initialiation, and uses the SSE instruction set.  Right now, neither  
 Phobos nor Tango contains what I want.

Jason House <jason.james.house gmail.com> writes:

Denis Koroskin Wrote:

 On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house gmail.com>
wrote:
 
 Denis Koroskin Wrote:

 I think believe we could take advantage of current state of both  
 libraries in D2 - they are both incomplete and being redesigned to fit  
 D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing  
 outdated modules and modules with same functionality. This will make  
 Phobos really small and much easier to learn.

 On the other hand, Tango will continue providing all the extended  
 functionality.

 Here is a list of Phobos modules that I believe could be safely removed:

 - crc32 and std.md5 - these should be deprecated in favor of  
 tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4,  
 SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto  
 for details.

 - std.atomics - tango.core.Atomic is superior to it (std.atomics has  
 nothing but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in  
 Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*

 In almost *all* cases Tango has cleaner, faster and less buggy  
 implementation of the same functionality.

 That's an interesting list.  Without the ability to distribute Phobos  
 and Tango together from the digitalmars.com site, I doubt anything will  
 get dropped from Phobos in favor of what is in Tango.  For a combined  
 distribution to ever occur requires a whole lot more coordination  
 between Phobos and Tango that I doubt we'll see for a very long time.

 
 Is there any problem? Walter gave a special permission to Tango team to
distribute DMD with Tango. I believe Tango team can give similar permission to
distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I
don't see why it can't ship with DMD. Unless Walter is against it.


If after all the pledges to fix the Tango/Phobos split and a lot of time to
take action, eveything should be fixed. When we have to say "can" "could" or
other hypothetical terms, it makes me think there is a problem.

I am disapponted that druntime can't make its way into D1. Without that,
nothing will happen with D1, ever. Meanwhile D2 is at least on hold. Lately,
there's been discussion of how the licenses of Phobos and Tango are different.
I assume that any legal ambiguity will block distribution by digital mars
 

 
 Oh, and Tango2 should exists, of course.
 
 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?

 std.bind is useful for binding data that will change before the delegate  
 is called.  I've used bind a lot when doing inter-thread communication  
 with queues of pending commands.

 I'd also like to use a variant of bit array with fixed sizes, easier  
 initialiation, and uses the SSE instruction set.  Right now, neither  
 Phobos nor Tango contains what I want.

 
 
 

Don <nospam nospam.com> writes:

Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

 
 This is already bound to be an issue because there is disagreement on 
 how e.g. containers should look like (Java-style vs. STL-style). Which 
 should be chosen? This naturally influences how algorithms are defined.
 
 
 Andrei


The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries 
will work regardless of which GUI library is chosen. Programmers can 
still rely on the Posix and C standard libraries.

Can we work out the math stuff at least? There's no difference between 
Phobos and Tango there. All we need is an agreement on common module 
naming (eg, create core.math).

By the way, Andrei, this is exactly the kind of attitude which I was 
ranting about. There are clear areas of duplicated code (fortunately 
much of it is in druntime now), and even Tango's containers still seem 
to be in a state of flux (the old container library is deprecated, and 
very little of Tango is currently using containers).
Everyone -- can we be productive instead of dismissive, please?

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

 This is already bound to be an issue because there is disagreement on 
 how e.g. containers should look like (Java-style vs. STL-style). Which 
 should be chosen? This naturally influences how algorithms are defined.


 Andrei

 
 
 The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries 
 will work regardless of which GUI library is chosen. Programmers can 
 still rely on the Posix and C standard libraries.

I agree.

 Can we work out the math stuff at least? There's no difference between 
 Phobos and Tango there. All we need is an agreement on common module 
 naming (eg, create core.math).

That would be great. I don't think that's a major issue anyway. If I 
were you, to be compatible with today's state of affairs, I'd simply put 
in the makefile the code necessary for switching the module prefixes.

 By the way, Andrei, this is exactly the kind of attitude which I was 
 ranting about. There are clear areas of duplicated code (fortunately 
 much of it is in druntime now), and even Tango's containers still seem 
 to be in a state of flux (the old container library is deprecated, and 
 very little of Tango is currently using containers).
 Everyone -- can we be productive instead of dismissive, please?

I think you're reading significantly more into what I wrote than I meant 
to put in.


Andrei

Don <nospam nospam.com> writes:

Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

 This is already bound to be an issue because there is disagreement on 
 how e.g. containers should look like (Java-style vs. STL-style). 
 Which should be chosen? This naturally influences how algorithms are 
 defined.


 Andrei


 The analogy with KDE vs Gnome doesn't seem valid to me -- most 
 libraries will work regardless of which GUI library is chosen. 
 Programmers can still rely on the Posix and C standard libraries.

 
 I agree.
 
 Can we work out the math stuff at least? There's no difference between 
 Phobos and Tango there. All we need is an agreement on common module 
 naming (eg, create core.math).

 
 That would be great. I don't think that's a major issue anyway. If I 
 were you, to be compatible with today's state of affairs, I'd simply put 
 in the makefile the code necessary for switching the module prefixes.

It means that any code which uses a library based on both Tango and a 
library based on Phobos will end up with two copies of all of the 
functions, and they'll have different name mangling etc. You end up with 
two incompatible Bigints, for example, even though they have identical 
code inside.

 By the way, Andrei, this is exactly the kind of attitude which I was 
 ranting about. There are clear areas of duplicated code (fortunately 
 much of it is in druntime now), and even Tango's containers still seem 
 to be in a state of flux (the old container library is deprecated, and 
 very little of Tango is currently using containers).
 Everyone -- can we be productive instead of dismissive, please?

 
 I think you're reading significantly more into what I wrote than I meant 
 to put in.

Good to hear.

 
 
 Andrei

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Can we work out the math stuff at least? There's no difference 
 between Phobos and Tango there. All we need is an agreement on common 
 module naming (eg, create core.math).

 That would be great. I don't think that's a major issue anyway. If I 
 were you, to be compatible with today's state of affairs, I'd simply 
 put in the makefile the code necessary for switching the module prefixes.

 
 It means that any code which uses a library based on both Tango and a 
 library based on Phobos will end up with two copies of all of the 
 functions, and they'll have different name mangling etc. You end up with 
 two incompatible Bigints, for example, even though they have identical 
 code inside.

Interestingly, this might be less of a problem when using LDC. LLVM has 
an IPO pass to merge identical functions (opt -mergefunc).

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

 This is already bound to be an issue because there is disagreement 
 on how e.g. containers should look like (Java-style vs. STL-style). 
 Which should be chosen? This naturally influences how algorithms are 
 defined.


 Andrei


 The analogy with KDE vs Gnome doesn't seem valid to me -- most 
 libraries will work regardless of which GUI library is chosen. 
 Programmers can still rely on the Posix and C standard libraries.

 I agree.

 Can we work out the math stuff at least? There's no difference 
 between Phobos and Tango there. All we need is an agreement on common 
 module naming (eg, create core.math).

 That would be great. I don't think that's a major issue anyway. If I 
 were you, to be compatible with today's state of affairs, I'd simply 
 put in the makefile the code necessary for switching the module prefixes.

 
 It means that any code which uses a library based on both Tango and a 
 library based on Phobos will end up with two copies of all of the 
 functions, and they'll have different name mangling etc. You end up with 
 two incompatible Bigints, for example, even though they have identical 
 code inside.

Oh, I see. You want your library to be usable whether the end user 
prefers Phobos or Tango. But then why not stick it into a namespace of 
your choosing? Let's say your libraries are general enough to warrant 
putting them in a common core, but then anyone who defines some library 
don't have to go to the "core ombudsman" to add it to the common 
namespace. They'd just create unique namespaces of their own. No?


Andrei

Daniel Keep <daniel.keep.lists gmail.com> writes:

Andrei Alexandrescu wrote:
 Don wrote:
 [snip]

 It means that any code which uses a library based on both Tango and a
 library based on Phobos will end up with two copies of all of the
 functions, and they'll have different name mangling etc. You end up
 with two incompatible Bigints, for example, even though they have
 identical code inside.

 
 Oh, I see. You want your library to be usable whether the end user
 prefers Phobos or Tango. But then why not stick it into a namespace of
 your choosing? Let's say your libraries are general enough to warrant
 putting them in a common core, but then anyone who defines some library
 don't have to go to the "core ombudsman" to add it to the common
 namespace. They'd just create unique namespaces of their own. No?
 
 
 Andrei

I think he means this: let's say you're writing app A.  A depends on
libraries B and C.  B depends on Phobos, and C depends on Tango.  Both B
and C happen to use BigInts or IO or anything else that isn't shared.

All of a sudden, you've now got to link in TWO standard libraries
instead of just one, each with potentially duplicated code.

From personal experience, the alternative isn't much better: writing
code that switches between the two.

I have an XML library that can use either Phobos or Tango.  It does this
by implementing all the calls it needs in a shim library, essentially
using it's own standard library.

It gets really fun when you need to implement some call that's trivial
in one library, but really hard in the other.  I remember having to
build an IO layer so that both Phobos and Tango had the same semantics
regarding EOF or something...

Urgh.

  -- Daniel

Don <nospam nospam.com> writes:

Daniel Keep wrote:
 
 Andrei Alexandrescu wrote:
 Don wrote:
 [snip]

 It means that any code which uses a library based on both Tango and a
 library based on Phobos will end up with two copies of all of the
 functions, and they'll have different name mangling etc. You end up
 with two incompatible Bigints, for example, even though they have
 identical code inside.

 Oh, I see. You want your library to be usable whether the end user
 prefers Phobos or Tango. But then why not stick it into a namespace of
 your choosing? Let's say your libraries are general enough to warrant
 putting them in a common core, but then anyone who defines some library
 don't have to go to the "core ombudsman" to add it to the common
 namespace. They'd just create unique namespaces of their own. No?


 Andrei

 
 I think he means this: let's say you're writing app A.  A depends on
 libraries B and C.  B depends on Phobos, and C depends on Tango.  Both B
 and C happen to use BigInts or IO or anything else that isn't shared.
 
 All of a sudden, you've now got to link in TWO standard libraries
 instead of just one, each with potentially duplicated code.

And you can't obtain a BigInt from library B and pass it into library C, 
since they are different types; even though they have 100% identical 
source code except for the name.

 
 From personal experience, the alternative isn't much better: writing
 code that switches between the two.
 
 I have an XML library that can use either Phobos or Tango.  It does this
 by implementing all the calls it needs in a shim library, essentially
 using it's own standard library.
 
 It gets really fun when you need to implement some call that's trivial
 in one library, but really hard in the other.  I remember having to
 build an IO layer so that both Phobos and Tango had the same semantics
 regarding EOF or something...
 
 Urgh.
 
   -- Daniel

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Don wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 [snip]

 It means that any code which uses a library based on both Tango and a
 library based on Phobos will end up with two copies of all of the
 functions, and they'll have different name mangling etc. You end up
 with two incompatible Bigints, for example, even though they have
 identical code inside.

 Oh, I see. You want your library to be usable whether the end user
 prefers Phobos or Tango. But then why not stick it into a namespace of
 your choosing? Let's say your libraries are general enough to warrant
 putting them in a common core, but then anyone who defines some library
 don't have to go to the "core ombudsman" to add it to the common
 namespace. They'd just create unique namespaces of their own. No?


 Andrei

 I think he means this: let's say you're writing app A.  A depends on
 libraries B and C.  B depends on Phobos, and C depends on Tango.  Both B
 and C happen to use BigInts or IO or anything else that isn't shared.

 All of a sudden, you've now got to link in TWO standard libraries
 instead of just one, each with potentially duplicated code.

 
 And you can't obtain a BigInt from library B and pass it into library C, 
 since they are different types; even though they have 100% identical 
 source code except for the name.

This will partially be solved by structural casts. I have an 
implementation but haven't put it in phobos yet. Structural casts will 
allow types that have the same layout to be cast to one another. Of 
course, that's still not ideal but it's one step forward.


Andrei

Don <nospam nospam.com> writes:

Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

 This is already bound to be an issue because there is disagreement 
 on how e.g. containers should look like (Java-style vs. STL-style). 
 Which should be chosen? This naturally influences how algorithms 
 are defined.


 Andrei


 The analogy with KDE vs Gnome doesn't seem valid to me -- most 
 libraries will work regardless of which GUI library is chosen. 
 Programmers can still rely on the Posix and C standard libraries.

 I agree.

 Can we work out the math stuff at least? There's no difference 
 between Phobos and Tango there. All we need is an agreement on 
 common module naming (eg, create core.math).

 That would be great. I don't think that's a major issue anyway. If I 
 were you, to be compatible with today's state of affairs, I'd simply 
 put in the makefile the code necessary for switching the module 
 prefixes.

 It means that any code which uses a library based on both Tango and a 
 library based on Phobos will end up with two copies of all of the 
 functions, and they'll have different name mangling etc. You end up 
 with two incompatible Bigints, for example, even though they have 
 identical code inside.

 
 Oh, I see. You want your library to be usable whether the end user 
 prefers Phobos or Tango. But then why not stick it into a namespace of 
 your choosing? Let's say your libraries are general enough to warrant 
 putting them in a common core, but then anyone who defines some library 
 don't have to go to the "core ombudsman" to add it to the common 
 namespace. They'd just create unique namespaces of their own. No?

That's possible too. Originally, my code was in the 'mathextra' 
namespace, and I'm somewhat regretting moving it it out.

You still need an ombudsman, though, to determine which libraries are 
standard, and which are not, in order to prevent namespace collisions. 
Personally, I like the boost model -- all you need is a root level (like 
'boost') to act as a namespace protection mechanism, and then a library 
standardisation policy.

But then you have the question as to the organisation of the 'std' 
namespace -- for example, it contains such obscure stuff as std.openrj 
which is actually a stand-alone library.

(I notice Dennis has just posted some similar sentiments, so I'll stop 
for now).

It could be that all that we need is to create a standard naming policy.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Piotrek" wrote
 Hello!

 It's just an idea. After reading about issues on disallowing DWT to stay 
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some 
 question appeared in my mind. For propaganda sake isn't it better to not 
 make such a big division between phobos and tango in the module naming? 
 Logically:

 phobos -> std
 tango  -> stdex (not tango -> tango)

Let's not forget the licensing issues.  Tango is incompatible with some 
developers license wise, as you must include attribution for Tango in any 
derivative works (i.e. compiled binaries).  Phobos has a less restrictive 
opt-in policy.  I think Walter intends to keep it that way, at least for 
DMD.  Note that other compilers are free to use Tango or their own standard 
library, the D spec is pretty free from library references.

With regards to Tango for D2.  It is going to happen.  It may not be 
tomorrow, but it will probably be done this year.  To answer some questions 
throughout this discussion, it will look similar to Tango/D1, but will 
utilize many of the features of D2, as well as obey the requirements.  For 
example, it's not simply going to cast away const to keep the implementation 
closer to D1.  So it will look different than Tango/D1 and most likely, will 
not be one code base.  Which means, people will have to maintain both, which 
is no small feat.  But it can (and will) be done.  I like D2 too much to not 
do it :)

The Tango D2 branch currently in SVN compiles and runs on Linux DMD 2.019. 
We have basic functionality for many of the examples, but not all unit tests 
pass.  However, it should be usable to test simple code.  So far, we have 
ported completely tango.core and tango.util.log.  We have yet to incorporate 
druntime, as I didn't want to tackle issues that might be in druntime as 
well as porting issues.  I think I will try to upgrade to 2.023, as it seems 
druntime/compiler interaction is getting a lot more stable, and then 
continue porting.

I don't see Tango and Phobos becoming more like one or the other, but as 
others have said, there are definite sections of code that can be used from 
both without interference.  I/O is not one of them, and I don't see that 
changing.  But due to the open source nature, you can port or re-implement 
features of one library into the other, so while you may be choosing between 
two different styles, you shouldn't have to choose one or the other for 
functionality.

I also don't think this is a bad thing.  One of two things will happen. 
Either one library totally dominates the other, and eventually everyone 
starts using the more popular one (the Beta/VHS route), or both libraries 
flourish, and due to the common runtime, can be used concurrently in 
projects (the KDE/GNOME route).  Either way, I don't see the current rift 
between Tango/Phobos being a major detriment to D.  It will be short-lived 
IMO.

-Steve 

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Steven Schveighoffer wrote:
 "Piotrek" wrote
 Hello!

 It's just an idea. After reading about issues on disallowing DWT to stay 
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some 
 question appeared in my mind. For propaganda sake isn't it better to not 
 make such a big division between phobos and tango in the module naming? 
 Logically:

 phobos -> std
 tango  -> stdex (not tango -> tango)

 
 Let's not forget the licensing issues.  Tango is incompatible with some 
 developers license wise, as you must include attribution for Tango in any 
 derivative works (i.e. compiled binaries).  Phobos has a less restrictive 
 opt-in policy.  I think Walter intends to keep it that way, at least for 
 DMD.  Note that other compilers are free to use Tango or their own standard 
 library, the D spec is pretty free from library references.

Yah. This also creates some asymmetry, as e.g. Walter avoids looking at 
Tango whereas Phobos is out in the clear. Given that I work on Phobos 
too and know next to nothing about licensing issues, I myself defaulted 
to not looking at Tango (I did look cursory a couple of years ago, 
before being involved with Phobos.)

 I also don't think this is a bad thing.  One of two things will happen. 
 Either one library totally dominates the other, and eventually everyone 
 starts using the more popular one (the Beta/VHS route), or both libraries 
 flourish, and due to the common runtime, can be used concurrently in 
 projects (the KDE/GNOME route).  Either way, I don't see the current rift 
 between Tango/Phobos being a major detriment to D.  It will be short-lived 
 IMO.

Nicely put. I believe the same.


Andrei

John Reimer <terminal.node gmail.com> writes:

Hello Steven,

 "Piotrek" wrote
 
 Hello!
 
 It's just an idea. After reading about issues on disallowing DWT to
 stay in standardization area (Anomaly on Wiki4D GuiLibraries page)
 some question appeared in my mind. For propaganda sake isn't it
 better to not make such a big division between phobos and tango in
 the module naming? Logically:
 
 phobos -> std
 tango  -> stdex (not tango -> tango)

 Let's not forget the licensing issues.  Tango is incompatible with
 some developers license wise, as you must include attribution for
 Tango in any derivative works (i.e. compiled binaries).  Phobos has a
 less restrictive opt-in policy.  I think Walter intends to keep it
 that way, at least for DMD.  Note that other compilers are free to use
 Tango or their own standard library, the D spec is pretty free from
 library references.
 
 With regards to Tango for D2.  It is going to happen.  It may not be
 tomorrow, but it will probably be done this year.  To answer some
 questions throughout this discussion, it will look similar to
 Tango/D1, but will utilize many of the features of D2, as well as obey
 the requirements.  For example, it's not simply going to cast away
 const to keep the implementation closer to D1.  So it will look
 different than Tango/D1 and most likely, will not be one code base.
 Which means, people will have to maintain both, which is no small
 feat.  But it can (and will) be done.  I like D2 too much to not do it
 :)
 
 The Tango D2 branch currently in SVN compiles and runs on Linux DMD
 2.019. We have basic functionality for many of the examples, but not
 all unit tests pass.  However, it should be usable to test simple
 code.  So far, we have ported completely tango.core and
 tango.util.log.  We have yet to incorporate druntime, as I didn't want
 to tackle issues that might be in druntime as well as porting issues.
 I think I will try to upgrade to 2.023, as it seems druntime/compiler
 interaction is getting a lot more stable, and then continue porting.
 
 I don't see Tango and Phobos becoming more like one or the other, but
 as others have said, there are definite sections of code that can be
 used from both without interference.  I/O is not one of them, and I
 don't see that changing.  But due to the open source nature, you can
 port or re-implement features of one library into the other, so while
 you may be choosing between two different styles, you shouldn't have
 to choose one or the other for functionality.
 
 I also don't think this is a bad thing.  One of two things will
 happen. Either one library totally dominates the other, and eventually
 everyone starts using the more popular one (the Beta/VHS route), or
 both libraries flourish, and due to the common runtime, can be used
 concurrently in projects (the KDE/GNOME route).  Either way, I don't
 see the current rift between Tango/Phobos being a major detriment to
 D.  It will be short-lived IMO.
 
 -Steve
 


A fair analysis, but I think incomplete.  Once again, the problem has more 
to do with the perception of new users and outsiders.  I believe those of 
is in here, those of us who have frustrated and agonized over D over the 
last few years are going to be in a much better position of accepting the 
situation as it develops: we've grown with it, so our sympathies are well 
rooted -- we may very much enjoy having the option of using either of or 
both of two great libraries.  I can easily agree that your analysis has some 
sense to it because of that.  


But, as I said before, the hardest part remains in finding a method to promote 
it as a "good thing" to everyone else who has no real emotional attatchment 
to the language, those who see learning a language as a synonymous with
learning 
one "standard" library (because that seems to be the general history of
programming 
languages).  Maybe I'm wrong about this one (I hope I am wrong, and you are 
right), but I don't think it's wise to completely discredit the possibility 
of a problem in having two popular libraries at the core of D 2.0.  If the 
libraries do go the Beta/VHS route... well that's just a mercy for D.   


Still trying to think positively,  of course. :)

-JJR

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"John Reimer" wrote
 Hello Steven,
 I don't see Tango and Phobos becoming more like one or the other, but
 as others have said, there are definite sections of code that can be
 used from both without interference.  I/O is not one of them, and I
 don't see that changing.  But due to the open source nature, you can
 port or re-implement features of one library into the other, so while
 you may be choosing between two different styles, you shouldn't have
 to choose one or the other for functionality.

 I also don't think this is a bad thing.  One of two things will
 happen. Either one library totally dominates the other, and eventually
 everyone starts using the more popular one (the Beta/VHS route), or
 both libraries flourish, and due to the common runtime, can be used
 concurrently in projects (the KDE/GNOME route).  Either way, I don't
 see the current rift between Tango/Phobos being a major detriment to
 D.  It will be short-lived IMO.

 -Steve


 A fair analysis, but I think incomplete.  Once again, the problem has more 
 to do with the perception of new users and outsiders.  I believe those of 
 is in here, those of us who have frustrated and agonized over D over the 
 last few years are going to be in a much better position of accepting the 
 situation as it develops: we've grown with it, so our sympathies are well 
 rooted -- we may very much enjoy having the option of using either of or 
 both of two great libraries.  I can easily agree that your analysis has 
 some sense to it because of that.

 But, as I said before, the hardest part remains in finding a method to 
 promote it as a "good thing" to everyone else who has no real emotional 
 attatchment to the language, those who see learning a language as a 
 synonymous with learning one "standard" library (because that seems to be 
 the general history of programming languages).  Maybe I'm wrong about this 
 one (I hope I am wrong, and you are right), but I don't think it's wise to 
 completely discredit the possibility of a problem in having two popular 
 libraries at the core of D 2.0.  If the libraries do go the Beta/VHS 
 route... well that's just a mercy for D.

 Still trying to think positively,  of course. :)

Keep thinking positively :)  There will always be naysayers, people who 
think D sucks, no matter how many of their objections you fix, they will 
find something else to gripe about.  There's not much you can do about those 
people.  The ones I am interested in convincing are those who turn to D to 
fill a need, such as "C++ sucks, I wonder if there's something better", or 
"I like language X, but I need something that compiles to native code", or 
whatever the reason.  These are the people who are willing to invest the 
time necessary to learn the core language.  If those people, after learning 
D and about the standard library situation still turn away, then there would 
be something wrong.  But I don't think we are in that situation.  Most of 
the people in this newsgroup are in that category and have stuck it out and 
want to make D work.  Every once in a while, a fierce Phobos vs. Tango 
debate arises, and it sucks so much time out of people that they are sure it 
is the main reason people don't like D.  When you start using D, you pick a 
library, and most likely stick to it.  There are plenty of resources that 
work for both the libraries, that I don't think it's that terrible.  There 
are so many other holes in the D regime that I think the fact that you have 
a choice between two standard libraries is the least of our concern.  How 
about a good integrated IDE/Compiler/Debugger?  A visual GUI editor?  A 
better doc system?  And most of all an EASY way to install such tools. 
Following 18 different web pages on unpacking zip files and installing 
source control systems does not foster new use.  I'd say the issue brought 
up about dsource considered harmful is a huge legitimate deterrent.  It 
takes a long time to scour through all the abandoned projects to find out if 
the functionality you're looking for is implemented and maintained or not. 
I know at least one newbie that I helped learn D on IRC from knowing only 
Python that decided to implement 2 projects that had already been done but 
were buried in dsource somewhere.

Me, I don't care about the library debate, I've already picked Tango as my 
standard library.  I don't care if it's not the standard library.  I don't 
care about the brand name, as long as it does what I need it to do.  I've 
moved on to more important tasks.  If other people like Phobos, fine, it 
doesn't bother me at all.  I don't need to have a battle about it.  I just 
want to write code and have it work.  And Tango helps me do that better, so 
that was my choice.  I feel like this debate about which standard library 
wears the official crown is useless noise.  No offense to the OP, but this 
is a never-ending loop that just seems to take up too much of people's time. 
On that note, I'll bow out of the discussion.  I need to get some work done 
:)

-Steve 

Don <nospam nospam.com> writes:

Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with some 
 developers license wise, as you must include attribution for Tango in any 
 derivative works (i.e. compiled binaries). 

Are you sure? Where is that written down? I can't find that anywhere in 
the Tango license.

Bill Baxter <wbaxter gmail.com> writes:

On Tue, Jan 20, 2009 at 3:00 PM, Don <nospam nospam.com> wrote:
 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in any
 derivative works (i.e. compiled binaries).

 Are you sure? Where is that written down? I can't find that anywhere in the
 Tango license.

Probably this:

6. Attribution Rights. You must retain, in the Source Code of any
Derivative Works that You create, all copyright, patent, or trademark
notices from the Source Code of the Original Work, as well as any
notices of licensing and any descriptive text identified therein as an
"Attribution Notice." You must cause the Source Code for any
Derivative Works that You create to carry a prominent Attribution
Notice reasonably calculated to inform recipients that You have
modified the Original Work.

I think it's just saying you can't remove stuff from the source code
that says who wrote it.  But it's got a thick legal accent that's a
little difficult to understand.

--bb

Don <nospam nospam.com> writes:

Bill Baxter wrote:
 On Tue, Jan 20, 2009 at 3:00 PM, Don <nospam nospam.com> wrote:
 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in any
 derivative works (i.e. compiled binaries).

 Are you sure? Where is that written down? I can't find that anywhere in the
 Tango license.

 
 Probably this:
 
 6. Attribution Rights. You must retain, in the Source Code of any
 Derivative Works that You create, all copyright, patent, or trademark
 notices from the Source Code of the Original Work, as well as any
 notices of licensing and any descriptive text identified therein as an
 "Attribution Notice." You must cause the Source Code for any
 Derivative Works that You create to carry a prominent Attribution
 Notice reasonably calculated to inform recipients that You have
 modified the Original Work.
 
 I think it's just saying you can't remove stuff from the source code
 that says who wrote it.  But it's got a thick legal accent that's a
 little difficult to understand.

Yes, it explicitly states that it's source code-only requirement.
Perhaps the page should include an approximate explanation, to remove 
confusion

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Don" wrote
 Bill Baxter wrote:
 On Tue, Jan 20, 2009 at 3:00 PM, Don <nospam nospam.com> wrote:
 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in 
 any
 derivative works (i.e. compiled binaries).

 Are you sure? Where is that written down? I can't find that anywhere in 
 the
 Tango license.

 Probably this:

 6. Attribution Rights. You must retain, in the Source Code of any
 Derivative Works that You create, all copyright, patent, or trademark
 notices from the Source Code of the Original Work, as well as any
 notices of licensing and any descriptive text identified therein as an
 "Attribution Notice." You must cause the Source Code for any
 Derivative Works that You create to carry a prominent Attribution
 Notice reasonably calculated to inform recipients that You have
 modified the Original Work.

 I think it's just saying you can't remove stuff from the source code
 that says who wrote it.  But it's got a thick legal accent that's a
 little difficult to understand.

 Yes, it explicitly states that it's source code-only requirement.
 Perhaps the page should include an approximate explanation, to remove 
 confusion

I'm not a lawyer, but I think that the artistic license requires source 
redistribution (I agree the license is difficult to comprehend), whereas the 
BSD style license requires attribution with binaries.  So either way, you 
must provide attribution.  Some companies may frown upon that, especially 
when we're talking about a standard library.

I'm not saying it should change, but that is one other reason that I think 
Walter has not considered adopting Tango as *the* standard library.

-Steve 

Sean Kelly <sean invisibleduck.org> writes:

Steven Schveighoffer wrote:
 "Don" wrote
 Bill Baxter wrote:
 On Tue, Jan 20, 2009 at 3:00 PM, Don <nospam nospam.com> wrote:
 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in 
 any
 derivative works (i.e. compiled binaries).

 Are you sure? Where is that written down? I can't find that anywhere in 
 the
 Tango license.

 Probably this:

 6. Attribution Rights. You must retain, in the Source Code of any
 Derivative Works that You create, all copyright, patent, or trademark
 notices from the Source Code of the Original Work, as well as any
 notices of licensing and any descriptive text identified therein as an
 "Attribution Notice." You must cause the Source Code for any
 Derivative Works that You create to carry a prominent Attribution
 Notice reasonably calculated to inform recipients that You have
 modified the Original Work.

 I think it's just saying you can't remove stuff from the source code
 that says who wrote it.  But it's got a thick legal accent that's a
 little difficult to understand.

 Yes, it explicitly states that it's source code-only requirement.
 Perhaps the page should include an approximate explanation, to remove 
 confusion

 
 I'm not a lawyer, but I think that the artistic license requires source 
 redistribution (I agree the license is difficult to comprehend), whereas the 
 BSD style license requires attribution with binaries.  So either way, you 
 must provide attribution.  Some companies may frown upon that, especially 
 when we're talking about a standard library.

I've read the BSD license very carefully and I think it only requires 
attribution with binary distributions of the library, not apps written 
with the library.  If I'm wrong I'd love to know, because druntime is 
currently BSD licensed (something I've been meaning to reconsider).


Sean

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Sean Kelly" wrote
 Steven Schveighoffer wrote:
 "Don" wrote
 Bill Baxter wrote:
 On Tue, Jan 20, 2009 at 3:00 PM, Don <nospam nospam.com> wrote:
 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with 
 some
 developers license wise, as you must include attribution for Tango in 
 any
 derivative works (i.e. compiled binaries).

 Are you sure? Where is that written down? I can't find that anywhere 
 in the
 Tango license.

 Probably this:

 6. Attribution Rights. You must retain, in the Source Code of any
 Derivative Works that You create, all copyright, patent, or trademark
 notices from the Source Code of the Original Work, as well as any
 notices of licensing and any descriptive text identified therein as an
 "Attribution Notice." You must cause the Source Code for any
 Derivative Works that You create to carry a prominent Attribution
 Notice reasonably calculated to inform recipients that You have
 modified the Original Work.

 I think it's just saying you can't remove stuff from the source code
 that says who wrote it.  But it's got a thick legal accent that's a
 little difficult to understand.

 Yes, it explicitly states that it's source code-only requirement.
 Perhaps the page should include an approximate explanation, to remove 
 confusion

 I'm not a lawyer, but I think that the artistic license requires source 
 redistribution (I agree the license is difficult to comprehend), whereas 
 the BSD style license requires attribution with binaries.  So either way, 
 you must provide attribution.  Some companies may frown upon that, 
 especially when we're talking about a standard library.

 I've read the BSD license very carefully and I think it only requires 
 attribution with binary distributions of the library, not apps written 
 with the library.  If I'm wrong I'd love to know, because druntime is 
 currently BSD licensed (something I've been meaning to reconsider).

As D currently is statically linked, any application is a binary 
distribution of the library.  However, even with shared libraries, I believe 
it is still considered a binary distribution if your application uses the 
library (as your code needs the dynamic library to run).  This is why the 
LGPL exists.  I don't know if there is an equivalent BSD version.

Again, not a lawyer :)

-steve 

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 "Sean Kelly" wrote
 Steven Schveighoffer wrote:
 "Don" wrote
 Bill Baxter wrote:
 On Tue, Jan 20, 2009 at 3:00 PM, Don <nospam nospam.com> wrote:
 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with
 some
 developers license wise, as you must include attribution for Tango in
 any
 derivative works (i.e. compiled binaries).

 Are you sure? Where is that written down? I can't find that anywhere
 in the
 Tango license.

 Probably this:

 6. Attribution Rights. You must retain, in the Source Code of any
 Derivative Works that You create, all copyright, patent, or trademark
 notices from the Source Code of the Original Work, as well as any
 notices of licensing and any descriptive text identified therein as an
 "Attribution Notice." You must cause the Source Code for any
 Derivative Works that You create to carry a prominent Attribution
 Notice reasonably calculated to inform recipients that You have
 modified the Original Work.

 I think it's just saying you can't remove stuff from the source code
 that says who wrote it.  But it's got a thick legal accent that's a
 little difficult to understand.

 Yes, it explicitly states that it's source code-only requirement.
 Perhaps the page should include an approximate explanation, to remove
 confusion

 I'm not a lawyer, but I think that the artistic license requires source
 redistribution (I agree the license is difficult to comprehend), whereas
 the BSD style license requires attribution with binaries.  So either way,
 you must provide attribution.  Some companies may frown upon that,
 especially when we're talking about a standard library.

 I've read the BSD license very carefully and I think it only requires
 attribution with binary distributions of the library, not apps written
 with the library.  If I'm wrong I'd love to know, because druntime is
 currently BSD licensed (something I've been meaning to reconsider).

 As D currently is statically linked, any application is a binary
 distribution of the library.  However, even with shared libraries, I believe
 it is still considered a binary distribution if your application uses the
 library (as your code needs the dynamic library to run).  This is why the
 LGPL exists.  I don't know if there is an equivalent BSD version.
 Again, not a lawyer :)

You don't need to be :-).  People's perception of a license is as important
as what it means in fact.  None of this is an issue for the DMD distribution
because I've granted Walter permission to distribute druntime under the
Phobos license, but it's something I want to take care of regardless.  I
may just make the darn thing public domain to save myself the hassle
of finding a license everyone is happy with.


Sean

Lars Ivar Igesund <larsivar igesund.net> writes:

Don wrote:

 Steven Schveighoffer wrote:
 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in any
 derivative works (i.e. compiled binaries).

 
 Are you sure? Where is that written down? I can't find that anywhere in
 the Tango license.

Steve is wrong in this matter.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund <larsivar igesund.net> writes:

Steven Schveighoffer wrote:

 "Piotrek" wrote
 Hello!

 It's just an idea. After reading about issues on disallowing DWT to stay
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some
 question appeared in my mind. For propaganda sake isn't it better to not
 make such a big division between phobos and tango in the module naming?
 Logically:

 phobos -> std
 tango  -> stdex (not tango -> tango)

 
 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in any
 derivative works (i.e. compiled binaries).  Phobos has a less restrictive
 opt-in policy.  I think Walter intends to keep it that way, at least for
 DMD.  Note that other compilers are free to use Tango or their own
 standard library, the D spec is pretty free from library references.

Sorry, where do you find this attribution clause? The only two restrictions put
on Tango source is:

 * You cannot relicense the source - can't possibly be a problem to anyone
 * You cannot take the source and say you wrote it (unless you actually did) -
not a problem for a single person unless he'd like to be dishonest.

Saying that Tango is license-encumbered in any way is a gross misunderstanding.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Lars Ivar Igesund" wrote
 Steven Schveighoffer wrote:

 "Piotrek" wrote
 Hello!

 It's just an idea. After reading about issues on disallowing DWT to stay
 in standardization area (Anomaly on Wiki4D GuiLibraries page) some
 question appeared in my mind. For propaganda sake isn't it better to not
 make such a big division between phobos and tango in the module naming?
 Logically:

 phobos -> std
 tango  -> stdex (not tango -> tango)

 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in any
 derivative works (i.e. compiled binaries).  Phobos has a less restrictive
 opt-in policy.  I think Walter intends to keep it that way, at least for
 DMD.  Note that other compilers are free to use Tango or their own
 standard library, the D spec is pretty free from library references.

 Sorry, where do you find this attribution clause? The only two 
 restrictions put on Tango source is:

 * You cannot relicense the source - can't possibly be a problem to anyone
 * You cannot take the source and say you wrote it (unless you actually 
 did) - not a problem for a single person unless he'd like to be dishonest.

 Saying that Tango is license-encumbered in any way is a gross 
 misunderstanding.

Sorry if I'm spreading misinformation, but I understood this clause in the 
BSD license to mean that any binary distribution must contain attribution:

"Redistributions in binary form must reproduce the above copyright notice, 
this list of conditions and the following disclaimer in the documentation 
and/or other materials provided with the distribution."

The mentioned copyright notice being "Copyright (c) 2004-2008, Tango 
contributors All rights reserved."

As D is statically compiled, any application which uses Tango is effectively 
a binary distribution of it.  At least that's what I interpret it as.  How 
do youi interpret the above line?

Conversely, the Phobos license's clause is:

"The origin of this software must not be misrepresented; you must not claim 
that you wrote the original software. If you use this software in a product, 
an acknowledgment in the product documentation would be appreciated but is 
not required."

Which I interpret to mean that you cannot misrepresent that you wrote 
Phobos, but it is appreciated if you give Digital Mars credit for it in your 
application.

I can't really understand whether it is required to distribute the source 
code of a derivative work under the Academic Free License, so I don't really 
understand that.  Maybe that is the license you can use for distributing 
binaries without attribution?

I'd love to be wrong, because that would mean Tango is a lot more open than 
I originally thought.

-Steve 

Lars Ivar Igesund <larsivar igesund.net> writes:

Steven Schveighoffer wrote:

 "Lars Ivar Igesund" wrote
 Steven Schveighoffer wrote:

 "Piotrek" wrote
 Hello!

 It's just an idea. After reading about issues on disallowing DWT to
 stay in standardization area (Anomaly on Wiki4D GuiLibraries page) some
 question appeared in my mind. For propaganda sake isn't it better to
 not make such a big division between phobos and tango in the module
 naming? Logically:

 phobos -> std
 tango  -> stdex (not tango -> tango)

 Let's not forget the licensing issues.  Tango is incompatible with some
 developers license wise, as you must include attribution for Tango in
 any
 derivative works (i.e. compiled binaries).  Phobos has a less
 restrictive
 opt-in policy.  I think Walter intends to keep it that way, at least for
 DMD.  Note that other compilers are free to use Tango or their own
 standard library, the D spec is pretty free from library references.

 Sorry, where do you find this attribution clause? The only two
 restrictions put on Tango source is:

 * You cannot relicense the source - can't possibly be a problem to anyone
 * You cannot take the source and say you wrote it (unless you actually
 did) - not a problem for a single person unless he'd like to be
 dishonest.

 Saying that Tango is license-encumbered in any way is a gross
 misunderstanding.

 
 Sorry if I'm spreading misinformation, but I understood this clause in the
 BSD license to mean that any binary distribution must contain attribution:
 
 "Redistributions in binary form must reproduce the above copyright notice,
 this list of conditions and the following disclaimer in the documentation
 and/or other materials provided with the distribution."
 
 The mentioned copyright notice being "Copyright (c) 2004-2008, Tango
 contributors All rights reserved."
 
 As D is statically compiled, any application which uses Tango is
 effectively
 a binary distribution of it.  At least that's what I interpret it as.  How
 do youi interpret the above line?

You are correct about the BSD license, but where you are wrong is the fact that
you as a user choose which of the two available licenses you wish to agree
with. BSD with the binary clause is necessary for compatibility with (L)GPL,
whereas APL, stands for completely free binary use, but the source restriction
that you cannot remove the name of the authors (although you can freely augment
the list if that is a correct picture).

So it is not both licenses, but the one that suits you.

 Conversely, the Phobos license's clause is:
 
 "The origin of this software must not be misrepresented; you must not
 claim that you wrote the original software. If you use this software in a
 product, an acknowledgment in the product documentation would be
 appreciated but is not required."

In practice this should be the same as the APL, only that the APL is written in
legalese for better or worse.


 I can't really understand whether it is required to distribute the source
 code of a derivative work under the Academic Free License, so I don't
 really
 understand that. 

It is not required, AFAIK only LGPL and GPL of the common licenses require that.

 Maybe that is the license you can use for distributing
 binaries without attribution?

Yes.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Lars Ivar Igesund" wrote
 Steven Schveighoffer wrote:
 I can't really understand whether it is required to distribute the source
 code of a derivative work under the Academic Free License, so I don't
 really
 understand that.

 It is not required, AFAIK only LGPL and GPL of the common licenses require 
 that.

That is good to hear.  Can a statement like this be made on the license 
page?  Or in the license itself?  I found it very difficult to discern what 
was meant, at some point it states that you must provide a copy of the 
source code, but I wasn't sure how that applies.

Sorry for the confusion...

-Steve 

Lars Ivar Igesund <larsivar igesund.net> writes:

Steven Schveighoffer wrote:

 "Lars Ivar Igesund" wrote
 Steven Schveighoffer wrote:
 I can't really understand whether it is required to distribute the
 source code of a derivative work under the Academic Free License, so I
 don't really
 understand that.

 It is not required, AFAIK only LGPL and GPL of the common licenses
 require that.

 
 That is good to hear.  Can a statement like this be made on the license
 page?  Or in the license itself?  I found it very difficult to discern
 what was meant, at some point it states that you must provide a copy of
 the source code, but I wasn't sure how that applies.

I thought the license page (.../wiki/License) was pretty clear  ... even if the
licenses themselves aren't.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Bill Baxter <wbaxter gmail.com> writes:

On Wed, Jan 21, 2009 at 6:29 AM, Lars Ivar Igesund <larsivar igesund.net> wrote:

 I thought the license page (.../wiki/License) was pretty clear  ... even if
the licenses themselves aren't.

Actually this was something I meant to bring up.  I couldn't actually
find that page when I was looking for it.  I ended up doing a search
on the Tango site for "license".

I think there should be a link to the license page somewhere on the
front page.   Right now the word "license" doesn't appear anywhere on
that page.

--bb

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

Bill Baxter wrote:
 On Wed, Jan 21, 2009 at 6:29 AM, Lars Ivar Igesund <larsivar igesund.net>
wrote:
 
 I thought the license page (.../wiki/License) was pretty clear  ... even if
the licenses themselves aren't.

 
 Actually this was something I meant to bring up.  I couldn't actually
 find that page when I was looking for it.  I ended up doing a search
 on the Tango site for "license".
 
 I think there should be a link to the license page somewhere on the
 front page.   Right now the word "license" doesn't appear anywhere on
 that page.

There’s a link on the front page “All Documentation” where you find the 
link to the “License Agreement” page, but having the latter on the front 
page wouldn’t be a bad idea either, I suppose.

Yigal Chripun <yigal100 gmail.com> writes:

Bill Baxter wrote:
 On Wed, Jan 21, 2009 at 6:29 AM, Lars Ivar Igesund<larsivar igesund.net> 
wrote:

 I thought the license page (.../wiki/License) was pretty clear  ... even if
the licenses themselves aren't.

 Actually this was something I meant to bring up.  I couldn't actually
 find that page when I was looking for it.  I ended up doing a search
 on the Tango site for "license".

 I think there should be a link to the license page somewhere on the
 front page.   Right now the word "license" doesn't appear anywhere on
 that page.

 --bb

The link is on the "about" page.

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

Lars Ivar Igesund wrote:
 Steven Schveighoffer wrote:
 
 "Lars Ivar Igesund" wrote
 Steven Schveighoffer wrote:
 I can't really understand whether it is required to distribute the
 source code of a derivative work under the Academic Free License, so I
 don't really
 understand that.

 It is not required, AFAIK only LGPL and GPL of the common licenses
 require that.

 That is good to hear.  Can a statement like this be made on the license
 page?  Or in the license itself?  I found it very difficult to discern
 what was meant, at some point it states that you must provide a copy of
 the source code, but I wasn't sure how that applies.

 
 I thought the license page (.../wiki/License) was pretty clear  ... even if
the licenses themselves aren't.

It’s actually /wiki/LibraryLicense. I’ve created /wiki/License including 
and displaying the contents of LibraryLicense.

Jason House <jason.james.house gmail.com> writes:

dsimcha Wrote:

 Yeah, but we also want decent performance and even compared to opApply,
 coroutines/fibers are slow as molasses in January at the North Pole during the
 last Ice Age.

One type of coroutine optimization was mentioned previously on this list:
http://www.digitalmars.com/d/archives/digitalmars/D/Coroutine_s_Communication_70713.html

I'm sure that it's possible to optimize coroutines such that they require less
restoring of the stack, or flattening into inline functions.  I'm also going to
guess that this style of optimization won't make it into dmd for a very long
time.  

I'd much prefer to quickly write a bug-free coroutine ranges and then go back
and optimize those that show up in the profiler as bottlenecks.