digitalmars.D - eliminate writeln et comp?

Hey all y'all,


Here's another nice bicycle shed discussion. During the recent 
discussion about globals being harmful, Walter told me something that 
made me think. I said, hey, there are things that are global - look at 
stdout. He said, well, that's a bad thing. He then argued that it would 
be better and cleaner to write:

stdout.writeln("Hello, world");

instead of the current:

writeln("Hello, world");

On one hand, I agree with Walter. On the other, I want to avoid the 
phenomenon of the all-too-long "Hello, world" example.

What do you think?


Andrei

Mar 17 2009

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Tue, Mar 17, 2009 at 08:35:35AM -0700, Andrei Alexandrescu wrote:
 What do you think?


Eeek. That's too much typing for a trivial, common operation.

I wouldn't mind writefln being implemented as a macro that is turned to
fwritefln(stdout, ...)

But, I'd be fairly annoyed having to write the extra seven characters each
time if the short version wasn't there.

 
 Andrei


-- 
Adam D. Ruppe
http://arsdnet.net

Mar 17 2009

"Nick Sabalausky" <a a.a> writes:

"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.967.1237304767.22690.digitalmars-d puremagic.com...
 On Tue, Mar 17, 2009 at 08:35:35AM -0700, Andrei Alexandrescu wrote:
 What do you think?


 Eeek. That's too much typing for a trivial, common operation.

 I wouldn't mind writefln being implemented as a macro that is turned to
 fwritefln(stdout, ...)

 But, I'd be fairly annoyed having to write the extra seven characters each
 time if the short version wasn't there.


That's how tango and C# do it.

Stdout.formatln("Hello"); // Tango
Console.WriteLine("Hello"); // C#

My preference has always been for something shorter, but the current 
tango/C# ways have never really bothered me. You get used to it pretty 
quick.

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Denis Koroskin wrote:
 That's not a very frequent operation. In most cases you should use 
 Cout("Hello"); instead. An ideal design solution, imo (fast, short and 
 clear).


Interesting. Should I do the same in phobos?

stdout("wyda");

I'd like that particularly because write() is too common a name to place 
at namespace level for my taste. So then we'd have:

stdout("wyda"); // no newline
stdout("wyda\n"); // newline but no flushing on binary stream
stdout("wyda", newline); // write'n'flush
stdout.writeln("wyda"); // same

If we go that route I'll even drop writeln and rely on passing newline. 
For formatting there'd be stdout.format and stdout.formatln or something.

 Back on topic, in most cases I use:
 
 debug writefln("hello");
 
 because I have no console in release version (and it throws when there 
 is no stdout, look in the bugzilla for a bug report). It is already long 
 enough, so I wouldn't like it to be even longer:
 
 debug stdio.writefln("hello");
 
 My 0.02 rubles.
 


Got them.


Andrei

Mar 17 2009

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:
 Interesting. Should I do the same in phobos?
 stdout("wyda");


Generally I suggest to put a short & easy way useful for most situations, plus
something more complex (and generally with a more complex syntax) for the
special situations. For the general basic printing I like put()/putr() (r = add
a final newline).

Bye,
bearophile

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Denis Koroskin wrote:
 On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Denis Koroskin wrote:
 That's not a very frequent operation. In most cases you should use 
 Cout("Hello"); instead. An ideal design solution, imo (fast, short 
 and clear).


 Interesting. Should I do the same in phobos?

 stdout("wyda");

 I'd like that particularly because write() is too common a name to 
 place at namespace level for my taste. So then we'd have:

 stdout("wyda"); // no newline
 stdout("wyda\n"); // newline but no flushing on binary stream
 stdout("wyda", newline); // write'n'flush
 stdout.writeln("wyda"); // same

 If we go that route I'll even drop writeln and rely on passing 
 newline. For formatting there'd be stdout.format and stdout.formatln 
 or something.


 This is funny because Tango has adopted exactly the same design.


Well it isn't funny. It's obvious: you just told me about it! :o)

 The only difference is that Stdout is written in upper case:
 
 import tango.io.Stdout;
 
 void main() {
    Stdout("Hello, World\n"); // no flushing
    Stdout("Hello, World").newline; // new line appended, flushs
    Stdout.format("Hello, {}!", "Andrei").newline; // formatting
    Stdout.formatln("Hello, {}!", "Kris");
 }
 
 It would be great if the two libraries share the same interface.


Ionno. In Phobos, types are Capitalized, values are camelCase or 
justminuscules.

 BTW, since you are in process of redesigning of Phobos IO/stream system, 
 it would be great if you take a look at the Tango IO system, first. I 
 recall you telling that you didn't give a good look at Tango, so now is 
 the time. I particularly insist on talking to Kris about it; perhaps, he 
 has some ideas on the topic. He may also share experience with you 
 (errors he made etc). I'll give you a few ideas of mine in a separate post.


I don't know about licensing issues, and last thing I need would be to 
be accused of stealing from Tango.

 You shouldn't avoid looking on someone's code, especially if it may help 
 D get better standard library. There's nothing wrong with borrowing 
 ideas from others, too, especially if they give you a permission for 
 that. Tango is dual-licensed under Academic Free License v3.0 and BSD 
 License, so there might not be a need to, but anyway.


I have zero knowledge of licensing stuff, but I understand Walter does. 
He's not looking at Tango so nor should I. I'm sure it has some cool 
ideas, but so do other libraries.


Andrei

Mar 17 2009

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

Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 That's not a very frequent operation. In most cases you should use 
 Cout("Hello"); instead. An ideal design solution, imo (fast, short 
 and clear).


 Interesting. Should I do the same in phobos?

 stdout("wyda");

 I'd like that particularly because write() is too common a name to 
 place at namespace level for my taste. So then we'd have:

 stdout("wyda"); // no newline
 stdout("wyda\n"); // newline but no flushing on binary stream
 stdout("wyda", newline); // write'n'flush
 stdout.writeln("wyda"); // same

 If we go that route I'll even drop writeln and rely on passing 
 newline. For formatting there'd be stdout.format and stdout.formatln 
 or something.


 This is funny because Tango has adopted exactly the same design.


 Well it isn't funny. It's obvious: you just told me about it! :o)
 
 The only difference is that Stdout is written in upper case:

 import tango.io.Stdout;

 void main() {
    Stdout("Hello, World\n"); // no flushing
    Stdout("Hello, World").newline; // new line appended, flushs
    Stdout.format("Hello, {}!", "Andrei").newline; // formatting
    Stdout.formatln("Hello, {}!", "Kris");
 }

 It would be great if the two libraries share the same interface.


 Ionno. In Phobos, types are Capitalized, values are camelCase or 
 justminuscules.
 
 BTW, since you are in process of redesigning of Phobos IO/stream 
 system, it would be great if you take a look at the Tango IO system, 
 first. I recall you telling that you didn't give a good look at Tango, 
 so now is the time. I particularly insist on talking to Kris about it; 
 perhaps, he has some ideas on the topic. He may also share experience 
 with you (errors he made etc). I'll give you a few ideas of mine in a 
 separate post.


 I don't know about licensing issues, and last thing I need would be to 
 be accused of stealing from Tango.
 
 You shouldn't avoid looking on someone's code, especially if it may 
 help D get better standard library. There's nothing wrong with 
 borrowing ideas from others, too, especially if they give you a 
 permission for that. Tango is dual-licensed under Academic Free 
 License v3.0 and BSD License, so there might not be a need to, but 
 anyway.


 I have zero knowledge of licensing stuff, but I understand Walter does. 
 He's not looking at Tango so nor should I. I'm sure it has some cool 
 ideas, but so do other libraries.


