Re: How to make Moose more "functional"?

The way most people use them, builders (lazy or otherwise) are generally expected to throw an exception if they encounter an error building the value. In some cases, if undef is considered an acceptable value for the attribute, it may be preferable to return undef instead of throwing an exception. But this is probably not often.

If you're wanting to achieve referential transparency, the best place to start is by making all your objects immutable - that is, use is => "ro" for all your attributes, use something like Sub::Trigger::Lock to lock down arrayref and hashref attribute values, don't use native attribute traits which act like mutators, etc.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Comment on Re: How to make Moose more "functional"? Select or Download Code

Replies are listed 'Best First'.
Re^2: How to make Moose more "functional"? by einhverfr (Friar) on May 23, 2014 at 13:34 UTC
I understand that and I understand the reasoning behind it. The problem though is that exceptions break functional programming. Sometimes you have to use them anyway, such as something went wrong with the system outside the function (operating system error in a system call) but they are to be used sparingly. The basic guarantee of functional programming is that for any given x, f(x) has a definite value. If x is not in the domain of the function, then you have an undefined result. If you are having to stop execution of your program because you got a bad input and start recovery from that, then you are doing functional programming wrong. The way that this works in Scala is that you can raise exceptions which behave more or less the way they do in Java, but these should be used in very rare circumstances. You can also return errors from functions, thus preserving referential integrity. So I am trying to get away from the typical flow-oriented "oops I didn't expect that" approach to exceptions and try to have more referential integrity. But to do that, one needs to be able to annotate failures. What I am thinking is that maybe having a role which can wrap getters/setters of immutable objects and log error conditions in a further namespace might be a good way to go. If I had a tied hash that in scalar context always evaluated to undef but in a hash environment always evaluated to a system that would give me a proper view of the error, that might help.	[reply]

Replies are listed 'Best First'.

Re^2: How to make Moose more "functional"?
by einhverfr (Friar) on May 23, 2014 at 13:34 UTC

I understand that and I understand the reasoning behind it. The problem though is that exceptions break functional programming. Sometimes you have to use them anyway, such as something went wrong with the system outside the function (operating system error in a system call) but they are to be used sparingly.

The basic guarantee of functional programming is that for any given x, f(x) has a definite value. If x is not in the domain of the function, then you have an undefined result. If you are having to stop execution of your program because you got a bad input and start recovery from that, then you are doing functional programming wrong.

The way that this works in Scala is that you can raise exceptions which behave more or less the way they do in Java, but these should be used in very rare circumstances. You can also return errors from functions, thus preserving referential integrity.

So I am trying to get away from the typical flow-oriented "oops I didn't expect that" approach to exceptions and try to have more referential integrity. But to do that, one needs to be able to annotate failures.

What I am thinking is that maybe having a role which can wrap getters/setters of immutable objects and log error conditions in a further namespace might be a good way to go. If I had a tied hash that in scalar context always evaluated to undef but in a hash environment always evaluated to a system that would give me a proper view of the error, that might help.

[reply]