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 "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
prev sibling next sibling 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).

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} You can google for the C# format strings or have a look at the 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()



'__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
 "%(a)s %(b)s" % locals()



-- 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. # names.rb 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. # names.rb 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.


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.


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

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

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

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: puts "X is #{X}" 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 meant to expose metal. For something like "X is #{X}" to work in D, 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).

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: puts "X is #{X}"

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]

I don't like this syntax: the interesting part of #{X} is that the 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}. I'm surprised that Ruby doesn't allow 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 
 meant to expose metal.  For something like "X is #{X}" to work in D, 
 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).

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: puts "X is #{X}"

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]

I don't like this syntax: the interesting part of #{X} is that the 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}. I'm surprised that Ruby doesn't allow puts "X is #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:
 I'm surprised that Ruby doesn't allow puts "X is #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

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:
 I'm surprised that Ruby doesn't allow puts "X is #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

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}



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



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}



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



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

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!

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
 

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
 

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

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
 

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

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