You know, this is just counter-productive. There are several people - 
all of them very valuable members of the D community, with countless 
contributions - who have put forth a library with its goals being mainly 
the success of D and especially a vital, alive development process. This 
library is available licensed under BSD, which basically means you can 
do whatever you please with it, as long as you don’t remove the 
copyright of the original authors.

Now, what you’re doing is despite the fact that the Tango sources are 
completely free and available to you, deny any kind of insight you might 
be able to gather in there. Why? If you’re responsible for the standard 
library and you *do* take ideas from Tango and integrate them into the 
official standard library, you’re doing every Tango dev a big favour. 
Because, you know, that’s why there is Tango. You didn’t forget that, 
did you?

No offense intended, of course. I just think you should really 
reconsider your decision to not look at Tango, based on facts. Not based 
on “I  might step on someone’s toes because of I don’t know why.”

Kind regards,
Alex

PS: Pretty please, don’t get me wrong, I really appreciate your 
contributions to D! :)

Mar 19 2009

Don <nospam nospam.com> writes:

Adam D. Ruppe wrote:
 On Thu, Mar 19, 2009 at 11:47:37AM +0100, Alexander P�nek wrote:
 This 
 library is available licensed under BSD, which basically means you can 
 do whatever you please with it, as long as you don???t remove the 
 copyright of the original authors.


 I think that's an unreasonable demand in a standard library. Incorporating
 BSD code into phobos, any amount of it, requires that every D program
 that is ever written to include their copyright notice, since phobos
 is redistributed in binary form with every D program.


I agree, requiring to include copyright with every binary distribution 
is unacceptable for a standard library. But...

Tango is also available under the Academic Free License. Which I don't 
understand, despite having read through the ten page explanation of it.
Specifically, you're allow to change it to "any license of your choice 
that does not contradict the terms and conditions, including Licensor's 
reserved rights and remedies, in this Academic Free License;"

But what does that mean? Which licenses does it include? Does it include 
the zlib license? I presume not.
In which case Andrei and Walter's position is entirely justified. If 
that is correct, I will cease contributing to Tango.

Someone, _please_ tell me I'm wrong.

 That's a pain to hobbyists and might be a roadblock to use the
 language professionally.
 
 As far as I know, the entire phobos library is currently public domain
 or zlib license, which is basically just public domain written out
 explicitly. That's the way it should remain.

Mar 19 2009

Don <nospam nospam.com> writes:

Robert Jacques wrote:
 On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> wrote:
 I agree, requiring to include copyright with every binary distribution 
 is unacceptable for a standard library. But...
 Tango is also available under the Academic Free License. Which I don't 
 understand, despite having read through the ten page explanation of it.
 Specifically, you're allow to change it to "any license of your choice 
 that does not contradict the terms and conditions, including 
 Licensor's reserved rights and remedies, in this Academic Free > 
 License;"
 But what does that mean? Which licenses does it include? Does it 
 include the zlib license? I presume not.
 In which case Andrei and Walter's position is entirely justified. If 
 that is correct, I will cease contributing to Tango.
 Someone, _please_ tell me I'm wrong.


 No, sadly you're right. According to wikipedia, the AFL is not GPL 
 compatible. If AFL could be converted to zlib then you could convert ALF 
 source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF 
 can not be convert to zlib.
 
 So far the only other licence I saw without the binary-licence 
 distribution problem is the Boost Software License (BSL1.0) (And of 
 course the WTFYW licence) And I'm guessing this issue is why they wrote 
 a new licence instead of reusing an old one.


The zlib license also doesn't have the binary distribution problem.

The Boost license looks pretty good to me, and they seem to have used 
better legal consultation than the zlib license. I also like the fact 
that it only occupies 3 lines of source code -- that's much better than 
zlib.

Boost, zlib, WTFYW, and public domain, seem to be the only ones which 
are suitable for a standard library.

 Actually, some of the BSD/MIT like licences might be valid if you 
 included the licence string as a constant in the binary distribution 
 (although this is definitely not in the spirit of the licence)

Mar 20 2009

Fawzi Mohamed <fmohamed mac.com> writes:

On 2009-03-20 13:28:06 +0100, Don <nospam nospam.com> said:

 Robert Jacques wrote:
 On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> wrote:
 I agree, requiring to include copyright with every binary distribution 
 is unacceptable for a standard library. But...
 Tango is also available under the Academic Free License. Which I don't 
 understand, despite having read through the ten page explanation of it.
 Specifically, you're allow to change it to "any license of your choice 
 that does not contradict the terms and conditions, including Licensor's 
 reserved rights and remedies, in this Academic Free > License;"
 But what does that mean? Which licenses does it include? Does it 
 include the zlib license? I presume not.






I read more carefully and tried to understand it better,  I had not 
understood the problem that makes it incompatible with GPL, the thing 
is that it puts extra restrictions that limit the responsibility of the 
licenser, in particular has provisions for revoking the patent granted 
to the licensee should he choose to make a patent claim about the 
original work.

