RE: [Caml-list] How much optimized is the 'a option type ?

["Jon Harrop" <jon@ffconsultancy.com>]

Jonathan Kimmitt wrote:
> If you compare this behaviour with the inferior clone F# written by
Microsoft,
> you can see that one of the things they added to the language was a nil
> pointer, thus abandoning all type safety immediately and all because they
> did not want to change their .NET runtime system for C# etc.

F# has a very good FFI to C#. In particular, it is memory safe. F# has null
because it is required for interop with C#. Idiomatic F# code does not use
null. Compare with OCaml's memory-unsafe FFI to C...

> They also have the notion of initialising a typed object to in an invalid
default,
> which is another obvious disaster area.

When you dequeue an element from a mutable queue that is represented
internally as an over-sized array you need to null-out the removed element
or you leak everything reachable from that value that would otherwise be
unreachable. F# uses Unchecked.defaultof<_> to create a default value of any
type (even a value type). The Queue module in the OCaml stdlib uses
"Obj.magic None" which works because OCaml doesn't have value types.

> Oh and did I mention operators like +/- etc are overloaded so you cannot
> infer function types without adding type annotations.

In F# the same arithmetic operators work transparently on the byte, sbyte,
uint16, int16, uint32, int32, uint64, int64, float, float32, BigInteger and
BigRational types as well as decimal, DateTime, vectors, matrices and
user-defined types. OCaml has + for int, +. for float and +/ for big
rationals and no other numeric types. Imagine what would happen if OCaml
supported just the full complement of numeric types, let alone the others?
You'd need 15 different operators just to support the numeric types I
listed...

> The final insult is to make indentation significant in the syntax so that
if
> you post a program to a list which does not respect whitespace (for
> example using a well-known Microsoft mail client), it completely destroys
> the meaning of the program.

I agree. :-)

Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
Behalf Of Jonathan Kimmitt
Sent: 17 January 2014 11:24
To: caml-list@inria.fr
Subject: Re: [Caml-list] How much optimized is the 'a option type ?

In my humble opinion the main purpose of Some _ | None is to avoid the
requirement for a nil pointer in OCaml. If an external function wants to
return nil in order to indicate, for example that a certain resource is not
available, it can return None instead and this prevents dereferencing a nil
pointer in OCaml because the None cannot be dereferenced. If you compare
this behaviour with the inferior clone F# written by Microsoft, you can see
that one of the things they added to the language was a nil pointer, thus
abandoning all type safety immediately and all because they did not want to
change their .NET runtime system for C# etc. They also have the notion of
initialising a typed object to in an invalid default, which is another
obvious disaster area. Oh and did I mention operators like +/- etc are
overloaded so you cannot infer function types without adding type
annotations.
The final insult is to make indentation significant in the syntax so that if
you post a program to a list which does not respect whitespace (for example
using a well-known Microsoft mail client), it completely destroys the
meaning of the program.

I'm sure the authors of F# have their reasons for making all these changes,
and I'm not one to stand in the way of progress, and I don't set out to
offend anybody, but I think they got it wrong ...

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs