Re: short thoughts on D (like my twitter)

[Nick Sabalausky]

Adam D. Ruppe destructiona...@gmail.com wrote in message 
news:isu59p$6sd$1...@digitalmars.com...
 Nick Sabalausky wrote:
 But I do have something that just happens to arguably be a lot like
 a blog and uses a blogging engine ;)

 Gah, only weens use blogging engines!

 I tend to just write my stuff as plain html files (like you can see
 here). Sometimes I'll factor out common things, but I usually
 don't venture far from plain text.


Heh, I have no idea what a ween is. I gotta (partially) agree though, I've 
yet to find a blogging engine that I'm particularly happy with. The main 
reason I didn't want to go with plain HTML though was because that makes 
creating and updating navigation a pain. Maybe something like Ddoc could 
take care of that, though. But I also like allowing comments (with captcha), 
because then I actually get occasional feedback. And some people do like RSS 
(more below...).

Of course, as you can see, it wouldn't take many features to make me happy. 
And heck, I don't really even *need* the ability to update through a web 
interface (although that does make it easier than reaching for my ftp app 
and updating a bunch of files). So it would probably be pretty easy to just 
make something myself that I'd be happy with. And I've been thinking about 
doing that. But even as simple as it would be, it's just one more thing on 
top my pile of pet projects that's already probably big enough for three 
lifetimes...


 On the feed issue, that's something that doesn't bug me either -
 I just keep a list of sites I like in my brain and check them
 whenever I have nothing better to do. This perhaps only works
 for me because I read so few sites!


I've tried out RSS feeds before, but ended up never really getting any use 
out of them. I think I'm in the same boat as you. These D NGs are about all 
I care about being up-to-date on, and I already check them directly anyway.

Of course, the ironly is despite never using them, I've actually implemented 
RSS feeds for two different paid jobs (They were surprisingly easy). In 
fact, I seem to have a pattern of occasionally winding up working on things 
that I don't personally use: I've worked on a WAP/WML site (remember those?) 
and dabbeld a little in SymbianOS dev with C/C++ and J2ME without having 
ever actually owned a cell.

Anyway, I do like to at least provide an RSS/ATOM feed since it is useful 
for some people.


 Some quick commentary on IFTI:

 I actually discovered this by accident. Of course, I use IFTI
 all over the place, like most D programmers probably do.

 But, since the T argument was a default one here, I often didn't
 specify it:

 int a = cgi.request!int(a);

 (Why use this instead of to!int(cgi.get[a])? The request
 implementation checks both get and post.)

 Then, I started adding it, but still specified:

 int a = cgi.request!int(a, 100);


 One time, I just didn't write the template argument and it
 still worked!


 While it's a really mundane feature of D, I still felt a bit
 of hey cool when it worked.



 The to!enum was another thing I didn't expect. I thought it would
 do the same as casting an int, but it works from name, which is
 actually very cool. More user friendly, and that white listing
 aspect is also pretty useful.

 mysql.query(select * from users where  ~
  to!string(cgi.request(field, Field.name)) ~
  = ?, value);


 Building a sql string like that is fairly ugly, and normally, it'd
 be /completely/ insane. You're just begging for trivially easy
 sql injections.


 But, thanks to the enum acting as a whitelist, you actually can
 do that in D.


 (Note that while I'm putting this in the web.d directory and talking
 about cgi, lots of this stuff works on the command line too. Imagine
 an enum for command line flags - converting is easy, you can
 to!string one of the enums safely, you can list the arguments
 using reflection, and final switch() can be used to ensure you
 cover them all!

 D's enums have a lot of hidden treasures.)

Hmm, so basically: The surprises are pleasant ones. Reminds me of a certain 
other language... ;)

Re: short thoughts on D (like my twitter)

[Adam D. Ruppe]

Nick Sabalausky wrote:
 Heh, I have no idea what a ween is.

Word I made up... meant to be a less serious version of wimpy loser. :)

  The main reason I didn't want to go with plain HTML though was
 because that makes creating and updating navigation a pain.

Yea, some kind of helper program is good there.. I'll probably
start using one too if I add enough content. For a while, I used
a little program written in C to build that stuff for me... for
all the stuff I write for dynamic websites, I take lots of steps
to avoid using them myself!

  (although that does make it easier than reaching for my ftp app
 and updating a bunch of files)

I cheat here too - my website is hosted from my computer, so I
write the files in place!

 Hmm, so basically: The surprises are pleasant ones. Reminds me of
 a certain other language... ;)

VB6??!?!?!!?

Re: short thoughts on D (like my twitter)

[Sean Kelly]

Tumblr?  It doesn't have the length limitation. 

Sent from my iPhone

On Jun 10, 2011, at 10:12 AM, Adam D. Ruppe destructiona...@gmail.com wrote:

 http://arsdnet.net/web.d/short-thoughts.html
 
 I sometimes find little things I want to comment on, but it isn't
 enough to make it's own page.
 
 So I've decided to make one page where I'll dump them from time to
 time, like a twitter, but not twitter because twitter sucks.
 
 
 I started with something I just found pretty cool: using
 to!enum(string) does super easy whitelisting of input! And, IFTI
 lets you avoid repeating yourself if you want a default value.

Re: short thoughts on D (like my twitter)

[Sean Kelly]

How about drdobbs.com?  Short-form entries are common there.

Sent from my iPhone

On Jun 11, 2011, at 4:33 AM, Nick Sabalausky a@a.a wrote:

 Adam D. Ruppe destructiona...@gmail.com wrote in message 
 news:isu59p$6sd$1...@digitalmars.com...
 Nick Sabalausky wrote:
 But I do have something that just happens to arguably be a lot like
 a blog and uses a blogging engine ;)
 
 Gah, only weens use blogging engines!
 
 I tend to just write my stuff as plain html files (like you can see
 here). Sometimes I'll factor out common things, but I usually
 don't venture far from plain text.
 
 
 Heh, I have no idea what a ween is. I gotta (partially) agree though, I've 
 yet to find a blogging engine that I'm particularly happy with. The main 
 reason I didn't want to go with plain HTML though was because that makes 
 creating and updating navigation a pain. Maybe something like Ddoc could 
 take care of that, though. But I also like allowing comments (with captcha), 
 because then I actually get occasional feedback. And some people do like RSS 
 (more below...).
 
 Of course, as you can see, it wouldn't take many features to make me happy. 
 And heck, I don't really even *need* the ability to update through a web 
 interface (although that does make it easier than reaching for my ftp app 
 and updating a bunch of files). So it would probably be pretty easy to just 
 make something myself that I'd be happy with. And I've been thinking about 
 doing that. But even as simple as it would be, it's just one more thing on 
 top my pile of pet projects that's already probably big enough for three 
 lifetimes...
 
 
 On the feed issue, that's something that doesn't bug me either -
 I just keep a list of sites I like in my brain and check them
 whenever I have nothing better to do. This perhaps only works
 for me because I read so few sites!
 
 
 I've tried out RSS feeds before, but ended up never really getting any use 
 out of them. I think I'm in the same boat as you. These D NGs are about all 
 I care about being up-to-date on, and I already check them directly anyway.
 
 Of course, the ironly is despite never using them, I've actually implemented 
 RSS feeds for two different paid jobs (They were surprisingly easy). In 
 fact, I seem to have a pattern of occasionally winding up working on things 
 that I don't personally use: I've worked on a WAP/WML site (remember those?) 
 and dabbeld a little in SymbianOS dev with C/C++ and J2ME without having 
 ever actually owned a cell.
 
 Anyway, I do like to at least provide an RSS/ATOM feed since it is useful 
 for some people.
 
 
 Some quick commentary on IFTI:
 
 I actually discovered this by accident. Of course, I use IFTI
 all over the place, like most D programmers probably do.
 
 But, since the T argument was a default one here, I often didn't
 specify it:
 
 int a = cgi.request!int(a);
 
 (Why use this instead of to!int(cgi.get[a])? The request
 implementation checks both get and post.)
 
 Then, I started adding it, but still specified:
 
 int a = cgi.request!int(a, 100);
 
 
 One time, I just didn't write the template argument and it
 still worked!
 
 
 While it's a really mundane feature of D, I still felt a bit
 of hey cool when it worked.
 
 
 
 The to!enum was another thing I didn't expect. I thought it would
 do the same as casting an int, but it works from name, which is
 actually very cool. More user friendly, and that white listing
 aspect is also pretty useful.
 
 mysql.query(select * from users where  ~
 to!string(cgi.request(field, Field.name)) ~
  = ?, value);
 
 
 Building a sql string like that is fairly ugly, and normally, it'd
 be /completely/ insane. You're just begging for trivially easy
 sql injections.
 
 
 But, thanks to the enum acting as a whitelist, you actually can
 do that in D.
 
 
 (Note that while I'm putting this in the web.d directory and talking
 about cgi, lots of this stuff works on the command line too. Imagine
 an enum for command line flags - converting is easy, you can
 to!string one of the enums safely, you can list the arguments
 using reflection, and final switch() can be used to ensure you
 cover them all!
 
 D's enums have a lot of hidden treasures.)
 
 Hmm, so basically: The surprises are pleasant ones. Reminds me of a certain 
 other language... ;)
 
 
 

Re: short thoughts on D (like my twitter)

[Jeff Nowakowski]

On 06/11/2011 10:41 AM, Adam D. Ruppe wrote:

Nick Sabalausky wrote:

Heh, I have no idea what a ween is.


Word I made up... meant to be a less serious version of wimpy loser. :)


Sorry, you didn't make that word up. It's in the Urban Dictionary:

http://www.urbandictionary.com/define.php?term=ween

And I know it well from my rec.games.netrek days as a common insult.

Re: short thoughts on D (like my twitter)

[Andrej Mitrovic]

On 6/11/11, Sean Kelly s...@invisibleduck.org wrote:
 How about drdobbs.com?  Short-form entries are common there.

After they've completely screwed up all the existing links to old
articles, I don't know why anyone would want to write there.

Re: short thoughts on D (like my twitter)

[Nick Sabalausky]

Jeff Nowakowski j...@dilacero.org wrote in message 
news:it033e$1g7a$1...@digitalmars.com...
 On 06/11/2011 10:41 AM, Adam D. Ruppe wrote:
 Nick Sabalausky wrote:
 Heh, I have no idea what a ween is.

 Word I made up... meant to be a less serious version of wimpy loser. :)

 Sorry, you didn't make that word up. It's in the Urban Dictionary:

 http://www.urbandictionary.com/define.php?term=ween

 And I know it well from my rec.games.netrek days as a common insult.

You could probably string any random letters together and it would be in 
urban dictionary.

Re: Flag proposal

[Lars T. Kyllingstad]

On Fri, 10 Jun 2011 18:16:14 -0500, Andrei Alexandrescu wrote:

 On 6/10/11 6:03 PM, Dmitry Olshansky wrote:
 On 11.06.2011 0:58, Andrei Alexandrescu wrote:
 On 6/10/11 3:30 PM, Nick Sabalausky wrote:
 I really see Flag more as a way to try to rationalize avoiding adding
 named
 parameters to the language.

 There are fights that I believe are important and others that I think
 are less so. I find name parameters nice to have but more in the
 second category. There's just so much stuff that's more important.

 And yes, the legibility of foo(Flag!param.yes,
 Flag!otherParam.no);,

 Fair point. I figured this should be easier:

 foo(yes!param, no!otherParam);

 I think this looks not half bad and does not require change in the
 language.
 Still yes.param and no.param might be easier on the eyes, though IMO it
 should look more like just param and no.param. e.g.
 StopWatch(autoStart);
 StopWatch(no!autoStart); // or no.autoStart
 
 Ask, and ye shall receive.
 
 https://github.com/andralex/phobos/
commit/801ccc96ce56827cd0d0b608895269bdccba4330

I'm sold. :)

To add my 2 cents to the named arguments debate, I can't believe people 
are still asking for this.  At this point in D's development, adding such 
would be a major language change, and there really shouldn't be any more 
of those.  I mean, D2 supposedly went stable almost a year ago!  If/when 
work starts on D3, we can get back to it.

In the mean time, I think Flag!param with the new Yes/No types nicely 
solves a common case of code duplication in Phobos.  It is not, nor do I 
think Andrei intended it to be, a general attempt to emulate named 
parameters.

-Lars

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Daniel Gibson]

Am 11.06.2011 07:50, schrieb Nick Sabalausky:
 Robert Clipsham rob...@octarineparrot.com wrote in message 
 news:issvrr$qn3$2...@digitalmars.com...

 You seem to be using cafe press for your other merchandise, there's a tool 
 on there for custom t-shirts.

 http://www.cafepress.com/cp/customize/makeadesign2.aspx?clear=trueno=321color=6#designer

 It's probably easier to do it through there. If not, I could probably make 
 an image.

 Also, hate to be a grammar nazi, but that should probably be I wrote this 
 article /about/ D, and all I got was this lousy!T shirt.

 
 Not to be a bikeshed painter, but I'd suggest I wrote /an/ article... 
 Having this in both predicates sounds repetitive. Plus, this suggests 
 that the article is nearby.
 
 (Where the hell did that last paragraph I wrote come from? I *know* I didn't 
 pay *that* much attention in English class!)
 
 
 

