Re: Program logic bugs vs input/environmental errors
On 28.9.2014. 1:15, Walter Bright wrote: This issue comes up over and over, in various guises. I feel like Yosemite Sam here: https://www.youtube.com/watch?v=hBhlQgvHmQ0 In that vein, Exceptions are for either being able to recover from input/environmental errors, or report them to the user of the application. When I say They are NOT for debugging programs, I mean they are NOT for debugging programs. assert()s and contracts are for debugging programs. After all, what would you think of a compiler that spewed out messages like this: dmd test.d test.d(15) Error: missing } thrown from dmd/src/parse.c(283) ? See: https://issues.dlang.org/show_bug.cgi?id=13543 As for the programmer wanting to know where the message missing } came from, li grep -r dmd/src/*.c missing } works nicely. I do that sort of thing all the time. It really isn't a problem. We has this issue at work (we are working with php). We outputted a stack trace for both exceptions and asserts but the lines that should be addressed are not always so obvious. I found a solution and it works great for us. All library code is marked appropriately so when stack is outputted it is shadows out (with gray color) all the lines in library code and point out first non-library line from the top of the stack. In 95% of the time it is the line that the programmer should look into. Other 5% is the time when it shows the line where programmer is forwarding a call to the library but turns out to be ok as it turns out to be much more comprehensible than the entire stack. One note worth mentioning is that juniors have much easier time understanding which lines concern them, and from that I can only conclude that such approach is more intuitive. Marking is done on namespace level so it can be easily disabled for entire namespace. I think outputting a stack trace for asserts is a must because of that 5%. And for exceptions I agree completely with your arguments and I think that there is no need for stack. From my experience this has been a good approach and I think is worth considering.
Re: Program logic bugs vs input/environmental errors
On 28.9.2014. 21:32, Walter Bright wrote: On 9/28/2014 11:25 AM, bearophile wrote: Exceptions are often used to help debugging... https://www.youtube.com/watch?v=hBhlQgvHmQ0 Example exception messages: Unable to connect to database Invalid argument count Invalid network package format All this messages do not require a stack trace as they do not require code fixes, they indicate an issue outside the program itself. If stack trace is required then assert should have been used instead. Or to better put it: can anyone give an example of exception that would require stack trace?
Re: RFC: reference counted Throwable
On 21.9.2014. 22:57, Peter Alexander wrote: On Sunday, 21 September 2014 at 19:36:01 UTC, Nordlöw wrote: On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote: Please chime in with thoughts. Why don't we all focus our efforts on upgrading the current GC to a state-of-the GC making use of D's strongly typed memory model before discussing these things? GC improvements are critical, but... As discussed, having exception objects being GC-allocated is clearly a large liability that we need to address. They prevent otherwise careful functions from being @nogc so they affect even apps that otherwise would be okay with a little litter here and there. No improvements to the GC can fix this. @nogc needs to be usable, whether you are a GC fan or not. I think that what is being suggested is that upgrading GC would widespread the point of view on what can and should be done. For example, now that ranges and mixins exist great ideas comes to mind, and without them we can only guess. I think that GC is in the same position.
Re: Memory allocation purity
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote: On Thu, 15 May 2014 05:51:14 + via Digitalmars-d digitalmars-d@puremagic.com wrote: Yep, purity implies memoing. No, it doesn't. _All_ that it means when a function is pure is that it cannot access global or static variables unless they can't be changed after being initialized (e.g. they're immutable, or they're const value types), and it can't call any other functions which aren't pure. It means _nothing_ else. And it _definitely_ has nothing to do with functional purity. Now, combined with other information, you _can_ get functional purity out it - e.g. if all the parameters to a function are immutable, then it _is_ functionally pure, and optimizations requiring functional purity can be done with that function. But by itself, pure means nothing of the sort. So, no, purity does _not_ imply memoization. - Jonathan M Davis Um. Yes it does. http://dlang.org/function.html#pure-functions functional purity (i.e. the guarantee that the function will always return the same result for the same arguments) The fact that it should not be able to effect or be effected by the global state is not a basis for purity, but rather a consequence. Even other sources are consistent on this matter, and this is what purity by definition is.
Re: Memory allocation purity
On 15.5.2014. 11:35, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 10:14:48 +0200
luka8088 via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yep, purity implies memoing.
No, it doesn't. _All_ that it means when a function is pure is that
it cannot access global or static variables unless they can't be
changed after being initialized (e.g. they're immutable, or they're
const value types), and it can't call any other functions which
aren't pure. It means _nothing_ else. And it _definitely_ has
nothing to do with functional purity.
Now, combined with other information, you _can_ get functional
purity out it - e.g. if all the parameters to a function are
immutable, then it _is_ functionally pure, and optimizations
requiring functional purity can be done with that function. But by
itself, pure means nothing of the sort.
So, no, purity does _not_ imply memoization.
- Jonathan M Davis
Um. Yes it does. http://dlang.org/function.html#pure-functions
functional purity (i.e. the guarantee that the function will always
return the same result for the same arguments)
The fact that it should not be able to effect or be effected by the
global state is not a basis for purity, but rather a consequence.
Even other sources are consistent on this matter, and this is what
purity by definition is.
The reread the paragraph at the top of the section of the documentation
that you linked to:
Pure functions are functions which cannot access global or static,
mutable state save through their arguments. This can enable
optimizations based on the fact that a pure function is guaranteed to
mutate nothing which isn't passed to it, and in cases where the
compiler can guarantee that a pure function cannot alter its arguments,
it can enable full, functional purity (i.e. the guarantee that the
function will always return the same result for the same arguments).
That outright says that pure only _can_ enable functional purity - in
particular when the compiler is able to guarantee that the function
cannot mutate its arguments. pure itself however means nothing of the
sort. The fact that pure functions cannot access global state _is_ the
basis for functional purity when combined with parameters that
arguments cannot be mutated.
I am aware of weak/strong purity. I am only talking about strong purity now.
To quote bearophile:
bool randomBit() pure nothrow @safe {
return (new int[1].ptr) (new int[1].ptr);
}
void main() {}
Pure functions are functions which cannot access global or static,
mutable state save through their arguments. - no objections here
This can enable optimizations based on the fact that a pure function is
guaranteed to mutate nothing which isn't passed to it, and in cases
where the compiler can guarantee that a pure function cannot alter its
arguments, it can enable full, functional purity (i.e. the guarantee
that the function will always return the same result for the same
arguments). - no arguments where passed to the function, it should
always return the same result
If you get hung up on what the concept of functional purity is or what
you thought pure was before using D, then you're going to have a hard
time understanding what pure means in D. And yes, it's a bit weird, but
it comes from the practical standpoint of how to make functional purity
possible without being too restrictive to be useful. So, it really
doesn't matter what other sources say about what purity means. That's
not what D's pure means. D's pure is just a building block for what
purity normally means. It makes it so that the compiler can detect
functional purity and then optimize based on it, but it doesn't in and
of itself have anything to do with functional purity.
If the documentation isn't getting that across, then I guess that it
isn't clear enough. But I would have thought that the part that said
and in cases where the compiler can guarantee that a pure function
cannot alter its arguments, it can enable full, functional purity
would have made it clear that D's pure is _not_ functionally pure by
itself. The first part of the paragraph says what pure really means:
Pure functions are functions which cannot access global or static,
mutable state save through their arguments. Everything else with
regards to functional purity is derived from there, but in and of
itself, that's _all_ that the pure attribute in D means.
See also: http://klickverbot.at/blog/2012/05/purity-in-d/
- Jonathan M Davis
Yeah, it does not seem to be clear enough.
It comes down to two simple questions:
- should you be able to make a strong pure rand() function i D?
- if not, why?
My answer would be: no, because the result should always be the same.
Of course I could be wrong, but my understanding of it fits
Re: Memory allocation purity
On 15.5.2014. 11:45, Don wrote: On Thursday, 15 May 2014 at 08:14:50 UTC, luka8088 wrote: On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote: On Thu, 15 May 2014 05:51:14 + via Digitalmars-d digitalmars-d@puremagic.com wrote: Yep, purity implies memoing. No, it doesn't. _All_ that it means when a function is pure is that it cannot access global or static variables unless they can't be changed after being initialized (e.g. they're immutable, or they're const value types), and it can't call any other functions which aren't pure. It means _nothing_ else. And it _definitely_ has nothing to do with functional purity. Now, combined with other information, you _can_ get functional purity out it - e.g. if all the parameters to a function are immutable, then it _is_ functionally pure, and optimizations requiring functional purity can be done with that function. But by itself, pure means nothing of the sort. So, no, purity does _not_ imply memoization. - Jonathan M Davis Um. Yes it does. http://dlang.org/function.html#pure-functions functional purity (i.e. the guarantee that the function will always return the same result for the same arguments) The fact that it should not be able to effect or be effected by the global state is not a basis for purity, but rather a consequence. Even other sources are consistent on this matter, and this is what purity by definition is. Please note: D's 'pure' annotation does *not* mean that the function is pure. It means that it is statically verified to be OK to call it from a pure function. The compiler determines if a function is pure, the programmer never does. There are two things going on here, and they are quite distinct. (1) Really the keyword should be something like '@noglobal', rather than 'pure'. It's called pure for historical reasons. To reduce confusion I'll call D's pure '@noglobal' and the functional languages pure '@memoizable'. But it turns out that @memoizable isn't actually an interesting property, whereas '@noglobal' is. No global state is a deep, transitive property of a function. Memoizable is a superficial supersetextra property which the compiler can trivially determine from @noglobal. Suppose you have function f(), which calls function g(). If f does not depend on global state, then g must not depend on global state. BUT if f() can be memoizable even if g() is not memoizable. This approach used by D enormously increases the number of functions which can be statically proven to be pure. The nomenclature can create confusion though. (2) Allowing GC activity inside a @noglobal function does indeed weaken our ability to memoize. The compiler can still perform memoizing operations on most functions that return GC-allocated memory, but it's more difficult. We don't yet have data on how much of a problem this is. An interesting side-effect of the recent addition of @nogc to the language, is that we get this ability back. Yeah, I read all about weak/string purity and I do understand the background. I was talking about strong purity, maybe I should pointed that out. So, to correct myself: As I understood strong purity implies memoization. Am I correct?
Re: Memory allocation purity
On 15.5.2014. 12:48, Don wrote: On Thursday, 15 May 2014 at 10:31:47 UTC, luka8088 wrote: On 15.5.2014. 11:45, Don wrote: On Thursday, 15 May 2014 at 08:14:50 UTC, luka8088 wrote: On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote: On Thu, 15 May 2014 05:51:14 + via Digitalmars-d digitalmars-d@puremagic.com wrote: Yep, purity implies memoing. No, it doesn't. _All_ that it means when a function is pure is that it cannot access global or static variables unless they can't be changed after being initialized (e.g. they're immutable, or they're const value types), and it can't call any other functions which aren't pure. It means _nothing_ else. And it _definitely_ has nothing to do with functional purity. Now, combined with other information, you _can_ get functional purity out it - e.g. if all the parameters to a function are immutable, then it _is_ functionally pure, and optimizations requiring functional purity can be done with that function. But by itself, pure means nothing of the sort. So, no, purity does _not_ imply memoization. - Jonathan M Davis Um. Yes it does. http://dlang.org/function.html#pure-functions functional purity (i.e. the guarantee that the function will always return the same result for the same arguments) The fact that it should not be able to effect or be effected by the global state is not a basis for purity, but rather a consequence. Even other sources are consistent on this matter, and this is what purity by definition is. Please note: D's 'pure' annotation does *not* mean that the function is pure. It means that it is statically verified to be OK to call it from a pure function. The compiler determines if a function is pure, the programmer never does. There are two things going on here, and they are quite distinct. (1) Really the keyword should be something like '@noglobal', rather than 'pure'. It's called pure for historical reasons. To reduce confusion I'll call D's pure '@noglobal' and the functional languages pure '@memoizable'. But it turns out that @memoizable isn't actually an interesting property, whereas '@noglobal' is. No global state is a deep, transitive property of a function. Memoizable is a superficial supersetextra property which the compiler can trivially determine from @noglobal. Suppose you have function f(), which calls function g(). If f does not depend on global state, then g must not depend on global state. BUT if f() can be memoizable even if g() is not memoizable. This approach used by D enormously increases the number of functions which can be statically proven to be pure. The nomenclature can create confusion though. (2) Allowing GC activity inside a @noglobal function does indeed weaken our ability to memoize. The compiler can still perform memoizing operations on most functions that return GC-allocated memory, but it's more difficult. We don't yet have data on how much of a problem this is. An interesting side-effect of the recent addition of @nogc to the language, is that we get this ability back. Yeah, I read all about weak/string purity and I do understand the background. I was talking about strong purity, maybe I should pointed that out. So, to correct myself: As I understood strong purity implies memoization. Am I correct? Yes. 'strong pure' means pure in the way that the functional language crowd means 'pure'. 'weak pure' just means doesn't use globals. But note that strong purity isn't an official concept, it was just the terminology I used when explain to Walter what I meant. I don't like the term because it's rather misleading -- in reality you could define a whole range of purity strengths (more than just two). The stronger the purity, the more optimizations you can apply. Ok. Now it is much clearer, thanks.
Re: Memory allocation purity
On 15.5.2014. 13:04, Jonathan M Davis via Digitalmars-d wrote: On Thu, 15 May 2014 10:48:07 + Don via Digitalmars-d digitalmars-d@puremagic.com wrote: Yes. 'strong pure' means pure in the way that the functional language crowd means 'pure'. 'weak pure' just means doesn't use globals. But note that strong purity isn't an official concept, it was just the terminology I used when explain to Walter what I meant. I don't like the term because it's rather misleading -- in reality you could define a whole range of purity strengths (more than just two). The stronger the purity, the more optimizations you can apply. Yeah, I agree. The problem is that it always seems necessary to use the terms weak pure to describe the distinction - or maybe I just suck at coming up with a better way to describe it than you did initially. Your recent post in this thread talking about @noglobal seems to be a pretty good alternate way to explain it though. Certainly, the term pure throws everyone off at first. - Jonathan M Davis Yeah, +1. Or @isolated, as in isolated from outer scopes.
Re: Memory allocation purity
On 15.5.2014. 17:24, Andrei Alexandrescu wrote: On 5/15/14, 3:31 AM, luka8088 wrote: Yeah, I read all about weak/string purity and I do understand the background. I was talking about strong purity, maybe I should pointed that out. So, to correct myself: As I understood strong purity implies memoization. Am I correct? Yes, as long as you don't rely on distinguishing objects by address. Purity of allocation is frequently assumed by functional languages because without it it would be difficult to get much work done. Then, most functional languages make it difficult or impossible to distinguish values by their address. In D that's easy. A D programmer needs to be aware of that, and I think that's fine. Andrei Hm, this does not seem right. @safe prevents you from taking the address of of a value, as stated in http://dlang.org/function.html#safe-functions , shouldn't pure do the same? Reading again through the @safe docs it seems to me that purity (both strong and weak) should imply @safe. I have seen many claims that in D pure means something else from what it means in functional languages and I think that it is too bad if there is not going to be functional language alike purity in D. I have not seen any example of something that can't be forbidden by the compiler if such support would considered.
Re: range behaviour
On 13.5.2014. 19:40, H. S. Teoh via Digitalmars-d wrote:
On Tue, May 13, 2014 at 01:29:32PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
Even in this case, I'd put an in-contract on f2 that verifies that the
range is indeed non-empty:
...
void f2(R)(R r)
if (isInputRange!R)
in { assert(!r.empty); }
body {
doSomething(r.front);
}
[...]
This is a potential issue because if it turns out that empty _must_ be
called than the author could put the front population logic inside empty.
Consider:
struct R {
bool empty () { front = 1; return false; }
int front = 0;
void popFront () { front = 0; }
}
This is a valid code if empty _must_ be called, but it will behave
differently if passed to f2 in case asserts are compiled out. In case
asserts are compiled out empty is never called and front in never populated.
Because of this I think that it is necessary to document range behavior.
Re: Livestreaming DConf?
On 9.5.2014. 21:48, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei +1 definitely gonna watch!
Re: More radical ideas about gc and reference counting
On 6.5.2014. 20:10, Walter Bright wrote: On 5/6/2014 10:47 AM, Manu via Digitalmars-d wrote: On 7 May 2014 01:46, Andrei Alexandrescu via Digitalmars-d I'm not even sure what the process it... if I go through and LGTM a bunch of pulls, does someone accept my judgement and click the merge button? You can see why I might not feel qualified to do such a thing? You don't need to be qualified (although you certainly are) to review PR's. The process is anyone can review/comment on them. Non-language-changing PR's can be pulled by anyone on Team DMD. Language changing PR's need to be approved by Andrei and I. Team DMD consists of people who have a consistent history of doing solid work reviewing PR's. Interesting. This really needs to pointed out on the site.
Re: From slices to perfect imitators: opByValue
On 8.5.2014. 5:58, Andrei Alexandrescu wrote: This magic of T[] is something that custom ranges can't avail themselves of. In order to bring about parity, we'd need to introduce opByValue which (if present) would be automatically called whenever the object is passed by value into a function. This change would allow library designers to provide good solutions to making immutable and const ranges work properly - the way T[] works. Looks very similar to some kind of opImplicitConvert. http://forum.dlang.org/thread/teddgvbtmrxumffrh...@forum.dlang.org http://forum.dlang.org/thread/gq0fj7$4av$1...@digitalmars.com Maybe it would be better to have a more general solution instead of special case solution, if there is no reason against implicit conversion of course.
