www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Two standard libraries?

reply Steve Teale <steve.teale britseyeview.com> writes:
It bothers me that Phobos and Tango seem to be completely divergent.  One of
the things that makes a language successful is that it has a good standard
library.  It seems that with D, you have to be a betting man - which standard
library will prevail.

It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.

I am not saying that Phobos is perfect.  It has lots of omissions, but I have a
feeling that it is about at the right level to enable authors to write the more
OO stuff on top of it.

I'm sure that this is a sensitive subject, but there you go!  I think we all
agree that Walter has done a damn good job on D, so why should we reject his
thinking on Phobos?  I've been watching Walter for a long time now, and in my
book, he knows as much about his subject as anyone does, especially considering
the coverage that's expected of him.

If D is to succeed, I think we should work together rather than compete.  I'd
like to see a much more formal system for contributors to take responsibility
for areas of Phobos.  Maybe it exists, but if it does, it's hardly in your
face.  I'd also like to see people back off on trying to replace it.  Let's
improve it and augment it.
Jul 13 2007
next sibling parent reply "Craig Black" <cblack ara.com> writes:
Dude, you are totally off base.  Vanity!?  Are you kidding me?  The people 
behind Tango are not looking for glory.  They simply want a better standard 
library and so are taking the necessary steps to achieve that goal.  We 
could "improve and augment" Phobos if Walter had the time to coordinate and 
organize contributions.  The Tango project is way more organized than Phobos 
and encourages multiple contributors.  I think it was created out of 
frustration with Phobos.  If Walter had been more proactive about 
coordinating and integrating outisde contributions, I don't think that Tango 
would have ever been started.

I'm not disrespecting Walter in any way.  Walter has indeed done a great job 
on the D language, but Phobos as a standard library is somewhat lacking. 
It's quite understandable that he just doesn't have enough time to maintain 
it properly.  Maintaining the D compiler is a full-time position. 
Maintaining the standard library is another full time position, and is more 
appropriately delegated to someone else.

-Craig

"Steve Teale" <steve.teale britseyeview.com> wrote in message 
news:f789hk$o0m$1 digitalmars.com...

 It bothers me that Phobos and Tango seem to be completely divergent.  One 
 of the things that makes a language successful is that it has a good 
 standard library.  It seems that with D, you have to be a betting man - 
 which standard library will prevail.

 It seemes to me that given Walter's definition of the language - a system 
 programming language - that Phobos is closer to the mark.  If users want a 
 more object oriented standard library, that's all well and good, but it 
 should be a shoe-in, then if you want to use the OO stuff you can, but 
 code that's been written to work with Phobos should work unmodified with 
 other libraries.  (Note the recent discussion on C++ security). Any other 
 approach seems to me to reek of vanity.

 I am not saying that Phobos is perfect.  It has lots of omissions, but I 
 have a feeling that it is about at the right level to enable authors to 
 write the more OO stuff on top of it.

 I'm sure that this is a sensitive subject, but there you go!  I think we 
 all agree that Walter has done a damn good job on D, so why should we 
 reject his thinking on Phobos?  I've been watching Walter for a long time 
 now, and in my book, he knows as much about his subject as anyone does, 
 especially considering the coverage that's expected of him.

 If D is to succeed, I think we should work together rather than compete. 
 I'd like to see a much more formal system for contributors to take 
 responsibility for areas of Phobos.  Maybe it exists, but if it does, it's 
 hardly in your face.  I'd also like to see people back off on trying to 
 replace it.  Let's improve it and augment it.
Jul 13 2007
parent Alexander Panek <alexander.panek brainsware.org> writes:
I can only confirm what Craig said; Tango is an approach of the
community to provide a standard library - for the community. Apart from
that, it's not about competition, actually, but about improvement. The
goal is to make D more applicable and scalable for projects with
more complex designs.

Honestly, the fact that people seem to think "Walter done a great job
with D/DMD, lets believe his libraries are best, too!", or similar,
makes me a bit scared. I really appreciate and respect Walter, of
course, but sacrificing his work, even though it (Phobos) is not his
essential competence, is just ridiculous. No offense intended, but
there are some better *library* designers out there than Walter will
ever be, while being the only developer of DMD.

Kind regards,
Alex

On Fri, 13 Jul 2007 12:17:15 -0500
"Craig Black" <cblack ara.com> wrote:


 Dude, you are totally off base.  Vanity!?  Are you kidding me?  The
 people behind Tango are not looking for glory.  They simply want a
 better standard library and so are taking the necessary steps to
 achieve that goal.  We could "improve and augment" Phobos if Walter
 had the time to coordinate and organize contributions.  The Tango
 project is way more organized than Phobos and encourages multiple
 contributors.  I think it was created out of frustration with
 Phobos.  If Walter had been more proactive about coordinating and
 integrating outisde contributions, I don't think that Tango would
 have ever been started.
 
 I'm not disrespecting Walter in any way.  Walter has indeed done a
 great job on the D language, but Phobos as a standard library is
 somewhat lacking. It's quite understandable that he just doesn't have
 enough time to maintain it properly.  Maintaining the D compiler is a
 full-time position. Maintaining the standard library is another full
 time position, and is more appropriately delegated to someone else.
 
 -Craig
 
 "Steve Teale" <steve.teale britseyeview.com> wrote in message 
 news:f789hk$o0m$1 digitalmars.com...

 It bothers me that Phobos and Tango seem to be completely
 divergent.  One of the things that makes a language successful is
 that it has a good standard library.  It seems that with D, you
 have to be a betting man - which standard library will prevail.

 It seemes to me that given Walter's definition of the language - a
 system programming language - that Phobos is closer to the mark.
 If users want a more object oriented standard library, that's all
 well and good, but it should be a shoe-in, then if you want to use
 the OO stuff you can, but code that's been written to work with
 Phobos should work unmodified with other libraries.  (Note the
 recent discussion on C++ security). Any other approach seems to me
 to reek of vanity.

 I am not saying that Phobos is perfect.  It has lots of omissions,
 but I have a feeling that it is about at the right level to enable
 authors to write the more OO stuff on top of it.

 I'm sure that this is a sensitive subject, but there you go!  I
 think we all agree that Walter has done a damn good job on D, so
 why should we reject his thinking on Phobos?  I've been watching
 Walter for a long time now, and in my book, he knows as much about
 his subject as anyone does, especially considering the coverage
 that's expected of him.

 If D is to succeed, I think we should work together rather than
 compete. I'd like to see a much more formal system for contributors
 to take responsibility for areas of Phobos.  Maybe it exists, but
 if it does, it's hardly in your face.  I'd also like to see people
 back off on trying to replace it.  Let's improve it and augment it.
Jul 13 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
What's so wrong with having two standard libraries and letting users choose the
one they feel more comfortable with? Having come from a Java background, I find
Tango much easier to work with and powerful than Phobos, but to each his own. I
just wish it was easier to link against one or the other (compiler switch...)
instead of having to switch between them all the time.

Steve Teale Wrote:


 It bothers me that Phobos and Tango seem to be completely divergent.  One of
the things that makes a language successful is that it has a good standard
library.  It seems that with D, you have to be a betting man - which standard
library will prevail.
 
 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.
 
 I am not saying that Phobos is perfect.  It has lots of omissions, but I have
a feeling that it is about at the right level to enable authors to write the
more OO stuff on top of it.
 
 I'm sure that this is a sensitive subject, but there you go!  I think we all
agree that Walter has done a damn good job on D, so why should we reject his
thinking on Phobos?  I've been watching Walter for a long time now, and in my
book, he knows as much about his subject as anyone does, especially considering
the coverage that's expected of him.
 
 If D is to succeed, I think we should work together rather than compete.  I'd
like to see a much more formal system for contributors to take responsibility
for areas of Phobos.  Maybe it exists, but if it does, it's hardly in your
face.  I'd also like to see people back off on trying to replace it.  Let's
improve it and augment it.
Jul 13 2007
parent reply Tristam MacDonald <swiftcoder gmail.com> writes:
The problem is that I (as a user) want to use one library. And if one 3rd party
library I want to use depends on Phobos, and another on Tango, they either have
to be entirely interoperable - correct me if I am wrong, but this doesn't seem
to be the case - or I end up rolling my own, because neither one does what I
want.

I quite frankly don't like Tango's Pythonesque 'batteries included' approach,
but that is of course entirely a matter of personal opinion. I am not fond of
Phobos either, mostly because of a complete lack of templated containers.

What I would like to see is an approach which combines a small, lean 'core'
library (just the basics like IO and containers), and then have the 'batteries'
implemented as distinct small libraries on top of the core. This allows one to
choose exactly what functionality one needs, with out the extra 'fluff'.

Robert Fraser Wrote:


 What's so wrong with having two standard libraries and letting users choose
the one they feel more comfortable with? Having come from a Java background, I
find Tango much easier to work with and powerful than Phobos, but to each his
own. I just wish it was easier to link against one or the other (compiler
switch...) instead of having to switch between them all the time.
 
 Steve Teale Wrote:
 

 It bothers me that Phobos and Tango seem to be completely divergent.  One of
the things that makes a language successful is that it has a good standard
library.  It seems that with D, you have to be a betting man - which standard
library will prevail.
 
 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.
 
 I am not saying that Phobos is perfect.  It has lots of omissions, but I have
a feeling that it is about at the right level to enable authors to write the
more OO stuff on top of it.
 
 I'm sure that this is a sensitive subject, but there you go!  I think we all
agree that Walter has done a damn good job on D, so why should we reject his
thinking on Phobos?  I've been watching Walter for a long time now, and in my
book, he knows as much about his subject as anyone does, especially considering
the coverage that's expected of him.
 
 If D is to succeed, I think we should work together rather than compete.  I'd
like to see a much more formal system for contributors to take responsibility
for areas of Phobos.  Maybe it exists, but if it does, it's hardly in your
face.  I'd also like to see people back off on trying to replace it.  Let's
improve it and augment it.
Jul 13 2007
parent Sean Kelly <sean f4.ca> writes:
Tristam MacDonald wrote:

 
 What I would like to see is an approach which combines a small, lean 'core'
library (just the basics like IO and containers), and then have the 'batteries'
implemented as distinct small libraries on top of the core. This allows one to
choose exactly what functionality one needs, with out the extra 'fluff'.


Tango is actually designed to work this way, but in practice most people 
don't want to bother with the extra installation steps that such an 
approach requires.  Still, I expect that at some point, there will be 
2-3 different Tango distributions.  One which includes everything, and 
the others being more minimal.  Using a build tool like Bud or Rebuild 
tends to make the most sense with such an approach, because dealing with 
separate libraries for each package can be cumbersome.