I'd suggest D instead of English.
Something like
  writeArticle(D, topicofrecipient);
  shirts ~= lousy!T(shirt);
or something smarter ;)

Cheers,
- Daniel

Re: Article discussing Go, could well be D

[Nick Sabalausky]

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message 
news:isu8vs$d2f$1...@digitalmars.com...
 On 6/10/11 6:14 PM, Nick Sabalausky wrote:
 Andrei Alexandrescuseewebsiteforem...@erdani.org  wrote in message
 news:isovj2$2133$1...@digitalmars.com...

 That's it. We need a package management expert on board to either revive
 dsss or another similar project, or define a new package manager
 altogether. No yeah I have some code somewhere feel free to copy from
 it; we need professional execution. Then we need to make that tool part
 of the standard distribution such that library discovery, installation,
 and management is as easy as running a command.

 I'm putting this up for grabs. It's an important project of high impact.
 Wondering what you could do to help D? Take this to completion.


 Just a thought: DVM is already set up to handle managing multiple 
 versions
 of DMD. And I don't think it's a stretch to figure that support for GDC 
 and
 LDC would be natural extensions at some point, plus some dmd.conf/sc.ini
 management functionality (which would be needed for installing D 
 libraries).
 So maybe DVM could be expanded to handle arbitrary D packages as well?

 I think that's an excellent idea. Jacob, would you be interested in 
 working on that?


If he isn't interested and no one else wants to jump in, then I'd be willing 
to volunteer for it. I'm already familiar with DVM's internals from doing 
the Windows port.

Or maybe Andrew Wiley would want to be involved. He did say that he hoped to 
turn his xfbuild-like tool into a DSSS replacement. Might be good not to 
duplicate efforts.

Re: Article discussing Go, could well be D

[Walter Bright]

On 6/8/2011 11:56 PM, Nick Sabalausky wrote:

What you said above is also why I *strongly* believe that good (and I mean
*good*) documentation is every bit as important as actually
writing/releasing a tool or library in the first place. I've seen so much
already-made work that's rendered barely-usable due to less-than-stellar
documentation (or even worse: bad or non-existant documentation). What's the
point out of putting stuff out there if nobody knows how to use it? What's
the point of using something if figuring it out and getting it to work takes
about as much effort as DIY? That's why (for public projects anyway) I force
myself, even if I don't want to, to put all the effort I need to into
documentation to make things as easy as possible. Otherwise, all that effort
writing the code would likely have been for nothing anyway.



Sure. I struggle with writing documentation myself, and Ddoc has cut my effort 
involved in doing it by more than half. (I even use Ddoc to build Kindle ebooks, 
4 so far!)

Re: Article discussing Go, could well be D

[Walter Bright]

On 6/8/2011 7:18 PM, Jonathan M Davis wrote:

So, being able to call C code is fantastic and buys us a lot, but for a lot of
programmers, that just doesn't cut it. They want the libraries to be in D.


I think we've got some good traction lately in providing interfaces to popular c 
libraries in etc.c. It's a great first step.

Re: Article discussing Go, could well be D

[Andrew Wiley]

On Fri, Jun 10, 2011 at 3:48 PM, Nick Sabalausky a@a.a wrote:

 Andrew Wiley wiley.andre...@gmail.com wrote in message
 news:mailman.776.1307728872.14074.digitalmar...@puremagic.com...
  On Fri, Jun 10, 2011 at 9:29 AM, Caligo iteronve...@gmail.com wrote:
 
  On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu
  seewebsiteforem...@erdani.org wrote:
   That's it. We need a package management expert on board to either
   revive
   dsss or another similar project, or define a new package manager
  altogether.
   No yeah I have some code somewhere feel free to copy from it; we
 need
   professional execution. Then we need to make that tool part of the
  standard
   distribution such that library discovery, installation, and management
   is
  as
   easy as running a command.
  
   I'm putting this up for grabs. It's an important project of high
   impact.
   Wondering what you could do to help D? Take this to completion.
  
  
   Andrei
  
 
  Andrei, I have to respectfully disagree with you on that, sorry.
 
  D is supposed to be a system programming language, not some scripting
  language like Ruby.  Besides, the idea of some kind of package
  management for a programming language is one of the worst ideas ever,
  specially when it's a system programming language.  You have no idea
  how much pain and suffering it's going to cause the OS developers and
  package maintainers.  I can see how the idea might be attractive to
  non-*nix users, but most other *nix OSs have some kind of package
  management system and searching for, installing, and managing software
  is as easy as running a command.
 
 
  It doesn't have to be hard if you build the package manager in such a way
  that it can be integrated into the OS package manager, whether that means
  letting the OS package manager modify the language package manager's
  database or just adding a switch that turns your package manager into a
  dumb
  build tool so dependency checks can be left to the OS package manager.
  That's my theory, anyway.
 

 I'd say one critical requirement for a package manager is that it be based
 around the idea of supporting multiple versins of the same lib at the same
 time. If you're just going to re-invent your own little DLL hell you'd
 almost be better off just going with the OS package manager.


Well, yes, but if the OS package manager can't handle multiple versions of
the same lib (and so far, I haven't seem one that can), making that work
isn't a necessary part of OS package manager integration. I agree that the
language package manager should be able to manage multiple versions in
whatever local stores it maintains.
The trick is that if I install a package through the OS package manager,
there needs to be a way for the language package manager to know what was
installed and use that if possible. And, when an application is released, it
needs to be possible for it to be built as an OS package depending entirely
on other OS packages instead of the language package manager's local stores,
and if the language package manager is built in such a way that this is
feasible, it should become much more useful.
This is all just hand-waving at this point, but it seems like if a sane
method can be devised to make this sort of thing happen, the end result will
be much better.

Re: Flag proposal [OT]

[Alix Pexton]

On 11/06/2011 06:18, Andrej Mitrovic wrote:

We should rename Yes and No to Yay and Nay to make them alignable, and
even more importantly to make us appear as old Englishmen!


Yay and Nay are too similar looking, but luckily, Yay is not 
actually a old English word :)  A more correct alternative would be 
Aye (pronounced the same as eye), which (along with Nay) is still 
used for some voting actions (such as councillors deciding where to go 
for lunch). I myself say it al least 20 times a day :)


A...

Re: Flag proposal

[bearophile]

Andrej Mitrovic:

 I've found someone that contradicts you:
 http://www.digitalmars.com/d/archives/digitalmars/D/Function-local_imports_109317.html

Thank you. That person didn't have enough experience yet, it seems. More 
experienced Python programmers use local imports only in very uncommon 
situations, you see it from the lot of Python code in the standard library. So 
I despite its little advantage of local reasoning improvements I think it's far 
from the top of the list of the important things to desire, I think that 
currently design improvement efforts are better spent toward more generally 
useful features instead :-)

Bye,
bearophile

Re: Flag proposal

[Mafi]

Am 11.06.2011 01:16, schrieb Andrei Alexandrescu:

Ask, and ye shall receive.

https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330



I like this version much more but shouldn't it also be 
flag.KeepTerminator for consistency?


Mafi

Re: XMLWriter

[Tomek Sowiński]

Tomek Sowiński napisał:

 Documentation:
 http://www.keepandshare.com/doc/2863798/std-xml-html-june-11-2011-2-43-am-93k?da=y#XMLWriter

I just noticed it requires everyone to sign in :-(

Please use this link:
http://pastehtml.com/view/awrj8r4zg.html#XMLWriter

-- 
Tomek

Re: Flag proposal

[Lutger Blijdestijn]

bearophile wrote:

 Andrei:
 
 This module won't compile in today's D, but not for a matter of
 principles; it's just a random limitation of the language. (It does work
 if you import from within a class or struct.) You can insert most
 declarations in a scope, so the ones you can't insert are just awkward
 exceptions, unless there's a good reason to actively disable them. Any
 code should work if you just wrap another scope around it.
 
 Walter and I call the above a turtle feature, in allusion to the
 turtles all the way down meme. Walter wants to fix this, and similar
 limitations that act unturtly. Imports inside a scope won't be visible
 outside that scope, and importing the same module from several different
 functions will come at no cost in compilation time.
 
 You are allowed to import modules inside functions in Python too (there is
 a just a minor restriction), but I have never asked for this feature in D
 because this feature has a cost too. Putting all imports at the top of the
 module is more tidy, it allows the person that reads the code to find all
 the used imports very quickly. If they are spread in the module they
 become less easy to find, you need to use your editor/IDE to search for
 them.
 
 Bye,
 bearophile

Why would you have to find local imports? It's considered good practice to 
narrow scope of variables and put declarations as close as possible to point 
of use, yet you don't hunt for local variable declarations all the time.

If an import is local, it is simply (supposedly) only of concern to that 
scope and relevant when doing work concerning whatever is in that scope. In 
effect this could as well lead to reducing to need to look for imports!

Python is a bit different because there's an awful lot more going on when 
importing, with increased chances of bugs when not careful. Simply importing 
something more than once can introduce errors. Hopefully, that is less so 
with D. The only really tricky thing are module constructors (circular 
imports). But at this level, it's probably easier to use facilities of dmd 
to tell you what imports what.

Re: Flag proposal

[Michel Fortin]

On 2011-06-10 22:08:31 -0400, Andrei Alexandrescu 
seewebsiteforem...@erdani.org said:



On 6/10/11 8:08 PM, Michel Fortin wrote:

On 2011-06-10 18:57:20 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:


https://github.com/andralex/phobos/commit/84c75336a4ef04b4c3b1924d7ac9329e744ab8e7



It's

still 



a hack, but I'll agree it makes the encapsulation a little better
if you use yes!abc at the function call point.

However, I still think it's a deterioration from the user's point of
view compared to the current situation with hand-crafted enums: it still
requires a string, and the documentation will say func(Flag!abc abc),
repeating the parameter's name unless you hand-craft a special Ddoc
version of the function declaration. It's better than Flag!abc.yes,
but it's worse than Abc.yes.


But the problem is the same today.

enum Abc : bool { no, yes }
void fun(Abc abc = Abc.no);

No difference. In the function declaration, the word abc occurs three times.


I actually didn't meant to post the above. I wrote it, then thought I 
should sleep on it before deciding whether I'd post it or not since I 
was a little to tired. Then I hit a bad key combo and the message 
reached the server before I could unplug my network cable. I'm not 
surprised you could find some inconsistencies in it.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Flag proposal [OT]

[Nick Sabalausky]

Alix Pexton alix.dot.pex...@gmail.dot.com wrote in message 
news:isvae3$2o51$1...@digitalmars.com...
 On 11/06/2011 06:18, Andrej Mitrovic wrote:
 We should rename Yes and No to Yay and Nay to make them alignable, and
 even more importantly to make us appear as old Englishmen!

 Yay and Nay are too similar looking, but luckily, Yay is not 
 actually a old English word :)  A more correct alternative would be Aye 
 (pronounced the same as eye), which (along with Nay) is still used for 
 some voting actions (such as councillors deciding where to go for lunch). 
 I myself say it al least 20 times a day :)


Dost thou, verily?

Re: Flag proposal

[Nick Sabalausky]

Michel Fortin michel.for...@michelf.com wrote in message 
news:isvhkr$3s4$1...@digitalmars.com...

 I actually didn't meant to post the above. I wrote it, then thought I 
 should sleep on it before deciding whether I'd post it or not since I was 
 a little to tired. Then I hit a bad key combo and the message reached the 
 server before I could unplug my network cable. I'm not surprised you could 
 find some inconsistencies in it.


That dang Send Message keyboard combo gets me now and then, too. In fact, 
last time was just yesterday. I'm all for keyboard accessability for 
everything, but I'd love to see the keyboard access for Send Message be a 
bit less easy. On my mail client, it's Ctrl-Enter, which of course is just 
begging for it to be accidentally hit while editing text. 

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 07:01:13 -0400, Nick Sabalausky a@a.a said:


Michel Fortin michel.for...@michelf.com wrote in message
news:isvhkr$3s4$1...@digitalmars.com...


I actually didn't meant to post the above. I wrote it, then thought I
should sleep on it before deciding whether I'd post it or not since I was
a little to tired. Then I hit a bad key combo and the message reached the
server before I could unplug my network cable. I'm not surprised you could
find some inconsistencies in it.


That dang Send Message keyboard combo gets me now and then, too. In fact,
last time was just yesterday. I'm all for keyboard accessability for
everything, but I'd love to see the keyboard access for Send Message be a
bit less easy. On my mail client, it's Ctrl-Enter, which of course is just
begging for it to be accidentally hit while editing text.


Just after sending this message, I changed the combo in my newsreader 
from command-option-D to command-option-control-shift-D, like I did for 
my mail client a while ago.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Flag proposal

[Daniel Gibson]

