Re: D kernel for Jupyter notebook
On Monday, 20 August 2018 at 00:14:03 UTC, Shigeki Karita wrote: On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: Proof of concept works, but it requires some further development to be useful to do work in. [...] Great. I have tried DUB integration. It seems to work. https://github.com/ShigekiKarita/grain/blob/master/example/repl.d I'm making a jupyter based tutorial for my library. It might be the first example for jupyterd. https://github.com/ShigekiKarita/grain/blob/master/tutorial.ipynb
Re: expectations 0.1.0
On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky (Abscissa) wrote: By contrast, a function that returns an `Expected!T` does *not* force its caller to acknowledge it. If an error occurs, and the caller never checks value or hasValue...nothing happens. That's called squelching an error, and its EXACTLY the same problem as using non-Expect return values to indicate errors. I'd regard that as very notable hole in any Expected design as it breaks one of the core points of using Expect vs returning plain error codes: The user can still accidentally (or deliberately) squelch an error. If you receive an `Expected!T`, you have the following choices available to you: 1. Handle the success case locally, and the failure case non-locally (i.e. use `value` directly). 2. Handle both the success case and the failure case locally (i.e. check `hasValue`). 3. Handle both the success case and the failure case non-locally (i.e., pass the `Expected!T` along untouched). The difference between `Expected`, on the one hand, and both `Success` and plain-old exceptions, on the other, is that `Expected` gives you choice #3, and the other two don't. Why is choice #3 important? Because it doesn't branch. Both success and failure follow the same code path. That makes functions that use `Expected` much easier to compose than ones that throw exceptions. For example, if you throw an exception in the middle of a range pipeline, the entire thing comes crashing down--but an `Expected!T` will pass right through, and let you handle it when it comes out the other end. Now, you will probably object--and rightly so--that there is an implicit assumption being made here, which is that "handle the success case" is equivalent to "use the return value." Clearly, this equivalence does not always hold in the presence of side effects. That's why `Expected!void` is so problematic. Nevertheless, I think it holds in enough cases to make `Expected` useful in practice. In particular, it is guaranteed to hold for strongly-pure functions, and will also hold for functions whose side effects are visible only through the return value (e.g., `readln`). I don't see the laziness here as being the core point. The laziness is the "how", not the raison d'etre. The laziness is simply a tool being used to achieve the real goals of: - Allowing the caller the decide between foo/tryFoo versions without the API duplication. - Decreasing exception-related overhead and increasing utility of nothrow. The laziness (on the part of the caller, i.e., the code that *receives* the `Expected!T`) is important because it's what makes choice #3 possible. It's an essential part of the design.
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote:
Glad to announce D 2.082.0.
This release comes with more efficient update functions for
associative arrays, unsafe code in debug blocks, UDAs for
function parameters, an improved dependency resolution and
avoidance of online update checks for dub, and signed Windows
binaries.
http://dlang.org/download.html
http://dlang.org/changelog/2.082.0.html
-Martin
I found changes in std.math make some codes not working anymore
https://dlang.org/changelog/2.082.0.html#math_float_double_implementations
// working in 2.081.2, not 2.082.0
import std.math;
import std.stdio;
void main() {
static d = exp(-1.0);
}
// error in 2.082.0
/home/skarita/dlang/dmd-2.082.0/linux/bin64/../../src/phobos/std/math.d(2360):
Error: static variable P cannot be read at compile time
/home/skarita/dlang/dmd-2.082.0/linux/bin64/../../src/phobos/std/math.d(2360):
called from here: poly(xx, P)
/home/skarita/dlang/dmd-2.082.0/linux/bin64/../../src/phobos/std/math.d(2221):
called from here: expImpl(x)
/home/skarita/dlang/dmd-2.082.0/linux/bin64/../../src/phobos/std/math.d(2225):
called from here: exp(cast(real)x)
./test.d(5):called from here: exp(-1)
Failed: ["/home/skarita/dlang/dmd-2.082.0/linux/bin64/dmd", "-v",
"-o-", "./test.d", "-I."]
Is there any workaround to avoid this?
Re: expectations 0.1.0
On 09/03/2018 02:49 AM, Paul Backus wrote:
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa)
wrote:
Note that the above has *nothing* to do with retrieving a value.
Retrieving a value is merely used by the implementation as a trigger
to lazily decide whether the caller wants `foo` or `tryFoo`. Going out
of scope without making the choice could also be considered another
trigger point. In fact, this "out-of-scope without being checked"
could even be used as an additional trigger for even the non-void
variety. After all: what if an error occurs, but the caller checks
*neither* value nor hasValue?
The thing is, triggering on explicit access lets you handle errors
lazily, whereas triggering at the end of the scope forces you to handle
them eagerly.
Vladimir's `Success` type is, essentially, a way for a function to send
something back up the stack that its caller is forced to acknowledge.
Yes, that's correct.
Throwing an exception is *also* a way for a function to send something
back up the stack that its caller is forced to acknowledge.
Yes, but it's heavier-weight AND prevents the callee from being nothrow.
but when it comes to overall control-flow
semantics, they are basically equivalent.
Control-flow semantics, sure, but as I pointed out in my previous
sentence, there's more relevant things involved here than just control
flow semantics.
By contrast, a function that returns an `Expected!T` does *not* force
its caller to acknowledge it. If an error occurs, and the caller never
checks value or hasValue...nothing happens.
That's called squelching an error, and its EXACTLY the same problem as
using non-Expect return values to indicate errors. I'd regard that as
very notable hole in any Expected design as it breaks one of the core
points of using Expect vs returning plain error codes: The user can
still accidentally (or deliberately) squelch an error.
To clarify: If the caller never checks value or hasValue, that does NOT
mean the caller has carefully and deliberately chosen to disregard the
error. It *could* mean that, but it could also mean they simply messed
up. Deliberately squeching an error should NEVER be implicit, it should
always require something like:
catch(...) { /+ Do nothing +/ }
or
if(!x.hasValue) { /+ Do nothing +/ }
That's what being lazy
means: if you never open the box, it doesn't matter whether the cat is
alive or dead.
I don't see the laziness here as being the core point. The laziness is
the "how", not the raison d'etre. The laziness is simply a tool being
used to achieve the real goals of:
- Allowing the caller the decide between foo/tryFoo versions without the
API duplication.
- Decreasing exception-related overhead and increasing utility of nothrow.
Having one specialization be lazy and one be eager
would be a nightmare for anyone trying to use the library.
Vladimir's Success vs Expect!T is NOT an example of "eager vs lazy". In
BOTH cases, the callee treats errors lazily. And in BOTH cases, the
caller (or whomever the caller passes it off to) is expected to, at some
point, make a deliberate, explicit choice between "handle or throw". And
as I said before, allowing the caller to accidentally (or implicitly)
squelch the error is a fundamental breakage in the whole point behind
Except.
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 15:51:37 UTC, lurker wrote: if i remember correctly (5.), it wants a different/other version of the tool chain. never the less, i'll continue using c# and not install (1.) again, since in earlier versions of D i eventually had to deinstall VS2017 and then reinstall it fresh. too much work. btw, 1. was the only plugin i had. Maybe check your environment variables for leftover entries from previous installations. Without a more concrete bug report it's hard to help you though, try https://issues.dlang.org/. Also there is some initial work on an alternative toolchain based on lld and mingw import libs to avoid the heavy VS installation.
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 22:04:11 UTC, Mike Franklin wrote: I guess we should keep an eye on this for the next releases, could you take care of this Mike? Take care of what exactly? What specifically needs to be done? Testing Windows installation of at least the first beta and the actual release for whether Windows Defender et.al. try to scare away people.
Re: expectations 0.1.0
On Monday, 3 September 2018 at 06:00:06 UTC, Thomas Mader wrote: On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: There are generally two classic approaches to error handling: std::expected is not the only thing on this topic going on in C++. There is also the proposal from Herb Sutter [1]. It's not a library solution and changes even the ABI but it's an interesting approach. He also tries to get compatibility into C via an extension. (See 4.6.11 in [1]) [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf This would be great to have in D. Swift [0] has something similar, and personally after using it for a few years, I can say that I've seen next to no unhandled exception errors in iOS code at least. [0] https://www.mikeash.com/pyblog/friday-qa-2017-08-25-swift-error-handling-implementation.html
Re: expectations 0.1.0
On Monday, 3 September 2018 at 06:49:41 UTC, Paul Backus wrote: To me, the only acceptable choices are for `Expected!void` to have the same lazy semantics as `Expected!T`, or for `Expected!void` to be removed altogether. Having one specialization be lazy and one be eager would be a nightmare for anyone trying to use the library. For the reasons Vladimir brought up, I'm leaning toward removal--without something like Rust's `#[must_use]` attribute, it seems like `Expected!void` is likely to do more harm than good. I'm leaning on agreeing with removal of Expected!void as well When we get opPostMove then maybe Expected!void can throw on a move or a copy if the result was a failure. This would also not allow the error to be ignored as it'd throw. Or... can it throw in ~this() if it was not checked?
Re: expectations 0.1.0
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa) wrote: Note that the above has *nothing* to do with retrieving a value. Retrieving a value is merely used by the implementation as a trigger to lazily decide whether the caller wants `foo` or `tryFoo`. Going out of scope without making the choice could also be considered another trigger point. In fact, this "out-of-scope without being checked" could even be used as an additional trigger for even the non-void variety. After all: what if an error occurs, but the caller checks *neither* value nor hasValue? The thing is, triggering on explicit access lets you handle errors lazily, whereas triggering at the end of the scope forces you to handle them eagerly. Vladimir's `Success` type is, essentially, a way for a function to send something back up the stack that its caller is forced to acknowledge. Throwing an exception is *also* a way for a function to send something back up the stack that its caller is forced to acknowledge. The exact details are different, but when it comes to overall control-flow semantics, they are basically equivalent. By contrast, a function that returns an `Expected!T` does *not* force its caller to acknowledge it. If an error occurs, and the caller never checks value or hasValue...nothing happens. That's what being lazy means: if you never open the box, it doesn't matter whether the cat is alive or dead. The problem, when it comes to `Expected!void`, is that there's no good way to express what we *actually* care about--the function's side effect--as a value. If we could write `Expected!(IO!Unit)` like in Haskell, everything would be fine. To me, the only acceptable choices are for `Expected!void` to have the same lazy semantics as `Expected!T`, or for `Expected!void` to be removed altogether. Having one specialization be lazy and one be eager would be a nightmare for anyone trying to use the library. For the reasons Vladimir brought up, I'm leaning toward removal--without something like Rust's `#[must_use]` attribute, it seems like `Expected!void` is likely to do more harm than good.
Re: expectations 0.1.0
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: There are generally two classic approaches to error handling: std::expected is not the only thing on this topic going on in C++. There is also the proposal from Herb Sutter [1]. It's not a library solution and changes even the ABI but it's an interesting approach. He also tries to get compatibility into C via an extension. (See 4.6.11 in [1]) [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