Sean
Jul 13 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Steve Teale wrote:

 
 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security).


While one might argue that it is easier to wrap a strictly procedural 
library with an OO layer than vice-versa, I think the ease with which 
any library may be encapsulated in a wrapper is more dependent on its 
design (the assumptions it makes, how features are exposed, etc) than on 
whether the interface uses functions or objects.  That said, I don't 
personally consider Tango to be an object-oriented library because it 
does not require the user to define his own objects in order to use it.


Sean
Jul 13 2007
parent reply Steve Teale <steve.teale britseyeview.com> writes:
Sean Kelly Wrote:


 Steve Teale wrote:

 
 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security).


 
 While one might argue that it is easier to wrap a strictly procedural 
 library with an OO layer than vice-versa, I think the ease with which 
 any library may be encapsulated in a wrapper is more dependent on its 
 design (the assumptions it makes, how features are exposed, etc) than on 
 whether the interface uses functions or objects.  That said, I don't 
 personally consider Tango to be an object-oriented library because it 
 does not require the user to define his own objects in order to use it.
 
 
 Sean


Sean, I take your point, and maybe should not have used the term "OO", but my
idea of progress is:

printf("X is: %s\n", toStringz(x))
cout << "X is: " << x << endl;
Stdout("X is: ")(x).newline;
writefln("X is: %s", x);

rather than:

printf("X is: %s\n", toStringz(&x))
cout << "X is: " << x << endl;
writefln("X is: %s", x);
Stdout("X is: ")(x).newline;
Jul 14 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Steve Teale wrote:

 Sean Kelly Wrote:
 

 Steve Teale wrote:

 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security).


 While one might argue that it is easier to wrap a strictly procedural 
 library with an OO layer than vice-versa, I think the ease with which 
 any library may be encapsulated in a wrapper is more dependent on its 
 design (the assumptions it makes, how features are exposed, etc) than on 
 whether the interface uses functions or objects.  That said, I don't 
 personally consider Tango to be an object-oriented library because it 
 does not require the user to define his own objects in order to use it.


 Sean


 
 Sean, I take your point, and maybe should not have used the term "OO", but my
idea of progress is:
 
 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);
 
 rather than:
 
 printf("X is: %s\n", toStringz(&x))
 cout << "X is: " << x << endl;
 writefln("X is: %s", x);
 Stdout("X is: ")(x).newline;
 


For what it's worth, Stdout supports a number of different output 
methods.  The "whisper syntax" you show above is just the most commonly 
known.  For formatted output similar to writefln you'd do:

Stdout.format( "X is: {}", x ).newline;

Another option is:

Stdout( "X is: ", x ).newline;

This last prints comma-delimeted output, since that's how it appears in 
the Stdout call.  For what it's worth, Kris recently explained all this 
on D.learn.


Sean
Jul 14 2007
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly wrote:

 For what it's worth, Stdout supports a number of different output 
 methods.  The "whisper syntax" you show above is just the most commonly 
 known.  For formatted output similar to writefln you'd do:
 
 Stdout.format( "X is: {}", x ).newline;



Using Stdout.formatln() instead of Stdout.format().newline is more 
likely to be accepted by phobos users.

Out of curiosity, why is {} used instead of %s?
Jul 14 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:f7atnl$2lm6$1 digitalmars.com...

 Out of curiosity, why is {} used instead of %s?


It makes it easier to make more flexible formatting, and also so you can put 
indices into the braces.  Indexing the arguments is important because word 
order in different languages can be different.  For example, say you had the 
message in English:

"Employee {} is not in personnel database {}", personName, databaseName

Now look at a language like Japanese, where you'd probably put the database 
name first; it'd be arranged something like "in personnel database {}, 
employee {} does not exist".  Now you have to change the order of the 
arguments after the format string.  But with indexing, you can say {0} 
always is the employee name, and {1} always is the database name, so that 
you can format them in the correct order for other languages, without having 
to change the actual format code.  Just change the format string.

Another reason is custom formatting.  You know how you can do %x with 
printf-style to get a hex number.  You can add in some digits to change the 
number of digits to display etc. like %08x.  But what if you had a class 
which could be formatted beyond the simple "use toString (or toUtf8 in Tango 
:P)"?  Like, what if that class represented a set of coordinates, like 
latitude/longitude?  There might be more than one way to display it; 
including or ommitting some of the pieces of the coordinates, rouding pieces 
off to certain precisions etc.  What you can do with the {} formatting 
specifiers is pass an entirely custom format string after the colon which is 
used to format certain types.  You'd have to write a custom formatter class 
to do this, but the basic formatting framework is already in place; all you 
have to do is write a formatting method which parses out that string and 
formats the components correctly.  No way would you be able to do that with 
the % formatters without some ugly additions.

And lastly I think the {} looks prettier ;)
Jul 14 2007
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Jarrett Billingsley wrote:

 What you can do with the {} formatting
 specifiers is pass an entirely custom format string after the colon which is 
 used to format certain types.


The colon?  I've never seen examples of Tango I/O with a colon.  Do you 
mean something like the following?

Stdout.format("Foo with custom formatting = {:custom}",foo);
Jul 14 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
Jason House schrieb:

 The colon?  I've never seen examples of Tango I/O with a colon.  Do you
 mean something like the following?
 
 Stdout.format("Foo with custom formatting = {:custom}",foo);


{index:format,alignment}

tango.text.convert.Layout unittests:
http://dsource.org/projects/tango/browser/trunk/tango/text/convert/Layout.d#L571
Jul 14 2007
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Jarrett Billingsley wrote:

 "Jason House" <jason.james.house gmail.com> wrote in message 
 news:f7atnl$2lm6$1 digitalmars.com...

 Out of curiosity, why is {} used instead of %s?


 
 It makes it easier to make more flexible formatting, and also so you can put 
 indices into the braces.  Indexing the arguments is important because word 
 order in different languages can be different.  For example, say you had the 
 message in English:
 
 "Employee {} is not in personnel database {}", personName, databaseName
 
 Now look at a language like Japanese, where you'd probably put the database 
 name first; it'd be arranged something like "in personnel database {}, 
 employee {} does not exist".  Now you have to change the order of the 
 arguments after the format string.  But with indexing, you can say {0} 
 always is the employee name, and {1} always is the database name, so that 
 you can format them in the correct order for other languages, without having 
 to change the actual format code.  Just change the format string.


That's a great argument -- I think it deserves to be in the Tango docs. It's 
surely a frequently asked question from programmers with a C/C++/Phobos
background.
Jul 14 2007
prev sibling parent reply Roberto Mariottini <rmariottini mail.com> writes:
Jarrett Billingsley wrote:
[...]

 Now look at a language like Japanese, where you'd probably put the database 
 name first; it'd be arranged something like "in personnel database {}, 
 employee {} does not exist".  Now you have to change the order of the 
 arguments after the format string.  But with indexing, you can say {0} 
 always is the employee name, and {1} always is the database name, so that 
 you can format them in the correct order for other languages, without having 
 to change the actual format code.  Just change the format string.


May I suggest to use an identifier instead of a numeric index?
I have several years of experience with multi-language code and I can 
say that for a translator is better.

For example:

"{0} has {1} pieces in {2}"

Could be:

"{supplier} has {stock} pieces in {city}"

and make the translator happy.

Ciao
Jul 16 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Roberto Mariottini wrote:

 Jarrett Billingsley wrote:
 [...]

 Now look at a language like Japanese, where you'd probably put the 
 database name first; it'd be arranged something like "in personnel 
 database {}, employee {} does not exist".  Now you have to change the 
 order of the arguments after the format string.  But with indexing, 
 you can say {0} always is the employee name, and {1} always is the 
 database name, so that you can format them in the correct order for 
 other languages, without having to change the actual format code.  
 Just change the format string.


 
 May I suggest to use an identifier instead of a numeric index?
 I have several years of experience with multi-language code and I can 
 say that for a translator is better.
 
 For example:
 
 "{0} has {1} pieces in {2}"
 
 Could be:
 
 "{supplier} has {stock} pieces in {city}"
 
 and make the translator happy.


How would such identifiers be matched up with variadic arguments?


Sean
Jul 16 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Sean Kelly wrote:

 Roberto Mariottini wrote:

 Jarrett Billingsley wrote:
 [...]

 Now look at a language like Japanese, where you'd probably put the 
 database name first; it'd be arranged something like "in personnel 
 database {}, employee {} does not exist".  Now you have to change the 
 order of the arguments after the format string.  But with indexing, 
 you can say {0} always is the employee name, and {1} always is the 
 database name, so that you can format them in the correct order for 
 other languages, without having to change the actual format code.  
 Just change the format string.


 May I suggest to use an identifier instead of a numeric index?
 I have several years of experience with multi-language code and I can 
 say that for a translator is better.

 For example:

 "{0} has {1} pieces in {2}"

 Could be:

 "{supplier} has {stock} pieces in {city}"

 and make the translator happy.


 
 How would such identifiers be matched up with variadic arguments?


hmm.. Could it match the variable names with the inserts?

string supplier = "Bob";
string city = "Someplace far far away";
int stock = 5;

format("{supplier} has {stock} pieces in {city}",
   supplier, city, stock);

Maybe with some more reflection features it could be possible.

Regan
Jul 16 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Regan Heath Wrote:


 For example:

 "{0} has {1} pieces in {2}"

 Could be:

 "{supplier} has {stock} pieces in {city}"

 and make the translator happy.


 
 How would such identifiers be matched up with variadic arguments?


 
 hmm.. Could it match the variable names with the inserts?
 
 string supplier = "Bob";
 string city = "Someplace far far away";
 int stock = 5;
 
 format("{supplier} has {stock} pieces in {city}",
    supplier, city, stock);
 
 Maybe with some more reflection features it could be possible.
 
 Regan
 


 
Well, not even scripting languages keep names of local variables in memory at
runtime, so I assume you mean compile-time. That means that the localized
properties would have to be known at compile time (via file imports, etc.),
which, assuming you store every language in the executable, might lead to some
code bloat and a not-so-nimble architecture. But if that's what you're going
for, someone demonstrated a while back that this is already possible, via
mixins, and will get a lot easier with macros. Search for PHP-style print or
something like that (I'm too lazy & limited by BlackBerry bandwidth to  get you
the exact link).
Jul 16 2007
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Robert Fraser wrote:

 Well, not even scripting languages keep names of local variables in
 memory at runtime...


Hmm?


 a = 12
 b = 'waffles'
 locals()






