Re: Overloaded functions in Ocaml?

"'Mr. Herr' [email protected] [ocaml_beginners]" <[email protected]> Fri, 4 Mar 2016 10:49:15 +0100
Newsgroups gmane.comp.lang.ocaml.beginners
Message-ID <[email protected]>

On 03.03.2016 06:17, Douglas Lewit [email protected] [ocaml_beginners] wrote:
>  
> Thanks everyone for these great answers.  I didn't finish reading the recommended
> article, but the beginning of it looked really interesting.  I'm not working with
> user-defined types in Ocaml yet, but.... that's my next step for sure.  But I have
> done a lot of work with arrays, 2D-arrays, and I love using recursive functions to
> manipulate lists.  Very cool.  Although I don't understand why lists are called
> immutable in Ocaml or any functional language.  If a list is really an immutable or
> "frozen" object ( borrowing a term from Ruby ) then it should be impossible to do
> this:
>
> 1 :: [2; 3; 4; 5] ;;
>
> Unless of course [1; 2; 3; 4; 5] and [2; 3; 4; 5] are two separate lists with
> different memory addresses.  ( And the old list gets garbage collected since a
> variable name no longer references it? )
>
Well, I would say unless the language does not give you any possibility to change the
old "binding" -  in FP we talk about bindings.

For example in scheme:

scheme> (define x 5)
scheme> (define (f y) (+ x y))
scheme> (f 4)
$1 = 9
scheme> (define x 11)
scheme> (f 4)
$2 = 15

The same sequence in ocaml:

# let x = 5;;
val x : int = 5
# let f y = x + y;;
val f : int -> int = <fun>
# f 4;;
- : int = 9
# let x = 11;;
val x : int = 11
# f 4;;
- : int = 9
#

BTW it is questionable trying to understand one language in terms of another, because
some concepts may be very different.

For example, in imperative programming languages the basic building block is a
statement. In FP you don't have
statements, you have expressions.

/Str.

> Sorry if these questions are a little elementary, but I'm still in the learning stages.
>
> Oh yeah, parametric polymorphism looks especially interesting.  I'll have to
> explore that much further.  I like the List.length example.  That function is not
> limited to lists of any one type, but works on lists of all types.  I like that
> example!
>
> Regarding ints and floats, I do recall a linear algebra professor talking about how
> computers are usually pretty good at representing floats near 0.  As you move
> farther and farther out from 0, the distance between adjacent floats actually
> increases.  I think this is really more of a machine epsilon issue than a pure math
> issue.  BUT.... we need floats!  I can't imagine studying any technical discipline
> using only ints.  ( Except maybe discrete math. )
>
>
>