Am 11.06.2011 13:09, schrieb Michel Fortin:
 On 2011-06-11 07:01:13 -0400, Nick Sabalausky a@a.a said:
 
 Michel Fortin michel.for...@michelf.com wrote in message
 news:isvhkr$3s4$1...@digitalmars.com...

 I actually didn't meant to post the above. I wrote it, then thought I
 should sleep on it before deciding whether I'd post it or not since I
 was
 a little to tired. Then I hit a bad key combo and the message reached
 the
 server before I could unplug my network cable. I'm not surprised you
 could
 find some inconsistencies in it.

 That dang Send Message keyboard combo gets me now and then, too. In
 fact,
 last time was just yesterday. I'm all for keyboard accessability for
 everything, but I'd love to see the keyboard access for Send Message
 be a
 bit less easy. On my mail client, it's Ctrl-Enter, which of course is
 just
 begging for it to be accidentally hit while editing text.
 
 Just after sending this message, I changed the combo in my newsreader
 from command-option-D to command-option-control-shift-D, like I did for
 my mail client a while ago.
 
 

When using a newsreader you should be able to retract a message, at
least in Thunderbird you can just delete your own message to remove it
from the server.

Re: Flag proposal

[Andrei Alexandrescu]

On 6/10/11 11:55 PM, Nick Sabalausky wrote:

However, I still think it's a deterioration from the user's point of
view compared to the current situation with hand-crafted enums: it still
requires a string, and the documentation will say func(Flag!abc abc),
repeating the parameter's name unless you hand-craft a special Ddoc
version of the function declaration. It's better than Flag!abc.yes,
but it's worse than Abc.yes.


But the problem is the same today.

enum Abc : bool { no, yes }
void fun(Abc abc = Abc.no);

No difference. In the function declaration, the word abc occurs three
times.



Which makes Flag even less of an improvement.


I'm not sure I figure the reasoning. You can't penalize twice for the 
same reason. This makes the existing situation less desirable, not Flag 
less of an improvement over it.


Andrei

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 07:11:19 -0400, Daniel Gibson metalcae...@gmail.com said:


When using a newsreader you should be able to retract a message, at
least in Thunderbird you can just delete your own message to remove it
from the server.


I know, but Unison doesn't have that option.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 12:36 AM, Nick Sabalausky wrote:

Andrei Alexandrescuseewebsiteforem...@erdani.org  wrote in message
news:isualt$hf2$1...@digitalmars.com...


Combining existing features towards new ends is in some ways more
difficult than language design because you play within a confined ground,
and I am a bit disappointed that a few posters have shown only contempt
for such an effort.



That analysis of the situation hinges on the steadfast notion that Flag is a
great thing.


Actually my point there was that we should be coy at this point about 
changing the language. Flag doesn't have much to do with it. It is clear 
to me that a language change would obviate Flag and would have 
additional advantages. The point is it would also have disadvantages.



I absolutely appreciate doing things in library instead of language
when reasonable to do so. You don't see me asking for map/reduce or
ranges to be built into the language, do you? What a lot of people
*don't* like is this seemingly frequent pattern:

1. Andrei comes up with something he feels is a great idea (And you
do have a lot of genuinely great ideas, don't get me wrong. Probably
more than most of us, certainly including me.)

2. The idea is posted to the NG ostensibly for discussion.

3. Andrei shoots down every objection as being wrong, failing to
understand the idea's greatness, or some meta-argument trump card
like X is the N-word of the programming world is pulled out.

4. The proposed idea can't possibly have any significant flaws, so
everyone else on the board is obviously in contempt of something more
fundamental, in this case, the strategy of preferring library
solutions over language additions.


I thought what I was doing was to rationally discuss the proposal. 
Clearly I am in favor of it since I'm proposing it. But that doesn't 
mean I need to resort to eliciting emotional response, demeaning the 
counter-arguments, or discussing the competence or ulterior motives of 
the opponents.



Just because some of us feel this one particular thing doesn't work well in
library, does *not* imply we think new features are generally preferable as
language additions. So please stop leaping to that conclusion.


Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against. For 
(2) the course of action is to point out the liabilities of changing the 
language.



Andrei

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 4:38 AM, bearophile wrote:

Andrej Mitrovic:


I've found someone that contradicts you:
http://www.digitalmars.com/d/archives/digitalmars/D/Function-local_imports_109317.html


Thank you. That person didn't have enough experience yet, it seems. More 
experienced Python programmers use local imports only in very uncommon 
situations, you see it from the lot of Python code in the standard library. So 
I despite its little advantage of local reasoning improvements I think it's far 
from the top of the list of the important things to desire, I think that 
currently design improvement efforts are better spent toward more generally 
useful features instead :-)

Bye,
bearophile


I'm not very familiar with Python's module system. Is it very similar to 
D's?


Thanks,

Andrei

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 4:58 AM, Mafi wrote:

Am 11.06.2011 01:16, schrieb Andrei Alexandrescu:

Ask, and ye shall receive.

https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330




I like this version much more but shouldn't it also be
flag.KeepTerminator for consistency?

Mafi


Not sure I understand. How do you mean that?

Andrei

Re: Flag proposal [OT]

[Alix Pexton]

On 11/06/2011 11:56, Nick Sabalausky wrote:

Alix Pextonalix.dot.pex...@gmail.dot.com  wrote in message
news:isvae3$2o51$1...@digitalmars.com...

On 11/06/2011 06:18, Andrej Mitrovic wrote:

We should rename Yes and No to Yay and Nay to make them alignable, and
even more importantly to make us appear as old Englishmen!


Yay and Nay are too similar looking, but luckily, Yay is not
actually a old English word :)  A more correct alternative would be Aye
(pronounced the same as eye), which (along with Nay) is still used for
some voting actions (such as councillors deciding where to go for lunch).
I myself say it al least 20 times a day :)



Dost thou, verily?




Aye!

A...

Re: Flag proposal

[bearophile]

Lutger Blijdestijn:

It's considered good practice to narrow scope of variables and put 
declarations as close as possible to point of use, yet you don't hunt for 
local variable declarations all the time.

I agree this turtle idea has some good sides too. But I want to stress that 
it's not among the first five things I think D has to change/improve. More 
important are tuple unpacking syntax sugar, named arguments, conditional 
attributes, better vector operations, etc.

Bye,
bearophile

Re: Flag proposal

[bearophile]

Andrei:

 I'm not very familiar with Python's module system. Is it very similar to 
 D's?

If you take a look at the Python module system, you copy the first half of it, 
its more evident characteristics, ignoring its care for details and corner 
cases, and you remove its dynamic characteristics, you produce a kind of D 
module system :-)

Python doesn't have the anti-hijacking feature, and it's more dynamic. Its 
package system is more refined than the primitive D package system (and it 
seems it's not easy to design right, because even the last versions of Python 
have modified a the its semantics of packages).

In Python when you do import foo you import only the name foo. This is 
probably one of the first things I've asked in D, and I am for it still, but 
most D programmers have not appreciated this idea, so I have stopped asking for 
it since lot of time.

(S)ML language has a WAY more complex module system, but despite its 
advantages, I think D/Python module system is good enough and it's easy to 
learn to use.

In the end on the surface if you know the Python module system it's easy to 
learn to use the D one, and the opposite too is true. I think the D package 
system needs to be improved, using more brain. This is another example of why D 
design development can't be stopped yet.

Bye,
bearophile

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Alix Pexton]

On 10/06/2011 09:56, Walter Bright wrote:

On 6/9/2011 5:10 PM, Robert Clipsham wrote:

On 10/06/2011 00:40, Steven Schveighoffer wrote:

[snip]

I wrote this article on D, and all I got was this lousy!T shirt

-Steve


I would happily accept this as my runners up prize.


If someone wants to edit up an image for a lousy!T shirt, I can see
about getting it produced.



I think I made the attached the right size for printing on the pocket 
area of a t-shirt from cafepress. I think it may alternatively work well 
printed across the shoulders, which would be a little larger.


I've made the changes to the wording that have been suggested by some 
others in this thread, and applied minimal d-ification. K.I.S. etc...


It is by no means a final design, but perhaps a starting point, so 
suggestions welcome.


A...

P.S.
consider it Public Domain :)
attachment: d-tshirt.png

Re: Should GC.malloc be considered 'pure'?

[bearophile]

Kagamin:

 Won't this pollute everything with @trasparent annotations, because code 
 usually doesn't depend on pointer value so it would want to work on 
 transparent pointers.

Probably some compromise is better, that allows you to drop this annotation in 
most situations where it's not necessary... I am not sure I am intelligent and 
expert enough to design this yet. I am learning, but it's not easy stuff. A 
brainstorm-style design may be needed :-)

Bye,
bearophile

Re: Flag proposal

[Mike Parker]

On 6/11/2011 8:16 AM, Andrei Alexandrescu wrote:

On 6/10/11 6:03 PM, Dmitry Olshansky wrote:

On 11.06.2011 0:58, Andrei Alexandrescu wrote:

On 6/10/11 3:30 PM, Nick Sabalausky wrote:

I really see Flag more as a way to try to rationalize avoiding adding
named
parameters to the language.


There are fights that I believe are important and others that I think
are less so. I find name parameters nice to have but more in the
second category. There's just so much stuff that's more important.


And yes, the legibility of foo(Flag!param.yes,
Flag!otherParam.no);,


Fair point. I figured this should be easier:

foo(yes!param, no!otherParam);


I think this looks not half bad and does not require change in the
language.
Still yes.param and no.param might be easier on the eyes, though IMO it
should look more like just param and no.param.
e.g.
StopWatch(autoStart);
StopWatch(no!autoStart); // or no.autoStart


Ask, and ye shall receive.

https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330



Andrei




I was going to add my voice against this proposal until I saw this. Nice 
one!

article comppetition

[alan marble]

I wanted to believe that after all the shit D would now finally take off thanks 
to the article competition. I was A BIT surprised to see how small amount of 
articles AND votes the thing got. The community is super small loser circle 
jerk hobby. There's no way around that. I'm goingg back to C++ and C# since D 
was such a disappointment. I just hope you stop waisting your time with D, it 
does not make much sense.

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 7:20 AM, bearophile wrote:

Lutger Blijdestijn:


It's considered good practice to narrow scope of variables and put
declarations as close as possible to point of use, yet you don't
hunt for local variable declarations all the time.


I agree this turtle idea has some good sides too. But I want to
stress that it's not among the first five things I think D has to
change/improve. More important are tuple unpacking syntax sugar,
named arguments, conditional attributes, better vector operations,
etc.


Again, there are two broad categories of changes: feature additions and 
removal of undue limitations. We favor doing the latter.


Andrei

Re: article comppetition

[Bernard Helyer]

On Sat, 11 Jun 2011 08:48:19 -0400, alan marble wrote:

 I wanted to believe that after all the shit D would now finally take off
 thanks to the article competition. I was A BIT surprised to see how
 small amount of articles AND votes the thing got. The community is super
 small loser circle jerk hobby. There's no way around that. I'm goingg
 back to C++ and C# since D was such a disappointment. I just hope you
 stop waisting your time with D, it does not make much sense.

Bapr hcba n zvqavtug qernel, juvyr V cbaqrerq jrnx naq jrnel,
 Bire znal n dhnvag naq phevbhf ibyhzr bs sbetbggra yber,
 Juvyr V abqqrq, arneyl anccvat, fhqqrayl gurer pnzr n gnccvat,
 Nf bs fbzr bar tragyl enccvat, enccvat ng zl punzore qbbe.
 `'Gvf fbzr ivfvgbe,' V zhggrerq, `gnccvat ng zl punzore qbbe -
 Bayl guvf, naq abguvat zber.'

Re: Flag proposal

[Mafi]

Am 11.06.2011 14:07, schrieb Andrei Alexandrescu:

On 6/11/11 4:58 AM, Mafi wrote:

Am 11.06.2011 01:16, schrieb Andrei Alexandrescu:

Ask, and ye shall receive.

https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330





I like this version much more but shouldn't it also be
flag.KeepTerminator for consistency?

Mafi


Not sure I understand. How do you mean that?

Andrei


I meant something like this:

template FlagImpl(string name) {
enum FlagImpl : bool {
yes = true, no = false
}
}

//usage Flag.xy as alias for FlagImpl!xy
//to be consistent with yes.xy and no.xy
struct Flag {
template opDispatch(string name) {
alias FlagImpl!name opDispatch;
}
}

Now, opDispatch cannot currently be a type, can it.

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Mafi]

Am 11.06.2011 14:33, schrieb Alix Pexton:


It is by no means a final design, but perhaps a starting point, so
suggestions welcome.


What about:
/++ I wrote an article about D and all I got was ++/
this.Lousy!T shirt;

//d-programming-language.org

stackoverflow.com question

[Andrei Alexandrescu]

http://stackoverflow.com/questions/6315882/pattern-matching-in-d

Andrei

Re: Flag proposal

[Steven Schveighoffer]

On Fri, 10 Jun 2011 19:16:14 -0400, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:



On 6/10/11 6:03 PM, Dmitry Olshansky wrote:

On 11.06.2011 0:58, Andrei Alexandrescu wrote:

On 6/10/11 3:30 PM, Nick Sabalausky wrote:

I really see Flag more as a way to try to rationalize avoiding adding
named
parameters to the language.


There are fights that I believe are important and others that I think
are less so. I find name parameters nice to have but more in the
second category. There's just so much stuff that's more important.


And yes, the legibility of foo(Flag!param.yes,
Flag!otherParam.no);,


Fair point. I figured this should be easier:

foo(yes!param, no!otherParam);