{'__builtins__': <module '__builtin__' (built-in)>, '__name__': 
'__main__', 'b': 'waffles', '__doc__': None, 'a': 12}

 "%(a)s %(b)s" % locals()






'12 waffles'

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Jul 16 2007
parent reply =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Kirk McDonald wrote:

 Robert Fraser wrote:

 Well, not even scripting languages keep names of local variables in
 memory at runtime...


 
 Hmm?
 
  >>> a = 12
  >>> b = 'waffles'
  >>> locals()
 {'__builtins__': <module '__builtin__' (built-in)>, '__name__': 
 '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
  >>> "%(a)s %(b)s" % locals()
 '12 waffles'
 


And if I may add:

<?php

$a = 5;
$b = 'a';
$$b = 'Hello, world!';
echo $a;

?>
Jul 16 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Julio César Carrascal Urquijo wrote:

 Kirk McDonald wrote:

 Robert Fraser wrote:

 Well, not even scripting languages keep names of local variables in
 memory at runtime...


 Hmm?

  >>> a = 12
  >>> b = 'waffles'
  >>> locals()
 {'__builtins__': <module '__builtin__' (built-in)>, '__name__': 
 '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
  >>> "%(a)s %(b)s" % locals()
 '12 waffles'


 
 And if I may add:
 
 <?php
 
 $a = 5;
 $b = 'a';
 $$b = 'Hello, world!';
 echo $a;
 
 ?>


And also Ruby.


puts Symbol.all_symbols.inspect


This will print for you an array of a few thousand symbols from the 
runtime, among them the names of many variables.  Changing the source to:
myVar = 42
puts Symbol.all_symbols.index(:myVar)

Gave me '1117'.  At least in Ruby each such symbol is retained exactly 
once, no matter how many things have that name.  (Otherwise... could you 
imagine the memory consumption...)

-- Chris Nicholson-Sauls
Jul 17 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
I stand corrected.

Chris Nicholson-Sauls Wrote:


 Julio César Carrascal Urquijo wrote:

 Kirk McDonald wrote:

 Robert Fraser wrote:

 Well, not even scripting languages keep names of local variables in
 memory at runtime...


 Hmm?

  >>> a = 12
  >>> b = 'waffles'
  >>> locals()
 {'__builtins__': <module '__builtin__' (built-in)>, '__name__': 
 '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
  >>> "%(a)s %(b)s" % locals()
 '12 waffles'


 
 And if I may add:
 
 <?php
 
 $a = 5;
 $b = 'a';
 $$b = 'Hello, world!';
 echo $a;
 
 ?>


 
 And also Ruby.
 

 puts Symbol.all_symbols.inspect
 
 
 This will print for you an array of a few thousand symbols from the 
 runtime, among them the names of many variables.  Changing the source to:
 myVar = 42
 puts Symbol.all_symbols.index(:myVar)
 
 Gave me '1117'.  At least in Ruby each such symbol is retained exactly 
 once, no matter how many things have that name.  (Otherwise... could you 
 imagine the memory consumption...)
 
 -- Chris Nicholson-Sauls
Jul 17 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:

 I stand corrected.


Ok people come on.  Doesn't he have something of a point?  Doesn't byte 
compilation at least remove the names of local variables that clearly 
are not and therefor cannot ever be referred to by name?

--bb
Jul 17 2007
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:

 Robert Fraser wrote:

 I stand corrected.


 
 Ok people come on.  Doesn't he have something of a point?  Doesn't byte 
 compilation at least remove the names of local variables that clearly 
 are not and therefor cannot ever be referred to by name?
 
 --bb


It depends upon the language.  To return to Ruby as an example, this is 
a language that only supports full reflection, but even full mutation at 
run-time, to the extent that much of a Ruby application could easily be 
generated on the fly.  Therefore, in this case at least, absolute all 
such state information and meta-information MUST be retained.  In the 
case of PHP, for example, it might be able to toss quite a lot of them, 
yes, based on the presence or absence of those few constructs that make 
use of them.  Then again that could actually make it compile slower, and 
PHP apps aren't usually designed to be long-lived.  Increased PHP 
compile times means losing much of its usefulness.

I'd be interested in seeing what Java does.

-- Chris Nicholson-Sauls
Jul 17 2007
parent OF <nospam nospammington.com> writes:
Chris Nicholson-Sauls Wrote:


 [...]
 
 I'd be interested in seeing what Java does.
 
 -- Chris Nicholson-Sauls


Java bytecode doesn't have names for local variables, just stack indexes...
though it's more than possible that such information could be included for
debug reasons. I've only worked with the actual assembly, so dunno about the
later really.
Jul 18 2007
prev sibling parent renoX <renosky free.fr> writes:
Bill Baxter a écrit :

 Robert Fraser wrote:

 I stand corrected.


 
 Ok people come on.  Doesn't he have something of a point?  Doesn't byte 
 compilation at least remove the names of local variables that clearly 
 are not and therefor cannot ever be referred to by name?


Well, ideally if there is a function which needs to the variable name at 
runtime, then the compiler *should* keep the name.. Otherwise, yes the 
compiler can drop the name to save memory.

Using index to refer to variable in a list strikes me as a very bad idea 
leading to a lot of potential mistake (think about the maintenance!), so 
a way to use variables name (at least for constant string at compilation 
time) should be provided.

I have made a 'format string' templated function which worked this way, 
I posted it some time ago..

renoX


 
 --bb
Jul 28 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Robert Fraser wrote:

 Regan Heath Wrote:
 

 For example:

 "{0} has {1} pieces in {2}"

 Could be:

 "{supplier} has {stock} pieces in {city}"

 and make the translator happy.


 How would such identifiers be matched up with variadic arguments?


 hmm.. Could it match the variable names with the inserts?

 string supplier = "Bob";
 string city = "Someplace far far away";
 int stock = 5;

 format("{supplier} has {stock} pieces in {city}",
    supplier, city, stock);

 Maybe with some more reflection features it could be possible.

 Regan


  
 Well, not even scripting languages keep names of local variables in memory at
runtime, so I assume you mean compile-time. That means that the localized
properties would have to be known at compile time (via file imports, etc.),
which, assuming you store every language in the executable, might lead to some
code bloat and a not-so-nimble architecture. But if that's what you're going
for, someone demonstrated a while back that this is already possible, via
mixins, and will get a lot easier with macros. Search for PHP-style print or
something like that (I'm too lazy & limited by BlackBerry bandwidth to  get you
the exact link).


That was me. It's true, no new reflection features are required. The difficulty 
is in deciding how it should work, rather than implementing it.
Specifically, what do you do if some of the variables are calculations?
Eg, if stock is (palettesize*numberofpalettes*15) ?
You could do
format("{supplier} has {stock = (palettesize*numberofpalettes*15)} pieces in 
{city}");
But I don't think that's what was intended -- you don't want the translator 
seeing the calculations!

You could have a separate string converting names to indices, but it's starting 
to look clumsy.
Jul 16 2007
parent Reiner Pope <some address.com> writes:
Don Clugston wrote:

 Robert Fraser wrote:

 Regan Heath Wrote:


 For example:

 "{0} has {1} pieces in {2}"

 Could be:

 "{supplier} has {stock} pieces in {city}"

 and make the translator happy.


 How would such identifiers be matched up with variadic arguments?


 hmm.. Could it match the variable names with the inserts?

 string supplier = "Bob";
 string city = "Someplace far far away";
 int stock = 5;

 format("{supplier} has {stock} pieces in {city}",
    supplier, city, stock);

 Maybe with some more reflection features it could be possible.

 Regan


  
 Well, not even scripting languages keep names of local variables in 
 memory at runtime, so I assume you mean compile-time. That means that 
 the localized properties would have to be known at compile time (via 
 file imports, etc.), which, assuming you store every language in the 
 executable, might lead to some code bloat and a not-so-nimble 
 architecture. But if that's what you're going for, someone 
 demonstrated a while back that this is already possible, via mixins, 
 and will get a lot easier with macros. Search for PHP-style print or 
 something like that (I'm too lazy & limited by BlackBerry bandwidth 
 to  get you the exact link).


 
 That was me. It's true, no new reflection features are required. The 
 difficulty is in deciding how it should work, rather than implementing it.
 Specifically, what do you do if some of the variables are calculations?
 Eg, if stock is (palettesize*numberofpalettes*15) ?
 You could do
 format("{supplier} has {stock = (palettesize*numberofpalettes*15)} 
 pieces in {city}");
 But I don't think that's what was intended -- you don't want the 
 translator seeing the calculations!
 
 You could have a separate string converting names to indices, but it's 
 starting to look clumsy.


Alternatively, you could generate a name-to-varargs-index AA at 
compile-time, and use this in your runtime string formatter. Something like:

int stock = ... ;
string supplier = ... ;
City city = ... ;
string formatstring = getLocalizedFormatString(); // runtime
mixin(DoRuntimeFormat!(formatstring, stock, supplier, city));

...

template DoRuntimeFormat(alias formatString, Names...)
{
     const char[] DoRuntimeFormat = "format(" + formatString.stringof
        + ", " + ConvertToAA!(Names) + ");";
}


   -- Reiner
Jul 17 2007
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Roberto Mariottini wrote:

 May I suggest to use an identifier instead of a numeric index?
 I have several years of experience with multi-language code and I can 
 say that for a translator is better.
 
 For example:
 
 "{0} has {1} pieces in {2}"
 
 Could be:
 
 "{supplier} has {stock} pieces in {city}"
 
 and make the translator happy.



It's an interesting idea, but the trick is knowing how to go from the 
identifier into the literal numerical index of the arguments.  Something 
like "{0,supplier} has {1,stock} pieces in {2,city}" could work.

Of course, if you're really going to support internationalization, it'd 
be nice to not need to translate one copy of the program into another 
and simply embed the text for multiple languages in the command line. 
Another candidate would be to put it through some kind of behind the 
scenes translator.  Maybe the two could be combined...  where the 
program could be run for a specific language and text would be 
translated first by a manual translation if available and then either 
dump the original (english) or attempt an automatic translation.
Jul 16 2007
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Sean Kelly Wrote:


 Steve Teale wrote:

 Sean Kelly Wrote:
 

 Steve Teale wrote:

 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security).


 While one might argue that it is easier to wrap a strictly procedural 
 library with an OO layer than vice-versa, I think the ease with which 
 any library may be encapsulated in a wrapper is more dependent on its 
 design (the assumptions it makes, how features are exposed, etc) than on 
 whether the interface uses functions or objects.  That said, I don't 
 personally consider Tango to be an object-oriented library because it 
 does not require the user to define his own objects in order to use it.


 Sean


 
 Sean, I take your point, and maybe should not have used the term "OO", but my
idea of progress is:
 
 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);
 
 rather than:
 
 printf("X is: %s\n", toStringz(&x))
 cout << "X is: " << x << endl;
 writefln("X is: %s", x);
 Stdout("X is: ")(x).newline;
 


 
 For what it's worth, Stdout supports a number of different output 
 methods.  The "whisper syntax" you show above is just the most commonly 
 known.  For formatted output similar to writefln you'd do:
 
 Stdout.format( "X is: {}", x ).newline;
 
 Another option is:
 
 Stdout( "X is: ", x ).newline;
 
 This last prints comma-delimeted output, since that's how it appears in 
 the Stdout call.  For what it's worth, Kris recently explained all this 
 on D.learn.
 
 
 Sean


Sean,

I give in.  I know that your motivations are genuine.  I just don't want two
see classes of D citizens.  In Europe we fought for centuries over this sort of
thing.  Somehow we should get to astate of affairs where if you are writing a
library you should not have to make a religious choice as to which standard
library you subscribe to.  Please talk to Walter at the conference, and try and
get this sorted.  I would love to attend, but I live on the other side of the
world, and still need to go to work.

Steve
Jul 14 2007
parent Sean Kelly <sean f4.ca> writes:
Steve Teale wrote:

 
 Sean,
 
 I give in.  I know that your motivations are genuine.  I just don't want two
see classes of D citizens.  In Europe we fought for centuries over this sort of
thing.  Somehow we should get to astate of affairs where if you are writing a
library you should not have to make a religious choice as to which standard
library you subscribe to.  Please talk to Walter at the conference, and try and
get this sorted.  I would love to attend, but I live on the other side of the
world, and still need to go to work.


Releasing Tango was a calculated short-term risk.  We felt we had 
something to offer, but wanted it left up to the community to decide 
whether we were right.  Our belief was that by releasing fairly early in 
D's lifetime, any growing pains resulting from the presence of two such 
libraries would be sorted out fairly quickly.  I do think the conference 
is timed quite well in this respect, and am looking forward to meeting 
the man behind the compiler :-)


Sean
Jul 14 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Steve Teale a écrit :

 Sean Kelly Wrote:
 

 Steve Teale wrote:

 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security).


 While one might argue that it is easier to wrap a strictly procedural 
 library with an OO layer than vice-versa, I think the ease with which 
 any library may be encapsulated in a wrapper is more dependent on its 
 design (the assumptions it makes, how features are exposed, etc) than on 
 whether the interface uses functions or objects.  That said, I don't 
 personally consider Tango to be an object-oriented library because it 
 does not require the user to define his own objects in order to use it.


 Sean


 
 Sean, I take your point, and maybe should not have used the term "OO", but my
idea of progress is:
 
 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);