Which is reasonable, but an extra restriction, and thus incompatible with GPL

 In which case Andrei and Walter's position is entirely justified. If 
 that is correct, I will cease contributing to Tango.
 Someone, _please_ tell me I'm wrong.


 No, sadly you're right. According to wikipedia, the AFL is not GPL 
 compatible. If AFL could be converted to zlib then you could convert 
 ALF source to zlib and it would then be GPL compatible. Q.E.D. Hence, 
 ALF can not be convert to zlib.
 
 So far the only other licence I saw without the binary-licence 
 distribution problem is the Boost Software License (BSL1.0) (And of 
 course the WTFYW licence) And I'm guessing this issue is why they wrote 
 a new licence instead of reusing an old one.


 The zlib license also doesn't have the binary distribution problem.
 The Boost license looks pretty good to me, and they seem to have used 
 better legal consultation than the zlib license. I also like the fact 
 that it only occupies 3 lines of source code -- that's much better than 
 zlib.
 
 Boost, zlib, WTFYW, and public domain, seem to be the only ones which 
 are suitable for a standard library.


I agree that these a good licenses for a standard library.

Mar 20 2009

Fawzi Mohamed <fmohamed mac.com> writes:

On 2009-03-20 05:46:08 +0100, "Robert Jacques" <sandford jhu.edu> said:

 On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> wrote:
 I agree, requiring to include copyright with every binary distribution  
 is unacceptable for a standard library. But...
 Tango is also available under the Academic Free License. Which I don't  
 understand, despite having read through the ten page explanation of it.
 Specifically, you're allow to change it to "any license of your choice  
 that does not contradict the terms and conditions, including Licensor's 
  reserved rights and remedies, in this Academic Free > License;"
 But what does that mean? Which licenses does it include? Does it 
 include  the zlib license? I presume not.
 In which case Andrei and Walter's position is entirely justified. If  
 that is correct, I will cease contributing to Tango.
 Someone, _please_ tell me I'm wrong.


 No, sadly you're right. According to wikipedia, the AFL is not GPL  
 compatible. If AFL could be converted to zlib then you could convert 
 ALF  source to zlib and it would then be GPL compatible. Q.E.D. Hence, 
 ALF can  not be convert to zlib.


yes as far as I understand the problem with AFL is that it has a kind 
of viral component like GPL, in that derivative work need to have a 
compatible license, and redistribution should ensure that the license 
is preserved, zlib does not have that.

I don't think it is wrong, but I would be happy also with zlib...

Fawzi

 So far the only other licence I saw without the binary-licence  
 distribution problem is the Boost Software License (BSL1.0) (And of 
 course  the WTFYW licence) And I'm guessing this issue is why they 
 wrote a new  licence instead of reusing an old one.
 
 Actually, some of the BSD/MIT like licences might be valid if you 
 included  the licence string as a constant in the binary distribution 
 (although this  is definitely not in the spirit of the licence)

Mar 20 2009

Fawzi Mohamed <fmohamed mac.com> writes:

after some extra digging

tango licensing:

BSD (and this is the revised 3 clause BSD)
- is compatible with GPL
- copyright need to be advertised also in the documentation and binary

a commonly used permissive license (which probably you are using when 
linking for example network code in almost any operating system).
It does *not* include the original fourth statement of BSD