I think this looks not half bad and does not require change in the
language.
Still yes.param and no.param might be easier on the eyes, though IMO it
should look more like just param and no.param.
e.g.
StopWatch(autoStart);
StopWatch(no!autoStart); // or no.autoStart


Ask, and ye shall receive.

https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330


This is better.  Does the definition of the function still require  
repetition?  i.e. getLine(Flag!KeepTerminator keepTerminator =  
Yes.KeepTerminator).  I suppose we can live with that.


Still reads weird to me with the value coming before the category, but I  
suppose the names can be adjusted accordingly.


As far as the negation, I think we need one more layer of type:

struct FlagParam(string pname)
{
   Flag!pname value;
   alias value this;
   this(Flag!pname x) { this.value = x }
   FlagParam op???() const { return FlagParam(cast(Flag!pname)!value); }
}

BTW, is there a way to hook !?  Maybe this won't work...  The idea is to  
have Yes.abc return FlagParam!abc(Flag!abc.yes).


-Steve

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 07:54:58 -0400, Andrei Alexandrescu 
seewebsiteforem...@erdani.org said:



Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against. For 
(2) the course of action is to point out the liabilities of changing 
the language.


I'm actually not sure whether I want named arguments or not, but I'm 
quite sure I don't want to use Flag! in my code. I'd actually prefer 
a simple bool parameter to Flag!.


Currently, it looks like we have these possibilities:

// definition  // call with a constant

void func(bool abc);- func(true);

enum Abc { no, yes }
void func(Abc abc); - func(Abc.yes);

void func(Flag!Abc abc);  - func(Flag!Abc.yes);
- func(yes!Abc);
- func(Yes.Abc);

which then becomes this if you're using a boolean expression instead of 
a constant:


// definition  // call with an expression

void func(bool abc);- func(expression);

enum Abc { no, yes }
void func(Abc abc); - func(expression ? Abc.yes : Abc.no);
- func(cast(Abc)expression);

	void func(Flag!Abc abc);  - func(expression ? Flag!Abc.yes : 
Flag!Abc.no);

- func(expression ? yes!Abc : no!Abc);
- func(expression ? Yes.Abc : No.Abc);
- func(cast(Flag!Abc)expression);

My take on this is that we shouldn't try to reinvent the boolean in the 
standard library. If you want to replace a bool with a two-option enum 
at some places for clarity, that's fine. But I wouldn't elevate that to 
a pattern meant to be used everywhere. And personally, I don't like the 
proliferation of yes/no enums: if you use an enum, value names should 
be more meaningful than a simple yes/no.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 09:05:52 -0400, Steven Schveighoffer 
schvei...@yahoo.com said:



As far as the negation, I think we need one more layer of type:

struct FlagParam(string pname)
{
Flag!pname value;
alias value this;
this(Flag!pname x) { this.value = x }
FlagParam op???() const { return FlagParam(cast(Flag!pname)!value); }
}

BTW, is there a way to hook !?  Maybe this won't work...  The idea is 
to  have Yes.abc return FlagParam!abc(Flag!abc.yes).


If you need to convert a bool to a Flag!abc, you can do any of these:

func(expression ? Yes.abc : No.abc);

or

func(cast(Flag!abc)expression);

or, with your proposal:

func(FlagParam!abc(expression));

None of this is very appealing, but I find the first is the most readable.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Alix Pexton]

On 11/06/2011 14:00, Mafi wrote:

Am 11.06.2011 14:33, schrieb Alix Pexton:


It is by no means a final design, but perhaps a starting point, so
suggestions welcome.


What about:
/++ I wrote an article about D and all I got was ++/
this.Lousy!T shirt;

//d-programming-language.org


I thought about that, I wasn't sure it would parse as valid D code 

also, the difference in the line lengths/breaks is less aesthetically 
pleasing (imho)...


I also considered...


/++ I wrote an article about D
and all I got was ++/
this(){
Lousy!T shirt;
}

which I know is valid, albeit, pointless D, but it also has a less 
appealing shape (imho)...


A...

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 8:25 AM, Michel Fortin wrote:

On 2011-06-11 09:05:52 -0400, Steven Schveighoffer
schvei...@yahoo.com said:


As far as the negation, I think we need one more layer of type:

struct FlagParam(string pname)
{
Flag!pname value;
alias value this;
this(Flag!pname x) { this.value = x }
FlagParam op???() const { return FlagParam(cast(Flag!pname)!value); }
}

BTW, is there a way to hook !? Maybe this won't work... The idea is
to have Yes.abc return FlagParam!abc(Flag!abc.yes).


If you need to convert a bool to a Flag!abc, you can do any of these:

func(expression ? Yes.abc : No.abc);

or

func(cast(Flag!abc)expression);

or, with your proposal:

func(FlagParam!abc(expression));

None of this is very appealing, but I find the first is the most readable.


Agreed. I'll venture to add that I find the first also more desirable 
than an implicit conversion from func(expression).


Andrei

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 8:16 AM, Michel Fortin wrote:

On 2011-06-11 07:54:58 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:


Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against.
For (2) the course of action is to point out the liabilities of
changing the language.


I'm actually not sure whether I want named arguments or not, but I'm
quite sure I don't want to use Flag! in my code. I'd actually prefer a
simple bool parameter to Flag!.

Currently, it looks like we have these possibilities:

// definition // call with a constant

void func(bool abc); - func(true);


The call entails simple data coupling as documented by Steve McConnell: 
you can pass any unstructured Boolean for any meaning of abc.



enum Abc { no, yes }
void func(Abc abc); - func(Abc.yes);


To add the documentation effort:

/**
This is an argument for func. Refer to func below.
*/
enum Abc {
  no, /// you don't want func to do Abc
  yes /// you do want func to do Abc
}

/**
This is func. Mind Abc defined above.
*/
void func(Abc abc);

I think we agree this is rather awkward (I know because I wrote a fair 
amount of such).


So we have the advantage of a nice call syntax and the disadvantage of 
verbose definition and documentation.



void func(Flag!Abc abc); - func(Flag!Abc.yes);
- func(yes!Abc);
- func(Yes.Abc);

which then becomes this if you're using a boolean expression instead of
a constant:


Aha! This reasoning is flawed as I'll explain below.


// definition // call with an expression

void func(bool abc); - func(expression);

enum Abc { no, yes }
void func(Abc abc); - func(expression ? Abc.yes : Abc.no);
- func(cast(Abc)expression);

void func(Flag!Abc abc); - func(expression ? Flag!Abc.yes :
Flag!Abc.no);
- func(expression ? yes!Abc : no!Abc);
- func(expression ? Yes.Abc : No.Abc);
- func(cast(Flag!Abc)expression);

My take on this is that we shouldn't try to reinvent the boolean in the
standard library.


I think this characterization is wrong. Let me replace the meaningless 
Abc with an actual example, e.g. OpenRight in std.algorithm.


OpenRight is not a Boolean. Its *representation* is Boolean. It is 
categorical data with two categories. You can represent it with an 
unstructured Boolean the same way you can represent an automaton state 
with an unstructured integer or temperature with an unstructured double, 
but then you'd have the disadvantages that dimensional analysis 
libraries are solving.


For representing categorical data with small sets, programming languages 
use enumerated types. This is because in a small set you can actually 
give name each element. That way you have a separate type for the 
categorical data so you can enjoy good type checking. The mistake I 
believe you are making is the conflation of a categorical data with two 
categories with an unstructured Boolean. By making that conflation you 
lose the advantages of good typechecking in one fell swoop.


(But not all categorical data is a small set, and consequently 
enumerated types are insufficient. Consider e.g. the notion of a user 
id. People routinely use integers for that, and suffer endless 
consequences because of bugs caused by unstructured integers posing as 
user IDs. I have seen instances of such bugs in several codebases in 
different languages.)


As a direct consequence, it is *wrong* to desire to pass an unstructured 
Boolean expression in lieu of OpenRight. So it is *good* that you can't. 
What you *should* be doing is to define an OpenRight value in the first 
place and use it, or construct it in place with expr ? OpenRight.yes : 
OpenRight.no, with the advantage that the conversion intent is explicit 
and visible.



If you want to replace a bool with a two-option enum
at some places for clarity, that's fine. But I wouldn't elevate that to
a pattern meant to be used everywhere. And personally, I don't like the
proliferation of yes/no enums: if you use an enum, value names should be
more meaningful than a simple yes/no.


I think you'd be entirely wrong to make this distinction. There's zero, 
one, and many. Not zero, one, two, and many.



Andrei

Re: Flag proposal

[David Nadlinger]

On 6/11/11 1:54 PM, Andrei Alexandrescu wrote:

Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against. For
(2) the course of action is to point out the liabilities of changing the
language.


