Walter Bright <newshound2@digitalmars.com> wrote:
> On 1/11/2015 5:06 AM, Dicebot wrote:
>> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
> 
> It's a great question. I have a lot of experience with error codes, and with exceptions. I have zero with the packed scheme, though that doesn't stop me from having an opinion :-)
> 
> Perhaps I misunderstand, but given A calls B calls C,
> 
>    A => B => C
> 
> and C detects an error, and A knows what to do with the error. B then becomes burdened with checking for the error, invoking some sort of cleanup code, and then propagating it.
> 
> Wouldn't this be uglifying B's source code?
> 
> With exceptions, C throws, A catches, and B's cleanup happens automatically.
> 
> This matters very much for pipeline style programming (i.e. ranges and algorithms).

- Error codes are automatically ignored
- Exceptions are automatically propagated

IMO both are not ideal and lead to sloppy programming.
Ignoring errors is of course worse than aborting where you could have
handled the error.

Rust-style "packed" errors are nice because you are forced to think about the correct handling.

On 1/11/2015 11:09 PM, Tobias Müller wrote:
> - Error codes are automatically ignored
> - Exceptions are automatically propagated
>
> IMO both are not ideal and lead to sloppy programming.
> Ignoring errors is of course worse than aborting where you could have
> handled the error.
>
> Rust-style "packed" errors are nice because you are forced to think about
> the correct handling.


I don't think this is an answer to my point.

On Monday, 12 January 2015 at 07:09:54 UTC, Tobias Müller wrote:
> Walter Bright <newshound2@digitalmars.com> wrote:
>> On 1/11/2015 5:06 AM, Dicebot wrote:
>>> What is your opinion of approach advertised by various functional languages and
>>> now also Rust? Where you return error code packed with actual data and can't
>>> access data without visiting error code too, compiler simply won't allow it.
>> 
>> It's a great question. I have a lot of experience with error codes, and
>> with exceptions. I have zero with the packed scheme, though that doesn't
>> stop me from having an opinion :-)
>> 
>> Perhaps I misunderstand, but given A calls B calls C,
>> 
>>    A => B => C
>> 
>> and C detects an error, and A knows what to do with the error. B then
>> becomes burdened with checking for the error, invoking some sort of
>> cleanup code, and then propagating it.
>> 
>> Wouldn't this be uglifying B's source code?
>> 
>> With exceptions, C throws, A catches, and B's cleanup happens automatically.
>> 
>> This matters very much for pipeline style programming (i.e. ranges and algorithms).
>
> - Error codes are automatically ignored
> - Exceptions are automatically propagated
>
> IMO both are not ideal and lead to sloppy programming.
> Ignoring errors is of course worse than aborting where you could have
> handled the error.
>
> Rust-style "packed" errors are nice because you are forced to think about
> the correct handling.

There's nothing stopping you from just throwing errors out in Rust(last I used it anyways) via empty match statements and/or unwrap.

On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote:
> It's a great question. I have a lot of experience with error codes, and with exceptions. I have zero with the packed scheme, though that doesn't stop me from having an opinion :-)
>
> Perhaps I misunderstand, but given A calls B calls C,
>
>    A => B => C
>
> and C detects an error, and A knows what to do with the error. B then becomes burdened with checking for the error, invoking some sort of cleanup code, and then propagating it.
>
> Wouldn't this be uglifying B's source code?
>
> With exceptions, C throws, A catches, and B's cleanup happens automatically.
>
> This matters very much for pipeline style programming (i.e. ranges and algorithms).

Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/

On 1/11/2015 11:53 PM, Tobias Pankrath wrote:
> On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote:
>> This matters very much for pipeline style programming (i.e. ranges and
>> algorithms).
>
> Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/

I don't fully understand it, but it appears to require that each component have two paths coded into it - the regular path, and the error path, and there has to be adapters for components that only have a regular path. Exceptions means only one path has to be coded.

I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high.

Walter Bright:

> I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high.

Apparently if the language syntax is designed for that style of functional programming, the "inconvenience" seems to be very low.

Bye,
bearophile

On Monday, 12 January 2015 at 09:41:08 UTC, bearophile wrote:
> Walter Bright:
>
>> I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high.
>
> Apparently if the language syntax is designed for that style of functional programming, the "inconvenience" seems to be very low.

Yes, dataflow.

On 11 January 2015 at 10:48, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Over the last few days, I have been getting weird errors from various programs I run on Windows 7. Programs would just fail, or produce corrupt output (I'm looking at you, Windows Moviemaker).
>
> I have a 128Gb SSD drive for my system drive, for speed, and a 4T secondary spinning drive for storage. I knew I was getting nearly out of space on the SSD drive, and had a 256Gb SSD drive ready to swap in.
>
> To migrate the system to the new disk, the idea was to use Windows Backup/Restore of the image. Unfortunately, Windows Backup would get a ways through the process, then fail with no message beyond an error code. Googling the error code produced a vast number of results, and various schemes for fixing it, some official, some not. None of them were applicable. Many involved loading new drivers, editting the system registry, and all sort of unappealing "solutions".
>

Up to this point, I you reminded me of a talk by Joe Armstrong
(inventor of Erlang)

https://www.youtube.com/watch?v=lKXe3HUG2l4

On Monday, 12 January 2015 at 09:31:25 UTC, Walter Bright wrote:
> On 1/11/2015 11:53 PM, Tobias Pankrath wrote:
>> On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote:
>>> This matters very much for pipeline style programming (i.e. ranges and
>>> algorithms).
>>
>> Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/
>
> I don't fully understand it, but it appears to require that each component have two paths coded into it - the regular path, and the error path, and there has to be adapters for components that only have a regular path. Exceptions means only one path has to be coded.
>
> I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high.

Not really, after you have the library that can handle all code paths, the code just needs to be written using such building blocks[0], as they are quite general.

Which is relatively easy in FP first languages.

[0] Aka monadic combinators

On Monday, 12 January 2015 at 09:31:25 UTC, Walter Bright wrote:
> On 1/11/2015 11:53 PM, Tobias Pankrath wrote:
>> On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote:
>>> This matters very much for pipeline style programming (i.e. ranges and
>>> algorithms).
>>
>> Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/
>
> I don't fully understand it, but it appears to require that each component have two paths coded into it - the regular path, and the error path, and there has to be adapters for components that only have a regular path. Exceptions means only one path has to be coded.

As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#.

Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: >>, >>= and >=> which take care of the adaption.