5 ms·

I know it's slow at the moment, but is anyone planning on using pattern matching for anything in particular? Curious what use cases are particularly suitable fo

I know it's slow at the moment, but is anyone planning on using pattern matching for anything in particular? Curious what use cases are particularly suitable for it.

ljm 7y ago
I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages. Will have to properly try it out.
- jolux 7y ago
  what's the purpose of Either and Maybe in a dynamically typed language?
  - chrisseaton 7y ago
    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 7y ago
      What forces you to check for None?
      - chrisseaton 7y ago
        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 7y ago
        >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 7y ago
        > 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 7y ago
        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.
        chrisseaton 7y ago
        > I don’t understand what you’re suggesting with Maybe I’m suggesting adding a trace of where a None value is created and propagated, for debugging purposes. > the primary advantage remains in not having to trust that, not having to write tests for it Is that the primary advantage? I’m not as sure as you seem to be. And of course there’s one huge part of monads that you have to take on trust even in Haskell isn’t there? The monad laws! No type system is enforcing those. If you’re comfortable trusting someone else is following that rule why is trusting they follow another so alien? But if you don’t like the idea don’t worry I’m not going to come round to your house and force you!
  - ljm 7y ago
    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.
    - obstacle1 7y ago
      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 7y ago
        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 7y ago
        What if using those functional concepts is my attempt at thoughtful design? You're making a hell of an assumption with that one.
    - int_19h 7y ago
      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.
    - jolux 7y ago
      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."
  - edflsafoiewq 7y ago
    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 7y ago
      or allow returning multiple values. for example in CL searching for a thing returns two values the is-found and the value
      - uryga 7y ago
        ...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 7y ago
        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 7y ago
      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.
  - StuffedParrot 7y ago
    How are they related at all?

I know it's slow at the moment, but is anyone planning on using pattern matching for anything in particular? Curious what use cases are particularly suitable for it.

ljm 7y ago

I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages. Will have to properly try it out.

jolux 7y ago
what's the purpose of Either and Maybe in a dynamically typed language?
- chrisseaton 7y ago
  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 7y ago
    What forces you to check for None?
    - chrisseaton 7y ago
      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 7y ago
        >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 7y ago
        > 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 7y ago
        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.
        chrisseaton 7y ago
        > I don’t understand what you’re suggesting with Maybe I’m suggesting adding a trace of where a None value is created and propagated, for debugging purposes. > the primary advantage remains in not having to trust that, not having to write tests for it Is that the primary advantage? I’m not as sure as you seem to be. And of course there’s one huge part of monads that you have to take on trust even in Haskell isn’t there? The monad laws! No type system is enforcing those. If you’re comfortable trusting someone else is following that rule why is trusting they follow another so alien? But if you don’t like the idea don’t worry I’m not going to come round to your house and force you!
- ljm 7y ago
  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.
  - obstacle1 7y ago
    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 7y ago
      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 7y ago
      What if using those functional concepts is my attempt at thoughtful design? You're making a hell of an assumption with that one.
  - int_19h 7y ago
    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.
  - jolux 7y ago
    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."
- edflsafoiewq 7y ago
  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 7y ago
    or allow returning multiple values. for example in CL searching for a thing returns two values the is-found and the value
    - uryga 7y ago
      ...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 7y ago
      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 7y ago
    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.
- StuffedParrot 7y ago
  How are they related at all?