*And*, at least for me, still count it as an (informal) vote against 
Flag. You wrote about »The point is it [named arguments] would also have 
disadvantages«, but at the same time, you seem to ignore that using a 
non-obvious construct all over the standard library adds to perceived 
the »language complexity« (from the user's perspective) just as well, 
even more so if opDispatch or other »hacks« are used to beautify the 
implementation.


Yes, I do think named parameters would be a step forward and we should 
definitely look into adding them to D. But independently, I don't think 
that reinventing bool in Phobos is a good idea. How would you explain 
somebody new to D that, while usually it's »Something.property«, you 
have to write »Yes.foo« instead of »Foo.yes«? Also, there is the issue 
of error messages:


---
void foo(Flag!bar flag) {}

void main() {
  foo(No.baz);
}
---

leads to

---
Error: function foo (Flag flag) is not callable using argument types (Flag)
Error: cannot implicitly convert expression (opDispatch()) of type Flag 
to Flag

---

I don't know about you, but I think this is not quite an acceptable 
error message for mistyping a single character while trying to pass a 
boolean parameter to some standard library function.


David

Re: Flag proposal

[David Nadlinger]

On 6/11/11 3:56 PM, Andrei Alexandrescu wrote:

To add the documentation effort:

/**
This is an argument for func. Refer to func below.
*/
enum Abc {
no, /// you don't want func to do Abc
yes /// you do want func to do Abc
}

/**
This is func. Mind Abc defined above.
*/
void func(Abc abc);

I think we agree this is rather awkward (I know because I wrote a fair
amount of such).

So we have the advantage of a nice call syntax and the disadvantage of
verbose definition and documentation.


So what? Library code is typically written once, and used often. Also, 
what's wrong with the followig (maybe there is really an issue with it, 
didn't run it through DDoc):


---
/**
 * This is func.
 *
 * Params:
 *   abc = Abc.yes to destroy the world, Abc.no to leave it intact.
 */
void func(Abc abc) {}

/// Ditto.
enum Abc : bool { no, yes }
---

David

Re: Flag proposal

[bearophile]

Andrei:

 Again, there are two broad categories of changes: feature additions and 
 removal of undue limitations. We favor doing the latter.

I understand, but that's not always the best decision in this early stage of D 
life. There are also few little feature changes I have put in Bugzilla since 
lot of time. The more time passes, the less easy they are to apply.

Bye,
bearophile

Re: Flag proposal

[bearophile]

 There are also few little feature changes I have put in Bugzilla since lot of 
 time.

I am starting to think that just putting those issues in bugzilla was not 
enough, they seem to get mostly ignored. More periodic drumming in this 
newsgroup was needed... :-(

Bye,
bearophile

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 9:08 AM, David Nadlinger wrote:

On 6/11/11 1:54 PM, Andrei Alexandrescu wrote:

Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against. For
(2) the course of action is to point out the liabilities of changing the
language.


*And*, at least for me, still count it as an (informal) vote against
Flag.


Of course it does, but the point is there are arguments that might 
convince the person.



You wrote about »The point is it [named arguments] would also have
disadvantages«, but at the same time, you seem to ignore that using a
non-obvious construct all over the standard library adds to perceived
the »language complexity« (from the user's perspective) just as well,
even more so if opDispatch or other »hacks« are used to beautify the
implementation.


I agree that implementation complexity has a cost. That would be 
justified if the idiom becomes commonly used outside the library.



Yes, I do think named parameters would be a step forward and we should
definitely look into adding them to D. But independently, I don't think
that reinventing bool in Phobos is a good idea.


You may want to refer to my answer to Michel.


Andrei

Re: Flag proposal

[Steven Schveighoffer]

On Sat, 11 Jun 2011 09:25:19 -0400, Michel Fortin  
michel.for...@michelf.com wrote:


On 2011-06-11 09:05:52 -0400, Steven Schveighoffer  
schvei...@yahoo.com said:



As far as the negation, I think we need one more layer of type:
 struct FlagParam(string pname)
{
Flag!pname value;
alias value this;
this(Flag!pname x) { this.value = x }
FlagParam op???() const { return FlagParam(cast(Flag!pname)!value);  
}

}
 BTW, is there a way to hook !?  Maybe this won't work...  The idea  
is to  have Yes.abc return FlagParam!abc(Flag!abc.yes).


If you need to convert a bool to a Flag!abc, you can do any of these:

func(expression ? Yes.abc : No.abc);

or

func(cast(Flag!abc)expression);

or, with your proposal:

func(FlagParam!abc(expression));

None of this is very appealing, but I find the first is the most  
readable.


We need another struct besides Yes and No that allows creation with  
another opDispatch:


Foo.abc(expression);

The best name for Foo is Flag, but that's taken...

But still, is there a way to override the type returned by !flag?  I think  
there isn't...  That's kind of sucky.  Flipping of a flag is a very common  
feature, I would expect to be able to do it easily.


Hm... what if opCast!bool() returns something other than bool?  does that  
actually work?  That *would* be a hack :)


We could also possibly use unary - to denote flipping a flag.  That's very  
hacky too, but I think it would work.


-Steve

Re: stackoverflow.com question

[bearophile]

Andrei:

 http://stackoverflow.com/questions/6315882/pattern-matching-in-d

Pattern matching is very useful if you have a functional mindset. In Haskell 
functions are mostly based on it. But to implement pattern matching you 
probably need some kind of structural typing (this means two data types are 
seen as the same type if they contain the same fields in the same order, 
regardless of the names. Time ago I have vaguely asked for structural typing 
for D tuples), and some significant amount of added language complexity (Scala 
pattern matching has required several small things). So I don't think it's good 
to add pattern matching to D2.

A possible *low-priority* idea is instead to allow arrays too and structs as 
items to switch on, to allow switching on bigInts too:
http://d.puremagic.com/issues/show_bug.cgi?id=596
(I have said low priority because I think there are more important things to 
add.)

Bye,
bearophile

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 9:30 AM, Steven Schveighoffer wrote:

On Sat, 11 Jun 2011 09:25:19 -0400, Michel Fortin
michel.for...@michelf.com wrote:


On 2011-06-11 09:05:52 -0400, Steven Schveighoffer
schvei...@yahoo.com said:


As far as the negation, I think we need one more layer of type:
struct FlagParam(string pname)
{
Flag!pname value;
alias value this;
this(Flag!pname x) { this.value = x }
FlagParam op???() const { return FlagParam(cast(Flag!pname)!value); }
}
BTW, is there a way to hook !? Maybe this won't work... The idea is
to have Yes.abc return FlagParam!abc(Flag!abc.yes).


If you need to convert a bool to a Flag!abc, you can do any of these:

func(expression ? Yes.abc : No.abc);

or

func(cast(Flag!abc)expression);

or, with your proposal:

func(FlagParam!abc(expression));

None of this is very appealing, but I find the first is the most
readable.


We need another struct besides Yes and No that allows creation with
another opDispatch:

Foo.abc(expression);

The best name for Foo is Flag, but that's taken...

But still, is there a way to override the type returned by !flag? I
think there isn't... That's kind of sucky. Flipping of a flag is a very
common feature, I would expect to be able to do it easily.


I agree that's a drawback. I couldn't find a reasonable workaround.

Andrei

Re: bug in purity validation

[Stewart Gordon]

On 05/06/2011 11:10, Timon Gehr wrote:
snip

Ah, the implicit this parameter...


What's that to do with anything?

Stewart.

Re: Improving (foreach) ranges

[eles]

 And the multi-dimensional slicing discussions tend to advocate mapping
 a..b to [a,b].

which would be such a shame...

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu 
seewebsiteforem...@erdani.org said:



On 6/11/11 8:16 AM, Michel Fortin wrote:

On 2011-06-11 07:54:58 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:


Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against.
For (2) the course of action is to point out the liabilities of
changing the language.


I'm actually not sure whether I want named arguments or not, but I'm
quite sure I don't want to use Flag! in my code. I'd actually prefer a
simple bool parameter to Flag!.

Currently, it looks like we have these possibilities:

// definition // call with a constant

void func(bool abc); - func(true);


The call entails simple data coupling as documented by Steve McConnell: 
you can pass any unstructured Boolean for any meaning of abc.


Which is often useful if the value is conditional to a boolean 
expression. The only lacking thing is the parameter name which would 
make things clear to the reader.


Structured data is useful only if you pass it around; if you use it 
only once as a function parameter and nowhere else, then it just gets 
in the way. If your argument was that structured data is always 
preferred to unstructured data, I disagree.




enum Abc { no, yes }
void func(Abc abc); - func(Abc.yes);


To add the documentation effort:

/**
This is an argument for func. Refer to func below.
*/
enum Abc {
   no, /// you don't want func to do Abc
   yes /// you do want func to do Abc
}

/**
This is func. Mind Abc defined above.
*/
void func(Abc abc);

I think we agree this is rather awkward (I know because I wrote a fair 
amount of such).


So we have the advantage of a nice call syntax and the disadvantage of 
verbose definition and documentation.


Yes, and I think most of the time this should be a bool. Or to be 
precise: if it's not worth documenting separately, especially if it's 
used just once as a flag to a specific function, and if you don't 
expect it to extend to more than yes/no, then it should be a bool.




void func(Flag!Abc abc); - func(Flag!Abc.yes);
- func(yes!Abc);
- func(Yes.Abc);

which then becomes this if you're using a boolean expression instead of
a constant:


Aha! This reasoning is flawed as I'll explain below.


// definition // call with an expression

void func(bool abc); - func(expression);

enum Abc { no, yes }
void func(Abc abc); - func(expression ? Abc.yes : Abc.no);
- func(cast(Abc)expression);

void func(Flag!Abc abc); - func(expression ? Flag!Abc.yes :
Flag!Abc.no);
- func(expression ? yes!Abc : no!Abc);
- func(expression ? Yes.Abc : No.Abc);
- func(cast(Flag!Abc)expression);

My take on this is that we shouldn't try to reinvent the boolean in the
standard library.


I think this characterization is wrong. Let me replace the meaningless 
Abc with an actual example, e.g. OpenRight in std.algorithm.


OpenRight is not a Boolean. Its *representation* is Boolean. It is 
categorical data with two categories. You can represent it with an 
unstructured Boolean the same way you can represent an automaton state 
with an unstructured integer or temperature with an unstructured 
double, but then you'd have the disadvantages that dimensional analysis 
libraries are solving.


For representing categorical data with small sets, programming 
languages use enumerated types. This is because in a small set you can 
actually give name each element. That way you have a separate type for 
the categorical data so you can enjoy good type checking. The mistake I 
believe you are making is the conflation of a categorical data with two 
categories with an unstructured Boolean. By making that conflation you 
lose the advantages of good typechecking in one fell swoop.


I think you're misinterpreting. I don't like yes/no enums because I 
don't find the value names meaningful, but I'm perfectly fine with 
two-element enums if they are properly named.



(But not all categorical data is a small set, and consequently 
enumerated types are insufficient. Consider e.g. the notion of a user 
id. People routinely use integers for that, and suffer endless 
consequences because of bugs caused by unstructured integers posing as 
user IDs. I have seen instances of such bugs in several codebases in 
different languages.)


I totally agree with making specific types to avoid mixing unrelated 
things, as long as it's reasonable. You wouldn't argue for a UserId 
type if values of this type weren't passed around.



As a direct consequence, it is *wrong* to desire to pass an 
unstructured Boolean expression in lieu of OpenRight. So it is *good* 
that you can't. What you *should* be doing is to define an OpenRight 
value in the first place and use it, or construct it in place with 
expr ? OpenRight.yes : OpenRight.no, with the advantage that the 
conversion intent is explicit and visible.


But boundaries can be open or 

Re: bug in purity validation

[Timon Gehr]

Stewart Gordon wrote:
 On 05/06/2011 11:10, Timon Gehr wrote:
 snip
 Ah, the implicit this parameter...

 What's that to do with anything?

 Stewart.

I weakly pure function may modify any memory location reachable by its (mutable)
parameters. What I didn't realize at first and late in the night is that 
obviously
this also applies to the implicit 'this' parameter.


Timon

Re: No fall-through for switch (WAS: Re: [Submission] D Slices)

[eles]

 For the rare cases where fall-through is actually needed

well, at least this one took off

Re: Removing undefined behavior of bitshifts

[Stewart Gordon]

On 07/06/2011 00:20, Timon Gehr wrote:
snip

I'd much prefer the behavior to be defined as 1x; being equivalent to
1(0x1fx); (That's what D effectively does during runtime. It is also what
the machine code supports, at least in x87).


Defining the behaviour to match that of one brand of processor would be arbitrary and 
confusing.  Why not define it just to shift by the requested number of bits?


Any extra processor instructions to make it behave correctly for cases where this number 
= 32 would be the part of the backend code generation.  And if the right operand is a 
compile-time constant (as it probably is usually), these extra instructions can be 
eliminated or at least optimised to the particular value.



Are there any practical downsides to making the behavior defined? (Except that
the CTFE Code would have to be fixed). I think Java does it too.


Apparently Java shifts are modulo the number of bits in the type of the left operand.  Or 
something like that.  You'd think it was an oversight in the original implementation that 
was kept for bug compatibility, but you could well ask how they dealt with finding the 
behaviour to be machine dependent (contrary to the whole philosophy of Java).


Stewart.

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 10:40 AM, Michel Fortin wrote:

On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:

For representing categorical data with small sets, programming
languages use enumerated types. This is because in a small set you can
actually give name each element. That way you have a separate type for
the categorical data so you can enjoy good type checking. The mistake
I believe you are making is the conflation of a categorical data with
two categories with an unstructured Boolean. By making that conflation
you lose the advantages of good typechecking in one fell swoop.


I think you're misinterpreting. I don't like yes/no enums because I
don't find the value names meaningful, but I'm perfectly fine with
two-element enums if they are properly named.


What is meaningless about OpenRight.yes?


(But not all categorical data is a small set, and consequently
enumerated types are insufficient. Consider e.g. the notion of a user
id. People routinely use integers for that, and suffer endless
consequences because of bugs caused by unstructured integers posing as
user IDs. I have seen instances of such bugs in several codebases in
different languages.)


I totally agree with making specific types to avoid mixing unrelated
things, as long as it's reasonable. You wouldn't argue for a UserId type
if values of this type weren't passed around.


The problem is the definition of reasonable is loose. For all I can 
tell we agree, it's just we have different notions of what's reasonable.



But boundaries can be open or closed on the right, but also on the left.
Unfortunately, because you choose to call the enum OpenRight, it can
only be used on the right, and nowhere else.


But this is intentional. If I wanted something more general, I would 
have used something more general! What are you saying here?



What you're doing with OpenRight, and more generally with Flag!, is
narrowing excessively the category to the point where it can be used at
one place and one place only: as a specific parameter to a specific
function. If you had another parameter for the left side, you'd create
an OpenLeft enum with exactly the same choices. I doubt this kind of
categorization has any advantage.


In fact, no. The same Flag instantiation can be used with distinct 
functions. Its advantage is that you don't need to go out of your way 
and define it. It's a sort of a lambda, a literal for a categorical value.



Actually, I think the advantage you seek has nothing to do with
categorization and much more to do with a desire to see those parameter
names appear at the call site. You're actually using over-categorization
to achieve that, and with Flag! you're going to make this systematic.
Sorry, I can't approve.


I think it's best to discuss the pros and cons of the proposal than the 
proposer's desires. Yes, clarifying the intent at the call site is a 
good thing. And yes, systematization can be good. Named parameters would 
be one way to go about it, and categorization would be another. If you 
characterize the approach as *over* categorization, I'm interested in 
your justification of that qualification.



If you want to replace a bool with a two-option enum
at some places for clarity, that's fine. But I wouldn't elevate that to
a pattern meant to be used everywhere. And personally, I don't like the
proliferation of yes/no enums: if you use an enum, value names should be
more meaningful than a simple yes/no.


I think you'd be entirely wrong to make this distinction. There's
zero, one, and many. Not zero, one, two, and many.


No idea what you mean there.


Sets with zero and one elements have distinctive properties compared to 
sets of more than one element. Sets with two elements don't.



Andrei

Re: [Submission] D Slices

[eles]

 This is not practical.  It would be too expensive to check because
the
 hardware does not support it.

neither does for bounds checking. expensiveness does not matter so
much in the debug version.

 As has been said, multiple times, UTYPE_MAX is not a valid index,
and that
 is not because of the open-interval on the right.  It's because of
 addressing in a zero-based index world, you simply can't have an
array
 bigger than your address space.  An array with UTYPE_MAX as a valid
index
 must have at least UTYPE_MAX + 1 elements.

well, on unsigned nbits=3, UTYPE_MAX =7 and that's a valid index, as
you write a[0]..a[7]. the array has UTYPE_MAX+1 elements (ie.
length, aka $) and this is exactly why mentioning $ as length
instead of last element is inconsistent when you write a[0..$] (the
second index is, *with this syntax* UTPE_MAX+1 and is not
representable)

 But, it's not really important anyways.  The open-right indexing
ship has
 not only sailed, it's made it across the ocean, formed several
colonies,
 and is currently declaring independence.

Even if independence is acquired, empires are doomed to fall in the
end. See China rising.


 You're about a decade too late
 with this argument.

well, C++ standards gave the same answers when changes were proposed,
this is why the need for D in the first place. age of a choice does
not make it any better. there are good and bad habits. see the famous
  *recommendation* for writing in templates in order to not
conflict with  operator.

 How much of a possibility would you think Matlab has of changing its
 indexing scheme to be like D's?  About the same chance as D adopting
 Matlab's, I'd say.

what about multi-dimensional slicing?

  If this is a reason you will not use D, then I'm sorry
 that you won't be with us, but that's just life.

I do not much use it anyway. My job (both work and teaching, is C and
OpenCL). What I was doing was to recommend it as next language to my
students, when they ask about what OOP to learn (they had some
choices, among C++ and Java). I find it very difficult to further
recommend a language that I do not believe in. Well, I still have two
weeks to think about that, semester ends on June 20 (exam of C).

Re: [Submission] D Slices

[eles]

  Basically, using subtraction in loop conditions is a big no-no.

then... why the compiler allows it? design should eliminate those
big no-nos. else, we tend again to educate users, see the case
for not allowing writing:

while(condition);

and requiring instead

while(condition){}

just because the first was... well, a big no-no (at least from the
maintenance point of view).

next on the list, why not give access to the current index in
foreach instruction? while I find nice to write foreach as a
simpler way to loop through a collection, sometimes you need to do
some processing function of element's index. yes, there are some
issues for unordered collections (if any) and this could also prevent
some compiler optimizations, maybe.

D:

foreach(item; set) {
  // do something to item
}

Go:

for index, value := range someCollection {
  // do something to index and value
}

==or==

for index := range someCollection {
  // do something to index
}

Go seems to consider index information to be priority over the value
of the item. While this is debatable, I think it should be well to
provide the index information too in foreach loops. Maybe with a
slightly different syntax, such as:

foreach(index; item; set) {
  // do something to item
}

what do you think?

Re: [Submission] D Slices

[eles]

   *recommendation* for writing in templates in order to not
 conflict with  operator.

oh, well, the other way around

Re: [Submission] D Slices

[David Nadlinger]

Doesn't foreach (i, item; [a, b, c]) {} do it for you?

David


On 6/11/11 6:16 PM, eles wrote:

Basically, using subtraction in loop conditions is a big no-no.


then... why the compiler allows it? design should eliminate those
big no-nos. else, we tend again to educate users, see the case
for not allowing writing:

while(condition);

and requiring instead

while(condition){}

just because the first was... well, a big no-no (at least from the
maintenance point of view).

next on the list, why not give access to the current index in
foreach instruction? while I find nice to write foreach as a
simpler way to loop through a collection, sometimes you need to do
some processing function of element's index. yes, there are some
issues for unordered collections (if any) and this could also prevent
some compiler optimizations, maybe.

D:

foreach(item; set) {
   // do something to item
}

Go:

for index, value := range someCollection {
   // do something to index and value
}

==or==

for index := range someCollection {
   // do something to index
}

Go seems to consider index information to be priority over the value
of the item. While this is debatable, I think it should be well to
provide the index information too in foreach loops. Maybe with a
slightly different syntax, such as:

foreach(index; item; set) {
   // do something to item
}

what do you think?

TempAlloc Overhaul

[dsimcha]

I've overhauled my TempAlloc proposal based on some of the suggestions 
I've received.  Here are the major changes:


1.  I've reconsidered and decided TempAlloc belongs in its own Phobos 
module (std.tempalloc) instead of in core.memory, mainly because it uses 
Phobos in ways that aren't easy to get rid of.


2.  Move uninitializedArray (formerly newVoid) to its own pull request 
for inclusion in std.array.  This keeps the TempAlloc proposal more 
tightly focused.


3.  Make alignedMalloc and friends private for now, again to make the 
proposal more tightly focused.


4.  Rename tempdup to tempArray to emphasize that is semantics are more 
similar to std.array.array than .dup w.r.t. narrow strings.


5.  Move newStack into the TempAlloc namespace and rename it 
TempAlloc.newArray.


6.  TempAlloc.newArray now handles multidimensional arrays.  Its syntax 
is slightly modified to accommodate this.  Before:


double[] foo = newStack!double(100);

After:

double[] foo = TempAlloc.newArray!(double[])(100);

Code:

https://github.com/dsimcha/TempAlloc

Docs (NOT the same as the old URL):

http://cis.jhu.edu/~dsimcha/d/phobos/std_tempalloc.html

Re: Removing undefined behavior of bitshifts

[Timon Gehr]

Timon Gehr wrote:
 On 07/06/2011 00:20, Timon Gehr wrote:
 snip
 I'd much prefer the behavior to be defined as 1x; being equivalent to
 1(0x1fx); (That's what D effectively does during runtime. It is also what
 the machine code supports, at least in x87).

 Defining the behaviour to match that of one brand of processor would be
arbitrary and
 confusing.

Well, not too much. It is the easiest behavior to implement in hardware.
I thought that it is the most common behavior on different brands of processors,
but I might be mistaken.
Is there any processor that badly needs D support that handles it differently?

 Why not define it just to shift by the requested number of bits?
Because it would turn code that is currently

z = x  y;

to

z = y  (8*sizeof(x)) ? x  y : 0;

On many platforms. Given that you seldom want to shift by a custom amount, and
that it could eliminate some bugs, it might be a reasonable trade-off.



 Any extra processor instructions to make it behave correctly for cases where
this number
  = 32 would be the part of the backend code generation.  And if the right
operand is a
 compile-time constant (as it probably is usually), these extra instructions 
 can be
 eliminated or at least optimised to the particular value.

 Are there any practical downsides to making the behavior defined? (Except 
 that
 the CTFE Code would have to be fixed). I think Java does it too.

 Apparently Java shifts are modulo the number of bits in the type of the left
operand.  Or
 something like that.  You'd think it was an oversight in the original
implementation that
 was kept for bug compatibility, but you could well ask how they dealt with
finding the
 behaviour to be machine dependent (contrary to the whole philosophy of Java).

 Stewart.

I don't even care so much about what the result is, but I feel that saying the
program is in error/the behavior is undefined, when actually you'd just get
back some number is not optimal. (it allows the compiler to do anything if that
case occurs)
I would prefer to make the behavior at least implementation-defined (just a 
formal
change on the D website) or even defined with some runtime-overhead.


Timon

Re: TempAlloc Overhaul

[Jose Armando Garcia]

On Sat, Jun 11, 2011 at 1:26 PM, dsimcha dsim...@yahoo.com wrote:
 I've overhauled my TempAlloc proposal based on some of the suggestions I've
 received.  Here are the major changes:

 1.  I've reconsidered and decided TempAlloc belongs in its own Phobos module
 (std.tempalloc) instead of in core.memory, mainly because it uses Phobos in
 ways that aren't easy to get rid of.

 2.  Move uninitializedArray (formerly newVoid) to its own pull request for
 inclusion in std.array.  This keeps the TempAlloc proposal more tightly
 focused.

 3.  Make alignedMalloc and friends private for now, again to make the
 proposal more tightly focused.

 4.  Rename tempdup to tempArray to emphasize that is semantics are more
 similar to std.array.array than .dup w.r.t. narrow strings.

 5.  Move newStack into the TempAlloc namespace and rename it
 TempAlloc.newArray.

 6.  TempAlloc.newArray now handles multidimensional arrays.  Its syntax is
 slightly modified to accommodate this.  Before:

 double[] foo = newStack!double(100);

 After:

 double[] foo = TempAlloc.newArray!(double[])(100);

 Code:

 https://github.com/dsimcha/TempAlloc

 Docs (NOT the same as the old URL):

 http://cis.jhu.edu/~dsimcha/d/phobos/std_tempalloc.html


Just a high-level comment.

Now that you moved it to its own namespace do you have a need for a
struct with only static method? I think it is an abuse of the language
to use struct as a way of namespacing.

Re: [Submission] D Slices

[David Nadlinger]

On 6/11/11 6:08 PM, eles wrote:

well, on unsigned nbits=3, UTYPE_MAX =7 and that's a valid index, as
you write a[0]..a[7]. the array has UTYPE_MAX+1 elements (ie.
length, aka $) and this is exactly why mentioning $ as length
instead of last element is inconsistent when you write a[0..$] (the
second index is, *with this syntax* UTPE_MAX+1 and is not
representable)


As Steve said, this »problem« occurs only when your array length is 
larger than the address space.


I hereby challenge you to write some real-world D code and show me a 
single instance where the open-right slicing syntax would be a problem 
in this regard – personally, I didn't encounter one yet after writing 
several tens of thousands of lines of D code.


David

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 12:01:33 -0400, Andrei Alexandrescu 
seewebsiteforem...@erdani.org said:



On 6/11/11 10:40 AM, Michel Fortin wrote:

On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:

For representing categorical data with small sets, programming
languages use enumerated types. This is because in a small set you can
actually give name each element. That way you have a separate type for
the categorical data so you can enjoy good type checking. The mistake
I believe you are making is the conflation of a categorical data with
two categories with an unstructured Boolean. By making that conflation
you lose the advantages of good typechecking in one fell swoop.


I think you're misinterpreting. I don't like yes/no enums because I
don't find the value names meaningful, but I'm perfectly fine with
two-element enums if they are properly named.


What is meaningless about OpenRight.yes?


Choosing between yes and no is not meaningful. I'd rather choose 
between open and closed. Of course you'd have to pick a more 
fitting name for the enum, preferably one that could work for all 
bounds, not just the right one to make the category more useful.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: [Submission] D Slices

[Timon Gehr]

eles wrote:
 This is not practical.  It would be too expensive to check because
 the
 hardware does not support it.

 neither does for bounds checking. expensiveness does not matter so
 much in the debug version.

 As has been said, multiple times, UTYPE_MAX is not a valid index,
 and that
 is not because of the open-interval on the right.  It's because of
 addressing in a zero-based index world, you simply can't have an
 array
 bigger than your address space.  An array with UTYPE_MAX as a valid
 index
 must have at least UTYPE_MAX + 1 elements.

 well, on unsigned nbits=3, UTYPE_MAX =7 and that's a valid index, as
 you write a[0]..a[7]. the array has UTYPE_MAX+1 elements (ie.
 length, aka $) and this is exactly why mentioning $ as length
 instead of last element is inconsistent when you write a[0..$] (the
 second index is, *with this syntax* UTPE_MAX+1 and is not
 representable)

Yes, but that just means that you cannot represent the length of your array with
your machine word size. Such an array is meaningless. It does not fit in your
memory. You do not have a case here.

However, your argument could be extended to foreach-range statements:

// loop over all possible ubyte values:
foreach(i;ubyte.min..ubyte.max+1){...} // does not work, because ubyte.max+1 
overflows

// possible fix:
foreach(_i;0..256){ubyte i=_i;...}

I agree that half-open intervals are not the best choice for this _special 
case_.
They are very nice for all the other cases though.
Oh, and yes they simplify the implementation of foreach and make it more 
efficient
because the compiler does not have to care about overflow.
With half-open intervals, your iteration variable _cannot_ overflow, so no need 
to
check for that.

Now, what is more important: The 256 cases where your interval iterated over 
ends
at 255 or the ~32'000 cases were it does not?
The same argument gets much stronger if the type iterated over is bigger in 
size.

The closed-right solution has a special case too:

How do you represent the empty interval ending at UTYPE_MAX?
How do you represent the empty interval beginning at 0?

:o).


 But, it's not really important anyways.  The open-right indexing
 ship has
 not only sailed, it's made it across the ocean, formed several
 colonies,
 and is currently declaring independence.

 Even if independence is acquired, empires are doomed to fall in the
 end. See China rising.

The same argument applies to the empire of closed-right intervals.



 You're about a decade too late
 with this argument.

 well, C++ standards gave the same answers when changes were proposed,
 this is why the need for D in the first place. age of a choice does
 not make it any better. there are good and bad habits. see the famous
   *recommendation* for writing in templates in order to not
 conflict with  operator.

 How much of a possibility would you think Matlab has of changing its
 indexing scheme to be like D's?  About the same chance as D adopting
 Matlab's, I'd say.

 what about multi-dimensional slicing?

Thats very special-purpose and does not play with Ds reference semantics for
slices that well or even at all.
A library solution might implement different semantics for such a thing, maybe
closer to matlab. Ds operator overloading capabilities are of help here.
Matlab is a scripting language optimized for use in linear-algebra 
computations. D
is a general-purpose language.
I think it is natural that D does not support the same things out of the box.


  If this is a reason you will not use D, then I'm sorry
 that you won't be with us, but that's just life.

 I do not much use it anyway. My job (both work and teaching, is C and
 OpenCL). What I was doing was to recommend it as next language to my
 students, when they ask about what OOP to learn (they had some
 choices, among C++ and Java). I find it very difficult to further
 recommend a language that I do not believe in. Well, I still have two
 weeks to think about that, semester ends on June 20 (exam of C).

Why were you considering recommending a programming language you have almost no
experience with anyways?
I would be grateful if you point out that it exists, but recommending it might
indeed be a bad idea.


Timon

Re: Flag proposal [OT]

[Andrej Mitrovic]

On 6/11/11, Alix Pexton alix.dot.pex...@gmail.dot.com wrote:
 On 11/06/2011 06:18, Andrej Mitrovic wrote:
 We should rename Yes and No to Yay and Nay to make them alignable, and
 even more importantly to make us appear as old Englishmen!

 Yay and Nay are too similar looking, but luckily, Yay is not
 actually a old English word :)  A more correct alternative would be
 Aye (pronounced the same as eye), which (along with Nay) is still
 used for some voting actions (such as councillors deciding where to go
 for lunch). I myself say it al least 20 times a day :)

 A...


