Re: Walter's DConf 2014 Talks - Topics in Finance
On Saturday, 22 March 2014 at 01:24:38 UTC, Walter Bright wrote: On 3/21/2014 5:39 PM, bearophile wrote: That code must always be hard-real time. So a GC is allowed only during startup time (unless it's a quite special GC), hidden heap allocations are forbidden, data access patterns need to be carefully chosen, you even have to use most of the hot part of the stack, etc. These are all very doable in D, and I've written apps that do so. The "fear of GC" is completely overblown. Fear of GC is overblown. Fear of D's GC isn't.
Stack trace, can we do something ?
A paste is worth a long story : http://pastebin.com/XbL2dv9S That is really bad, and debugging horribly difficult. Basically, no file/line numbers and no demangling. We tend to get used to it, unless it gets exceptionally bad, but I'm pretty sure this kind of things can scare newcomers.
Re: Inline New Class
On Saturday, 22 March 2014 at 04:45:44 UTC, Vladimir Panteleev wrote: BTW, you may find that digitalmars.D.learn is a better place to post questions. I knew that... I swear I did... XP
Re: Inline New Class
On Saturday, 22 March 2014 at 04:35:57 UTC, Malkierian wrote:
OK, so I don't even know what it's actually called, but for
example, in Java:
exitItem.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
shell.getDisplay().dispose();
System.exit(0);
}
});
You can create a new subclass of one you want to use in a
function, with subclass function overrides such as this, but
yet I can't seem to figure out how to do this in D. The first
bracket always has a red underline telling me it's expecting a
')' (or a ';' in the case of trying to declare the listener
before using it in addSelectionListener).
http://dlang.org/class.html#anonymous
The syntax is:
new class SelectionAdapter { ... }
BTW, you may find that digitalmars.D.learn is a better place to
post questions.
Re: Inline New Class
On Saturday, 22 March 2014 at 04:35:57 UTC, Malkierian wrote:
OK, so I don't even know what it's actually called, but for
example, in Java:
exitItem.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
shell.getDisplay().dispose();
System.exit(0);
}
});
You can create a new subclass of one you want to use in a
function, with subclass function overrides such as this, but
yet I can't seem to figure out how to do this in D. The first
bracket always has a red underline telling me it's expecting a
')' (or a ';' in the case of trying to declare the listener
before using it in addSelectionListener).
That does already exists in D.
Inline New Class
OK, so I don't even know what it's actually called, but for
example, in Java:
exitItem.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
shell.getDisplay().dispose();
System.exit(0);
}
});
You can create a new subclass of one you want to use in a
function, with subclass function overrides such as this, but yet
I can't seem to figure out how to do this in D. The first
bracket always has a red underline telling me it's expecting a
')' (or a ';' in the case of trying to declare the listener
before using it in addSelectionListener).
Re: Walter's DConf 2014 Talks - Topics in Finance
On Saturday, 22 March 2014 at 00:34:22 UTC, TJB wrote: On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson wrote: On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. Thanks Dan Dan, Why a tough sell? Please explain. TJB Well, I am a fan of D. That said, there is a ton of money that goes into the HFT low latency arms race. I felt they were always willing to spend whatever it takes - but they had to make choices. First, I know for several firms there was a history the C++ vs Java back and forth until it was clear that the lowest latency systems were C/C++. The difference was attributed to many causes, but garbage collection always came up as a big one. I think just that association of C++ beating Java because of garbage collection will be enough to prevent many HFT shops from considering D for a long while, even if you could get rid of the gc entirely. Additionally, many of the advantages firms get come from dealing intelligently with the kernel and lowest level networking techniques which implies expertise in C and that often comes with a well-deserved pride in knowing how to make things run fast in specific ways. Further they are pushing even lower into custom hardware which is expensive. With the money to throw at it and the various alternatives to choose from there is a go big or go home mentality. They are not as worried about how fun it is to code in, how ugly your templates are, or how it might take longer to do something or to build something. I agree if you could get the finance industry interested in D that would be great. These are just my opinions and I left HFT a couple years back now. But, in this field, to expect a firm to get behind something like D you would need demonstrable improvements in performance irrespective of cost to develop. If they can do equivalent or better performance in C++ with more time to develop - then C++ still wins. Now if D can actually beat C++ significantly in quant programming performance things might change. Do you have ideas on how that could be done? If you consider automated, black box trading, most firms roll their own options infrastructure and these days QuantLib would not make the cut. But if you could demonstrate same functionality with improved performance by using D you could make a case. Thanks Dan
Re: Improve D's syntax to make it more python like
On Fri, Mar 21, 2014 at 06:47:28PM -0700, Andrei Alexandrescu wrote: > On 3/21/14, 5:18 PM, w0rp wrote: > >On Friday, 21 March 2014 at 21:52:47 UTC, H. S. Teoh wrote: > >>I'm disappointed about how many discussions revolve around > >>superficial things such as syntax, while neglecting weightier > >>matters such as semantics and expressiveness. > >> > >> > >>T > > > >http://www.haskell.org/haskellwiki/Wadler%27s_Law > > > >People love to debate syntax. Semantics are much more interesting and > >worth talking about. > > Well, one issue that's happening is that every so often github pull > requests that are simple but important (such as documentation) sit > there without getting due review. The regular contributors are > spending time looking into them, with takes away time from more > important issues they could work on. > > A dozen people are doing the simple work and the complicated work, > while the rest of the forum sits on the sidelines wringing hands about > what to do about the future of D. [...] Perhaps we should be talking about how more people can make github contributions instead. ;-) T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Re: Improve D's syntax to make it more python like
On 3/21/14, 5:18 PM, w0rp wrote: On Friday, 21 March 2014 at 21:52:47 UTC, H. S. Teoh wrote: I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T http://www.haskell.org/haskellwiki/Wadler%27s_Law People love to debate syntax. Semantics are much more interesting and worth talking about. Well, one issue that's happening is that every so often github pull requests that are simple but important (such as documentation) sit there without getting due review. The regular contributors are spending time looking into them, with takes away time from more important issues they could work on. A dozen people are doing the simple work and the complicated work, while the rest of the forum sits on the sidelines wringing hands about what to do about the future of D. Andrei
Re: Improve D's syntax to make it more python like
On 3/21/14, 11:47 AM, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Hey Pedro, I think some (including possibly myself) could enjoy a D dialect with Python indentation quite a bit. Given D's compilation speed, that can be achieved as a dialect without much aggravation by using a preprocessor. In fact I considered writing such a preprocessor as a running example through the chapters of TDPL, but didn't get around to it. Andrei
Re: Walter's DConf 2014 Talks - Topics in Finance
On 3/21/2014 5:39 PM, bearophile wrote: That code must always be hard-real time. So a GC is allowed only during startup time (unless it's a quite special GC), hidden heap allocations are forbidden, data access patterns need to be carefully chosen, you even have to use most of the hot part of the stack, etc. These are all very doable in D, and I've written apps that do so. The "fear of GC" is completely overblown. However, I do recognize that Phobos can be made a lot more non-GC friendly, and I am working on PR's to do that. For example, https://github.com/D-Programming-Language/phobos/pull/2014
Re: Improve D's syntax to make it more python like
On 03/22/2014 12:47 AM, Frustrated wrote: D syntax is of course less modern than that of Python: Python syntax is 1980s, D syntax is rooted in C syntax which is 1970s. It is an error to equate the quality of a programming language with the age of the base syntax: D and Python are both good programming languages, different agreed. Um, ALGOL was created in the early 60's of which python's spacing scheme is based on. =D. http://en.wikipedia.org/wiki/ALGOL#Examples_and_portability_issues Just because python came out after C does not change that. Do you think it might have been possible that Ritchie learned the lessons of ALGOL of which Rossum spat in his face? No way. Some people just never learn from history... "Python mandates a convention that programmers in ALGOL-style languages often follow." http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Indentation Yup. ALGOL-style languages such as D.
Re: Walter's DConf 2014 Talks - Topics in Finance
TJB: Why a tough sell? Please explain. That code must always be hard-real time. So a GC is allowed only during startup time (unless it's a quite special GC), hidden heap allocations are forbidden, data access patterns need to be carefully chosen, you even have to use most of the hot part of the stack, etc. Bye, bearophile
Re: Walter's DConf 2014 Talks - Topics in Finance
On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson wrote: On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. Thanks Dan Dan, Why a tough sell? Please explain. TJB
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 21:52:47 UTC, H. S. Teoh wrote: I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T http://www.haskell.org/haskellwiki/Wadler%27s_Law People love to debate syntax. Semantics are much more interesting and worth talking about.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. Thanks Dan
Re: Improve D's syntax to make it more python like
On Friday, March 21, 2014 14:51:13 H. S. Teoh wrote: > I'm disappointed about how many discussions revolve around superficial > things such as syntax, while neglecting weightier matters such as > semantics and expressiveness. I suspect that a lot of it just comes down to bikeshedding. Syntax is something that pretty much everyone can discuss, whereas semantics get a lot more complicated and require a much greater understanding. - Jonathan M Davis
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 19:23:34 UTC, Russel Winder wrote: On Fri, 2014-03-21 at 18:55 +, Frustrated wrote: […] Why not just learn the correct syntax instead of perpetuating ignorance? Python syntax is not modern. COBOL just needs to go away... D syntax is of course less modern than that of Python: Python syntax is 1980s, D syntax is rooted in C syntax which is 1970s. It is an error to equate the quality of a programming language with the age of the base syntax: D and Python are both good programming languages, different agreed. Um, ALGOL was created in the early 60's of which python's spacing scheme is based on. Just because python came out after C does not change that. Do you think it might have been possible that Ritchie learned the lessons of ALGOL of which Rossum spat in his face? Some people just never learn from history... "Python mandates a convention that programmers in ALGOL-style languages often follow." http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Indentation
Re: Improve D's syntax to make it more python like
I don't know if significant whitespace is actually "improving" the syntax. "As a simple, self-contained example, consider the representation of program structure. Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks. " Source: http://talks.golang.org/2012/splash.article -- Ziad
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote: It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading. Reading through the Wikipedia article on Computational Finance, it looks like it's basically performing simulations where some data is known but other is not. Random numbers are generated for the unknown data and the simulations are run several times to find the range of possible outcomes given the known values.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote: On 3/21/2014 2:14 PM, TJB wrote: I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading. I would be happy to help you with an option pricing example that is commonly used. Let me know if you are interested.
Re: Walter's DConf 2014 Talks - Topics in Finance
On 3/21/2014 2:14 PM, TJB wrote: I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading.
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 20:52:54 UTC, bearophile wrote: The Guest: It's already in progress: https://github.com/pplantinga/delight http://pplantinga.github.io/ Some design decision are bad, like "less" for "<", or the function definition syntax "function add(int a, b -> int):". Bye, bearophile I agree with you. They should stick to PEP-3107 style "def add(a, b: int) -> int:".
Re: Improve D's syntax to make it more python like
On Fri, Mar 21, 2014 at 05:47:03PM -0400, Jonathan M Davis wrote: > On Friday, March 21, 2014 18:47:47 Pedro Larroy wrote: > > Hi > > > > As a newcomer to D, I wonder, how difficult would be and would it > > be welcome by the D community to have D's syntax with significant > > whitespace and without brackets more like python? > > *shudder* Python is more like the antithesis of good syntax IMHO. > Sure, you could have a language with D's capabilities where the syntax > had been adjusted to be more python-like, but I don't know what the > benefit would be. Regardless, it's not like we're going to change D's > syntax at this point. That would be king of breaking changes which > wasn't worth what it cost. > > I expect that the closest you would get would be some project which > essentially created its own language and simply converted it to D when > compiling. [...] I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T -- What doesn't kill me makes me stranger.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:39:54 UTC, w0rp wrote:
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote:
Heh, right before I read this, I stumbled across this snippet
from Miguel De Icaza's blog from a couple months back, where
he regretted using C++ to build Moonlight, their Silverlight
implementation:
"But this would not be a Saturday blog post without pointing
out that Cairo's C-based API is easier and simpler to use than
many of those C++ libraries out there. The more sophisticated
the use of the C++ language to get some performance benefit,
the more unpleasant the API is to use.
The incredibly powerful Antigrain sports an insanely fast
software renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on
Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better
performance", "memory usage") and was a decision we came to
regret. Not only were the reasons wrong, it is not clear we
got any performance benefit and it is clear that we did worse
with memory usage.
But that is a story for another time."
http://tirania.org/blog/archive/2014/Jan-04.html
That is a really strange argument. Let's break it down into
stages.
1. Use C++ for better performance.
2. Find C++ library with better performance, but it's ugly.
3. Use C library in C++ instead because it's less ugly.
4. Conclude that C++ can't deliver better performance.
That is really weak. This is why the industry needs salvation
from C++ with D. It would mostly be then, "Oh it has better
performance with these template things... and it's not a pain
in the ass to use."
The removal of pain points is indeed, in my mind, the main issue.
:-)
Re: Improve D's syntax to make it more python like
On Friday, March 21, 2014 18:47:47 Pedro Larroy wrote: > Hi > > As a newcomer to D, I wonder, how difficult would be and would it > be welcome by the D community to have D's syntax with significant > whitespace and without brackets more like python? *shudder* Python is more like the antithesis of good syntax IMHO. Sure, you could have a language with D's capabilities where the syntax had been adjusted to be more python-like, but I don't know what the benefit would be. Regardless, it's not like we're going to change D's syntax at this point. That would be king of breaking changes which wasn't worth what it cost. I expect that the closest you would get would be some project which essentially created its own language and simply converted it to D when compiling. - Jonathan M Davis
Re: Walter's DConf 2014 Talks - Topics in Finance
Am 21.03.2014 22:39, schrieb w0rp:
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote:
Heh, right before I read this, I stumbled across this snippet from
Miguel De Icaza's blog from a couple months back, where he regretted
using C++ to build Moonlight, their Silverlight implementation:
"But this would not be a Saturday blog post without pointing out that
Cairo's C-based API is easier and simpler to use than many of those
C++ libraries out there. The more sophisticated the use of the C++
language to get some performance benefit, the more unpleasant the API
is to use.
The incredibly powerful Antigrain sports an insanely fast software
renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on
Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better
performance", "memory usage") and was a decision we came to regret.
Not only were the reasons wrong, it is not clear we got any
performance benefit and it is clear that we did worse with memory usage.
But that is a story for another time."
http://tirania.org/blog/archive/2014/Jan-04.html
That is a really strange argument. Let's break it down into stages.
1. Use C++ for better performance.
2. Find C++ library with better performance, but it's ugly.
3. Use C library in C++ instead because it's less ugly.
4. Conclude that C++ can't deliver better performance.
That is really weak. This is why the industry needs salvation from C++
with D. It would mostly be then, "Oh it has better performance with
these template things... and it's not a pain in the ass to use."
I would take Miguel's comments about C++ with a grain of salt.
Back when I participated in Gtkmm (early 200x), there were the
occasional C++ bashes coming from the Gtk+ guys and Miguel was never
found of C++.
--
Paulo
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote:
Heh, right before I read this, I stumbled across this snippet
from Miguel De Icaza's blog from a couple months back, where he
regretted using C++ to build Moonlight, their Silverlight
implementation:
"But this would not be a Saturday blog post without pointing
out that Cairo's C-based API is easier and simpler to use than
many of those C++ libraries out there. The more sophisticated
the use of the C++ language to get some performance benefit,
the more unpleasant the API is to use.
The incredibly powerful Antigrain sports an insanely fast
software renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on
Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better
performance", "memory usage") and was a decision we came to
regret. Not only were the reasons wrong, it is not clear we got
any performance benefit and it is clear that we did worse with
memory usage.
But that is a story for another time."
http://tirania.org/blog/archive/2014/Jan-04.html
That is a really strange argument. Let's break it down into
stages.
1. Use C++ for better performance.
2. Find C++ library with better performance, but it's ugly.
3. Use C library in C++ instead because it's less ugly.
4. Conclude that C++ can't deliver better performance.
That is really weak. This is why the industry needs salvation
from C++ with D. It would mostly be then, "Oh it has better
performance with these template things... and it's not a pain in
the ass to use."
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
Walter,
I see that you will be discussing "High Performance Code Using
D" at the 2014 DConf. This will be a very welcomed topic for
many of us. I am a Finance Professor. I currently teach and
do research in computational finance. Might I suggest that you
include some finance (say Monte Carlo options pricing)
examples? If you can get the finance industry interested in D
you might see a massive adoption of the language. Many are
desperate for an alternative to C++ in that space.
Heh, right before I read this, I stumbled across this snippet
from Miguel De Icaza's blog from a couple months back, where he
regretted using C++ to build Moonlight, their Silverlight
implementation:
"But this would not be a Saturday blog post without pointing out
that Cairo's C-based API is easier and simpler to use than many
of those C++ libraries out there. The more sophisticated the use
of the C++ language to get some performance benefit, the more
unpleasant the API is to use.
The incredibly powerful Antigrain sports an insanely fast
software renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on
Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better
performance", "memory usage") and was a decision we came to
regret. Not only were the reasons wrong, it is not clear we got
any performance benefit and it is clear that we did worse with
memory usage.
But that is a story for another time."
http://tirania.org/blog/archive/2014/Jan-04.html
Re: Improve D's syntax to make it more python like
A Python syntax wrapper around D is a fun thing. It's also suggested as a fun project to work in the D Programming Language book by Andrei. [1] If you're coming to D from Python though, I suppose my suggestion would to try and get used to the C-like syntax. If C-like syntax is unusual for you, you'll get used to it eventually. It is nice sometimes in D to be able to use braces to declare an arbitrary scope and so on, and the braces tie in pretty well with closure syntax. You'll get used to it. [1] http://books.google.co.uk/books?id=bn7GNq6fiIUC&pg=PT47&dq=d+programming+language+python&hl=en&sa=X&ei=Eq4sU-rREOOt7QaTzoCQBg&redir_esc=y#v=onepage&q=d%20programming%20language%20python&f=false
Re: Improve D's syntax to make it more python like
Whether or not white space is significant is a _very_ subjective matter. It's not a given that it's a universal improvement. D is a C language family member and that's not going to change, including it's treatment of whitespace and use of braces. On 3/21/14, 11:47 AM, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks.
Walter's DConf 2014 Talks - Topics in Finance
Walter, I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 20:43:24 UTC, Mason McGill wrote: On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? Definitely not the syntax! The promise of a relatively high level statically typed language with low level control and C/C++ levels of performance. That's what I'm looking for with D. I choke down the syntax, telling myself "at least it's better than C++". If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You're wrong about Julia. The syntax is most reminiscent of MATLAB and Octave. Others are wrong comparing Ruby/Perl/whatever to Python, at least the syntax. I find Python syntax very readable, it's the type system and semantics of Python that I dislike. Closest language to D with a Pythonesque syntax is Nimrod, nimrod-lang.org It's author, Araq, sometimes reads this forum. I believe that Haskell is the most popular statically typed language with indentation sensitive syntax. But Haskell is a lazy functional language where programming with side effects is more difficult. That's not like D. I doubt there's much interest in a new syntax for D. You may as well find or create a different language if it bothers you. I empathize, but I'm certain you'd be better off just getting used to the existing D syntax.
Re: Improve D's syntax to make it more python like
The Guest: It's already in progress: https://github.com/pplantinga/delight http://pplantinga.github.io/ Some design decision are bad, like "less" for "<", or the function definition syntax "function add(int a, b -> int):". Bye, bearophile
Re: Improve D's syntax to make it more python like
Am 21.03.2014 21:43, schrieb Mason McGill: On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You might also be interested in Dylan (https://opendylan.org/), though I don't know much about it. Dylan could have been a great language. A lisp for systems programming with algol syntax. Developed at Apple, originally targeted at the Newton. Since it was newly released as open source it has got some followers, but I am not sure if it will ever manage to get out of "could have been great" status. -- Paulo
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You might also be interested in Dylan (https://opendylan.org/), though I don't know much about it.
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. I don't think it's so difficult but it will increase a lot of code. Also, I don't believe the community will like something this. I'm not sure how accepted is python to most of this C/C++ guys. I personally don't like python/ruby/perl syntax.
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:51:46 UTC, bearophile wrote: Pedro Larroy: As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? You have to revive this project to port it to D2: http://delight.sourceforge.net/ Bye, bearophile It's already in progress: https://github.com/pplantinga/delight http://pplantinga.github.io/
Re: [Proposal] Add module for C-strings support in Phobos
You could also write: alias toStringz z; auto foo = "bar".z; and that would work too!
Re: [Proposal] Add module for C-strings support in Phobos
On Friday, 21 March 2014 at 19:59:51 UTC, angel wrote:
Going slightly beyond a new module code, it might, possibly, be
useful to enable zero-terminated string creation on the core
language level, with:
auto mystr = "hello"z;
The core language already knows zero-terminated strings:
void main() {
immutable(char)* s = "lol";
}
Regular 8-bit strings implicitly convert to pointers without
needing to explicitly call the .ptr property and they are always
zero terminated automatically.
This is why you can write printf("foo"); in D and have it just
work without complaining about needing toStringz.
You can also write:
const char* s = "lol";
and that works too. Not quite auto, but not a big hassle.
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 19:19:06 UTC, Walter Bright wrote:
Here's a litmus test you can use for purity. Consider:
int foo() pure;
{
auto a = foo();
}
Now, since 'a' is never used, we can delete the assignment, and
since foo is pure, we can delete foo():
{
}
Is this program distinguishable from the former? If not, then
foo() is not pure.
Consider this:
int foo(int* pa) pure
{
if (pa)
{
*pa = foo();
}
}
This is also pure according to D's type system, but it fails your
litmus test. This, however, passes:
int foo(immutable(int)* pa) pure
{
pa = pfoo();
}
I think the case of a monitor is closer to the first example.
Re: Ehem, ARM
On Saturday, 28 December 2013 at 22:21:46 UTC, Joakim wrote: I finished porting most of druntime to Android/x86 and have started trying to run the tests: I just got 31 out of 38 druntime modules' unit tests to pass. :) I figured out the segfault mentioned above was because TLS is done differently on Android- flags[] is a global when outside main and thread-local by default as a result, adding a shared attribute makes it work again- and I was getting a lot of segfaults on the unit tests for the same reason. After making all the simple globals in the unit tests, like cpuid in rt.arrayfloat/int/etc., into shared variables, only 8 modules' unittests segfault, one after passing. Bionic doesn't support __thread for TLS, but it does let you use the pthread_key_(create|delete)/pthread_(set|get)specific APIs, just as druntime does on OS X. Here's the bionic implementation: https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp I haven't completely grasped TLS and how it's done on OS X yet, but I get the sense I'll have to modify dmd a little to get TLS working with bionic. It appears that Martin and Johannes have looked into this before, so if you two have any feedback, let me know. I'm hoping TLS is the last remaining piece for druntime to be finished porting to Android/x86, then I want to try Phobos, which I'm guessing shouldn't be as bad. Been awhile since I updated on the Android effort: I'm now able to get all 38 druntime modules' unit tests to pass on Android/x86... under somewhat random conditions. It's finicky and some of the tests start failing and many segfaulting on exit, as mentioned before, if I make minor changes to the unit tests, like changing some TLS globals to shared. I'm guessing this is because I don't really have TLS working yet, I'm just taking advantage of the fact that the baked-in TLS in linux kinda sorta still works on Android. As long as it's local-exec, uninitialized TLS mostly works if it's less than 4-5 KB, while initialized TLS doesn't get initialized correctly. Of course, it's possible that I'm hitting some other codegen incompatibility altogether, unrelated to TLS, but the fact that it sometimes works depending on the number of TLS variables makes me think it's a TLS issue. I also got a bit more than half of the Phobos unit tests to pass, with a lot of seg faults there too. Android is going to need a packed TLS approach, similar to what Walter implemented for OS X with dmd: http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185 I've been looking into doing something similar for ELF, but this is the first time hacking on a compiler for me. If someone else more familiar with dmd or ldc could put packed TLS for ELF together more quickly, that would certainly speed things up. If not, I'll have something together eventually. ;)
Re: [Proposal] Add module for C-strings support in Phobos
Going slightly beyond a new module code, it might, possibly, be useful to enable zero-terminated string creation on the core language level, with: auto mystr = "hello"z; The 'z' in the end is much the same as 'L' in a '5L' ...
Re: Handling invalid UTF sequences
On 3/21/2014 10:14 AM, Dmitry Olshansky wrote: 21-Mar-2014 02:39, Walter Bright пишет: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) If we talk decoding then only dchar is relevant. If transcoding then, having 0xFF makes for broken UTF-8 encoding so I see no sense in going for it. 2. U+FFFD Also has the benefit of being recommended by the standard specifically for the case of substitution for bad encoding. Details: https://d.puremagic.com/issues/show_bug.cgi?id=12113 Ah, that's what I was looking for. The wikipedia article was a bit wishy-washy about the whole thing. I kinda like option 1. Not enough of an argument ;)
Re: Improve D's syntax to make it more python like
On Fri, 2014-03-21 at 19:13 +, Adam D. Ruppe wrote: […] > But I'm totally against it, Python has hideous syntax. I would leave D syntax as it is. Python syntax is not hideous, it is good; very Pythonic, unlike D. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Improve D's syntax to make it more python like
On Fri, 2014-03-21 at 18:55 +, Frustrated wrote: […] > Why not just learn the correct syntax instead of perpetuating > ignorance? Python syntax is not modern. COBOL just needs to go > away... D syntax is of course less modern than that of Python: Python syntax is 1980s, D syntax is rooted in C syntax which is 1970s. It is an error to equate the quality of a programming language with the age of the base syntax: D and Python are both good programming languages, different agreed. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 11:23 AM, Steven Schveighoffer wrote:
On Fri, 21 Mar 2014 14:18:05 -0400, Walter Bright
wrote:
On 3/21/2014 12:59 AM, monarch_dodra wrote:
Ok. That's a fair point. So in that case, our function is pointing at "data",
and is allowed to mutate it, and observe its state.
Now, if *another* piece of code is doing the same thing at the same time
(potentially mutating "data", does that still violate purity?
A mutex essentially reads and writes a global flag, which other functions can
also read and write.
That makes it NOT pure.
No, that's not the case. A mutex does not write a global flag, it writes a
shared flag. And the flag is passed into it.
Here's a litmus test you can use for purity. Consider:
int foo() pure;
{
auto a = foo();
}
Now, since 'a' is never used, we can delete the assignment, and since foo is
pure, we can delete foo():
{
}
Is this program distinguishable from the former? If not, then foo() is not pure.
Re: Handling invalid UTF sequences
On Thursday, March 20, 2014 15:39:50 Walter Bright wrote: > Currently we do it by throwing a UTFException. This has problems: > > 1. about anything that deals with UTF cannot be made nothrow > > 2. turns innocuous errors into major problems, such as DOS attack vectors > http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences > > One option to fix this is to treat invalid sequences as: > > 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) > > 2. U+FFFD > > I kinda like option 1. > > What do you think? After a discussion on this a few weeks back (where I was in favor of the current behavior when the discussion started), I'm now completely in favor of making it so that std.utf.decode simply replaces invalid code points with U+FFFD per the standard. Most code won't care and will continue to work as before. The main difference is that invalid Unicode would then fall in the same category as when a program is given a string with characters that it's not supposed to be given. Any code that checks for that sort of thing will then treat invalid Unicode as it would have treated other invalid strings, and code that doesn't care will continue to not care except that now it will work with invalid Unicode instead of throwing. A prime example is something like find. What does it care if it's given invalid Unicode? It will simply look for what you tell it to look for, and if it's not there, it won't find it. U+FFFD will just be one more character that doesn't match what it's looking for. The few programs that really care about whether a string that they're given contains any invalid Unicode can simply validate the string ahead of time. The main problem there is that we need to replace std.utf.validate with something like std.utf.isValidUnicode, because validate makes the horrendous decision of throwing rather than returning a bool (which is what triggered the previous discussion on the topic IIRC). There may be some concern about this change silently changing behavior, but I think that the reality is that the vast majority of programs will continue to work just fine, and our string processing code will be that much cleaner and faster as a result. So, I'm very much inclined to take the path of making this change and putting a warning about it in the changelog rather than not making the change or trying to do this alongside what we currently have. - Jonathan M Davis
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? I don't think it would be really hard to do in the compiler, you could probably make it work by hacking up the lexer. But I'm totally against it, Python has hideous syntax.
Re: Improve D's syntax to make it more python like
Pedro Larroy: As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? You have to revive this project to port it to D2: http://delight.sourceforge.net/ Bye, bearophile
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. Why not just learn the correct syntax instead of perpetuating ignorance? Python syntax is not modern. COBOL just needs to go away...
Re: Improve D's syntax to make it more python like
On 03/21/2014 07:47 PM, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. http://delight.sourceforge.net/
Improve D's syntax to make it more python like
Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks.
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 11:03:01 UTC, monarch_dodra wrote:
//
foreach ( a ;
chain(iota(0, N), only(N), iota(0, N).retro) )
{
writeln(' '.repeat(N - a), '*'.repeat(a*2+1)))
}
//
I don't think it's so complicated. It's just taking this.
someRange.mungeItHowever.each!useIt;
Instead of writing this.
foreach(someThing; someRange.mungeItHowever) someThing.useIt;
Maybe it's like the difference between writing foo(bar) and
bar.foo. It can just look a little nicer.
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 9:28 AM, Sean Kelly wrote:
On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote:
On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
How do they affect global state?
Mutexes implicitly share state. It's the reason they exist. They can't be
pure, because pure functions don't share state.
Locking a monitor is also a mutating operation and yet I believe you can have
const synchronized methods. They live somewhat outside the normal type system.
I don't see any point in having pure class methods, but what about:
pure int add(T)(const(T) a, const(T) b) {
return a + b;
}
Where the variables above are instances of a synchronized class? The operation
would implicitly lock their monitors to perform the addition.
Yes, I think the pairing of lock/unlock of a mutex can be pure, but just a lock
or just an unlock cannot be.
Re: Most basic nothrow, pure, @safe functions?
On Fri, 21 Mar 2014 14:18:05 -0400, Walter Bright wrote: On 3/21/2014 12:59 AM, monarch_dodra wrote: Ok. That's a fair point. So in that case, our function is pointing at "data", and is allowed to mutate it, and observe its state. Now, if *another* piece of code is doing the same thing at the same time (potentially mutating "data", does that still violate purity? A mutex essentially reads and writes a global flag, which other functions can also read and write. That makes it NOT pure. No, that's not the case. A mutex does not write a global flag, it writes a shared flag. And the flag is passed into it. I still think straight locking and unlocking of mutexes should be pure, because of the exclusive nature of the data protected by them. -Steve
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 12:59 AM, monarch_dodra wrote: Ok. That's a fair point. So in that case, our function is pointing at "data", and is allowed to mutate it, and observe its state. Now, if *another* piece of code is doing the same thing at the same time (potentially mutating "data", does that still violate purity? A mutex essentially reads and writes a global flag, which other functions can also read and write. That makes it NOT pure.
Re: Handling invalid UTF sequences
21-Mar-2014 02:39, Walter Bright пишет: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) If we talk decoding then only dchar is relevant. If transcoding then, having 0xFF makes for broken UTF-8 encoding so I see no sense in going for it. 2. U+FFFD Also has the benefit of being recommended by the standard specifically for the case of substitution for bad encoding. Details: https://d.puremagic.com/issues/show_bug.cgi?id=12113 I kinda like option 1. Not enough of an argument ;) -- Dmitry Olshansky
Re: DDT in Eclipse
On Thursday, 20 March 2014 at 12:14:09 UTC, Russel Winder wrote: I am finding that I have to remove DDT from Eclipse in order to get the latest CDT. Is this to be expected? Thanks. I had to do the same. It has something to do with the required version for the GDB plugin. I ended up just keeping two separate installations of eclipse (one for CDT and everything else, and one for DDT). This seems a little wasteful, but it's not that uncommon (NSight Eclipse for CUDA and Octclipse for Octave are two examples of other eclipse-mods that work in a standalone copy of Eclipse)
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 12:29:31 UTC, bearophile wrote:
So before taking any decision on the matter, more experiments
and usage examples are necessary, where you have longer chains.
If you have a longer chain:
items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum
.each(...);
using a each() allows you to keep a nice column. If you use
foreach your formatting and your logic has a hiccup, because
you are mixing two different styles:
foreach (item; items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum) {
// Do something imperative here.
}
But this is not a real example (it computes the entropy of
items, and you usually don't need an each there), so more usage
examples are needed. Taking a look at real world usages of
foreach() in Scala could be useful.
The former example doesn't become functional just because you
managed to use UFCS, it's just imperative code deceptively
disguised as functional code. The clear separation in the latter
example is a *good thing*.
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote:
On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
How do they affect global state?
Mutexes implicitly share state. It's the reason they exist.
They can't be pure, because pure functions don't share state.
Locking a monitor is also a mutating operation and yet I believe
you can have const synchronized methods. They live somewhat
outside the normal type system. I don't see any point in having
pure class methods, but what about:
pure int add(T)(const(T) a, const(T) b) {
return a + b;
}
Where the variables above are instances of a synchronized class?
The operation would implicitly lock their monitors to perform the
addition.
Re: Ruby-style "each" in D?
On 3/21/14, 4:02 AM, monarch_dodra wrote: So I toyed around a little. I played with mostly tee/tap and each. The first observation is that both can help make a "2D" ufcs chain, which is pretty nice. It makes more sense (IMO) to code it that way, than to use awkward "join", to concatenate the "2D" range into a continuous "1D" range, eg: join(lines, "\n"); First: "tee". Nice work! This convinced me that tee should call the lambda only upon the first call to .front on each iteration. Andrei
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 13:27:04 UTC, Vladimir Panteleev wrote: On Friday, 21 March 2014 at 13:24:50 UTC, Dicebot wrote: On Friday, 21 March 2014 at 12:55:09 UTC, Jacob Carlborg wrote: What's the purpose of "tee", is it the same as "tap"? "tap" in Ruby just returns the receiver after executing a block. This would be the implementation in D: Yeah "tee" is a horrible name, no chance I would have guess what it means just by the name. "tap" is much better. I think it's meant to mimic the UNIX command with the same name? If you know about the command, the function's purpose seems obvious. ...and has pretty much nothing in common with it! Also I don't see "requires UNIX familiarity to be used intuitively" warning in Phobos docs. Actually for similar reasons "tap" is also inferior to "each".
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 13:24:50 UTC, Dicebot wrote: On Friday, 21 March 2014 at 12:55:09 UTC, Jacob Carlborg wrote: What's the purpose of "tee", is it the same as "tap"? "tap" in Ruby just returns the receiver after executing a block. This would be the implementation in D: Yeah "tee" is a horrible name, no chance I would have guess what it means just by the name. "tap" is much better. I think it's meant to mimic the UNIX command with the same name? If you know about the command, the function's purpose seems obvious.
Re: Ruby-style "each" in D?
Vladimir Panteleev: Dicebot: Yeah "tee" is a horrible name, no chance I would have guess what it means just by the name. "tap" is much better. I think it's meant to mimic the UNIX command with the same name? If you know about the command, the function's purpose seems obvious. See also the Python function tee(): http://docs.python.org/2/library/itertools.html#itertools.tee Bye, bearophile
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 12:55:09 UTC, Jacob Carlborg wrote: What's the purpose of "tee", is it the same as "tap"? "tap" in Ruby just returns the receiver after executing a block. This would be the implementation in D: Yeah "tee" is a horrible name, no chance I would have guess what it means just by the name. "tap" is much better.
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 11:03:01 UTC, monarch_dodra wrote:
each "tee" triggers on the call to `popFront`. It does its job
(calls pred(r.front)), and then push the "pop down the chain.
What this means is that my "tee's" are actually executed right
to left! Talk about counter intuitive.
What's the purpose of "tee", is it the same as "tap"? "tap" in
Ruby just returns the receiver after executing a block. This
would be the implementation in D:
T tap (alias block, T) (T t)
{
block(t);
return t;
}
--
/Jacob Carlborg
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 00:42:00 UTC, Walter Bright wrote: Right on. I'm using Ruby every day. I don't really see much point in having "each" in D. We already have "foreach". Ruby uses "each" since it doesn't have "foreach". It to have a "for", which is a form of foreach, but that is just lowered to "each" anyway. Also, I don't see a point in having "each" which is lazy. -- /Jacob Carlborg
Re: Ruby-style "each" in D?
monarch_dodra:
chain(iota(0, N), only(N), iota(0, N).retro)
.each!(
(a) => writeln(' '.repeat(N - a), '*'.repeat(a*2+1))
)();
//
Something like this seems better (untested):
chain(N.iota, N.only, N.iota.retro)
.each!(a => '*'.replicate(a * 2 + 1).center(N).writeln);
I think this is a fair assesment of how "each" would be used?
This UFCS chain is just 2 lines long, it's not the best usage
example of each().
I'm not really sold on "each".
...
As for "tee": I'm convinced I didn't use it for its intended
function, but I think it shows its function can easily be
hijacked to do things it wasn't meant for.
You have used tee for something you think it's not very well
designed, and you have given only one usage example of each(),
and it's not the most common example.
So before taking any decision on the matter, more experiments and
usage examples are necessary, where you have longer chains. If
you have a longer chain:
items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum
.each(...);
using a each() allows you to keep a nice column. If you use
foreach your formatting and your logic has a hiccup, because you
are mixing two different styles:
foreach (item; items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum) {
// Do something imperative here.
}
But this is not a real example (it computes the entropy of items,
and you usually don't need an each there), so more usage examples
are needed. Taking a look at real world usages of foreach() in
Scala could be useful.
I think it'll be abused by those that want a "1-liner" at all
cost, leading to an image that "D is nothing but horrible 1
liners!", all that without providing any real functionality.
I think each() is meant for longer chains as you see in F#
languages.
Some possible usage examples for each():
import std.stdio, std.algorithm, std.string, std.exception,
std.file;
void main() {
string[][ubyte[]] an;
foreach (w; "unixdict.txt".readText.splitLines)
an[w.dup.representation.sort().release.assumeUnique] ~= w;
immutable m = an.byValue.map!q{ a.length }.reduce!max;
writefln("%(%s\n%)", an.byValue.filter!(ws => ws.length ==
m));
}
auto mode(T)(T[] items) pure nothrow {
int[T] aa;
foreach (item; items)
aa[item]++;
immutable m = aa.byValue.reduce!max;
return aa.byKey.filter!(k => aa[k] == m);
}
double equalBirthdays(in uint nSharers, in uint groupSize,
in uint nRepetitions, ref Xorshift rng) {
uint eq = 0;
foreach (immutable j; 0 .. nRepetitions) {
uint[365] group;
foreach (immutable i; 0 .. groupSize)
group[uniform(0, $, rng)]++;
eq += group[].any!(c => c >= nSharers);
}
return (eq * 100.0) / nRepetitions;
}
Bye,
bearophile
Re: Cannot cast X to Y at compile time...?
On 03/21/2014 06:12 AM, Kapps wrote:
On Thursday, 20 March 2014 at 21:32:08 UTC, dnspies wrote:
Sorry, I don't understand. When I cast something to the wrong
type, I should just get a null reference, shouldn't I? It
shouldn't throw an error.
If the compiler can statically determine that the cast is invalid you
get an error instead.
No.
class C{}
class D{}
void main(){
C c=new C;
D d=cast(D)c; // no error
assert(c !is null);
assert(d is null);
}
(In any case, his problem is that the cast fails in CTFE.)
You can use something like 'static if(is(T :
Foo))' to test at compile-time if T is implicitly convertible to Foo
(I'm not certain the exact semantics) or 'static
if(is(typeof(cast(Foo)T.init)))'.
There's probably better ways to do it, and I recommend asking on D.learn
to figure out how to do what you're looking for.
I guess it might be a compiler bug, but it is hard to tell lacking a
complete example.
Re: Ruby-style "each" in D?
On Friday, 21 March 2014 at 00:42:00 UTC, Walter Bright wrote:
On 3/20/2014 5:33 PM, bearophile wrote:
As I explained in a precedent post in this thread it's hard to
design something
if you don't try to use it, even something simple as a each().
Right on.
So I toyed around a little. I played with mostly tee/tap and
each. The first observation is that both can help make a "2D"
ufcs chain, which is pretty nice. It makes more sense (IMO) to
code it that way, than to use awkward "join", to concatenate the
"2D" range into a continuous "1D" range, eg: join(lines, "\n");
First: "tee".
I wanted to try to experience the "multiple tees" approach. I
made the code purposefully verbose, so as to better test it.
Because I wanted to process each item once, and only once, I used
the default policy of `Yes.pipeOnPop`. I did some tests with both
"tee!pred" and "tee(range, output)", but they were functionally
equivalent. Anyways, here was my first iteration:
//
size_t N = 5;
chain(iota(0, N), only(N), iota(0, N).retro) //0 .. N .. 0
.tee!((a)=>' '.repeat(N - a).write())() //leading spaces
.tee!((a)=>'*'.repeat(a).write())() //first half of
stars
.tee!((a)=>'*'.write())()//middle star
.tee!((a)=>'*'.repeat(a).write())() //second half
.tee!((a)=>writeln())() //linefeed
.reduce!"0"(0); //or consume/walk
//
Surprise! It's wrong!
each "tee" triggers on the call to `popFront`. It does its job
(calls pred(r.front)), and then push the "pop down the chain.
What this means is that my "tee's" are actually executed right to
left! Talk about counter intuitive.
So *this* is correct:
//
size_t N = 5;
chain(iota(0, N), only(N), iota(0, N).retro) //0 .. N .. 0
.tee!((a)=>writeln())() //linefeed
.tee!((a)=>'*'.repeat(a).write())() //second half
.tee!((a)=>'*'.write())()//middle star
.tee!((a)=>'*'.repeat(a).write())() //first half of
stars
.tee!((a)=>' '.repeat(N - a).write())() //leading spaces
.reduce!"0"(0); //or
consume/walk/each()
//
Odd!
Second:
Each tee pipes a call to front, and *then* calls front again when
popped. Effectively, if you have *N* tee's in your range, you'll
call "fun" roughly N*N/2 times. Not great.
This might be an unfair assesment of "tee", because I over-used
it on purpose, but I think it *does* show that it's not scaling
well, and that it is triggering in a confusing order.
Also:
//
size_t N = 5;
foreach ( a ; chain(iota(0, N), only(N), iota(0, N).retro))
{
' '.repeat(N - a).write();
'*'.repeat(a).write();
'*'.write();
'*'.repeat(a).write();
writeln();
}
//
Just saying. Why would I use "tee" when I have that?
But I think I'm using "tee" wrong: The idea is to "hook" it into
a chain that actually does something. It shouldn't be the main
"doer".
-
What about each?
I wrote this:
//
chain(iota(0, N), only(N), iota(0, N).retro)
.each!(
(a) => writeln(' '.repeat(N - a), '*'.repeat(a*2+1))
)();
//
I think this is a fair assesment of how "each" would be used? It
looks nice, and is relatively short. But then I wrote this:
//
foreach ( a ;
chain(iota(0, N), only(N), iota(0, N).retro) )
{
writeln(' '.repeat(N - a), '*'.repeat(a*2+1)))
}
//
Hum... you still get the same functional initial declaration, but
the "foreach" doesn't get in the way, while still keeping a clear
functional/imperative distinction.
--
Si that's my initial assessment.
I'm not really sold on "each". I think it'll be abused by those
that want a "1-liner" at all cost, leading to an image that "D is
nothing but horrible 1 liners!", all that without providing any
real functionality.
As for "tee": I'm convinced I didn't use it for its intended
function, but I think it shows its function can easily be
hijacked to do things it wasn't meant for.
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 10:03:20 UTC, Steve Teale wrote:
OK, so what happens that's different when I pull in
std.typetuple at the point where I need it? Does that avoid
pulling in all the other stuff?
The difference is whether or not the import gets executed at all.
For *you*, it doesn't make much difference where you do your
import, it only impacts the people that are *importing you*.
A trivial example is this:
//
module someModule;
void foo(T)(T t)
{
import someOtherModule1;
}
void bar(T)(T t)
{
import someOtherModule2;
}
//
Now imagine you need to use someModule.foo. You don't need
"someOtherModule2", since that's only needed by baz. So this
approach means you don't import it. someOtherModule1.
//
If the functions are not template, or in end user code, it
doesn't change much where you do the imports, since they'll
happen anyways. The only difference is which symbols are visible
where.
How does this problem manifest itself - code bloat, or slower
compilations, or what?
I can't answer that personally. I just know there was a pretty
big push from the dmd guys to cleanup the phobos code. I don't
know what the actual impacts are.
Re: Handling invalid UTF sequences
21.03.2014 12:25, monarch_dodra пишет:
On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote:
I'm a fan of this approach but Timon pointed out when I wrote about it
once that it's rather trivial to get an invalid string through slicing
mid-code point so now I'm not so sure.
It's just as easy to slice mid-codepoint as it is to access a range out
of bounds. In both cases, it's a programming error.
The only excuse I see for throwing an exception for slicing
mid-codepoint, is that
1. programmers are less aware of the issue, so it's more forgiving in a
released program (nobody likes a crash).
2. arguably, it's not the *program* state that's bad. It's the *data*.
Well, in regards to "2", you could argue that program state and data
state is one and the same.
I think I'm still in favor of it because you've obviously got a logic
error if that happens so your program isn't correct anyway (it's not a
matter of bad user input).
If I remember correctly, with a specially written UTF string, it *was*
possible to corrupt program state. I think. I need to double check. I
didn't give it much thought then ("it should virtually never happen"),
but it could be used as deliberate security vulnerability.
Almost nothing to add here. We already have `-noboundscheck` which can
dramatically increase performance, throwing `UTFError` should either use
same mechanics (`-noutfcheck`?) or just be stripped in release.
Personally I'd choose the latter as there are lots of (sometimes very
slow) assertions stripped with `-release` in real programs, which
indicates same critical data corruption.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 08:05:09 UTC, monarch_dodra wrote: On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote: Can someone tell me where this is written up? Thanks Steve You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a "as needed" basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as "dumb" as TypeTuple: => need std.typetuple => pulls traits => pulls typecons and algorithm => pulls array, string, uni, ascii, utf, conv => pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to "pollute" your namespace with imported symbols. OK, so what happens that's different when I pull in std.typetuple at the point where I need it? Does that avoid pulling in all the other stuff? How does this problem manifest itself - code bloat, or slower compilations, or what? Thanks Steve
Re: Handling invalid UTF sequences
On Thu, 20 Mar 2014 22:39:50 -, Walter Bright wrote: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) 2. U+FFFD I kinda like option 1. What do you think? In window/Win32.. WideCharToMultiByte has flags for a bunch of similar behaviours and allows you to define a default char to use as a replacement in such cases. swprintf when passed %S will convert a wchar_t UTF-16 argument into ascii, and replaces invalid characters with ? as it does so. swprintf_s (the safe version), IIRC, will invoke the invalid parameter handler for sequences which cannot be converted. I think, ideally, we want some sensible default behaviour but also the ability to alter it globally, and even better in specific calls where it makes sense to do so (where flags/arguments can be passed to that effect). So, the default behaviour could be to throw (therefore no breaking change) and we provide a function to change this to one of the other options, and another to select a replacement character (which would default to .init or U+FFFD). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Handling invalid UTF sequences
On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote:
I'm a fan of this approach but Timon pointed out when I wrote
about it once that it's rather trivial to get an invalid string
through slicing mid-code point so now I'm not so sure.
It's just as easy to slice mid-codepoint as it is to access a
range out of bounds. In both cases, it's a programming error.
The only excuse I see for throwing an exception for slicing
mid-codepoint, is that
1. programmers are less aware of the issue, so it's more
forgiving in a released program (nobody likes a crash).
2. arguably, it's not the *program* state that's bad. It's the
*data*.
Well, in regards to "2", you could argue that program state and
data state is one and the same.
I think I'm still in favor of it because you've obviously got a
logic error if that happens so your program isn't correct
anyway (it's not a matter of bad user input).
If I remember correctly, with a specially written UTF string, it
*was* possible to corrupt program state. I think. I need to
double check. I didn't give it much thought then ("it should
virtually never happen"), but it could be used as deliberate
security vulnerability.
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote: Can someone tell me where this is written up? Thanks Steve You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a "as needed" basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as "dumb" as TypeTuple: => need std.typetuple => pulls traits => pulls typecons and algorithm => pulls array, string, uni, ascii, utf, conv => pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to "pollute" your namespace with imported symbols.
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 07:14:47 UTC, Walter Bright wrote: On 3/21/2014 12:03 AM, monarch_dodra wrote: On Friday, 21 March 2014 at 03:04:36 UTC, Steven Schveighoffer wrote: Thinking about it some more, I see what you mean -- an unshared mutex is useless. But at the same time, some "logically" pure functions cannot be so without mutexes. E.g. memory allocation. Since when does "shared" => "impure" ? If the function takes a pointer to shared data, then you are explicitly saying "this function depends on this shared data". But as long is it isn't referencing some *other* global directly, it is perfectly pure. We've been using 'shared' here to mean shared with another piece of code that looks at the state, not 'shared' as in data shared amongst multiple threads. Ok. That's a fair point. So in that case, our function is pointing at "data", and is allowed to mutate it, and observe its state. Now, if *another* piece of code is doing the same thing at the same time (potentially mutating "data", does that still violate purity? As long a the function doesn't access/mutate something via direct global state, it's pure, isn't it? I think... it's tough to wrap your head around the issue.
New guideline to place import statements as locally as possible
Can someone tell me where this is written up? Thanks Steve
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 12:03 AM, monarch_dodra wrote: On Friday, 21 March 2014 at 03:04:36 UTC, Steven Schveighoffer wrote: Thinking about it some more, I see what you mean -- an unshared mutex is useless. But at the same time, some "logically" pure functions cannot be so without mutexes. E.g. memory allocation. Since when does "shared" => "impure" ? If the function takes a pointer to shared data, then you are explicitly saying "this function depends on this shared data". But as long is it isn't referencing some *other* global directly, it is perfectly pure. We've been using 'shared' here to mean shared with another piece of code that looks at the state, not 'shared' as in data shared amongst multiple threads.
Re: Most basic nothrow, pure, @safe functions?
On 3/20/2014 7:02 PM, deadalnix wrote: On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote: Mutexes implicitly share state. It's the reason they exist. They can't be pure, because pure functions don't share state. If you got that road, you can't allow memory allocators to be used in pure code. That isn't a good argument. The analogy doesn't apply. Operator new is regarded as supplying memory from an infinite reservoir. There is no implicit global state. The whole point of a mutex is to change state and share it. It's utterly different.
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 03:04:36 UTC, Steven Schveighoffer
wrote:
Thinking about it some more, I see what you mean -- an unshared
mutex is useless.
But at the same time, some "logically" pure functions cannot be
so without mutexes. E.g. memory allocation.
Since when does "shared" => "impure" ?
If the function takes a pointer to shared data, then you are
explicitly saying "this function depends on this shared data".
But as long is it isn't referencing some *other* global directly,
it is perfectly pure.
For example:
//
int i = 5;
void foo(int* p) pure
{++p;}
void main() pure
{
foo(&p);
}
//
This is "textbook" of a pure function changing global state.
So the way I see it: shared => pinter to mutex => touching it is
fair game => can be legit pure (IMO).
