Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Functional programming beyond Haskell

Name: Anonymous 2015-02-20 8:36

We have all learned functional programming in Haskell, but there are more functional languages like Lisp, Scheme, ML, and Clean.

Why should we even bother to look further than Haskell?

- You want your programs to run faster.
- Monads drive you mad (what are they anyway? warm fuzzy things?).
- You need objects.
- You sometimes need a more powerful module system.
http://www.cs.uu.nl/wiki/pub/Stc/BeyondFunctionalProgrammingInHaskell:AnIntroductionToOCaml/ocaml.pdf

Name: Anonymous 2015-02-28 15:55

>>94
Yes, seeing things like a + b makes it really hard to understand what is actually going on. Is it... could it possibly be... addition?
It depends. If it's Javascript it's more likely to coerce one or both arguments to string and perform concatenation than it is to perform arithmetic. (If it's C++ god only knows what it's going to do.)

But Javascript is a stupid language, I can't base an argument off that. So, what if we relaxed OCaml's rule in a new language and let it dispatch on type? We have such a language, it's called F#:

> 1 + 2;;
val it : int = 3 // duh

> 1. + 2.;;
val it : float = 3.0 // cool

> "a" + "b";;
val it : string = "ab" // hang on a sec

> let f a b = a + b;;
val f : a:int -> b:int -> int // hey wait I thought + was generic? at least you can't call this on strings.

> 1. + 2;;
1. + 2;;
-----^
.../stdin(14,6): error FS0001: The type 'int' does not match the type 'float' // aw dang


OCaml and F# both treat integer and floating point arithmetic as distinct, as they should, since the underlying machine types behave very differently and these languages aim to address the underlying machine types. But Haskell cares about the distinction too, it just doesn't mind coercing between the types because the machine behaviour is abstracted away:

Prelude> import Data.Bits
Prelude Data.Bits> shiftL 33 4
528
Prelude Data.Bits> shiftL 33.3 4

<interactive>:5:1:
No instance for (Bits a0) arising from a use of `shiftL'
The type variable `a0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Note: there are several potential instances:
instance Bits Int -- Defined in `Data.Bits'
instance Bits Integer -- Defined in `Data.Bits'
instance Bits GHC.Types.Word -- Defined in `Data.Bits'
In the expression: shiftL 33.3 4
In an equation for `it': it = shiftL 33.3 4

<interactive>:5:8:
No instance for (Fractional a0) arising from the literal `33.3'
The type variable `a0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Note: there are several potential instances:
instance Fractional Double -- Defined in `GHC.Float'
instance Fractional Float -- Defined in `GHC.Float'
instance Integral a => Fractional (GHC.Real.Ratio a)
-- Defined in `GHC.Real'
In the first argument of `shiftL', namely `33.3'
In the expression: shiftL 33.3 4
In an equation for `it': it = shiftL 33.3 4


Sort of.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List