I agree with you that cout or Stdout strike me as particularly ugly and 
that writefln is a (small) progress over printf.

But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling 
that even writefln is not enough..

renoX


 
 rather than:
 
 printf("X is: %s\n", toStringz(&x))
 cout << "X is: " << x << endl;
 writefln("X is: %s", x);
 Stdout("X is: ")(x).newline;
Jul 28 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
renoX wrote:

 ...
 I agree with you that cout or Stdout strike me as particularly ugly and
 that writefln is a (small) progress over printf.
 
 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling
 that even writefln is not enough..
 
 renoX


http://while-nan.blogspot.com/2007/06/mixins-ctfe-and-shell-style-variable.html

Just you wait until I get me grubby little mittens on AST macros... >:)

	-- Daniel
Jul 28 2007
parent reply renoX <renosky free.fr> writes:
Daniel Keep a écrit :

 
 renoX wrote:

 ...
 I agree with you that cout or Stdout strike me as particularly ugly and
 that writefln is a (small) progress over printf.

 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling
 that even writefln is not enough..

 renoX


 
 http://while-nan.blogspot.com/2007/06/mixins-ctfe-and-shell-style-variable.html


Yes, I've did something similar (I've posted it in the newsgroup some 
time ago), but what I wonder is why does Tango devs didn't use such 
solution instead of their current not-very pretty one..


 Just you wait until I get me grubby little mittens on AST macros... >:)


Yup, I've put my solution on freeze until macros..

renoX



 
 	-- Daniel
Jul 29 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
renoX wrote:

 Daniel Keep a écrit :

 renoX wrote:

 ...
 I agree with you that cout or Stdout strike me as particularly ugly and
 that writefln is a (small) progress over printf.

 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling
 that even writefln is not enough..

 renoX


 http://while-nan.blogspot.com/2007/06/mixins-ctfe-and-shell
style-variable.html 


 
 Yes, I've did something similar (I've posted it in the newsgroup some 
 time ago), but what I wonder is why does Tango devs didn't use such 
 solution instead of their current not-very pretty one..


Tango development started almost a year and a half ago, long before most 
of these features existed.  And I'd still consider them incomplete until 
we get full macro capability.


Sean
Jul 29 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
renoX wrote:

 Daniel Keep a écrit :

 renoX wrote:

 ...
 I agree with you that cout or Stdout strike me as particularly ugly and
 that writefln is a (small) progress over printf.

 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling
 that even writefln is not enough..

 renoX


 http://while-nan.blogspot.com/2007/06/mixins-ctfe-and-shell
style-variable.html 


 
 Yes, I've did something similar (I've posted it in the newsgroup some 
 time ago), but what I wonder is why does Tango devs didn't use such 
 solution instead of their current not-very pretty one..



 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);


Would people actually use
mixin(puts("X is ${X}\n"));
?

Mind you, when AST macros come, it would be trivial to replace
mixin(puts(...)) with puts(...),
so user code would not be condemned to ugliness forever.

But it sure would be nice to have some way to get macro syntax using CTFE
mixins.




 Just you wait until I get me grubby little mittens on AST macros... >:)


 
 Yup, I've put my solution on freeze until macros..
 
 renoX
 
 

     -- Daniel
Aug 02 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
renoX wrote:

 Steve Teale a écrit :

 Sean Kelly Wrote:


 Steve Teale wrote:

 It seemes to me that given Walter's definition of the language - a 
 system programming language - that Phobos is closer to the mark.  If 
 users want a more object oriented standard library, that's all well 
 and good, but it should be a shoe-in, then if you want to use the OO 
 stuff you can, but code that's been written to work with Phobos 
 should work unmodified with other libraries.  (Note the recent 
 discussion on C++ security).


 While one might argue that it is easier to wrap a strictly procedural 
 library with an OO layer than vice-versa, I think the ease with which 
 any library may be encapsulated in a wrapper is more dependent on its 
 design (the assumptions it makes, how features are exposed, etc) than 
 on whether the interface uses functions or objects.  That said, I 
 don't personally consider Tango to be an object-oriented library 
 because it does not require the user to define his own objects in 
 order to use it.


 Sean


 Sean, I take your point, and maybe should not have used the term "OO", 
 but my idea of progress is:

 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);


 
 I agree with you that cout or Stdout strike me as particularly ugly and 
 that writefln is a (small) progress over printf.
 
 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but feeling 
 that even writefln is not enough..
 
 renoX
 


Technically the Ruby sample would usually just be:


Which is essentially shorthand for:
$stdout.method(:puts).call('X is ' + X.method(:to_s).call());

And if you need to format X any at all, you'd use something like this:
puts 'X is %08x' % [X]

Which is shorthand for:
$stdout.method(:puts).call('X is %08x'.method(:"%").call(X));

Which is a wrapper around:
puts sprintf('X is %08x', X)

Aka:
$stdout.method(:puts).call(Kernel::sprintf('X  is %08x', X));

Uhm.... sorry, got a little carried away there.  ;)  But the main point 
was, in cases like this Ruby and D don't really compare -- what with the 
former being in a virtual environment and the latter a systems language 

wouldn't really require very much (symbol table, and runtime function to 
do the insertions) but the cost of such a thing becoming "mandatory" 
would be great.

I'd happily settle for a template or CTF that takes that string as 
parameter, and spits out an appropriate use of Stdout/writef.

On a side note, call me when we can duplicate this Ruby in D:

+-----[ Ruby ]-----------------------------------+
|
|    def verb_arg_str (flags, which)
|        ['none', 'any', 'this'][(flags >> case which
|            when :dobj then VFSHIFT_DOBJ
|            when :iobj then VFSHIFT_IOBJ
|        end) & VFMASK_ARGS]
|    end
|_________________________________________________

Er... actually we can, sans the symbol type in favor of a bool:

+-----[ D ]--------------------------------------+
|
|    char[] verbArgStr (uint flags, bool dobj) {
|      return ["none"[], "any", "this"][
|        (flags >> (dobj ? VFSHIFT_DOBJ : VFSHIFT_IOBJ))
|        & VFMASK_ARGS
|      ];
|    }
|_________________________________________________

Huh, how about that.

-- Chris Nicholson-Sauls
Jul 28 2007
parent reply renoX <renosky free.fr> writes:
Chris Nicholson-Sauls a écrit :

 renoX wrote:

 Steve Teale a écrit :

 Sean Kelly Wrote:


 Steve Teale wrote:

 It seemes to me that given Walter's definition of the language - a 
 system programming language - that Phobos is closer to the mark.  
 If users want a more object oriented standard library, that's all 
 well and good, but it should be a shoe-in, then if you want to use 
 the OO stuff you can, but code that's been written to work with 
 Phobos should work unmodified with other libraries.  (Note the 
 recent discussion on C++ security).


 While one might argue that it is easier to wrap a strictly 
 procedural library with an OO layer than vice-versa, I think the 
 ease with which any library may be encapsulated in a wrapper is more 
 dependent on its design (the assumptions it makes, how features are 
 exposed, etc) than on whether the interface uses functions or 
 objects.  That said, I don't personally consider Tango to be an 
 object-oriented library because it does not require the user to 
 define his own objects in order to use it.


 Sean


 Sean, I take your point, and maybe should not have used the term 
 "OO", but my idea of progress is:

 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);


 I agree with you that cout or Stdout strike me as particularly ugly 
 and that writefln is a (small) progress over printf.

 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but 
 feeling that even writefln is not enough..

 renoX


 
 Technically the Ruby sample would usually just be:



Oops, a long time since I've made Ruby thanks for the various 
explanation of how it works in Ruby.


 Which is essentially shorthand for:
 $stdout.method(:puts).call('X is ' + X.method(:to_s).call());

 And if you need to format X any at all, you'd use something like this:
 puts 'X is %08x' % [X]



