Add maybe types

[TobiasWrigstad]

EDIT The original topic of this issue was "Update PonyRT with support for null actors"

Pony seems to not have null and this causes problems whenever null is used in message sends. The appropriate messages (in actor.c?) should be updated with a case that ignores null or we implement null actors in a different way.

[supercooldave]

What is the use case for null actors?
Shouldn't we use option/Maybe type, like those functional languages?

[TobiasWrigstad]

I was thinking something like that, but in the run-time, that should be represented as
sending around some fixed pointer value like null for "null" and a pointer to the
non-null thing otherwise. An indirection is unacceptable.

Currently, all pointers to actors must be valid pointers -- and that is what I'd
like to extend. I will change this ticket to reflect the high-level point instead!

[supercooldave]

It is tricky to get right implementing maybe types using null. If the type is Maybe (Maybe int), how can I tell the difference between Nothing, Just Nothing and Just (Just 0)? All would be encoded as 0 – at least, in the scheme I'm imagining.

[TobiasWrigstad]

I wasn't thinking about maybe types for primitives. That does raise an issue! Still,
for pointers, the representation I suggested should not be a problem. I guess one
way is to "just use a bit to track [maybe status]" but this will half all our ints...
Probably better to use 2 words instead. Or to not have them at all.

This also graces another issue: how large are our ints/floats etc. Clearly we won't
do automatic conversion into bignums because of the overhead, but we need to think a
little. Currently, our ints are int64_t's which if fine by me.

[supercooldave]

I love the "clearly we won't" part. Why is it so clear for scalability? Big Data needs big ints.

The C solution is to make it extremely difficult to have big ints. The Haskell solution is to let to programmer state which, but assume big int unless otherwise specified. The Racket solution is to default to big ints and bury little ints in some library.

Sent from my iPhone

On 09/08/2014, at 9:14, TobiasWrigstad notifications@github.com wrote:

I wasn't thinking about maybe types for primitives. That does raise an issue! Still,
for pointers, the representation I suggested should not be a problem. I guess one
way is to "just use a bit to track [maybe status]" but this will half all our ints...
Probably better to use 2 words instead. Or to not have them at all.

This also graces another issue: how large are our ints/floats etc. Clearly we won't
do automatic conversion into bignums because of the overhead, but we need to think a
little. Currently, our ints are int64_t's which if fine by me.
—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[TobiasWrigstad]

Good that we are not doing big data (yet) then! We want performance. Having to check each integer operation is killing performance. I prefer the solution that's optimised for the common case (probably not big nums then) and where there is a relatively painless solution for having big nums (my autocorrect keeps changing into big nuns) like declaring them big in the type.

[TobiasWrigstad]

Furthermore, big data seems to mean lots of small numbers.