Oh damn, yay is what teenage girls would say, not old Englishmen. My
bad, it really is Aye. :p

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 11:56 AM, Michel Fortin wrote:

On 2011-06-11 12:01:33 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:


On 6/11/11 10:40 AM, Michel Fortin wrote:

On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:

For representing categorical data with small sets, programming
languages use enumerated types. This is because in a small set you can
actually give name each element. That way you have a separate type for
the categorical data so you can enjoy good type checking. The mistake
I believe you are making is the conflation of a categorical data with
two categories with an unstructured Boolean. By making that conflation
you lose the advantages of good typechecking in one fell swoop.


I think you're misinterpreting. I don't like yes/no enums because I
don't find the value names meaningful, but I'm perfectly fine with
two-element enums if they are properly named.


What is meaningless about OpenRight.yes?


Choosing between yes and no is not meaningful. I'd rather choose
between open and closed.


I don't see how OpenRight.yes is meaningless and Openness.right is 
meaningful.



Of course you'd have to pick a more fitting
name for the enum,


Name one.


preferably one that could work for all bounds, not
just the right one to make the category more useful.


Again, the charter of that particular category is only open to the right.

Anyway, that was the first thing grep yes std/* found. Let's see the 
next one:


/**
Specifies whether the output of certain algorithm is desired in sorted
format.
 */
