Hacker News Reader

Comment by ggchappell | Hacker News Reader

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 ....)

View on HN

Yeah, 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.

Yes, but, as I noted, Pony has type unions (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.

Maybe (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.

Actually, 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.

Is 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?)

There 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.

Got it, thanks. Interesting about Rust's design goals and tradeoffs.

Similarly, Pony's union (ie sum) type implementation always optimises to untagged, but required "boxing" raw machine-words when they're in a union type.

The Haskell void type () is also a None, and it's pretty helpful. The easiest example is `putStrLn :: String -> IO ()`.

Reply on news.ycombinator.com