APL
- similar to BSD, but with some extra protections against the liability 
of the licenser, in particular with respect to patents
- these extra restrictions make it incompatible with GPLv2
- it should be equivalent to apache 2.0 ( 
http://www.opensource.org/proliferation-report )
and so it might be compatible with GPLv3 but I am not 100% sure on this.

In any case the double licensing of tango allows one to use it also 
with GPL code

Fawzi

Mar 20 2009

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

Fawzi Mohamed wrote:
 after some extra digging
 
 tango licensing:
 
 BSD (and this is the revised 3 clause BSD)
 - is compatible with GPL
 - copyright need to be advertised also in the documentation and binary
 
 a commonly used permissive license (which probably you are using when
 linking for example network code in almost any operating system).
 It does *not* include the original fourth statement of BSD
 
 APL
 - similar to BSD, but with some extra protections against the liability
 of the licenser, in particular with respect to patents
 - these extra restrictions make it incompatible with GPLv2
 - it should be equivalent to apache 2.0 (
 http://www.opensource.org/proliferation-report )
 and so it might be compatible with GPLv3 but I am not 100% sure on this.
 
 In any case the double licensing of tango allows one to use it also with
 GPL code
 
 Fawzi
 


When was the last time you had to put this in your GCC-compiled programs?

"Portions of this program Copyright (C) Free Software Foundation.  Uses
glibc."

For a regular library, binary attribution clauses are OK.  For a
standard library, it's distasteful [1].  I shouldn't HAVE to worry about
legal issues from compiling Hello World.

  -- Daniel

[1] I've contributed code to Tango under BSD.  If I'd have known about
this issue, I would have made it Public Domain or a license without the
binary attribution clause.

Mar 20 2009

Christopher Wright <dhasenan gmail.com> writes:

Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled programs?
 
 "Portions of this program Copyright (C) Free Software Foundation.  Uses
 glibc."


Executable code resulting from compilation is not a work derived from GCC.

glibc is extremely difficult to link statically and is distributed under 
the LGPL, so no copyright notice is necessary.

If dmd had good support for dynamic linking, this wouldn't be nearly as 
much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it 
can't be applied to the runtime.

Mar 20 2009

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

Christopher Wright wrote:
 Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled programs?

 "Portions of this program Copyright (C) Free Software Foundation.  Uses
 glibc."


 Executable code resulting from compilation is not a work derived from GCC.
 
 glibc is extremely difficult to link statically and is distributed under
 the LGPL, so no copyright notice is necessary.
 
 If dmd had good support for dynamic linking, this wouldn't be nearly as
 much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it
 can't be applied to the runtime.


I think you're missing my point.  I'm saying that a standard library
shouldn't require you to insert legal disclaimers or attribution notices
into your program or its documentation.

A standard library should be be as invisible as possible in this regard.

  -- Daniel

Mar 21 2009

Christopher Wright <dhasenan gmail.com> writes:

Daniel Keep wrote:
 
 Christopher Wright wrote:
 Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled programs?

 "Portions of this program Copyright (C) Free Software Foundation.  Uses
 glibc."



 glibc is extremely difficult to link statically and is distributed under
 the LGPL, so no copyright notice is necessary.

 If dmd had good support for dynamic linking, this wouldn't be nearly as
 much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it
 can't be applied to the runtime.


 I think you're missing my point.  I'm saying that a standard library
 shouldn't require you to insert legal disclaimers or attribution notices
 into your program or its documentation.
 
 A standard library should be be as invisible as possible in this regard.
 
   -- Daniel


Right. It's invisible with glibc because you link to it dynamically, and 
because everyone installs it by default. Druntime has neither of these 
advantages.

Mar 21 2009

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

Christopher Wright wrote:
 Daniel Keep wrote:
 Christopher Wright wrote:
 Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled
 programs?

 "Portions of this program Copyright (C) Free Software Foundation.  Uses
 glibc."


 GCC.

 glibc is extremely difficult to link statically and is distributed under
 the LGPL, so no copyright notice is necessary.

 If dmd had good support for dynamic linking, this wouldn't be nearly as
 much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it
 can't be applied to the runtime.


 I think you're missing my point.  I'm saying that a standard library
 shouldn't require you to insert legal disclaimers or attribution notices
 into your program or its documentation.

 A standard library should be be as invisible as possible in this regard.

   -- Daniel


 Right. It's invisible with glibc because you link to it dynamically, and
 because everyone installs it by default. Druntime has neither of these
 advantages.


I'm not talking about distribution of the actual library machine code,
I'm talking about the LEGAL ISSUES.  Tango's license apparently requires
you to explicitly include attribution for Tango in your program.  This
means it's possible to naively compile "Hello, World" with Tango,
distribute it and break the law.

That glibc uses dynamic linking is immaterial: that there is no way to
avoid the legal issues with Tango no matter what you do is the point I'm
trying to make.

  -- Daniel

Mar 21 2009

Lars Ivar Igesund <larsivar igesund.net> writes:

Daniel Keep wrote:

 I'm not talking about distribution of the actual library machine code,
 I'm talking about the LEGAL ISSUES.  Tango's license apparently requires
 you to explicitly include attribution for Tango in your program.  This
 means it's possible to naively compile "Hello, World" with Tango,
 distribute it and break the law.


Sorry to use you as the source to enter the thread, Daniel.

Tango DOES NOT IN ANY WAY require you to put attribution into your program. 
That is a choice you as a user would make entirely on your own by choosing 
to use Tango licensed under the BSD (which is quite possible because this 
license is better suited for use alongside the GPL).

However, the AFL does not put such a restriction on your binaries, and 
(unless you use the GPL for your code) the AFL is the license most users 
should use. This is also noted on the license page (it was probably not 
clear enough, I hope it is now).

http://dsource.org/projects/tango/wiki/LibraryLicense

For current or prospective contributors; you are completely and entirely 
entitled to relicense your own code to whichever license you wish, however 
these should also include the AFL and BSD when used in Tango.

To change the license to something else at this point (for instance to 
Apache 2.0 only), would be a major undertaking, but something that we may 
consider to do at a later point.

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

Mar 21 2009

Georg Wrede <georg.wrede iki.fi> writes:

Lars Ivar Igesund wrote:
 Daniel Keep wrote:
 
 I'm not talking about distribution of the actual library machine code,
 I'm talking about the LEGAL ISSUES.  Tango's license apparently requires
 you to explicitly include attribution for Tango in your program.  This
 means it's possible to naively compile "Hello, World" with Tango,
 distribute it and break the law.


 Sorry to use you as the source to enter the thread, Daniel.
 
 Tango DOES NOT IN ANY WAY require you to put attribution into your program. 
 That is a choice you as a user would make entirely on your own by choosing 
 to use Tango licensed under the BSD (which is quite possible because this 
 license is better suited for use alongside the GPL).
 
 However, the AFL does not put such a restriction on your binaries, and 
 (unless you use the GPL for your code) the AFL is the license most users 
 should use. This is also noted on the license page (it was probably not 
 clear enough, I hope it is now).
 
 http://dsource.org/projects/tango/wiki/LibraryLicense
 
 For current or prospective contributors; you are completely and entirely 
 entitled to relicense your own code to whichever license you wish, however 
 these should also include the AFL and BSD when used in Tango.
 
 To change the license to something else at this point (for instance to 
 Apache 2.0 only), would be a major undertaking, but something that we may 
 consider to do at a later point.


I read http://dsource.org/projects/tango/wiki/LibraryLicense.

I am sorry to say, the page /still/ is not /clear/ enough. (As of Mar 
22, 00:24 UTC.)

The first bullets establish the intent, yes. But everything after that 
is actually... worthless. What the page should instead say, is /in terms 
understandable to/ *anybody*, explain what you have to do if you 
incorporate Tango in your software, or if you make another library that 
depends on Tango.

Even if this includes "awkward things" (like having to have a constant 
string in the binary, mentioning Tango in the "About" menu item, or 
whatever else), it should be stated in layman-understandable terms.

Currently, words like "encumbrance", phrases like "provides broad 
rights" etc. only make the prospective reader run away in frustration. 
Just state what you want, in language that can be understood at First 
Reading, without asking your mother. Or both of you having an IQ of 170+.

I'm not surprised that Don and others are getting second thoughts about 
contributing. A /clear/ stance to these issues makes everybody's 
(contributors, users, OS distributors, even app vendors) life easier. 
And, therefore, increases the popularity of Tango.

Mar 21 2009

Walter Bright <newshound1 digitalmars.com> writes:

Georg Wrede wrote:
 Even if this includes "awkward things" (like having to have a constant 
 string in the binary, mentioning Tango in the "About" menu item, or 
 whatever else), it should be stated in layman-understandable terms.
 
 Currently, words like "encumbrance", phrases like "provides broad 
 rights" etc. only make the prospective reader run away in frustration. 
 Just state what you want, in language that can be understood at First 
 Reading, without asking your mother. Or both of you having an IQ of 170+.



Having been involved with occasional contract disputes, I concur that 
the simpler and more obvious the language is, the better (and the lower 
your lawyer bill is :-) ).

Mar 22 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Having been involved with occasional contract disputes, I concur that
 the simpler and more obvious the language is, the better (and the lower
 your lawyer bill is :-) ).


A perfect argument for the WTFPL!

Mar 22 2009

Don <nospam nospam.com> writes:

dsimcha wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Having been involved with occasional contract disputes, I concur that
 the simpler and more obvious the language is, the better (and the lower
 your lawyer bill is :-) ).


 A perfect argument for the WTFPL!


Yeah, but imagine a big lawsuit involving the WTFPL. There'd be a huge 
court case about what the F-word means. It'd be hilarious.

Mar 23 2009

Fawzi Mohamed <fmohamed mac.com> writes:

