[jolux]

what's the purpose of Either and Maybe in a dynamically typed language?

[edflsafoiewq]

Pop an item from an array. What do you return when the array is empty?

Solution: nil. Problem: How do you tell the difference between "the array was empty" and "the item you popped was nil"?

Solution: have pop return a Maybe instead.

[alaaalawi]

or allow returning multiple values. for example in CL searching for a thing returns two values the is-found and the value

[uryga]

...which, btw, is equivalent to Maybe/Either – they're tagged unions, i.e. pairs (tag, content). Maybe<T> is isomorphic* to

  { has_value: bool,
    val: T|nil }

* well, this representation is a bit too permissive, since you could do

  {has_value: true, val: nil} 

if you wanted to get the types water-tight, you'd need dependent types, typing it as dependent pair:

  Maybe<T> =
    sigma (has_value: bool)
      if has_value
        then T
        else ()

which can then only have values

  (false, ())

or

  (true, <actual value of type T>)

[coldtea]

Which is the same thing, but in an ad-hoc way, and leaves it open to the developer to check or not, and thus to crash.

[inopinatus]

or solution: Null Object

or a whole value

or use an enumerator

or a collection decorator

All of which are simple solutions already available. No need to import every new paradigm hammer in the hope that everything is a nail.

[ljm]

Maybe I’ve just been bitten by the functional bug but I find they can communicate intent much better than scattering around null checks or catching exceptions (many of which require reading the source to understand what exceptions you might get).

It’s great in large scale projects, which I think is where a dynamic language starts to show its warts.

[int_19h]

Given that we're talking about it in a pattern matching context, you'd just pattern match on x vs nil, rather than matching on Just x or None. And in case of Either, you'd match on the types that you expect.

[obstacle1]

An alternative to scattering null checks around or using exceptions for control flow could be more thoughtfully designing your data/object model. No additional language constructs required!

[coldtea]

That attitude is the source of billions of dollars in bugs...

Never manually do the work that the compiler / runtime could do.

You can design "more thoughtfully designing your data/object model" (in other regards) AND have the compiler make sure you're not doing null referencing for you (so that that's not your concern anymore) -- instead of manually and in an ad-hoc way per project implementing another menial responsibility into the design of your model.

[ljm]

What if using those functional concepts is my attempt at thoughtful design? You're making a hell of an assumption with that one.

[jolux]

Yeah I suppose my bigger beef is I just don't like dynamic languages. Perhaps it is in fact a good idea for them, but being someone primarily interested in types, it largely falls into the realm of "don't care."

[coldtea]

Huh? Both Maybe / Optional and pattern matching is used in Haskell, Scala, and other typed languages... It's not about dynamic languages...

[jolux]

If you’ll notice my other comments in this thread, I think you’ll see I vastly prefer statically typed functional languages over dynamic ones. I was more commenting that I like monads and functors and Maybe and Either/Result but don't like dynamic languages.

[chrisseaton]

One use could be that you could capture source information in them, so when you get an unexpected None you can find where it came from.

[sorokod]

What forces you to check for None?

[chrisseaton]

The idea of Maybe is that you usually don't check for None. The idea is that you use it sort of like a collection in most cases, allowing the None to propagate up as the result of collection operations on other Nones. The issue can be that you get a None at the end and it isn't clear where it came from originally, and how it reached you. Adding stack trace information to each intermediate None, when in debug mode, can help you trace what went wrong.

[jolux]

>The idea is that you use it sort of like a collection in most cases

Sort of like a monad, even!

Honestly if you're running into problems like that though you should probably be using Either instead of Maybe like GP suggested. In my opinion, most of the benefit is still derived from strong static type checking, because otherwise you basically have to trust that callers respect your contract with these types. Perhaps Ruby 3.0 will make this feasible. I'm not sure of the details of the type system they intend to implement; whether it supports ADTs and such.

[chrisseaton]

> Sort of like a monad, even!

Yes that's it - they're monads! Either is also a monad, and you can store error information in the other side if you want, but a good thing about Maybe is it could transparently store the error information, and produce it when debugging, rather than baking it into the normal runtime semantics.

> you basically have to trust that callers respect your contract with these types

This is table-stakes for a dynamic language like Ruby, though. Yes people can do anything, but usually they follow the rules they're given.

[jolux]

Yes I’m aware they’re monads, my primary languages are OCaml and Haskell. I don’t understand what you’re suggesting with Maybe, that sounds like maybe adding some layer of magic onto it?

> Yes people can do anything, but usually they follow the rules they're given.

Sure, but the primary advantage remains in not having to trust that, not having to write tests for it, and communicating the contract itself inside the code it restricts. I’m just honestly not sure what purpose they serve here, and why you’d bother to call them monads when what you really seem to want is the stored debugging information.

[StuffedParrot]

How are they related at all?