4 ms·
Ah, I guess I misunderstood. From the tutorial: > Pony often uses the primitive None to indicate that something has "no value". So that is not a special value
by ggchappell 11y ago
Ah, I guess I misunderstood. From the tutorial:
> Pony often uses the primitive None to indicate that something has "no value".
So that is not a special value that we can assign to any variable.
"None" would seem to be pretty pointless all by itself, but I guess we could do a union of any old type with "None", to get a result much like Haskell's "Maybe". And then the Pony type system would give us much the same guarantees as Haskell's would; so we get a nullable variable that still allows for typesafe operations -- e.g., dereferencing, if applicable. (I guess ....)
- steveklabnik 11y agoYeah, when I read the parent comment, I thought that None was part of a type like Maybe, but the next sentence describes it as a unit type: > Of course, it does have a value, so that you can check what it is, and the value is the single instance of None.
- ggchappell 11y agoYes, but, as I noted, Pony has type unions (http://tutorial.ponylang.org/types/type-expressions/ http://tutorial.ponylang.org/types/type-expressions/). So you can roll your own Maybe types. From the page I linked above: > var x: (String | None) > Here we have an example of using a union to express an optional type, where x might be a String, but it also might be None. That's pretty clearly a Maybe.
- steveklabnik 11y agoMaybe (at least in Haskell/Rust) is a sum type, not a union type, though. EDIT: Ugh, sorry, those are the same, I was thinking of sum vs _product_ type, ignore me.
- ggchappell 11y agoActually, I think you've noted a significant issue: Pony looks to have been designed, at least in part, based on a sound theoretical foundation provided by modern type theory, semantics, etc. However, the documentation does not use the standard terminology of these fields. As a result, it is difficult to evaluate some of the claims that are made.
- vram22 11y agoIs a union type (at least in Haskell/Rust) structured like a union in C, where alternative types of values (e..g. int, float, char) occupy the same bytes, just not at the same time? Or is separate space allocated for the different types of values? Asking because, if a function returns a union type, with one type within it representing an integer (which can have any value), and if the function also wants to return an error condition, then no valid integer value can be used to indicate the error, because all integer values are valid return values from the function. In this case I would think that a union type should have separate space allocated for the integer value and the error-signalling value. (Something like what golang does with its return values?)
- steveklabnik 11y agoThere are two major forms of sum type implementations that I'm aware of: tagged and untagged. What you're describing is a tagged union, for exactly the reason you state: there's an extra field for a discriminant which lets you choose the tag. Untagged unions are C's unions, where there's no discriminant, and you just have to know which type is valid at a given time. Rust supports tagged unions, but can also optimize them to untagged in certain circumstances. We will probably add some kind of untagged union as well, mostly for FFI, but they're very unsafe, for the above reasons.
- vram22 11y agoGot it, thanks. Interesting about Rust's design goals and tradeoffs.
- 0cachecoherency 11y agoSimilarly, Pony's union (ie sum) type implementation always optimises to untagged, but required "boxing" raw machine-words when they're in a union type.
- drostie 11y agoThe Haskell void type () is also a None, and it's pretty helpful. The easiest example is `putStrLn :: String -> IO ()`.