On 2009-03-21 14:23:51 +0100, Daniel Keep <daniel.keep.lists gmail.com> said:

 
 
 Christopher Wright wrote:
 Daniel Keep wrote:
 
 Christopher Wright wrote:
 Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled
 programs?
 
 "Portions of this program Copyright (C) Free Software Foundation.  Uses
 glibc."


 GCC.
 
 glibc is extremely difficult to link statically and is distributed under
 the LGPL, so no copyright notice is necessary.
 
 If dmd had good support for dynamic linking, this wouldn't be nearly as
 much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it
 can't be applied to the runtime.


 I think you're missing my point.  I'm saying that a standard library
 shouldn't require you to insert legal disclaimers or attribution notices
 into your program or its documentation.
 
 A standard library should be be as invisible as possible in this regard.
 
 -- Daniel


 Right. It's invisible with glibc because you link to it dynamically, and
 because everyone installs it by default. Druntime has neither of these
 advantages.


 I'm not talking about distribution of the actual library machine code,
 I'm talking about the LEGAL ISSUES.  Tango's license apparently requires
 you to explicitly include attribution for Tango in your program.  This
 means it's possible to naively compile "Hello, World" with Tango,
 distribute it and break the law.
 
 That glibc uses dynamic linking is immaterial: that there is no way to
 avoid the legal issues with Tango no matter what you do is the point I'm
 trying to make.
 
   -- Daniel


This is bullshit, if you look at the header of c stdio.h you extremely 
likely to find exactly the same disclaimer (at least I did find it).

If in your program you have an "about" and copyright, or you have 
documentation to it, then yes you should credit the inclusion of tango 
if you use the BSD license.

If you want to avoid this then you should use the AFL license (which 
yes is incompatible with GPLv2).

This if looking more and more like FUD.

Fawzi

Mar 21 2009

Fawzi Mohamed <fmohamed mac.com> writes:

On 2009-03-21 20:19:15 +0100, Fawzi Mohamed <fmohamed mac.com> said:

 On 2009-03-21 14:23:51 +0100, Daniel Keep <daniel.keep.lists gmail.com> said:
 
 
 Christopher Wright wrote:
 Daniel Keep wrote:
 
 Christopher Wright wrote:
 Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled
 programs?
 
 "Portions of this program Copyright (C) Free Software Foundation.  Uses
 glibc."


 GCC.
 
 glibc is extremely difficult to link statically and is distributed under
 the LGPL, so no copyright notice is necessary.
 
 If dmd had good support for dynamic linking, this wouldn't be nearly as
 much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it
 can't be applied to the runtime.


 I think you're missing my point.  I'm saying that a standard library
 shouldn't require you to insert legal disclaimers or attribution notices
 into your program or its documentation.
 
 A standard library should be be as invisible as possible in this regard.
 
 -- Daniel


 Right. It's invisible with glibc because you link to it dynamically, and
 because everyone installs it by default. Druntime has neither of these
 advantages.


 I'm not talking about distribution of the actual library machine code,
 I'm talking about the LEGAL ISSUES.  Tango's license apparently requires
 you to explicitly include attribution for Tango in your program.  This
 means it's possible to naively compile "Hello, World" with Tango,
 distribute it and break the law.
 
 That glibc uses dynamic linking is immaterial: that there is no way to
 avoid the legal issues with Tango no matter what you do is the point I'm
 trying to make.
 
   -- Daniel


 This is bullshit, if you look at the header of c stdio.h you extremely 
 likely to find exactly the same disclaimer (at least I did find it).
 
 If in your program you have an "about" and copyright, or you have 
 documentation to it, then yes you should credit the inclusion of tango 
 if you use the BSD license.
 
 If you want to avoid this then you should use the AFL license (which 
 yes is incompatible with GPLv2).
 
 This if looking more and more like FUD.
 
 Fawzi


Sorry if I reacted a little too vehemently

Fawzi

Mar 21 2009

Don <nospam nospam.com> writes:

Fawzi Mohamed wrote:
 On 2009-03-21 14:23:51 +0100, Daniel Keep <daniel.keep.lists gmail.com> 
 said:
 
 Christopher Wright wrote:
 Daniel Keep wrote:
 Christopher Wright wrote:
 Daniel Keep wrote:
 When was the last time you had to put this in your GCC-compiled
 programs?

 "Portions of this program Copyright (C) Free Software Foundation.  
 Uses
 glibc."


 GCC.

 glibc is extremely difficult to link statically and is distributed 
 under
 the LGPL, so no copyright notice is necessary.

 If dmd had good support for dynamic linking, this wouldn't be 
 nearly as
 much of an issue. Sadly, ddl seems to be on hiatus, and at any 
 rate, it
 can't be applied to the runtime.


 I think you're missing my point.  I'm saying that a standard library
 shouldn't require you to insert legal disclaimers or attribution 
 notices
 into your program or its documentation.

 A standard library should be be as invisible as possible in this 
 regard.

 -- Daniel


 Right. It's invisible with glibc because you link to it dynamically, and
 because everyone installs it by default. Druntime has neither of these
 advantages.


 I'm not talking about distribution of the actual library machine code,
 I'm talking about the LEGAL ISSUES.  Tango's license apparently requires
 you to explicitly include attribution for Tango in your program.  This
 means it's possible to naively compile "Hello, World" with Tango,
 distribute it and break the law.

 That glibc uses dynamic linking is immaterial: that there is no way to
 avoid the legal issues with Tango no matter what you do is the point I'm
 trying to make.

   -- Daniel


 This is bullshit, if you look at the header of c stdio.h you extremely 
 likely to find exactly the same disclaimer (at least I did find it).
 
 If in your program you have an "about" and copyright, or you have 
 documentation to it, then yes you should credit the inclusion of tango 
 if you use the BSD license.


Even if it doesn't have an "about" or documentation, you STILL need to 
include a license, as far as I can see. I don't see anything in the BSD 
license that allows you to avoid it, ever.

 If you want to avoid this then you should use the AFL license (which yes 
 is incompatible with GPLv2).
 
 This if looking more and more like FUD.
 
 Fawzi
 


Tango genuinely _are_ incompatible in terms of license issues.

Are you sure that the AFL allows you to avoid the issue of providing a 
license? It's astonishingly difficult to make sense of that license. The 
16-page commentary that it links you to is total rubbish, it seems to 
basically be an attack on the GPL, without saying what the AFL actually 
is. It only says:

"In effect, then, AFL 3.0 is like the BSD license, with no
reciprocal obligation to disclose source code."
What the heck does "like" mean?
It's certainly not the same, since BSD is GPL-compatible and AFL isn't.
On that basis, it is NOT like the BSD license.
I find that document (http://www.rosenlaw.com/OSL3.0-explained.pdf) 
appalling, and it severely erodes my confidence in the AFL.

Mar 22 2009

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Mar 23, 2009 at 5:02 AM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Having been involved with occasional contract disputes, I concur that
 the simpler and more obvious the language is, the better (and the lower
 your lawyer bill is :-) ).


 A perfect argument for the WTFPL!


