4 ms·

> No null/undefined nonsense; nil replaces both Fuck nil, maybe is much better

brundolf 5y ago
To be clear, there will be strong nil-checks just like there are in TypeScript and other modern languages. Commonly nil will be used in a union type: func foo(): number|nil => ... const x = foo() const y = x + 2 // compile error const z = if (x != nil) { x + 2 } else { nil } At that point the difference compared with maybe is mostly superficial
- DylanSp 5y ago
  There's two major differences between that and a proper Maybe type. First, Maybe is composable; you can have Maybe (Maybe a), which distinguishes between Nothing, Just Nothing, and Just (Just a). There's not really a way to represent that with raw nil. Second, Maybe can integrate with the rest of the type system (thinking of the Functor/Applicative/Monad hierarchy from Haskell), which lets you easily have code like func foo(): Maybe<number> => ... x = foo() y = fmap someOtherFunction x instead of the more verbose y = if (x == nil) { nil } else { someOtherFunction x }
  - brundolf 5y ago
    I agree the if/else version here is a little verbose; I'll probably try to make this syntactically cleaner in some way. Maybe a Python-style `X if condition else Y`, maybe the parens and/or curlies could be removed, maybe this is a case for the upcoming expressive-switch or match syntax. There's a small chance I might even give some kind of dedicated map-like construct for |nils, since that will be such a common case. However, I want to avoid getting too deep into FP-land. The hope is for Bagel to be familiar and comfortable to existing JavaScript devs, where they can benefit from a degree of purity while being able to understand or at least guess at the meaning of a given construct in front of them based on their prior experience. To that end, I think terms like "either" will be unfamiliar, and I also think situations like (Just (Just X)) will create a lot more confusion than utility. I'm struggling to think of a useful case for that myself (I'm sure they exist, but the point remains). I'm thinking about the teams I've worked with, and I'm thinking about what would most effectively empower them to benefit from this "stateless subset" paradigm. A guiding principle is that I want Bagel to be a language that introduces some idealism into a pragmatic context, not one that's idealistic to the detriment of usability
    - brundolf 5y ago
      Addendum: I gave this some more thought and realized that actually, even as I have the compiler implemented right now, the else clause above is redundant because an expressive if/else with no else defaults to nil for that case: const z = if (x != nil) { x + 2 } // comes out to number|nil So that's less verbose and may be acceptable as-is. You also shouldn't need to chain the syntax for multiple values: const z = if (x != nil && y != nil && z != nil) { x + y + z } There may also be room to make the () optional like Rust does, or maybe just dropping the {} would be better. I'll have to see how each affects parsing and readability

To be clear, there will be strong nil-checks just like there are in TypeScript and other modern languages. Commonly nil will be used in a union type: func foo(): number|nil => ... const x = foo() const y = x + 2 // compile error const z = if (x != nil) { x + 2 } else { nil } At that point the difference compared with maybe is mostly superficial

DylanSp 5y ago
There's two major differences between that and a proper Maybe type. First, Maybe is composable; you can have Maybe (Maybe a), which distinguishes between Nothing, Just Nothing, and Just (Just a). There's not really a way to represent that with raw nil. Second, Maybe can integrate with the rest of the type system (thinking of the Functor/Applicative/Monad hierarchy from Haskell), which lets you easily have code like func foo(): Maybe<number> => ... x = foo() y = fmap someOtherFunction x instead of the more verbose y = if (x == nil) { nil } else { someOtherFunction x }
- brundolf 5y ago
  I agree the if/else version here is a little verbose; I'll probably try to make this syntactically cleaner in some way. Maybe a Python-style `X if condition else Y`, maybe the parens and/or curlies could be removed, maybe this is a case for the upcoming expressive-switch or match syntax. There's a small chance I might even give some kind of dedicated map-like construct for |nils, since that will be such a common case. However, I want to avoid getting too deep into FP-land. The hope is for Bagel to be familiar and comfortable to existing JavaScript devs, where they can benefit from a degree of purity while being able to understand or at least guess at the meaning of a given construct in front of them based on their prior experience. To that end, I think terms like "either" will be unfamiliar, and I also think situations like (Just (Just X)) will create a lot more confusion than utility. I'm struggling to think of a useful case for that myself (I'm sure they exist, but the point remains). I'm thinking about the teams I've worked with, and I'm thinking about what would most effectively empower them to benefit from this "stateless subset" paradigm. A guiding principle is that I want Bagel to be a language that introduces some idealism into a pragmatic context, not one that's idealistic to the detriment of usability
  - brundolf 5y ago
    Addendum: I gave this some more thought and realized that actually, even as I have the compiler implemented right now, the else clause above is redundant because an expressive if/else with no else defaults to nil for that case: const z = if (x != nil) { x + 2 } // comes out to number|nil So that's less verbose and may be acceptable as-is. You also shouldn't need to chain the syntax for multiple values: const z = if (x != nil && y != nil && z != nil) { x + y + z } There may also be room to make the () optional like Rust does, or maybe just dropping the {} would be better. I'll have to see how each affects parsing and readability