Re:“Mostly functional” programming does not work
by TheCoelacanth on Sunday April 27, 2014 @11:19AM
(#7655398)
> in Haskell a value is a value
The same is true of C++. Values and references in C++ can't be null. Pointers can be null, but that's a lower-level feature that doesn't have an equivalent in idiomatic Haskell.
Re:“Mostly functional” programming does not work
by dllthomas on Sunday April 27, 2014 @11:28AM
(#7655435)
"Ptr a" is an equivalent, in many senses. It's quite true that use is far less in idiomatic Haskell, especially as you're restricted to IO when operating on them.
Re:“Mostly functional” programming does not work
by swift on Sunday April 27, 2014 @03:55PM
(#7656553)
Ptr is exactly the same thing as a C pointer. Critically, if you have a Ptr to some value, that Ptr could become invalid if the value gets moved by the garbage collector, just like a C pointer would. That's why you'd never use Ptr except in FFI code, to access memory that isn't managed by Haskell's GC. (If you need to pass a pointer to a Haskell value to code written in another language, you'd use a StablePtr, which pins the value in the Haskell heap.)
In idiomatic Haskell, if you need something like a pointer you have several choices. If you're writing parallel code your best bet is STM. If you're writing code in IO, you can use an IORef. If you don't want that restriction, you can use an STRef.
(I'm aware that you probably know all this, but other people reading the thread might not.)
Re:“Mostly functional” programming does not work
by dllthomas on Sunday April 27, 2014 @04:07PM
(#7656609)
Right, it's "exactly the same thing" under the hood. It's different in the roles it serves. Your elaboration is appreciated!
Re:“Mostly functional” programming does not work
by metasim on Sunday April 27, 2014 @11:24AM
(#7655415)
It's worth noting that `Option(null)` is `None`. And while it's possible for any reference to be assigned `null`, it rarely happens in Scala code as a) it's well known to be bad form, and b) the IDE's can be configured to yell at you about it. Practically speaking (from the middle), it's not a problem.
Re:“Mostly functional” programming does not work
by GregBuchholz on Sunday April 27, 2014 @10:42AM
(#7655241)
>For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists;
x,y::Integer
x = x + 1
y = undefined
Re:“Mostly functional” programming does not work
by dllthomas on Sunday April 27, 2014 @11:31AM
(#7655444)
That's an important point, but since you can't test for undefined-ness it's not quite the same thing as carrying around something that's actually a Maybe Int but just hopes you'll check before implicitly using fromJust everywhere.
Re:“Mostly functional” programming does not work
by GregBuchholz on Sunday April 27, 2014 @02:00PM
(#7656045)
We just don't want to forget that exceptions and termination are effects, and that Haskell isn't perfectly pure...
a,b::Integer
a = div 1 0
b = sum [1..]
Re:“Mostly functional” programming does not work
by dllthomas on Sunday April 27, 2014 @02:56PM
(#7656261)
Certainly the case.
Re:“Mostly functional” programming does not work
by Dewie on Sunday April 27, 2014 @03:17PM
(#7656356)
If you want to avoid partial functions, I guess you would use Safe Haskell.
Re:“Mostly functional” programming does not work
by dllthomas on Sunday April 27, 2014 @03:35PM
(#7656461)
AFAIK, Safe Haskell doesn't do that. Am I missing something?
Re:“Mostly functional” programming does not work
by Dewie on Monday April 28, 2014 @01:37AM
(#7658365)
You're probably right. I can't find any mention of enforcing total functions.
Same goes for a value of type Employee; if I might or might not have an Employee (for instance, if the lookup function doesn't find someone with that employee number) then I have to use Maybe Employee.
Scala has the same concept with (IIRC) the Option type. But Scala also inherits null references from Java. In Java a reference to an Employee might be an optional value (so null is allowed) or it might be a required value (so null is not allowed). Scala has to play well with Java so anything has to be allowed to be a null reference. Except that Integers in Java (and hence Scala) aren't references, so I can't have a null reference to an Integer.
So now my "Option Employee" might wind up being a null reference to the Option, or it might be an Option that is empty, or it might be an Option that contains a null reference to the Employee, or it might actually have an Employee in it.
Gahh.