As I understand it, in some places a warranty on software is implied
if not specifically disclaimed.  That's why such disclaimers can be
found in just about every software license.  I am not a lawyer, but I
heard this from a lawyer.

--bb

Mar 22 2009

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

On 2009-03-17 20:26:16 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Interesting. Should I do the same in phobos?
 
 stdout("wyda");
 
 I'd like that particularly because write() is too common a name to 
 place at namespace level for my taste. So then we'd have:
 
 stdout("wyda"); // no newline
 stdout("wyda\n"); // newline but no flushing on binary stream
 stdout("wyda", newline); // write'n'flush
 stdout.writeln("wyda"); // same
 
 If we go that route I'll even drop writeln and rely on passing newline. 
 For formatting there'd be stdout.format and stdout.formatln or 
 something.


Seems nice. Can this work symmetrically for stdin?

	int i;
	stdin(i); // reads an integer and place it in i.

That would make things interesting, as with some streams you could use 
the same code to serialize and unserialize a data structures.

	stream(x, y, z); // either write or read the values depending on the stream.

This reminds me of boost serialization which use a similar trick 
allowing you to have a single function template to both serialize and 
unserialize a given data type.

But that probably couldn't work with the standard text stream types.

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

Mar 17 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Andrei Alexandrescu wrote:
 Hey all y'all,
 
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");
 
 instead of the current:
 
 writeln("Hello, world");
 
 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.
 
 What do you think?


There must be something I'm missing here. Either writeln is using a 
global "stdout" which you can't see in it's interface, or you are using 
that global "stdout" yourself and invoking writeln on it. There's still 
a global around. Nothing solved.

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it 
 would be better and cleaner to write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


 There must be something I'm missing here. Either writeln is using a 
 global "stdout" which you can't see in it's interface, or you are using 
 that global "stdout" yourself and invoking writeln on it. There's still 
 a global around. Nothing solved.


The difference is that in the current call the use of the global is 
implicit.

Andrei

Mar 17 2009

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent
 discussion about globals being harmful, Walter told me something that
 made me think. I said, hey, there are things that are global - look at
 stdout. He said, well, that's a bad thing. He then argued that it
 would be better and cleaner to write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


 There must be something I'm missing here. Either writeln is using a
 global "stdout" which you can't see in it's interface, or you are using
 that global "stdout" yourself and invoking writeln on it. There's still
 a global around. Nothing solved.


 implicit.


Once D will accept both syntaxes for methods, it will be up to the user.

void fn( t1 p1, t2, p2 );
fn( v1, v2 ); <-> v1.fn( v2 );

Mar 17 2009

Sean Kelly <sean invisibleduck.org> writes:

Andrei Alexandrescu wrote:
 Hey all y'all,
 
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");


But then stdout is still global :-)  However, I do think an "fwritef" 
routine would be good to have--I tend to write to stderr as often as stdout.

Mar 17 2009

Max Samukha <samukha voliacable.com.removethis> writes:

On Tue, 17 Mar 2009 08:56:58 -0700, Sean Kelly
<sean invisibleduck.org> wrote:

Andrei Alexandrescu wrote:
 Hey all y'all,
 
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");


But then stdout is still global :-)  However, I do think an "fwritef" 
routine would be good to have--I tend to write to stderr as often as stdout.


writef recognizes if its first parameter is a stream. you can already
use writef(stderr, ...)

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Max Samukha wrote:
 On Tue, 17 Mar 2009 08:56:58 -0700, Sean Kelly
 <sean invisibleduck.org> wrote:
 
 Andrei Alexandrescu wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:

 stdout.writeln("Hello, world");


 routine would be good to have--I tend to write to stderr as often as stdout.


 writef recognizes if its first parameter is a stream. you can already
 use writef(stderr, ...)


(Not in the upcoming Phobos.)


Andrei

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Sean Kelly wrote:
 Andrei Alexandrescu wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it 
 would be better and cleaner to write:

 stdout.writeln("Hello, world");


 But then stdout is still global :-)  However, I do think an "fwritef" 
 routine would be good to have--I tend to write to stderr as often as 
 stdout.


Yah, there is in the elusive new Phobos which I still can't release due 
to compiler bugs:

auto f = File("foo.txt", "w");
f.writef("%s", 42);


Andrei

Mar 17 2009

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

On Tue, Mar 17, 2009 at 4:58 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 (Not in the upcoming Phobos.)


It's a little difficult to have a style discussion with you about
Phobos when you're envisioning an entirely different library than what
we have now ;)

Mar 17 2009

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

On Tue, Mar 17, 2009 at 11:35 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent discussion
 about globals being harmful, Walter told me something that made me think. I
 said, hey, there are things that are global - look at stdout. He said, well,
 that's a bad thing. He then argued that it would be better and cleaner to
 write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


Keep writefln.  You're only going to be using it when (1) you're doing
debugging, when you want it short, and (2) you're writing a simple
console program.  There's always dout.writefln when you need more
power.

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Jarrett Billingsley wrote:
 On Tue, Mar 17, 2009 at 11:35 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent discussion
 about globals being harmful, Walter told me something that made me think. I
 said, hey, there are things that are global - look at stdout. He said, well,
 that's a bad thing. He then argued that it would be better and cleaner to
 write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


 Keep writefln.  You're only going to be using it when (1) you're doing
 debugging, when you want it short, and (2) you're writing a simple
 console program.  There's always dout.writefln when you need more
 power.


Is dout in the std.stream thing? That entire framework is due for 
retirement.

Andrei

Mar 17 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Hey all y'all,
 Here's another nice bicycle shed discussion. During the recent
 discussion about globals being harmful, Walter told me something that
 made me think. I said, hey, there are things that are global - look at
 stdout. He said, well, that's a bad thing. He then argued that it would
 be better and cleaner to write:
 stdout.writeln("Hello, world");
 instead of the current:
 writeln("Hello, world");
 On one hand, I agree with Walter. On the other, I want to avoid the
 phenomenon of the all-too-long "Hello, world" example.
 What do you think?
 Andrei


To me, the current form is best because it doesn't force you to explicitly
specify
that you want to write to stdout.  Thus, it makes simple things simple.  Of
course
DWIM isn't always a good idea, but when an obvious, safe default exists, I
prefer
not to have to explicitly specify this kind of stuff unless I want to override
the
default.

Also, I don't see globals as being all that evil in themselves.  Global
_mutable_
state is an absolute mortal sin, but I see absolutely nothing wrong with global
variables that are immutable, or even set once and treated as read-only by
convention after initialization.

Mar 17 2009

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Andrei Alexandrescu wrote:

 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");
 
 instead of the current:
 
 writeln("Hello, world");