variable name is located at the same point as its string representation 
which reduce greatly the risk of mistake, when I've made my 'puts' like 
function for D (which used template,posted a while ago) , I used %{X} 
for normal embedding and allowed also %08x{X}.




 
 Which is shorthand for:
 $stdout.method(:puts).call('X is %08x'.method(:"%").call(X));
 
 Which is a wrapper around:
 puts sprintf('X is %08x', X)
 
 Aka:
 $stdout.method(:puts).call(Kernel::sprintf('X  is %08x', X));
 
 Uhm.... sorry, got a little carried away there.  ;)  But the main point 
 was, in cases like this Ruby and D don't really compare -- what with the 
 former being in a virtual environment and the latter a systems language 

 wouldn't really require very much (symbol table, and runtime function to 
 do the insertions) but the cost of such a thing becoming "mandatory" 
 would be great.


It depends: when the string is known at compile-time (which happens 
quite often), then there is absolutely no overhead over printf.
For runtime string, yes this syntax would have a significant overhead.


 I'd happily settle for a template or CTF that takes that string as 
 parameter, and spits out an appropriate use of Stdout/writef.


Well I've posted one some time ago (improved format string), there 
didn't seem to be a huge interest so I've stopped working on it (beside 
with macros it should be better), but I can't help cringing with index 
counting "{1} {2}" format string, barf..

renoX


 
 On a side note, call me when we can duplicate this Ruby in D:
 
 +-----[ Ruby ]-----------------------------------+
 |
 |    def verb_arg_str (flags, which)
 |        ['none', 'any', 'this'][(flags >> case which
 |            when :dobj then VFSHIFT_DOBJ
 |            when :iobj then VFSHIFT_IOBJ
 |        end) & VFMASK_ARGS]
 |    end
 |_________________________________________________
 
 Er... actually we can, sans the symbol type in favor of a bool:
 
 +-----[ D ]--------------------------------------+
 |
 |    char[] verbArgStr (uint flags, bool dobj) {
 |      return ["none"[], "any", "this"][
 |        (flags >> (dobj ? VFSHIFT_DOBJ : VFSHIFT_IOBJ))
 |        & VFMASK_ARGS
 |      ];
 |    }
 |_________________________________________________
 
 Huh, how about that.
 
 -- Chris Nicholson-Sauls
Jul 29 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
renoX wrote:

 Chris Nicholson-Sauls a écrit :

 renoX wrote:

 Steve Teale a écrit :

 Sean Kelly Wrote:


 Steve Teale wrote:

 It seemes to me that given Walter's definition of the language - a 
 system programming language - that Phobos is closer to the mark.  
 If users want a more object oriented standard library, that's all 
 well and good, but it should be a shoe-in, then if you want to use 
 the OO stuff you can, but code that's been written to work with 
 Phobos should work unmodified with other libraries.  (Note the 
 recent discussion on C++ security).


 While one might argue that it is easier to wrap a strictly 
 procedural library with an OO layer than vice-versa, I think the 
 ease with which any library may be encapsulated in a wrapper is 
 more dependent on its design (the assumptions it makes, how 
 features are exposed, etc) than on whether the interface uses 
 functions or objects.  That said, I don't personally consider Tango 
 to be an object-oriented library because it does not require the 
 user to define his own objects in order to use it.


 Sean


 Sean, I take your point, and maybe should not have used the term 
 "OO", but my idea of progress is:

 printf("X is: %s\n", toStringz(x))
 cout << "X is: " << x << endl;
 Stdout("X is: ")(x).newline;
 writefln("X is: %s", x);


 I agree with you that cout or Stdout strike me as particularly ugly 
 and that writefln is a (small) progress over printf.

 But when I see Ruby's way: puts("X is ${X}\n"); I can't help but 
 feeling that even writefln is not enough..

 renoX


 Technically the Ruby sample would usually just be:



 
 Oops, a long time since I've made Ruby thanks for the various 
 explanation of how it works in Ruby.


I just happen to be working on a Ruby project lately, so it was fresh in 
mind.  ;)


 Which is essentially shorthand for:
 $stdout.method(:puts).call('X is ' + X.method(:to_s).call());


  >

 And if you need to format X any at all, you'd use something like this:
 puts 'X is %08x' % [X]


 

 variable name is located at the same point as its string representation 
 which reduce greatly the risk of mistake, when I've made my 'puts' like 
 function for D (which used template,posted a while ago) , I used %{X} 
 for normal embedding and allowed also %08x{X}.
 

 


Actually I feel much the same way.  If I ever find a clean way to code 
my own formatter that can borrow the calling context.... I'll get 
shivers.  (Probably have to write a Ruby extension in C to do so.)

-- Chris Nicholson-Sauls
Jul 29 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Chris Nicholson-Sauls wrote:

 renoX wrote:




 
 Actually I feel much the same way.  If I ever find a clean way to code
 my own formatter that can borrow the calling context.... I'll get
 shivers.  (Probably have to write a Ruby extension in C to do so.)
 
 -- Chris Nicholson-Sauls


Heh, my formatter supports "X is $(08x){X}" which is a bit longer, but
non-ambiguous.  ^^

	-- Daniel
Jul 29 2007
parent reply renoX <renosky free.fr> writes:
Daniel Keep Wrote:

 Chris Nicholson-Sauls wrote:

 renoX wrote:




 
 Actually I feel much the same way.  If I ever find a clean way to code
 my own formatter that can borrow the calling context.... I'll get
 shivers.  (Probably have to write a Ruby extension in C to do so.)
 
 -- Chris Nicholson-Sauls


 
 Heh, my formatter supports "X is $(08x){X}" which is a bit longer, but
 non-ambiguous.  ^^


I don't think that %08x{X} is ambiguous (and it has the advantage that it looks
very much like printf formatter which is a plus in a language which is the
successor of C/C++): anything between % and { is the 'formatter', anything
inside {..} is the expression to be formatted.

Could you explain why you think it's ambiguous?

Regards,
renoX


 
 	-- Daniel
Jul 30 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
renoX wrote:

 I don't think that %08x{X} is ambiguous (and it has the advantage that it
looks very much like printf formatter which is a plus in a language which is
the successor of C/C++): anything between % and { is the 'formatter', anything
inside {..} is the expression to be formatted.
 
 Could you explain why you think it's ambiguous?
 
 Regards,
 renoX
 


No, you're right; it's not ambiguous.  I suppose I just don't like that
the format options aren't explicitly delimited by anything; the parser I
wrote for mine is a bit stricter.

The other problem is that, as you said, it looks like a printf string.
My personal stance is that unless printf syntax is actually valid, it
shouldn't look like it is.

I suppose it all boils down to taste in the end; viva-la-dollar! :)

	-- Daniel
Jul 31 2007
parent reply renoX <renosky free.fr> writes:
Daniel Keep Wrote:

 renoX wrote:

 I don't think that %08x{X} is ambiguous (and it has the advantage that it
looks very much like printf formatter which is a plus in a language which is
the successor of C/C++): anything between % and { is the 'formatter', anything
inside {..} is the expression to be formatted.
 
 Could you explain why you think it's ambiguous?




[]

 No, you're right; it's not ambiguous.  I suppose I just don't like that
 the format options aren't explicitly delimited by anything; the parser I
 wrote for mine is a bit stricter.
 
 The other problem is that, as you said, it looks like a printf string.
 My personal stance is that unless printf syntax is actually valid, it
 shouldn't look like it is.


I agree that if it looks like printf then it should behave like printf: that's
why the printf syntax was also valid in the function I made and that the same
formater had the same result.


 I suppose it all boils down to taste in the end; viva-la-dollar! :)


Well, using printf-like formatter in a language which reuse C/C++ syntax make
more sense to me, but sure that's a matter of taste and in any case your $
notation is far better than what there is currently in the libraries..

renoX

 
 	-- Daniel
Jul 31 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
renoX wrote:

 Daniel Keep Wrote:

 renoX wrote:

 I don't think that %08x{X} is ambiguous (and it has the advantage that it
looks very much like printf formatter which is a plus in a language which is
the successor of C/C++): anything between % and { is the 'formatter', anything
inside {..} is the expression to be formatted.

 Could you explain why you think it's ambiguous?




 []

 No, you're right; it's not ambiguous.  I suppose I just don't like that
 the format options aren't explicitly delimited by anything; the parser I
 wrote for mine is a bit stricter.

 The other problem is that, as you said, it looks like a printf string.
 My personal stance is that unless printf syntax is actually valid, it
 shouldn't look like it is.


 
 I agree that if it looks like printf then it should behave like printf: that's
why the printf syntax was also valid in the function I made and that the same
formater had the same result.
 

 I suppose it all boils down to taste in the end; viva-la-dollar! :)


 
 Well, using printf-like formatter in a language which reuse C/C++ syntax make
more sense to me, but sure that's a matter of taste and in any case your $
notation is far better than what there is currently in the libraries..
 
 renoX

 	-- Daniel


 


Here's an odd thought: "%{08x:X}"
Wherein the {}'s mean, "this is looking at a variable outside", and the 
':' means "everything after this point is the variable's name".

-- Chris Nicholson-Sauls
Jul 31 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Chris Nicholson-Sauls wrote:

 renoX wrote:
 Here's an odd thought: "%{08x:X}"
 Wherein the {}'s mean, "this is looking at a variable outside", and the
 ':' means "everything after this point is the variable's name".
 
 -- Chris Nicholson-Sauls


I actually played with something similar for a while, but eventually
discarded it.  The problem was that there are times when you don't care
to format some expression, you just want to output the thing.  I didn't
like that you'd have to carry around the leading ':' when you're not
using it.

OTOH, this is pretty similar to what Tango uses in its formatter.  IIRC,
it's something like {n:f} where ':f' is your optional format string and
'n' is the position of the thing you want to format.  Or it might be the
other way around; I dunno :P

	-- Daniel
Jul 31 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Daniel Keep wrote:

 
 Chris Nicholson-Sauls wrote:

 renoX wrote:
 Here's an odd thought: "%{08x:X}"
 Wherein the {}'s mean, "this is looking at a variable outside", and the
 ':' means "everything after this point is the variable's name".

 -- Chris Nicholson-Sauls


 
 I actually played with something similar for a while, but eventually
 discarded it.  The problem was that there are times when you don't care
 to format some expression, you just want to output the thing.  I didn't
 like that you'd have to carry around the leading ':' when you're not
 using it.
 
 OTOH, this is pretty similar to what Tango uses in its formatter.  IIRC,
 it's something like {n:f} where ':f' is your optional format string and
 'n' is the position of the thing you want to format.  Or it might be the
 other way around; I dunno :P
 
 	-- Daniel