enum SortOutput {
no,  /// Don't sort output
yes, /// Sort output
}

This already is very unpleasant because certain is as imprecise as it 
gets. Plus one for Flag, I hope you agree.


Alright, so we have

void topNIndex(
alias less = a  b,
SwapStrategy ss = SwapStrategy.unstable,
Range, RangeIndex)(Range r, RangeIndex index,
SortOutput sorted = SortOutput.no);

With Flag in tow, you'd delete SortOutput and you'd replace the 
definition with:


void topNIndex(
alias less = a  b,
SwapStrategy ss = SwapStrategy.unstable,
Range, RangeIndex)(Range r, RangeIndex index,
Flag!sortOutput sorted = No.sortOutput);

Call:

auto a = [ 1, 2, 3 ];
topNIndex(a, Yes.sortOutput);

I understand you find the above meaningless and would advocate using a 
bool, which means:


topNIndex(a, true);

which would have even me running to the manual, and I wrote the darn thing.

With named parameters, we'd have something along the lines of:

topNIndex(a, sortOutput : true);

which is nice, but not present in the language (and I can tell after 
talking to Walter it won't be anytime soon).


With your choice of meaningful/less, you'd have something like:

enum HowToOutput { unsorted, sorted }
topNIndex(a, HowToOutput.sorted);

which is pretty much the same thing as yes/no, just more convoluted and 
less systematic. I mean you can't impose to yourself to choose any names 
except yes and no on account of them being meaningless.



Andrei

Re: Flag proposal

[jdrewsen]

Den 11-06-2011 03:26, David Nadlinger skrev:

On 6/11/11 3:21 AM, bearophile wrote:

Andrei:


This module won't compile in today's D, but not for a matter of
principles; it's just a random limitation of the language. (It does work
if you import from within a class or struct.) You can insert most
declarations in a scope, so the ones you can't insert are just awkward
exceptions, unless there's a good reason to actively disable them. Any
code should work if you just wrap another scope around it.

Walter and I call the above a turtle feature, in allusion to the
turtles all the way down meme. Walter wants to fix this, and similar
limitations that act unturtly. Imports inside a scope won't be visible
outside that scope, and importing the same module from several different
functions will come at no cost in compilation time.


You are allowed to import modules inside functions in Python too
(there is a just a minor restriction), but I have never asked for this
feature in D because this feature has a cost too. Putting all imports
at the top of the module is more tidy, it allows the person that reads
the code to find all the used imports very quickly. If they are spread
in the module they become less easy to find, you need to use your
editor/IDE to search for them.

Bye,
bearophile


At least allowing imports in unittests would be nice though – I
frequently find myself writing »version (unittest) {}« blocks before the
actual unit tests just to import some modules not needed during regular
builds (yeah, I suppose I'm somewhat pedantic about that).


+1

Re: [Submission] D Slices

[eles]

== Quote from David Nadlinger (s...@klickverbot.at)'s article
 Doesn't foreach (i, item; [a, b, c]) {} do it for you?
 David

well, you are right. mea culpa.

Re: [Submission] D Slices

[eles]

 As Steve said, this »problem« occurs only when your array length is
 larger than the address space.
 I hereby challenge you to write some real-world D code and show me a
 single instance where the open-right slicing syntax would be a problem
 in this regard – personally, I didn't encounter one yet after writing
 several tens of thousands of lines of D code.
 David

well, I cannot, because it is a situation that I did not encounter on the
standard desktop architecture, only on other architectures, where D is not
implemented. I use OpenCL for those.

Re: [OT] D's community is awesome!

[Robert Clipsham]

On 10/06/2011 22:31, Nick Sabalausky wrote:

Trass3ru...@known.com  wrote in message news:op.vwu1q2lv3ncmek@enigma...

Am 10.06.2011, 13:48 Uhr, schrieb Robert Clipsham
rob...@octarineparrot.com:

You're probably better off for it - I used to be strongly in the
mercurial camp, but having used git for a while I find I vastly prefer
it, despite still not knowing how to do quite a bit with it.


Yep, Mercurial's biggest drawback imo is that bookmarks (which let you do
something analogous to git's branches) aren't standard and thus aren't
pushed/pulled by default.


Isn't cloning a sufficient equivalent to git's branches?


Cloning is a lot slower and a lot less convenient. You end up with the 
SVN style of having multiple directories to keep track of everything in, 
a complete pain. Mercurial does have branches, but they are magnitudes 
slower than in git, and even the documentation for hg recommends cloning 
if you want to do anything serious.



And of course github is way better than bitbucket, but that's not
Mercurial's fault I admit.


Totally agree. Not that I'm big fan of GitHub, but yea, definitely better
than BitBucket.


I'm subscribed to both github and bitbucket blogs (or was anyway), the 
rate at which github adds cool stuff is far greater than that of 
bitbucket, I can't help but feel bitbucket is playing catch up.


--
Robert
http://octarineparrot.com/

Re: Flag proposal

[Ben Grabham]

On 11/06/11 15:28, Andrei Alexandrescu wrote:

On 6/11/11 9:08 AM, David Nadlinger wrote:

On 6/11/11 1:54 PM, Andrei Alexandrescu wrote:

Consider two statements:

1. I dislike Flag. It looks ugly to me.

2. I dislike Flag. Instead I want named arguments.

There is little retort to (1) - it simply counts as a vote against. For
(2) the course of action is to point out the liabilities of changing the
language.


*And*, at least for me, still count it as an (informal) vote against
Flag.


Of course it does, but the point is there are arguments that might
convince the person.


You wrote about »The point is it [named arguments] would also have
disadvantages«, but at the same time, you seem to ignore that using a
non-obvious construct all over the standard library adds to perceived
the »language complexity« (from the user's perspective) just as well,
even more so if opDispatch or other »hacks« are used to beautify the
implementation.


I agree that implementation complexity has a cost. That would be
justified if the idiom becomes commonly used outside the library.


Yes, I do think named parameters would be a step forward and we should
definitely look into adding them to D. But independently, I don't think
that reinventing bool in Phobos is a good idea.


You may want to refer to my answer to Michel.


Andrei


Hey,

Don't know whether I can vote but I looked through it and I prefer using 
booleans over this. This just doesn't look very nice to me and if you 
*really* wanted to use this in a program, you could just use an enum but 
I don't see why flags is good (even after reading through all your 
counter-arguments).


Nebster

Re: Available D2 implementation on Windows besides DMD?

[Robert Clipsham]

On 10/06/2011 21:18, Jonathan M Davis wrote:

On 2011-06-10 13:15, Nick Sabalausky wrote:

Robert Clipshamrob...@octarineparrot.com  wrote in message
news:ist1af$tbj$1...@digitalmars.com...


As for how well they optimize code, dmd has a state of the art optimizer
from the 90s, or there abouts - the code it generates is pretty speedy,
it has some obvious short comings though (I believe floating point and
inlining are lacking, as well as some more modern optimizations).


I'm pretty sure DMD does inlining. After all, it *does* have an -inline
commandlne flag. My understanding is that it just doesn't always inline
everything it could.


dmd _definitely_ has inlining. It could use some improvement (e.g. functions
with lazy parameters can't currently be inlined), but it _does_ have inlining.
And dmd's optimizations aren't bad. It's just that they could be better. I
expect that we'll see them improve further once the language has stablized
more. As much as faster code would be nice, correct code is much more
important. And there are still plenty of bugs to iron out in the compiler
(though it's definitely improving).

- Jonathan M Davis


Indeed, by lacking I didn't mean lacking the feature, I meant lacking in 
functionality/ability, there are a lot of things that it could inline 
but doesn't currently.


--
Robert
http://octarineparrot.com/

Re: [OT] D's community is awesome!

[Andrej Mitrovic]

My only problem with github is its extremely slow code display.
Opening up a larger module such as std.algorithm freezes firefox for a
good couple of seconds (ok, maybe firefox is to blame for not running
tabs concurrently or something), and scrolling is terribly slow too. I
could make some coffee while std.datetime opens.. And I'm running a
quad-core with 3 Gigs of RAM rolleyes.

And then they say the desktop is dead. With this performance.. I don't think so.

Also +1 on the great community. Maybe it's because we're a small
community so we tend to help each other more often. It's kind of like
the difference between living in a large metropolis and a small
village. I used to live in the latter for about a year or so when I
was restoring my apartment, and nearly everyone that passes next to me
said hello, and asked me about my day. It was very cozy living there.
:)

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Robert Clipsham]

On 11/06/2011 06:50, Nick Sabalausky wrote:

Robert Clipshamrob...@octarineparrot.com  wrote in message
news:issvrr$qn3$2...@digitalmars.com...


You seem to be using cafe press for your other merchandise, there's a tool
on there for custom t-shirts.

http://www.cafepress.com/cp/customize/makeadesign2.aspx?clear=trueno=321color=6#designer

It's probably easier to do it through there. If not, I could probably make
an image.

Also, hate to be a grammar nazi, but that should probably be I wrote this
article /about/ D, and all I got was this lousy!T shirt.



Not to be a bikeshed painter, but I'd suggest I wrote /an/ article...
Having this in both predicates sounds repetitive. Plus, this suggests
that the article is nearby.


Muphry's law that I missed that :

(http://en.wikipedia.org/wiki/Muphry's_law before you complain about my 
spelling)



(Where the hell did that last paragraph I wrote come from? I *know* I didn't
pay *that* much attention in English class!)


I've also noticed that my ability to write correct English has improved 
dramatically since I stopped learning it formally.


--
Robert
http://octarineparrot.com/

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Robert Clipsham]

On 11/06/2011 14:28, Alix Pexton wrote:

On 11/06/2011 14:00, Mafi wrote:

Am 11.06.2011 14:33, schrieb Alix Pexton:


It is by no means a final design, but perhaps a starting point, so
suggestions welcome.


What about:
/++ I wrote an article about D and all I got was ++/
this.Lousy!T shirt;

//d-programming-language.org


I thought about that, I wasn't sure it would parse as valid D code 

also, the difference in the line lengths/breaks is less aesthetically
pleasing (imho)...

I also considered...


/++ I wrote an article about D
and all I got was ++/
this(){
Lousy!T shirt;
}

which I know is valid, albeit, pointless D, but it also has a less
appealing shape (imho)...

A...


I prefer the initial one. I'd happily acquire such a shirt if one was 
available.


--
Robert
http://octarineparrot.com/

Re: D Recurrences

[Ben Grabham]

On 10/06/11 05:43, Jonathan M Davis wrote:

On 2011-06-09 20:35, Ben Grabham wrote:

On 09/06/11 20:15, Jonathan M Davis wrote:

The save property of a forward range returns a copy of that range. In
most cases, since ranges are generally restructs, it just returns the
range. You use it when you want to save the original range and still be
able pop elements off.

auto orig = range.save;

//pop off as many elements from range as I want.
//orig still has all of its elements

The elements aren't copied however, just the range. Regardless, it has
nothing to do with returning an element from a range, so I don't
understand your question about returning an index rather than a whole
object. Ranges don't really use indicies. indexOf will tell you the
index of a particular element, and you can increment a counter every
time you pop off an element if you want to know how many elements you've
consumed, but once an element has been popped off, it's not part of that
range anymore (though it could be part of a saved range), so that could
seriously affect by what you mean by index, depending on what you're
doing.

- Jonathan M Davis


I want to make it so that foreach works but I'm storing an array which
when changed, want to keep it like that, even after the foreach, I just
want to reset the index to 0

At the moment, I have to do:
foreach(i; 0..100)
...

lazy._n = 0;

foreach(i; 0..100)
...

I want to do:
foreach(n; lazy)
...
foreach(n; lazy)
...


0 .. 100 has nothing to do with ranges. That's a built-in feature of foreach.
This would use a range

foreach(i; iota(0, 100))

because iota generates one, but 0 .. 100 doesn't. But there's no array
involved in