I thought the current was printf :-)

Looking at dmd/samples/d/hello.d

--anders

Mar 17 2009

Georg Wrede <georg.wrede iki.fi> writes:

Anders F Bj�rklund wrote:
 Andrei Alexandrescu wrote:
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it 
 would be better and cleaner to write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");


 I thought the current was printf :-)
 
 Looking at dmd/samples/d/hello.d


LOL

Mar 17 2009

Georg Wrede <georg.wrede iki.fi> writes:

Andrei Alexandrescu wrote:
 Hey all y'all,
 
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");
 
 instead of the current:
 
 writeln("Hello, world");
 
 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.
 
 What do you think?


1. It is not often that a program that is first designed to write to 
stdout is changed to write to somewhere else. (The whole reason of 
stdout is, after all, that you can redirect outside the program!)

2. Of course it would be Proper (as in Prudent, almost as in goody 
two-shoes) to write stdout.writeln. But then, to be useful the 
programmer should write myOutDestination.writeln in order to be able to 
"conveniently" later change the destination.

3. IMHO later redefining stdout would be a moronic idea. (And 
/definitely/ not Prudent!)

4. Globals, shmobals... globals in spirit vs. globals in techicality. I 
can't /believe/ there's any idea in totally banning globals. Heck, this 
language has *goto*. Blind purism has made a few other languages 
impractical.

5. Good defaults a good UI make. Can't we just decide that a bare 
writeln(...) is defined as writing to stdout, period? Without thinking 
of globals.

6. stdout is "global" to such an extent, that it actually exists outside 
of the program. (RTF *nix man, man!)

Blehhhhhhh....

PS, I don't think you were serious with the post.

Mar 17 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Georg Wrede wrote:
 Andrei Alexandrescu wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it 
 would be better and cleaner to write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


 1. It is not often that a program that is first designed to write to 
 stdout is changed to write to somewhere else. (The whole reason of 
 stdout is, after all, that you can redirect outside the program!)
 
 2. Of course it would be Proper (as in Prudent, almost as in goody 
 two-shoes) to write stdout.writeln. But then, to be useful the 
 programmer should write myOutDestination.writeln in order to be able to 
 "conveniently" later change the destination.
 
 3. IMHO later redefining stdout would be a moronic idea. (And 
 /definitely/ not Prudent!)
 
 4. Globals, shmobals... globals in spirit vs. globals in techicality. I 
 can't /believe/ there's any idea in totally banning globals. Heck, this 
 language has *goto*. Blind purism has made a few other languages 
 impractical.
 
 5. Good defaults a good UI make. Can't we just decide that a bare 
 writeln(...) is defined as writing to stdout, period? Without thinking 
 of globals.
 
 6. stdout is "global" to such an extent, that it actually exists outside 
 of the program. (RTF *nix man, man!)
 
 Blehhhhhhh....
 
 PS, I don't think you were serious with the post.


I was, serious and especially curious. I'm with you on all of the above.

Andrei

Mar 17 2009

Georg Wrede <georg.wrede iki.fi> writes:

Andrei Alexandrescu wrote:
 Georg Wrede wrote:
 Andrei Alexandrescu wrote:
 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look 
 at stdout. He said, well, that's a bad thing. He then argued that it 
 would be better and cleaner to write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


 1. It is not often that a program that is first designed to write to 
 stdout is changed to write to somewhere else. (The whole reason of 
 stdout is, after all, that you can redirect outside the program!)

 2. Of course it would be Proper (as in Prudent, almost as in goody 
 two-shoes) to write stdout.writeln. But then, to be useful the 
 programmer should write myOutDestination.writeln in order to be able 
 to "conveniently" later change the destination.

 3. IMHO later redefining stdout would be a moronic idea. (And 
 /definitely/ not Prudent!)

 4. Globals, shmobals... globals in spirit vs. globals in techicality. 
 I can't /believe/ there's any idea in totally banning globals. Heck, 
 this language has *goto*. Blind purism has made a few other languages 
 impractical.

 5. Good defaults a good UI make. Can't we just decide that a bare 
 writeln(...) is defined as writing to stdout, period? Without thinking 
 of globals.

 6. stdout is "global" to such an extent, that it actually exists 
 outside of the program. (RTF *nix man, man!)

 Blehhhhhhh....

 PS, I don't think you were serious with the post.


 I was, serious and especially curious. I'm with you on all of the above.


:-)

Mar 17 2009

Georg Wrede <georg.wrede iki.fi> writes:

Andrei Alexandrescu wrote:

...

 I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");
 
 instead of the current:
 
 writeln("Hello, world");



int x;

I suggest we forbid int totally. It is too [insert something here], and 
it is ambiguous, strictly speaking.

So forbid it, and force the programmer to explicitly specify signed or 
unsigned, every single time. It would be better and cleaner.

Mar 17 2009

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

On Tue, 17 Mar 2009 19:46:37 +0300, Nick Sabalausky <a a.a> wrote:

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:mailman.967.1237304767.22690.digitalmars-d puremagic.com...
 On Tue, Mar 17, 2009 at 08:35:35AM -0700, Andrei Alexandrescu wrote:
 What do you think?


 Eeek. That's too much typing for a trivial, common operation.

 I wouldn't mind writefln being implemented as a macro that is turned to
 fwritefln(stdout, ...)

 But, I'd be fairly annoyed having to write the extra seven characters  
 each
 time if the short version wasn't there.


 That's how tango and C# do it.

 Stdout.formatln("Hello"); // Tango
 Console.WriteLine("Hello"); // C#

 My preference has always been for something shorter, but the current
 tango/C# ways have never really bothered me. You get used to it pretty
 quick.


That's not a very frequent operation. In most cases you should use
Cout("Hello"); instead. An ideal design solution, imo (fast, short and clear).

Back on topic, in most cases I use:

debug writefln("hello");

because I have no console in release version (and it throws when there is no
stdout, look in the bugzilla for a bug report). It is already long enough, so I
wouldn't like it to be even longer:

debug stdio.writefln("hello");

My 0.02 rubles.

Mar 17 2009

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

On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 That's not a very frequent operation. In most cases you should use  
 Cout("Hello"); instead. An ideal design solution, imo (fast, short and  
 clear).


 Interesting. Should I do the same in phobos?

 stdout("wyda");

 I'd like that particularly because write() is too common a name to place  
 at namespace level for my taste. So then we'd have:

 stdout("wyda"); // no newline
 stdout("wyda\n"); // newline but no flushing on binary stream
 stdout("wyda", newline); // write'n'flush
 stdout.writeln("wyda"); // same

 If we go that route I'll even drop writeln and rely on passing newline.  
 For formatting there'd be stdout.format and stdout.formatln or something.