Tango formatting is '{' [index] [',' alignment] [':' format] '}'

Where alignment is really a minimum width, and the format depends on the 
type you are formatting (the default is "s" as with Phobos' formatting).

Maybe my odd thought would be better as "%{X:08x}" then?  Hmm.

-- Chris Nicholson-Sauls
Aug 01 2007
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Chris Nicholson-Sauls wrote:

 Here's an odd thought: "%{08x:X}"
 Wherein the {}'s mean, "this is looking at a variable outside", and the 
 ':' means "everything after this point is the variable's name".
 
 -- Chris Nicholson-Sauls


I always rather liked Python's syntax for this.

http://docs.python.org/lib/typesseq-strings.html


 '%(X)08x' % {'X' : 12}






'0000000c'

That is, the identifier is placed inside of parentheses between the '%' 
and the rest of the format string. The primary difference, here, is that 
Python then expects a dictionary instead of positional format arguments. 
You can get a dictionary of the current scope's variables with the 
locals() function, thus you could easily say:


 a = 'hello'
 b = 'world'
 '%(a)s %(b)s' % locals()






'hello world'

This part is not as applicable to D (since its AAs must be statically 
typed), but I do like the format string syntax.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Jul 31 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Kirk McDonald wrote:

 Chris Nicholson-Sauls wrote:

 Here's an odd thought: "%{08x:X}"
 Wherein the {}'s mean, "this is looking at a variable outside", and
 the ':' means "everything after this point is the variable's name".

 -- Chris Nicholson-Sauls


 
 I always rather liked Python's syntax for this.
 
 http://docs.python.org/lib/typesseq-strings.html
 

 '%(X)08x' % {'X' : 12}






 '0000000c'
 
 That is, the identifier is placed inside of parentheses between the '%'
 and the rest of the format string. The primary difference, here, is that
 Python then expects a dictionary instead of positional format arguments.
 You can get a dictionary of the current scope's variables with the
 locals() function, thus you could easily say:
 

 a = 'hello'
 b = 'world'
 '%(a)s %(b)s' % locals()






 'hello world'
 
 This part is not as applicable to D (since its AAs must be statically
 typed), but I do like the format string syntax.
 


It would be cool if we got a __traits(locals) function that returned a
pointer to a struct whose members were overlaid over the function's
local stack...

...yeah, seems a bit overkill :P  I still think that macros wrapping
string mixins are the way to do it.

	-- Daniel
Jul 31 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Steve Teale wrote:

 It bothers me that Phobos and Tango seem to be completely divergent.
 One of the things that makes a language successful is that it has a
 good standard library.  It seems that with D, you have to be a
 betting man - which standard library will prevail.


I think the only issue is the fact that they're incompatible.  Maybe 
that's what you meant by 'divergent', but to me 'divergent' just means 
going in different directions, as in creating diversity.  The existence 
of a big Java-style library like Tango can only be seen as a plus for D, 
except for that darn incompatibility issue.

Tango could have been made compatible with phobos.  The reasons for 
making it a replacement for phobos rather than a regular library are (as 
I understand it):
1) They wanted to be in charge of their own garbage collector
2) Phobos' exception hierarchy makes no sense and they wanted to fix that.

And there were a few other minor things that annoyed them about Phobos, 
but by themselves I suspect wouldn't have been enough to warrant 
creating a schism.  (printf declared in object.d, toString actually 
returning utf-8 not just any old string).

It would be great if at the D conference the Tango folks could sit down 
and have a serious face-to-face with Walter about what it would take to 
make Tango D-compatible once again -- or perhaps that should be 
upgrading D to be Tango-compatible.  I'm thinking things like getting 
Walter to fix the exception hierarchy in Phobos, and maybe doing 
whatever it takes to make the garbage collector pluggable to allow 
experimentation in that area without creating a schism.

--bb
Jul 13 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 It would be great if at the D conference the Tango folks could sit down 
 and have a serious face-to-face with Walter about what it would take to 
 make Tango D-compatible once again -- or perhaps that should be 
 upgrading D to be Tango-compatible.  I'm thinking things like getting 
 Walter to fix the exception hierarchy in Phobos, and maybe doing 
 whatever it takes to make the garbage collector pluggable to allow 
 experimentation in that area without creating a schism.


I'm up for such a discussion.
Jul 13 2007
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Fri, 13 Jul 2007, Walter Bright wrote:


 Bill Baxter wrote:

 It would be great if at the D conference the Tango folks could sit down and
 have a serious face-to-face with Walter about what it would take to make
 Tango D-compatible once again -- or perhaps that should be upgrading D to be
 Tango-compatible.  I'm thinking things like getting Walter to fix the
 exception hierarchy in Phobos, and maybe doing whatever it takes to make the
 garbage collector pluggable to allow experimentation in that area without
 creating a schism.


 
 I'm up for such a discussion.


Interestingly enough, this is the specific discussion I wanted to make 
happen when I started discussing having a D conference with Walter.  
Things got a little outta hand. :)

Later,
Brad
Jul 13 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 It would be great if at the D conference the Tango folks could sit 
 down and have a serious face-to-face with Walter about what it would 
 take to make Tango D-compatible once again -- or perhaps that should 
 be upgrading D to be Tango-compatible.  I'm thinking things like 
 getting Walter to fix the exception hierarchy in Phobos, and maybe 
 doing whatever it takes to make the garbage collector pluggable to 
 allow experimentation in that area without creating a schism.


 
 I'm up for such a discussion.


Same here.  Heck, the point of the conference in my opinion is to meet 
people.  The talks largely exist to fuel conversation.


Sean
Jul 14 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 I'm up for such a discussion.


 
 Same here.  Heck, the point of the conference in my opinion is to meet 
 people.  The talks largely exist to fuel conversation.


Absolutely right. I'm really looking forward to it.
Jul 14 2007
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Bill Baxter Wrote:


 Steve Teale wrote:

 It bothers me that Phobos and Tango seem to be completely divergent.
 One of the things that makes a language successful is that it has a
 good standard library.  It seems that with D, you have to be a
 betting man - which standard library will prevail.


 
 I think the only issue is the fact that they're incompatible.  Maybe 
 that's what you meant by 'divergent', but to me 'divergent' just means 
 going in different directions, as in creating diversity.  The existence 
 of a big Java-style library like Tango can only be seen as a plus for D, 
 except for that darn incompatibility issue.
 
 Tango could have been made compatible with phobos.  The reasons for 
 making it a replacement for phobos rather than a regular library are (as 
 I understand it):
 1) They wanted to be in charge of their own garbage collector
 2) Phobos' exception hierarchy makes no sense and they wanted to fix that.
 
 And there were a few other minor things that annoyed them about Phobos, 
 but by themselves I suspect wouldn't have been enough to warrant 
 creating a schism.  (printf declared in object.d, toString actually 
 returning utf-8 not just any old string).
 
 It would be great if at the D conference the Tango folks could sit down 
 and have a serious face-to-face with Walter about what it would take to 
 make Tango D-compatible once again -- or perhaps that should be 
 upgrading D to be Tango-compatible.  I'm thinking things like getting 
 Walter to fix the exception hierarchy in Phobos, and maybe doing 
 whatever it takes to make the garbage collector pluggable to allow 
 experimentation in that area without creating a schism.
 
 --bb


Yes, I did mean incompatible, but I'd had a couple of beers at the time.  If
the issues you describe are all that is at the core of the schism, we should
really try to get it sorted.  It's really frustrating to find that half of the
things you'd like to use out of DSource are going to make you have to do major
surgery on your existing code.
Jul 14 2007
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Actually, I'm just about to switch from phobos to tango.  I initially 
went with phobos because it's what comes with D and was simpler for both 
me and anyone who uses my program...

I didn't have any issues for 2 months, then I started hitting issues 
with little or no way to get help.  I eventually traced one of my issues 
to a low numbered issue in the issue database that had never gotten 
fixed.  I saw Walter nearly overloaded with D 2.0, but got rapid 
responses and encouraging responses from the Tango team.  Many of my 
problems (bit or small) with Phobos have been fixed already in Tango... 
Or at least look like someone took a stab at it.  When you add in that 
the Tango team will be responsive to problems discovered and work to 
resolve issues, I'm sold!


Steve Teale wrote:

 It bothers me that Phobos and Tango seem to be completely divergent.  One of
the things that makes a language successful is that it has a good standard
library.  It seems that with D, you have to be a betting man - which standard
library will prevail.
 
 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.
 
 I am not saying that Phobos is perfect.  It has lots of omissions, but I have
a feeling that it is about at the right level to enable authors to write the
more OO stuff on top of it.
 
 I'm sure that this is a sensitive subject, but there you go!  I think we all
agree that Walter has done a damn good job on D, so why should we reject his
thinking on Phobos?  I've been watching Walter for a long time now, and in my
book, he knows as much about his subject as anyone does, especially considering
the coverage that's expected of him.
 
 If D is to succeed, I think we should work together rather than compete.  I'd
like to see a much more formal system for contributors to take responsibility
for areas of Phobos.  Maybe it exists, but if it does, it's hardly in your
face.  I'd also like to see people back off on trying to replace it.  Let's
improve it and augment it.
Jul 13 2007
parent reply TomD <t_demmer NOSPAM.web.de> writes:
Jason House Wrote:


 Actually, I'm just about to switch from phobos to tango.  I initially 
 went with phobos because it's what comes with D and was simpler for both 
 me and anyone who uses my program...
 
 I didn't have any issues for 2 months, then I started hitting issues 
 with little or no way to get help.  I eventually traced one of my issues 
 to a low numbered issue in the issue database that had never gotten 
 fixed.  I saw Walter nearly overloaded with D 2.0, but got rapid 
 responses and encouraging responses from the Tango team.  Many of my 
 problems (bit or small) with Phobos have been fixed already in Tango... 
 Or at least look like someone took a stab at it.  When you add in that 
 the Tango team will be responsive to problems discovered and work to 
 resolve issues, I'm sold!


I totally second that complaint. It is a pitty that even if you send in 
tested, working
patches, they do not get incorporated. Still, I prefer Phobos because it looks
much leaner, and has a better decumentation.

Ciao
Tom
Jul 14 2007
parent reply Steve Teale <steve.teale britseyeview.com> writes:
TomD Wrote:


 Jason House Wrote:
 

 Actually, I'm just about to switch from phobos to tango.  I initially 
 went with phobos because it's what comes with D and was simpler for both 
 me and anyone who uses my program...
 
 I didn't have any issues for 2 months, then I started hitting issues 
 with little or no way to get help.  I eventually traced one of my issues 
 to a low numbered issue in the issue database that had never gotten 
 fixed.  I saw Walter nearly overloaded with D 2.0, but got rapid 
 responses and encouraging responses from the Tango team.  Many of my 
 problems (bit or small) with Phobos have been fixed already in Tango... 
 Or at least look like someone took a stab at it.  When you add in that 
 the Tango team will be responsive to problems discovered and work to 
 resolve issues, I'm sold!


 I totally second that complaint. It is a pitty that even if you send in 