foreach(i; 0 .. 100)

anyway, and you state that you're storing an array as part of this, so I
really don't know what you're trying to do. I'd need to see actual code to be
of any help.

- Jonathan M Davis


Sorry, didn't really make that clear.

Inside the foreach, I'm using popFront and front to get the values and 
then outside, I set the index (_n) back to 0. What I want to do is 
save the _n value and then restore it at the beginning and end of the 
foreach respectively.


I don't have the code on me atm, but when I get hold of it, I'll post it 
if you still need it.


Thanks,
Nebster

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Timon Gehr]

On 11/06/2011 14:28, Alix Pexton wrote:
 On 11/06/2011 14:00, Mafi wrote:
 Am 11.06.2011 14:33, schrieb Alix Pexton:

 It is by no means a final design, but perhaps a starting point, so
 suggestions welcome.

 What about:
 /++ I wrote an article about D and all I got was ++/
 this.Lousy!T shirt;

 //d-programming-language.org

 I thought about that, I wasn't sure it would parse as valid D code 
 [snip.]

This would: (with minimal context)
T shirt;
struct T{
T lousy(T)(T arg){return arg;}
T submitArticle(Article){
return this.lousy!T(shirt);
}
}
struct Article{};


Timon

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Andrei Alexandrescu]

On 6/11/11 1:39 PM, Timon Gehr wrote:

On 11/06/2011 14:28, Alix Pexton wrote:

On 11/06/2011 14:00, Mafi wrote:

Am 11.06.2011 14:33, schrieb Alix Pexton:


It is by no means a final design, but perhaps a starting point, so
suggestions welcome.


What about:
/++ I wrote an article about D and all I got was ++/
this.Lousy!T shirt;

//d-programming-language.org


I thought about that, I wasn't sure it would parse as valid D code
[snip.]


This would: (with minimal context)
T shirt;
struct T{
 T lousy(T)(T arg){return arg;}
 T submitArticle(Article){
 return this.lousy!T(shirt);
 }
}
struct Article{};


Timon


We don't have (g|m)onads if we don't make it a range.

Andrei

Re: Should GC.malloc be considered 'pure'?

[pillsy]

== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
 On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ kenn...@gmail.com wrote:
  Given that the 'new' expression can be used in 'pure', should it be that
  GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
  weakly pure also?

 Yes.  But one of the possible issues here: weak purity is determined by
 the type of the parameters.  GC.malloc only takes non-reference types, so
 marking it as pure might make the compiler actually think these are
 strong-pure.

Would adding a third, dummy, reference-type parameter that takes a suitable 
default value allow you to hack
around this?

Cheers,
Pillsy

Re: Flag proposal

[Michel Fortin]

On 2011-06-11 13:08:48 -0400, Andrei Alexandrescu 
seewebsiteforem...@erdani.org said:



With named parameters, we'd have something along the lines of:

topNIndex(a, sortOutput : true);

which is nice, but not present in the language (and I can tell after 
talking to Walter it won't be anytime soon).


The funny thing is that named arguments are not that difficult to 
implement as long as you don't allow reordering. Much easier than 
const(Object)ref actually.


https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a

Took 


me less time than what I took arguing about Flag!.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: [OT] D's community is awesome!

[David Nadlinger]

On 6/11/11 8:18 PM, Andrej Mitrovic wrote:

My only problem with github is its extremely slow code display.
Opening up a larger module such as std.algorithm freezes firefox for a
good couple of seconds (ok, maybe firefox is to blame for not running
tabs concurrently or something), and scrolling is terribly slow too. I
could make some coffee while std.datetime opens.. And I'm running a
quad-core with 3 Gigs of RAMrolleyes.


This is strange, std.algorithm opens and scrolls super-smoothly here in 
both Firefox and Chrome (OS X) – without syntax highlighting though, 
presumably to avoid the precise problem you experience because the file 
is quite large.


And std.datetime doesn't even display in the GitHub UI due to its sheer 
size, but the »raw« view loads fast here as well (Firefox and Chrome 
again) – problems with that would rather be due to browser limitations 
or connection issues, I suppose, unless GitHub are screwing up serving a 
text file.


David

Re: Flag proposal

[Robert Clipsham]

On 11/06/2011 12:54, Andrei Alexandrescu wrote:

Consider two statements:

1. I dislike Flag. It looks ugly to me.


This statement holds true for me.


2. I dislike Flag. Instead I want named arguments.


This one is perhaps true. I've never needed named arguments.


There is little retort to (1) - it simply counts as a vote against. For
(2) the course of action is to point out the liabilities of changing the
language.

Andrei


So I had an idea.


struct Flag
{
static bool opDispatch(string n)()
{
static if (n[0..2] == no)
{
return false;
}
else
{
return true;
}
}
}

void myFunc(bool foo, bool bar)
{
}

void main()
{
myFunc(Flag.foo, Flag.noBar);
}


 * No ugly templates
 * Self documenting
 * No overhead (dmd can inline it to myFunc(true, false))
 * Caller decides if they want it

--
Robert
http://octarineparrot.com/

Re: TempAlloc Overhaul

[Robert Jacques]

On Sat, 11 Jun 2011 12:35:43 -0400, Jose Armando Garcia  
jsan...@gmail.com wrote:



On Sat, Jun 11, 2011 at 1:26 PM, dsimcha dsim...@yahoo.com wrote:
I've overhauled my TempAlloc proposal based on some of the suggestions  
I've

received.  Here are the major changes:

1.  I've reconsidered and decided TempAlloc belongs in its own Phobos  
module
(std.tempalloc) instead of in core.memory, mainly because it uses  
Phobos in

ways that aren't easy to get rid of.

2.  Move uninitializedArray (formerly newVoid) to its own pull request  
for

inclusion in std.array.  This keeps the TempAlloc proposal more tightly
focused.

3.  Make alignedMalloc and friends private for now, again to make the
proposal more tightly focused.

4.  Rename tempdup to tempArray to emphasize that is semantics are more
similar to std.array.array than .dup w.r.t. narrow strings.

5.  Move newStack into the TempAlloc namespace and rename it
TempAlloc.newArray.

6.  TempAlloc.newArray now handles multidimensional arrays.  Its syntax  
is

slightly modified to accommodate this.  Before:

double[] foo = newStack!double(100);

After:

double[] foo = TempAlloc.newArray!(double[])(100);

Code:

https://github.com/dsimcha/TempAlloc

Docs (NOT the same as the old URL):

http://cis.jhu.edu/~dsimcha/d/phobos/std_tempalloc.html



Just a high-level comment.

Now that you moved it to its own namespace do you have a need for a
struct with only static method? I think it is an abuse of the language
to use struct as a way of namespacing.


First, TempAlloc was originally developed in its own namespace. Second,  
there are no name conflicts between core.memory and TempAlloc which would  
require a sub-namespace. Third, Structs don't provide a true namespace.  
What you're neglecting is that each of those function names can't stand by  
itself. For example, people assume malloc and free always refer to the C  
functions. So, the TempAlloc functions would normally be TempAllocMalloc  
or TempAllocFree. But once the number of functions like this grows past a  
certain size, using TempAlloc.free, becomes syntactically nicer than  
TempAllocFree.

Re: Should GC.malloc be considered 'pure'?

[Robert Jacques]

On Sat, 11 Jun 2011 14:59:55 -0400, pillsy pillsb...@gmail.com wrote:


== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article

On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ kenn...@gmail.com wrote:
 Given that the 'new' expression can be used in 'pure', should it be  
that

 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
 weakly pure also?



Yes.  But one of the possible issues here: weak purity is determined by
the type of the parameters.  GC.malloc only takes non-reference types,  
so

marking it as pure might make the compiler actually think these are
strong-pure.


Would adding a third, dummy, reference-type parameter that takes a  
suitable default value allow you to hack

around this?

Cheers,
Pillsy


Given that malloc returns a mutable pointer, I think it would/should be  
considered weakly-pure.

Re: [OT] D's community is awesome!

[Andrej Mitrovic]

On 6/11/11, David Nadlinger s...@klickverbot.at wrote:
 On 6/11/11 8:18 PM, Andrej Mitrovic wrote:
 My only problem with github is its extremely slow code display.
 Opening up a larger module such as std.algorithm freezes firefox for a
 good couple of seconds (ok, maybe firefox is to blame for not running
 tabs concurrently or something), and scrolling is terribly slow too. I
 could make some coffee while std.datetime opens.. And I'm running a
 quad-core with 3 Gigs of RAMrolleyes.

 This is strange, std.algorithm opens and scrolls super-smoothly here in
 both Firefox and Chrome (OS X) – without syntax highlighting though,
 presumably to avoid the precise problem you experience because the file
 is quite large.

 And std.datetime doesn't even display in the GitHub UI due to its sheer
 size, but the »raw« view loads fast here as well (Firefox and Chrome
 again) – problems with that would rather be due to browser limitations
 or connection issues, I suppose, unless GitHub are screwing up serving a
 text file.

 David


Yeah there's no syntax highlighting in std.algorithm but it still take
8 seconds to load the tab (firefox freezes during that time), and then
scrolling acts erratic. Using raw is ok, it's just a text file in a
browser so that doesn't cause any issues.

Hmm.. maybe one of my installed firefox plugin has gone rogue or
something. I'll see if I can recreate this issue in IE/Chrome.

Re: [OT] D's community is awesome!

[Andrej Mitrovic]

* Btw. you're right about datetime, it doesn't even display in github
except the raw version, I had that wrong.

I just checked with IE, it works perfectly. Now I have to figure out
which FF plugin is causing this mess. Happy times..

Re: [OT] D's community is awesome!

[David Nadlinger]

On 6/11/11 9:27 PM, Andrej Mitrovic wrote:

[…]Using raw is ok, it's just a text file in a
browser so that doesn't cause any issues.


I thought you could »make some coffee while std.datetime opens«? ;)

David

Re: [OT] D's community is awesome!

[Andrej Mitrovic]

Well this is nuts I've disabled all plugins and it still freezes..
I'll give FF4 a try, if that thing doesn't work I'll have to consider
doing yet another browser switch. I hate doing these things..

Re: [OT] D's community is awesome!

[Andrej Mitrovic]

On 6/11/11, David Nadlinger s...@klickverbot.at wrote:
 On 6/11/11 9:27 PM, Andrej Mitrovic wrote:
 […]Using raw is ok, it's just a text file in a
 browser so that doesn't cause any issues.

 I thought you could »make some coffee while std.datetime opens«? ;)

 David


For std.algorithm, I could. If the coffee was instant and I had a hot
cup of water. :P

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Alix Pexton]

On 11/06/2011 19:35, Andrei Alexandrescu wrote:

On 6/11/11 1:39 PM, Timon Gehr wrote:

On 11/06/2011 14:28, Alix Pexton wrote:

On 11/06/2011 14:00, Mafi wrote:

Am 11.06.2011 14:33, schrieb Alix Pexton:


It is by no means a final design, but perhaps a starting point, so
suggestions welcome.


What about:
/++ I wrote an article about D and all I got was ++/
this.Lousy!T shirt;

//d-programming-language.org


I thought about that, I wasn't sure it would parse as valid D code
[snip.]


This would: (with minimal context)
T shirt;
struct T{
T lousy(T)(T arg){return arg;}
T submitArticle(Article){
return this.lousy!T(shirt);
}
}
struct Article{};


Timon


We don't have (g|m)onads if we don't make it a range.

Andrei


I think it is possible to take the d-ification too far 

A...

Re: [OT] D's community is awesome!

[Andrej Mitrovic]

Holy hell Chrome loads it in a blink of an eye, no lag whatsoever and
there's no laggy scrollbar either. Kudos to Google, I guess.

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 2:12 PM, Robert Clipsham wrote:

On 11/06/2011 12:54, Andrei Alexandrescu wrote:

Consider two statements:

1. I dislike Flag. It looks ugly to me.


This statement holds true for me.


2. I dislike Flag. Instead I want named arguments.


This one is perhaps true. I've never needed named arguments.


There is little retort to (1) - it simply counts as a vote against. For
(2) the course of action is to point out the liabilities of changing the
language.

Andrei


So I had an idea.


struct Flag
{
static bool opDispatch(string n)()
{
static if (n[0..2] == no)
{
return false;
}
else
{
return true;
}
}
}

void myFunc(bool foo, bool bar)
{
}

void main()
{
myFunc(Flag.foo, Flag.noBar);
}


* No ugly templates
* Self documenting
* No overhead (dmd can inline it to myFunc(true, false))
* Caller decides if they want it


// Generate document in nook format
generatePdf(doc.pdf, Flag.nook);


Andrei

Re: Flag proposal

[Andrei Alexandrescu]

On 6/11/11 1:59 PM, Michel Fortin wrote:

On 2011-06-11 13:08:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:


With named parameters, we'd have something along the lines of:

topNIndex(a, sortOutput : true);

which is nice, but not present in the language (and I can tell after
talking to Walter it won't be anytime soon).


The funny thing is that named arguments are not that difficult to
implement as long as you don't allow reordering. Much easier than
const(Object)ref actually.

https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a


Took
me less time than what I took arguing about Flag!.


Love the attitude!! Let's see what Don and Walter think.

Andrei