This is funny because Tango has adopted exactly the same design.
The only difference is that Stdout is written in upper case:

import tango.io.Stdout;

void main() {
    Stdout("Hello, World\n"); // no flushing
    Stdout("Hello, World").newline; // new line appended, flushs
    Stdout.format("Hello, {}!", "Andrei").newline; // formatting
    Stdout.formatln("Hello, {}!", "Kris");
}

It would be great if the two libraries share the same interface.

BTW, since you are in process of redesigning of Phobos IO/stream system, it
would be great if you take a look at the Tango IO system, first. I recall you
telling that you didn't give a good look at Tango, so now is the time. I
particularly insist on talking to Kris about it; perhaps, he has some ideas on
the topic. He may also share experience with you (errors he made etc). I'll
give you a few ideas of mine in a separate post.

You shouldn't avoid looking on someone's code, especially if it may help D get
better standard library. There's nothing wrong with borrowing ideas from
others, too, especially if they give you a permission for that. Tango is
dual-licensed under Academic Free License v3.0 and BSD License, so there might
not be a need to, but anyway.

 Back on topic, in most cases I use:
  debug writefln("hello");
  because I have no console in release version (and it throws when there  
 is no stdout, look in the bugzilla for a bug report). It is already  
 long enough, so I wouldn't like it to be even longer:
  debug stdio.writefln("hello");
  My 0.02 rubles.


 Got them.


 Andrei

Mar 17 2009

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

Andrei Alexandrescu Wrote:

 Hey all y'all,
 
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");
 
 instead of the current:
 
 writeln("Hello, world");
 
 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.
 
 What do you think?
 
 
 Andrei


A lot of people have enjoyed the simplicity of using Phobos and it'd be a shame
to ruin that.  writeln is extremely common, especially with gdb support broken
;)

Mar 17 2009

Bill Baxter <wbaxter gmail.com> writes:

On Wed, Mar 18, 2009 at 12:24 PM, Jason House
<jason.james.house gmail.com> wrote:
 Andrei Alexandrescu Wrote:

 Hey all y'all,


 Here's another nice bicycle shed discussion. During the recent
 discussion about globals being harmful, Walter told me something that
 made me think. I said, hey, there are things that are global - look at
 stdout. He said, well, that's a bad thing. He then argued that it would
 be better and cleaner to write:

 stdout.writeln("Hello, world");

 instead of the current:

 writeln("Hello, world");

 On one hand, I agree with Walter. On the other, I want to avoid the
 phenomenon of the all-too-long "Hello, world" example.

 What do you think?


 Andrei


 A lot of people have enjoyed the simplicity of using Phobos and it'd be a=


pport broken ;)

I think if you're going to change it at all it should be made shorter,
not longer.
And for heaven's sake, don't remove the version of the function that
automatically appends a newline!  I always forget to put the dang \n
at the end of all my printfs in C, so from the very beginning I though
writefln was a godsend for that one thing alone.

--bb

Mar 17 2009

Don <nospam nospam.com> writes:

Andrei Alexandrescu wrote:
 Hey all y'all,
 
 
 Here's another nice bicycle shed discussion. During the recent 
 discussion about globals being harmful, Walter told me something that 
 made me think. I said, hey, there are things that are global - look at 
 stdout. He said, well, that's a bad thing. He then argued that it would 
 be better and cleaner to write:
 
 stdout.writeln("Hello, world");
 
 instead of the current:
 
 writeln("Hello, world");
 
 On one hand, I agree with Walter. On the other, I want to avoid the 
 phenomenon of the all-too-long "Hello, world" example.
 
 What do you think?
 
 
 Andrei


I have always thought of writefln as the flagship function of Phobos. 
It's now looking as though the connection between Phobos2 and Phobos1 is 
not really any stronger than between Tango1 and Phobos1.
(This is an observation, not intended to be critical in any way).

Mar 18 2009

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Thu, Mar 19, 2009 at 11:47:37AM +0100, Alexander P�nek wrote:
 This 
 library is available licensed under BSD, which basically means you can 
 do whatever you please with it, as long as you don???t remove the 
 copyright of the original authors.


I think that's an unreasonable demand in a standard library. Incorporating
BSD code into phobos, any amount of it, requires that every D program
that is ever written to include their copyright notice, since phobos
is redistributed in binary form with every D program.

That's a pain to hobbyists and might be a roadblock to use the
language professionally.

As far as I know, the entire phobos library is currently public domain
or zlib license, which is basically just public domain written out
explicitly. That's the way it should remain.


-- 
Adam D. Ruppe
http://arsdnet.net

Mar 19 2009

"Robert Jacques" <sandford jhu.edu> writes:

On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> wrote:
 I agree, requiring to include copyright with every binary distribution  
 is unacceptable for a standard library. But...
Tango is also available under the Academic Free License. Which I don't  
 understand, despite having read through the ten page explanation of it.
 Specifically, you're allow to change it to "any license of your choice  
 that does not contradict the terms and conditions, including Licensor's  
 reserved rights and remedies, in this Academic Free > License;"
But what does that mean? Which licenses does it include? Does it include  
 the zlib license? I presume not.
 In which case Andrei and Walter's position is entirely justified. If  
 that is correct, I will cease contributing to Tango.
Someone, _please_ tell me I'm wrong.


No, sadly you're right. According to wikipedia, the AFL is not GPL  
compatible. If AFL could be converted to zlib then you could convert ALF  
source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF can  
not be convert to zlib.

So far the only other licence I saw without the binary-licence  
distribution problem is the Boost Software License (BSL1.0) (And of course  
the WTFYW licence) And I'm guessing this issue is why they wrote a new  
licence instead of reusing an old one.

Actually, some of the BSD/MIT like licences might be valid if you included  
the licence string as a constant in the binary distribution (although this  
is definitely not in the spirit of the licence)

Mar 19 2009

"Robert Jacques" <sandford jhu.edu> writes:

On Fri, 20 Mar 2009 08:28:06 -0400, Don <nospam nospam.com> wrote:
 Boost, zlib, WTFYW, and public domain, seem to be the only ones which  
 are suitable for a standard library.


Actually, due to some interesting aspects of international copyright law  
public domain isn't suitable for a standard library. In some countries it  
is not possible to put a work into the public domain; a work may only  
enter it once the copyright has expired.

Mar 20 2009

D Programming

C/C++ Programming

Other

digitalmars.D - eliminate writeln et comp?