tested, working
 patches, they do not get incorporated. Still, I prefer Phobos because it looks
much leaner, and has a better decumentation.
 
 Ciao
 Tom


Tom,

Then let's persist with this bitching until we get it sorted.  Someone else in
the thread has already noted that Walter has too much on his back already. 
Somehow we need to get these things unified, so it's safe to write a library. 
My version of Phobos is patched, as I suspect are many, but as you say there's
no way of checking these changes in.

Walter, you are eventually going to have to delegate this somewhere!

Steve
Jul 14 2007
parent reply TomD <t_demmer NOSPAM.web.de> writes:
Steve Teale Wrote:

[...]

 Then let's persist with this bitching until we get it sorted.  Someone else in
the thread has already noted that Walter has too much on his back already. 
Somehow we need to get these things unified, so it's safe to write a library. 
My version of Phobos is patched, as I suspect are many, but as you say there's
no way of checking these changes in.
 
 Walter, you are eventually going to have to delegate this somewhere!
 
 Steve
 


I did not mean to bitch. From what I understand, Walter wants to design and
write the perfect language and compiler. I like it, and it was love on first
sight:-)
But he needs to realize that even his day only has 36 hours and let
not-that-brilliant programmers help with the runtime. Putting Phobos under svn
might ease the task. 

Ciao
Tom
Jul 14 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
TomD wrote:

 Steve Teale Wrote:
 
 [...]

 Then let's persist with this bitching until we get it sorted.
 Someone else in the thread has already noted that Walter has too
 much on his back already.  Somehow we need to get these things
 unified, so it's safe to write a library.  My version of Phobos is
 patched, as I suspect are many, but as you say there's no way of
 checking these changes in.
 
 Walter, you are eventually going to have to delegate this
 somewhere!
 
 Steve
 


 I did not mean to bitch. From what I understand, Walter wants to
 design and write the perfect language and compiler. I like it, and it
 was love on first sight:-) But he needs to realize that even his day
 only has 36 hours and let not-that-brilliant programmers help with
 the runtime. Putting Phobos under svn might ease the task.


Just putting it under svn isn't enough.  It needs to have someone in 
charge of it.  To manage incoming patches.  To think about overall 
organization.  And ideally to work on things like a good set of 
templated containers.  Hmm... kind of exactly like what those Tango guys 
are doing.

--bb
Jul 14 2007
parent TomD <t_demmer NOSPAM.web.de> writes:
Bill Baxter Wrote:
[...]

 Just putting it under svn isn't enough.  It needs to have someone in 
 charge of it.  To manage incoming patches.  To think about overall 
 organization.  And ideally to work on things like a good set of 
 templated containers.  Hmm... kind of exactly like what those Tango guys 
 are doing.
 
 --bb


I know. I am contemplating how much work that would be. What makes me shy away
a bit is the importance of the project. On the other, looking at bugzilla,
there are 47 open issues connected to Phobos. Some have allegedly working
patches attached. I can check them with dmd/XP and dmd/Linux. Would adding a
comment to those issues confirming/not confirming the patches be helpful?

Ciao
Tom
Jul 15 2007
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
TomD Wrote:


 Steve Teale Wrote:
 
 [...]

 Then let's persist with this bitching until we get it sorted.  Someone else in
the thread has already noted that Walter has too much on his back already. 
Somehow we need to get these things unified, so it's safe to write a library. 
My version of Phobos is patched, as I suspect are many, but as you say there's
no way of checking these changes in.
 
 Walter, you are eventually going to have to delegate this somewhere!
 
 Steve
 


 I did not mean to bitch. From what I understand, Walter wants to design and
write the perfect language and compiler. I like it, and it was love on first
sight:-)
 But he needs to realize that even his day only has 36 hours and let
not-that-brilliant programmers help with the runtime. Putting Phobos under svn
might ease the task. 
 
 Ciao
 Tom


It was me that was bitching ;=)
Jul 15 2007
prev sibling next sibling parent reply Alan Knowles <alan akbkhome.com> writes:
I have to second this, but more from the reality of people depending on 
tango in their libraries. From what I've seen of tango, It's a bit 
over-designed/engineered for my taste, but I could easily change my 
opinion one day, and I've not found any justification for using it yet.

What irk's me though is that dsource is starting to see code that 
depends on tango. Which is adding a a huge barrier/dependancy that 
resulted in me just completely re-writing some code from scratch rather 
than re-using something already on dsource. I hate doing that, but 
forcing tango on downloading my code, is not something I'm particularly 
want to do at present.

While It doesnt sound like Walter will allow a more open commit policy 
on phobos, I'm at a bit of a loss to see how this could be resolved..

I'd hate to see where dsource ends up with a complete mishmash of phobos 
and tango only libraries.

Regards
Alan

Steve Teale wrote:

 It bothers me that Phobos and Tango seem to be completely divergent.
 One of the things that makes a language successful is that it has a
 good standard library.  It seems that with D, you have to be a
 betting man - which standard library will prevail.
 
 It seemes to me that given Walter's definition of the language - a
 system programming language - that Phobos is closer to the mark.  If
 users want a more object oriented standard library, that's all well
 and good, but it should be a shoe-in, then if you want to use the OO
 stuff you can, but code that's been written to work with Phobos
 should work unmodified with other libraries.  (Note the recent
 discussion on C++ security). Any other approach seems to me to reek
 of vanity.
 
 I am not saying that Phobos is perfect.  It has lots of omissions,
 but I have a feeling that it is about at the right level to enable
 authors to write the more OO stuff on top of it.
 
 I'm sure that this is a sensitive subject, but there you go!  I think
 we all agree that Walter has done a damn good job on D, so why should
 we reject his thinking on Phobos?  I've been watching Walter for a
 long time now, and in my book, he knows as much about his subject as
 anyone does, especially considering the coverage that's expected of
 him.
 
 If D is to succeed, I think we should work together rather than
 compete.  I'd like to see a much more formal system for contributors
 to take responsibility for areas of Phobos.  Maybe it exists, but if
 it does, it's hardly in your face.  I'd also like to see people back
 off on trying to replace it.  Let's improve it and augment it.
Jul 13 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Not sure if anyone has mentioned tangobos yet:

http://www.dsource.org/projects/tangobos/

Alan Knowles Wrote:


 I have to second this, but more from the reality of people depending on 
 tango in their libraries. From what I've seen of tango, It's a bit 
 over-designed/engineered for my taste, but I could easily change my 
 opinion one day, and I've not found any justification for using it yet.
 
 What irk's me though is that dsource is starting to see code that 
 depends on tango. Which is adding a a huge barrier/dependancy that 
 resulted in me just completely re-writing some code from scratch rather 
 than re-using something already on dsource. I hate doing that, but 
 forcing tango on downloading my code, is not something I'm particularly 
 want to do at present.
 
 While It doesnt sound like Walter will allow a more open commit policy 
 on phobos, I'm at a bit of a loss to see how this could be resolved..
 
 I'd hate to see where dsource ends up with a complete mishmash of phobos 
 and tango only libraries.
 
 Regards
 Alan
 
 Steve Teale wrote:

 It bothers me that Phobos and Tango seem to be completely divergent.
 One of the things that makes a language successful is that it has a
 good standard library.  It seems that with D, you have to be a
 betting man - which standard library will prevail.
 
 It seemes to me that given Walter's definition of the language - a
 system programming language - that Phobos is closer to the mark.  If
 users want a more object oriented standard library, that's all well
 and good, but it should be a shoe-in, then if you want to use the OO
 stuff you can, but code that's been written to work with Phobos
 should work unmodified with other libraries.  (Note the recent
 discussion on C++ security). Any other approach seems to me to reek
 of vanity.
 
 I am not saying that Phobos is perfect.  It has lots of omissions,
 but I have a feeling that it is about at the right level to enable
 authors to write the more OO stuff on top of it.
 
 I'm sure that this is a sensitive subject, but there you go!  I think
 we all agree that Walter has done a damn good job on D, so why should
 we reject his thinking on Phobos?  I've been watching Walter for a
 long time now, and in my book, he knows as much about his subject as
 anyone does, especially considering the coverage that's expected of
 him.
 
 If D is to succeed, I think we should work together rather than
 compete.  I'd like to see a much more formal system for contributors
 to take responsibility for areas of Phobos.  Maybe it exists, but if
 it does, it's hardly in your face.  I'd also like to see people back
 off on trying to replace it.  Let's improve it and augment it.
Jul 13 2007
parent reply Nicolai Waniek <no.spam thank.you.com> writes:
Robert Fraser wrote:

 Not sure if anyone has mentioned tangobos yet:
 
 http://www.dsource.org/projects/tangobos/
 
 Alan Knowles Wrote:
 


I personally don't like the idea of having yet another layer. This reminds me a
bit of Java: You have a layer, for a layered layer that layers something
completely else.
The word layer is used at least 4 times too often in the last sentence ;)


-- 
.71
nicolai dot waniek at sphere71 dot com
Jul 14 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Most of it isn't a layer - look at the code; most of it is just Phobos copied
directly with a few minor changes to make it compile under Tango. The real
problem is code bloat, but if that's not an issue, you can use it so that you
can use both Phobos and Tango libs in your application.

Nicolai Waniek Wrote:


 Robert Fraser wrote:

 Not sure if anyone has mentioned tangobos yet:
 
 http://www.dsource.org/projects/tangobos/
 
 Alan Knowles Wrote:
 


 
 I personally don't like the idea of having yet another layer. This reminds me a
 bit of Java: You have a layer, for a layered layer that layers something
 completely else.
 The word layer is used at least 4 times too often in the last sentence ;)
 
 
 -- 
 .71
 nicolai dot waniek at sphere71 dot com
Jul 14 2007
parent Nicolai Waniek <no.spam thank.you.com> writes:
Robert Fraser wrote:

 Most of it isn't a layer - look at the code; most of it is just Phobos copied
directly with a few minor changes to make it compile under Tango. The real
problem is code bloat, but if that's not an issue, you can use it so that you
can use both Phobos and Tango libs in your application.
 


Sorry, I didn't look that closely at the sources, but I always try to not-use
any layered stuff. I hope you didn't take my post as offending, that was not my
intend. All respect to anyone who publishes good stuff :-)



-- 
.71
nicolai dot waniek at sphere71 dot com
Jul 15 2007
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Tristam MacDonald Wrote:


 The problem is that I (as a user) want to use one library. And if one 3rd
party library I want to use depends on Phobos, and another on Tango, they
either have to be entirely interoperable - correct me if I am wrong, but this
doesn't seem to be the case - or I end up rolling my own, because neither one
does what I want.
 
 I quite frankly don't like Tango's Pythonesque 'batteries included' approach,
but that is of course entirely a matter of personal opinion. I am not fond of
Phobos either, mostly because of a complete lack of templated containers.
 
 What I would like to see is an approach which combines a small, lean 'core'
library (just the basics like IO and containers), and then have the 'batteries'
implemented as distinct small libraries on top of the core. This allows one to
choose exactly what functionality one needs, with out the extra 'fluff'.
 
 Robert Fraser Wrote:
 

 What's so wrong with having two standard libraries and letting users choose
the one they feel more comfortable with? Having come from a Java background, I
find Tango much easier to work with and powerful than Phobos, but to each his
own. I just wish it was easier to link against one or the other (compiler
switch...) instead of having to switch between them all the time.
 
 Steve Teale Wrote:
 

 It bothers me that Phobos and Tango seem to be completely divergent.  One of
the things that makes a language successful is that it has a good standard
library.  It seems that with D, you have to be a betting man - which standard
library will prevail.
 
 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.
 
 I am not saying that Phobos is perfect.  It has lots of omissions, but I have
a feeling that it is about at the right level to enable authors to write the
more OO stuff on top of it.
 
 I'm sure that this is a sensitive subject, but there you go!  I think we all
agree that Walter has done a damn good job on D, so why should we reject his
thinking on Phobos?  I've been watching Walter for a long time now, and in my
book, he knows as much about his subject as anyone does, especially considering
the coverage that's expected of him.
 
 If D is to succeed, I think we should work together rather than compete.  I'd
like to see a much more formal system for contributors to take responsibility
for areas of Phobos.  Maybe it exists, but if it does, it's hardly in your
face.  I'd also like to see people back off on trying to replace it.  Let's
improve it and augment it.
 
 


 


 


Your point is what got me going in the first place.  I wanted to use DDL, and
the first thing the documentation told me was to install Tango.
Jul 13 2007
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Brad Roberts Wrote:


 On Fri, 13 Jul 2007, Walter Bright wrote:
 

 Bill Baxter wrote:

 It would be great if at the D conference the Tango folks could sit down and
 have a serious face-to-face with Walter about what it would take to make
 Tango D-compatible once again -- or perhaps that should be upgrading D to be
 Tango-compatible.  I'm thinking things like getting Walter to fix the
 exception hierarchy in Phobos, and maybe doing whatever it takes to make the
 garbage collector pluggable to allow experimentation in that area without
 creating a schism.


 
 I'm up for such a discussion.


 
 Interestingly enough, this is the specific discussion I wanted to make 
 happen when I started discussing having a D conference with Walter.  
 Things got a little outta hand. :)
 
 Later,
 Brad


Fools rush in where angels fear to tread  ;=)
Jul 13 2007
prev sibling next sibling parent reply Nicolai Waniek <no.spam thank.you.com> writes:
I just wanted to share my opinion on the topic, altough most of it was already
mentioned above.

In my opinion we should concentrate on one library, instead of having both.
Phobos is good to have, because it ships with the dmd compiler so you can start
coding immediately, tango is really nice because it's more a community driven
project. Both libraries have their pros and their cons, but IMHO i waste too
much of my time switching between those two libraries. I think it is time to
decide how to proceed with the standard libraries. This is of course a topic
that should be discussed on the D conference (though I wont be there). Somehow
they should be merged, but don't ask me how.
My favourite would be a small core library (as stated by Tristam MacDonald) that
only includes the basic stuff and a standard library extending the core stuff to
a mix of phobos and tango. Of course one has to decide which garbage collector
to use, or to make more than one available.
My problem with both libraries is that I just use a subset of their features,
but I get the whole package compiled into my projects - and though we have 250GB
HDDs, i want my applications be (damn) small.


Best regards
Nicolai

-- 
.71
nicolai dot waniek at sphere71 dot com
Jul 14 2007
parent reply Sean Kelly <sean f4.ca> writes:
Nicolai Waniek wrote:

 My problem with both libraries is that I just use a subset of their features,
 but I get the whole package compiled into my projects - and though we have
250GB
 HDDs, i want my applications be (damn) small.


At this point, there are two factors that bloat D executables: TypeInfo, 
and file-level linking.  We're likely stuck with the former, but if the 
latter could be addressed then things would improve tremendously. 
Unfortunately, this suggests that we'll need a new linker for Win32.


Sean
Jul 14 2007
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:

 Nicolai Waniek wrote:

 My problem with both libraries is that I just use a subset of their 
 features,
 but I get the whole package compiled into my projects - and though we 
 have 250GB
 HDDs, i want my applications be (damn) small.


 
 At this point, there are two factors that bloat D executables: TypeInfo, 
 and file-level linking.  We're likely stuck with the former, but if the 
 latter could be addressed then things would improve tremendously. 
 Unfortunately, this suggests that we'll need a new linker for Win32.


For the former, perhaps it would be possible to have an extension to the module 
statement to indicate "this module should not generate any TypeInfo".
I'm particularly thinking of things like the Windows headers, which should 
entirely disappear if not used.
Jul 14 2007
parent Nicolai Waniek <no.spam thank.you.com> writes:
Don Clugston wrote:

 Sean Kelly wrote:
 
 For the former, perhaps it would be possible to have an extension to the
 module statement to indicate "this module should not generate any
 TypeInfo".
 I'm particularly thinking of things like the Windows headers, which
 should entirely disappear if not used.


Or there could be the "Delphi way of doing it": There no class has any type
information unless you activate it for that special class by adding (i guess,
it's long ago that I did that) {$R+} to the source:

{$R+}
TMyClass = class(TObject) ...
{$R-}


-- 
.71
nicolai dot waniek at sphere71 dot com
Jul 15 2007
prev sibling parent reply Nicolai Waniek <no.spam thank.you.com> writes:
Sean Kelly wrote:

 Nicolai Waniek wrote:
 
 At this point, there are two factors that bloat D executables: TypeInfo,
 and file-level linking.  We're likely stuck with the former, but if the
 latter could be addressed then things would improve tremendously.
 Unfortunately, this suggests that we'll need a new linker for Win32.
 
 
 Sean


I totally agree with you on these points, for example a minimal "hello world"
app on my linux box here makes >200kb, that's not what I think of as
"lightweight application" ;)




-- 
.71
nicolai dot waniek at sphere71 dot com
Jul 15 2007
parent Sean Kelly <sean f4.ca> writes:
Nicolai Waniek wrote:

 Sean Kelly wrote:

 Nicolai Waniek wrote:

 At this point, there are two factors that bloat D executables: TypeInfo,
 and file-level linking.  We're likely stuck with the former, but if the
 latter could be addressed then things would improve tremendously.
 Unfortunately, this suggests that we'll need a new linker for Win32.


 
 I totally agree with you on these points, for example a minimal "hello world"
 app on my linux box here makes >200kb, that's not what I think of as
 "lightweight application" ;)


For comparison, using printf on Win32/Tango, a "hello world" app is 
~100k.  Sometime prior to 1.0 the same app was ~70k.  And replacing 
printf with Stdout results in a ~130k app using the current release.

The 70k-100k jump involves a number of factors, one of which is an 
increase of the size of the Tango runtime code (mostly the thread code). 
  The rest is an increase in the size of TypeInfo, if I remember correctly.

I don't think it would be possible to have "opt-in" TypeInfo generation 
because TypeInfo is used for all sorts of things in the runtime: element 
comparison for the built-in AAs and array sorting, passing type 
information to the GC for scanning purposes, etc.  It may be that 
TypeInfo size could be reduced somehow, or TypeInfo could always be 
generated into some sort of peripheral object file, but I'll admit the 
idea that seems most promising is segment-level linking.  Since the GNU 
linker can already do this (with --gc-sections or some such), perhaps a 
good first step would be to get it working there?  I know there have 
been problems with this option and D exception handling code in the 
past, but I recall there being a suggested fix in the bug tracker somewhere.


Sean
Jul 15 2007
prev sibling parent reply Ender KaShae <astrothayne gmail.com> writes:
Steve Teale Wrote:


 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.
 


it would be so much better if one could use both tango and phobos, for some
things procedural programing makes more sense, sometimes OO programing makes
more sense, and theres nothing to keep these too situations isolated from each
other, since a program only imports the modules it needs I don't see why both
phobos and tango can be used simultanously.


 I am not saying that Phobos is perfect.  It has lots of omissions, but I have
a feeling that it is about at the right level to enable authors to write the
more OO stuff on top of it.
 


this is the approch that makes the most since to me, though a semi-standard
library like boost for c++ would be nice.  the only reason I can see for
rewriting the same functionality that exist in the standard library is if the
existing code is slow, or completely broken
Aug 01 2007
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Ender KaShae wrote:

 Steve Teale Wrote:
 

 It seemes to me that given Walter's definition of the language - a system
programming language - that Phobos is closer to the mark.  If users want a more
object oriented standard library, that's all well and good, but it should be a
shoe-in, then if you want to use the OO stuff you can, but code that's been
written to work with Phobos should work unmodified with other libraries.  (Note
the recent discussion on C++ security). Any other approach seems to me to reek
of vanity.


 
 it would be so much better if one could use both tango and phobos, for some
things procedural programing makes more sense, sometimes OO programing makes
more sense, and theres nothing to keep these too situations isolated from each
other, since a program only imports the modules it needs I don't see why both
phobos and tango can be used simultanously.


Consider Tangobos. :)
http://dsource.org/projects/tangobos

-- Chris Nicholson-Sauls
Aug 01 2007
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
 it would be so much better if one could use both tango and phobos, for some
things procedural programing makes more sense, sometimes OO programing makes
more sense, and theres nothing to keep these too situations isolated from each
other, since a program only imports the modules it needs I don't see why both
phobos and tango can be used simultanously.


Tangobos. I know that's not the point of it, but it works for that.


 

 I am not saying that Phobos is perfect.  It has lots of omissions, but I have
a feeling that it is about at the right level to enable authors to write the
more OO stuff on top of it.




While we _can_ write more OO stuff on top of Phobos, someone else (the Tango
team) has already done & tested it. Why reinvent the wheel?
Aug 01 2007